Linux-Treiber: ioctl oder sysfs?

Question

Linux-Treiber: ioctl oder sysfs?

8

Ich schreibe einen Treiber, um einige benutzerdefinierte Hardware zu steuern.

In den alten Tagen (also vor 15 Jahren) habe ich das mit ioctls gemacht, aber ich forsche jetzt in sysfs als mögliche Alternative.

Wie ich es verstehe, sind ioctls nicht völlig veraltet, aber sysfs wird bevorzugt (?)
Ich muss Sätze von Werten gleichzeitig lesen / schreiben, d. h. durch einen sysfs-Eintrag. Ich habe gelesen, dass dies nicht ideal ist, aber wenn nötig, akzeptabel ist (?)
Der Treiber muss den Schutz " mutex " haben, damit nur eine App gleichzeitig darauf schreiben kann. (Ich habe einige schreibgeschützte 'Info'-Einträge, die ich allen jederzeit zugänglich machen möchte.)

Was wäre nach dem oben Gesagten der beste Weg, um fortzufahren - ioctl oder sysfs?

Wenn sysfs, wie kann ich dann exklusiven Zugriff implementieren?

Wenn sysfs, wenn der Treiber keine Lese- / Schreib- / ioctl-Fops hat, braucht er open / release?!

(Dies ist ein 'privater' Treiber, also interessiert mich das nicht besonders;), aber wenn die neuen Möglichkeiten besser anwendbar sind, dann könnte ich mich auch damit befassen!)

Danke.

linux-device-driver ioctl sysfs

ColH 10.11.2016, 13:53

quelle

1 Antwort

Tags und Links linux-device-driver ioctl sysfs

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Steuern von protokollumgebungsabhängigen Eigenschaften in der Datei mit externen Anwendungseigenschaften

score 8 · Answer 1

Ich werde versuchen, Ihre Frage zumindest teilweise zu beantworten. Fühlen Sie sich frei zu kommentieren, um mich zu bitten, zu erweitern (oder zu verkleinern!)

Zunächst einmal werden ioctls heutzutage nicht mehr als veraltet angesehen, da die Menschen keine besseren Lösungen für alle Probleme gefunden haben, die sie lösen. Von den Menschen wird erwartet, dass sie die ioctl-Schnittstellen disziplinierter definieren und wahrheitsgemäß ausdrücken, was sie in der ioctl-Codierung lesen und schreiben werden, wenn überhaupt möglich. ioctls und sysfs haben unterschiedliche Stärken.
sysfs ist hauptsächlich nützlich, um bestimmte Attribute von Geräten dem Benutzerbereich auszusetzen, insbesondere einem Benutzer auf der Konsole oder einem Shell-Skript, und diese Attribute oder die Gerätekonfiguration ändern zu lassen. Eine einzelne sysfs-Datei wird normalerweise einem einzelnen Attribut zugeordnet und ist normalerweise lesbar (und / oder schreibbar) als einfache Textzeichenfolge. Beispielsweise könnte der aktuelle Energieverwaltungsstatus eines Geräts (z. B. "Aus") verfügbar sein und Sie könnten mit dem Shell-Befehl "cat" ein neues Schreiben erstellen.
sysfs ist in der Tat nicht an eine open / release Sitzung gebunden (und Sie sollten diese nicht implementieren müssen), so dass es wahrscheinlich nur für globale Attribute geeignet ist. Sollte kein Problem sein, wenn der Benutzer nur eine einzelne Operation auf dem Gerät zu einem Zeitpunkt durchführen soll, aber es schwieriger zu erzwingen (also wahrscheinlich nicht ideal für Ihre "Datensätze gleichzeitig"), es sei denn, Sie kodieren sie alle in eine Zeichenfolge). Und ja, Sie möchten alle Treiberdaten, auf die Sie von Ihren sysfs-Handlern zugreifen, mit Mutexen schützen, wahrscheinlich einen Mutex pro logischen Datensatz (oder einen für mehrere logische Sätze).
ioctl ist besser geeignet, um binäre Informationen zwischen Benutzer-Space und dem Treiber zu übergeben, und benötigt ein C-Programm oder ähnliches, um es zu benutzen. Benutzerdefinierte ioctls sind gut geeignet, um einen minimalen Treiber in den Kernel zu schreiben und Logik in ein passendes User-Space-Programm zu packen. Im Gegensatz zu sysfs benötigt es keine zusätzliche Logik zum Interpretieren von Textstrings - es kann Daten direkt aus dem Prozessspeicher des Benutzers lesen und schreiben - was weniger unnötigen Code bedeutet, aber auch mehr Möglichkeiten, die Daten nicht sicher zu überprüfen.