2016-06-15 8 views
0

schreibe ich derzeit ein Treibermodul, das einige Einträge in den sysfs bietet. Ich lese viel durch den Quellbaum des Treibers und das Internet. Ich habe zwei Approches gefunden, in denen die sysfs_create_group() aufgerufen wird:sysfs_create_group(): Wo anrufen?

a) am häufigsten: In der Funktion sonde() des Treibers. Wie hier adviced How to attach file operations to sysfs attribute in platform driver?

Zufall Ding sah ich an: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/rtc-ds1307.c#n1580

b) In der Treiber-Struktur. http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

Ich weiß, Greg KH ist ein sehr bekannter Entwickler. Also habe ich versucht seinem Rat zu folgen. In den bla_show()/bla_store() Funktionen habe ich versucht, meine Driver private Daten zu bekommen, aber meine printk()'s zeigten sehr unterschiedliche Adressen als ich in der Probe() Funktion ausgedruckt habe. Meine privaten Daten sind (null). Was ist falsch?

Wenn ich appch a) es funktioniert wie erwartet, aber wie Greg KH schlägt es auch falsch ist. Ich sehe es oft im Stallbaum bei verschiedenen Fahrern. Greg schreibt, der Userspace hat bereits die Benachrichtigung erhalten, dass es ein neues Gerät gibt, aber das LDD3-Buch gibt an, dass die Testfunktion vorhanden ist, um festzustellen, ob das Gerät vorhanden ist.

meine Frage Fazit:

  1. Warum die User-Space darüber benachrichtigt, selbst dann, wenn der Kernel tut wissen, ob es damit umgehen kann?
  2. Wo ist der richtige Ort, um sysfs_create_group() aufzurufen? Ist es a) oder b)?

LDD3: https://static.lwn.net/images/pdf/LDD3/ch14.pdf PDF Seite 24

Sonde ist eine Funktion namens die Existenz eines bestimmten Gerätes abzufragen (und ob diese Fahrer können damit arbeiten), entfernen wird aufgerufen, wenn die Gerät wird aus dem System entfernt, und Herunterfahren wird beim Herunterfahren Zeit zum Stilllegen des Geräts aufgerufen.

Ich bin verwirrter als vorher .....

Mit freundlichen Grüßen Georg

Antwort

3

A Gerätetreiber ist ein Programm, das eine bestimmte Art von Gerät steuert, die an den Computer angeschlossen ist, .

Plattformgeräte sind von Natur aus nicht erkennbar, d. H. Die Hardware kann nicht sagen "Hey! Ich bin anwesend!" zur Software. Für diese Art von Gerät benötigen wir einen Treiber, der als Plattformtreiber bezeichnet wird. Die Treiber stellen die Methoden test() und remove() zur Verfügung.

struct platform_driver { 
    int (*probe)(struct platform_device *); 
    int (*remove)(struct platform_device *); 
    . 
    . 
    struct device_driver driver;// this file has 2 parameter name or owner. 
}; 

Sonde() im Allgemeinen sollte überprüfen, ob die angegebene Gerät Hardware tatsächlich vorhanden ist. Zuerst registrieren wir unseren Fahrer. Sobald das Gerät gefunden wurde, ruft es die Treibersonde auf. Es verwendet den Namen zum Suchen eines Geräts.


Am: Ihr Gerät verfügbar ist, dann müssen Sie sysfs Eintrag für Kommunikation (zum Benutzerraum). so konzeptionell müssen Sie Ihren sysfs-Eintrag in Probe definieren.

sys_notify Funktion auf Ihrem Attribut und es wird Ihren Userspace-Code aufwachen. Es wird ausgelöst, wenn sysfs für den Benutzerbereich verfügbar ist. Es vermeidet nur einen blockierenden Anruf. Wenn der Kernel keine sysfs hat, wird der Benutzerbereich nicht benachrichtigt.

sysfs ist ein vom Linux-Kernel bereitgestelltes virtuelles Dateisystem, das Informationen über verschiedene Kernelsubsysteme, Hardwaregeräte und zugehörige Gerätetreiber vom Gerätemodell des Kernels über virtuelle Dateien in den Benutzerbereich exportiert. Wenn Ihr Gerät verfügbar ist, benötigen Sie diesen Eintrag, um Ihre Informationen zu exportieren.