Treiber laden und Device umbenennen über udev?
Hallo Liste, ich suche seit 2 Tagen nach der Möglichkeit, für einen USB-Barcodescanner den usb-serial Treiber zu laden und dem entstehenden Device einen bestimmten (persistenten) Namen zuzuweisen. Nach dem Studium diverser Google-Tips bin ich immerhin schon mal so weit gekommen, den Treiber selbst mit modprobe usbserial 080c 0400 zu starten, nachdem ich vorher den acm-Treiber entladen habe, der unerwünscht für den Scanner geladen wird, weil der eine USB-Class 2 (Modem) angibt. Dann wird mir ein ttyUSB0 erstellt, das auch den gewünschten Zweck erfüllt (ich kann die Schnittstelle mit minicom öffnet und dann bewundern, was den Scanner an Barcodes erkennt). Das habe ich auch soweit (als Aufruf von einem kurzen Script) in eine udev-Regel eingebunden - ziemlich weit vorne (15xxx) in Abhängigkeit von einem Event mit der VendorId und ProductId. Meine Herausforderung ist nun aber, dass ich für diesen speziellen Scanner auch einen festen Devicenamen haben muss. Nur: Wenn ich als weitere udev-Regel nach des Scripts mit denselben Kriterien versuche, einen Symlink anzulegen, passiert gar nichts. Die Frage ist nun: kann man über udev den richtigen Treiber laden UND das Device umbenennen? Wenn ja, dann wie? Ich habe auch mal mknode im Script hinter dem modeprobe ausprobiert. Nur: woher weiß ich die Major no, - die war bisher 188, aber das könnte sich mit der Reihenfolge von USB-Geräten ja auch mal ändern? Dank im Voraus fü Eure Antworten :-) Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Martin, On Friday 12 September 2008 23:32:17 Martin Hofius wrote:
Hallo Liste, ich suche seit 2 Tagen nach der Möglichkeit, für einen USB-Barcodescanner den usb-serial Treiber zu laden und dem entstehenden Device einen bestimmten (persistenten) Namen zuzuweisen.
Nach dem Studium diverser Google-Tips bin ich immerhin schon mal so weit gekommen, den Treiber selbst mit modprobe usbserial 080c 0400 zu starten, nachdem ich vorher den acm-Treiber entladen habe, der unerwünscht für den Scanner geladen wird, weil der eine USB-Class 2 (Modem) angibt. Dann wird mir ein ttyUSB0 erstellt, das auch den gewünschten Zweck erfüllt (ich kann die Schnittstelle mit minicom öffnet und dann bewundern, was den Scanner an Barcodes erkennt).
Die Treiber werden schon beim Booten geladen, bevor udev zum Tragen kommt. Bei mehreren gleichartigen Devices kann sich dadurch die Reihenfolge der Gerätenamen (Devicenummern) verändern, je nachdem, welche Treiber und welche Geräte in welcher Reihenfolge antworten. Abhilfe schaffst Du dadurch, daß Du die betroffenen Treiber (auch den, den Du benutzen möchtest) in die Blacklist aufnimmst (/etc/modules.d/blacklist). Die Reihenfolge, in der die Treiber manuell geladen werden, hängt von der Datei /etc/modprobe.conf und den Dateien unter /etc/modprobe.d/ ab. Da kannst Du dann eine Datei z.B. Barcode anlegen und den richtigen Treiber eintragen (options dein_Treiber index=??). Beim Index würde ich eine hohe Nummer >> aller usb-devises versuchen (hab ich noch nicht getestet. ob das so funktioniert).
Das habe ich auch soweit (als Aufruf von einem kurzen Script) in eine udev-Regel eingebunden - ziemlich weit vorne (15xxx) in Abhängigkeit von einem Event mit der VendorId und ProductId.
Meine Herausforderung ist nun aber, dass ich für diesen speziellen Scanner auch einen festen Devicenamen haben muss. Nur: Wenn ich als weitere udev-Regel nach des Scripts mit denselben Kriterien versuche, einen Symlink anzulegen, passiert gar nichts.
Nun noch unter /etc/udev/rules.d eine neue Datei erstellen. Zum Beispiel "10- Barcodescanner.rules" oder deine vorhandene 15xxx verwenden. Da trägst Du nun eine passende Regel ein, wohin dein Barcodescanner eingehängt werden soll. Mit lsusb und udevinfo mußt Du dir die Informationen suchen, um die passende Regel zu erstellen. Passt deine Regel, funktioniert dann auch das Anlegen des Symlinks. Der Eintrag als bestimmte Devicenummer funktioniert in udev nicht, da diese schon beim Laden des Treibers vergeben wird. Versuche es doch mal mit /dev/barcode. Auch wenn es nicht auf Anhieb klappt, sollte der Weg annährend richtig sein.
Die Frage ist nun: kann man über udev den richtigen Treiber laden UND das Device umbenennen? Wenn ja, dann wie?
Ich habe auch mal mknode im Script hinter dem modeprobe ausprobiert. Nur: woher weiß ich die Major no, - die war bisher 188, aber das könnte sich mit der Reihenfolge von USB-Geräten ja auch mal ändern?
Dank im Voraus fü Eure Antworten :-)
Gern geschehen, ich hoffe ich konnte Dir helfen. Die Suche nach diesen Informationen hatte mich viel Zeit gekostet, als ich Probleme mit der Zuordnung von Soundkarten hatte, die auch immer wieder in unterschiedlicher Reihenfolge geladen wurden. Viele Grüße Klaus -- Have a nice day ;-) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 13. September 2008 schrieb Klaus Rehberg:
Hallo Martin,
On Friday 12 September 2008 23:32:17 Martin Hofius wrote: ...> Die Treiber werden schon beim Booten geladen, bevor udev zum Tragen kommt. Bei mehreren gleichartigen Devices kann sich dadurch die Reihenfolge der Gerätenamen (Devicenummern) verändern, je nachdem, welche Treiber und welche Geräte in welcher Reihenfolge antworten. Nun ja, eigentlich wollte ich die passenden Treiber erst auf Anforderung - sprich beim Einstecken des Scanners (und der restlichen Geräte) - laden. Allerdings werden im normalen Betrieb später die Geräte sowieso schon beim Booten eingesteckt sein...
Abhilfe schaffst Du dadurch, daß Du die betroffenen Treiber (auch den, den Du benutzen möchtest) in die Blacklist aufnimmst (/etc/modules.d/blacklist). Danke, das ist glaube ich schon mal ein entscheidender Tipp!
Die Reihenfolge, in der die Treiber manuell geladen werden, hängt von der Datei /etc/modprobe.conf und den Dateien unter /etc/modprobe.d/ ab. Die hatte ich auch schon inspiziert, aber irgendwie doch noch nicht so ganz verstanden.
Da kannst Du dann eine Datei z.B. Barcode anlegen und den richtigen Treiber eintragen (options dein_Treiber index=??).
Beim Index würde ich eine hohe Nummer >> aller usb-devises versuchen (hab ich noch nicht getestet. ob das so funktioniert). Was bedeutet dieser Index?
...
Da trägst Du nun eine passende Regel ein, wohin dein Barcodescanner eingehängt werden soll.
Mit lsusb und udevinfo mußt Du dir die Informationen suchen, um die passende Regel zu erstellen. Passt deine Regel, funktioniert dann auch das Anlegen des Symlinks.
Das ist mein Problem, dass ich bei allen Versuchen mit irgendwelchen Daten aus diesen Informationen keine Zuordnung gefunden habe - zumindest nicht beim Anlegen des Symlinks. Aber vielleicht ist daran ja auch tatsächlich mein eigenes Script schuld, das den Treiber zuerst entlädt und dann wieder neu lädt, unmittelbar vor der Regel mit den Symlinks.
Der Eintrag als bestimmte Devicenummer funktioniert in udev nicht, da diese schon beim Laden des Treibers vergeben wird. Versuche es doch mal mit /dev/barcode. Ähmmm genau das wollte ich auch eigentlich bewirken. Nur war mir bisher noch nicht so ganz klar, wie ich denn den Symblink mit dem Namen /dev/barcode genau dem Treiber hinter der passenden Majo-Nummer zuordne, wenn ich diese nicht kenne. Oder reicht da schon in der udev-Regel die Filterangabe mit der Vendor- und ProductId?
...
Gern geschehen, ich hoffe ich konnte Dir helfen. Die Suche nach diesen Informationen hatte mich viel Zeit gekostet, als ich Probleme mit der Zuordnung von Soundkarten hatte, die auch immer wieder in unterschiedlicher Reihenfolge geladen wurden.
Ja, danke! Ich kann noch nicht behaupten, alles verstanden zu haben (kann es auch erst Montag wieder ausprobieren), aber vielleicht bringt mich das schon etwas weiter. Ich habe dann auch noch eine kleine weitere Herausforderung, die aber nicht direkt etwas mit Suse zu tun hat: ich muß es dann auch mit Debian irgdnwie hinbekommen - allerdings sahen mir die udev-Regeln und das Treiber Gestrüpp so ähnlich aus, dass ich doch erstmal mit SuSE anfangen wollte, bevor ich mir die etwas spröde Oberfläche von Debian antue... Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Saturday 13 September 2008 12:04:52 Martin Hofius wrote:
Am Samstag, 13. September 2008 schrieb Klaus Rehberg:
Hallo Martin,
On Friday 12 September 2008 23:32:17 Martin Hofius wrote:
...>
Die Treiber werden schon beim Booten geladen, bevor udev zum Tragen kommt. Bei mehreren gleichartigen Devices kann sich dadurch die Reihenfolge der Gerätenamen (Devicenummern) verändern, je nachdem, welche Treiber und welche Geräte in welcher Reihenfolge antworten.
Nun ja, eigentlich wollte ich die passenden Treiber erst auf Anforderung - sprich beim Einstecken des Scanners (und der restlichen Geräte) - laden. Allerdings werden im normalen Betrieb später die Geräte sowieso schon beim Booten eingesteckt sein...
Mit einer passenden udev Regel sollte das auch bei späterem Anschluß funktionieren (glaube ich wenigstens).
Da kannst Du dann eine Datei z.B. Barcode anlegen und den richtigen Treiber eintragen (options dein_Treiber index=??).
Beim Index würde ich eine hohe Nummer >> aller usb-devises versuchen (hab ich noch nicht getestet. ob das so funktioniert).
Was bedeutet dieser Index?
Der Index gibt die Reihenfolge an z.B. bei den Soundkarten wird dann die Karte mit dem Index 0 die /dev /dsp, die mit Index 1 dann /dev/dsp1 usw. .
Der Eintrag als bestimmte Devicenummer funktioniert in udev nicht, da diese schon beim Laden des Treibers vergeben wird. Versuche es doch mal mit /dev/barcode.
Ähmmm genau das wollte ich auch eigentlich bewirken. Nur war mir bisher noch nicht so ganz klar, wie ich denn den Symblink mit dem Namen /dev/barcode genau dem Treiber hinter der passenden Majo-Nummer zuordne, wenn ich diese nicht kenne. Oder reicht da schon in der udev-Regel die Filterangabe mit der Vendor- und ProductId?
Ja, das war auch mein Hauptproblem, eine passende udev-Regel zu finden, die dann auch das gewünschte macht. Mit udevinfo solltest Du etwas passendes finden.
Ja, danke! Ich kann noch nicht behaupten, alles verstanden zu haben
Kann ich auch nicht, hab halt mit - try and error - getestet, da mir damals auch Goog.. nicht wirklich geholfen hat.
(kann es auch erst Montag wieder ausprobieren), aber vielleicht bringt mich das schon etwas weiter.
Viel Erfolg und viele Grüße Klaus -- Have a nice day ;-) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Klaus, ich habe jetzt so langsam eine funktionierende Konfiguration - wenn auch mit Debian (weil der Kunde es so wollte), aber der Mechanismus scheint übereinzustimmen: Am Samstag, 13. September 2008 schrieb Klaus Rehberg:
On Saturday 13 September 2008 12:04:52 Martin Hofius wrote:
Am Samstag, 13. September 2008 schrieb Klaus Rehberg:
Hallo Martin,
On Friday 12 September 2008 23:32:17 Martin Hofius wrote:
...> ... Nun ja, eigentlich wollte ich die passenden Treiber erst auf Anforderung - sprich beim Einstecken des Scanners (und der restlichen Geräte) - laden. Allerdings werden im normalen Betrieb später die Geräte sowieso schon beim Booten eingesteckt sein...
Mit einer passenden udev Regel sollte das auch bei späterem Anschluß funktionieren (glaube ich wenigstens). Das mit der blacklist war der entscheidende Tip für den Scanner - das modprobe zum Laden des Treibers mußte ich dann wirklich in einer udev-Regel aufrufen, weil sonst der Treiber gar nicht geladen wurde. Die ganzen modprobe.conf Einstellungen scheinen nur Einstellungen für modprobe zu sein - aufgerufen wird damit überhaupt nichts automatisch.
Da kannst Du dann eine Datei z.B. Barcode anlegen und den richtigen Treiber eintragen (options dein_Treiber index=??). Siehe oben - die optionen könnte ich da eintragen, aber das modprobe müßte ichsowieso von Hand (oder per udev) anstoßen. ... Was bedeutet dieser Index?
Der Index gibt die Reihenfolge an z.B. bei den Soundkarten wird dann die Karte mit dem Index 0 die /dev /dsp, die mit Index 1 dann /dev/dsp1 usw. . Ich habe den Index schlussendlich gebraucht - eine passende Regel in udev (mit VendorId und ProductId hat mir das jeweils richtige Device gebracht und die interne Gerätenummer interessiert nicht wirklich.
Der Eintrag als bestimmte Devicenummer funktioniert in udev nicht, da diese schon beim Laden des Treibers vergeben wird. Versuche es doch mal mit /dev/barcode. siehe oben
Ja, das war auch mein Hauptproblem, eine passende udev-Regel zu finden, die dann auch das gewünschte macht. Mit udevinfo solltest Du etwas passendes finden.
Ja, danke! Ich kann noch nicht behaupten, alles verstanden zu haben
Kann ich auch nicht, hab halt mit - try and error - getestet, da mir damals auch Goog.. nicht wirklich geholfen hat. Ich habe es immer noch nicht ganz verstanden - für den Barcodescanner und ein weiteres Gerät brauchte ich die blacklist und mußte per udev und Script die Treiber dann auf Anforderung laden (und dann in einer darauf folgenden Regel einen Symlink erstellen). Für einen Touchscreen war es wiederum notwendig, die nicht in der richtigen Reihenfolge geladenen Treiber dafür (hid...) in einem runlevel-Script zu entladen und anschließend neu zu laden - da half keine blacklist und auch keine udev-Regel...
Trotzdem Danke - die Tipps haben mich schon weitergebracht und es läuft jetzt alles ;-) Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Mit, 17 Sep 2008, Martin Hofius schrieb:
Das mit der blacklist war der entscheidende Tip für den Scanner - das modprobe zum Laden des Treibers mußte ich dann wirklich in einer udev-Regel aufrufen, weil sonst der Treiber gar nicht geladen wurde. Die ganzen modprobe.conf Einstellungen scheinen nur Einstellungen für modprobe zu sein - aufgerufen wird damit überhaupt nichts automatisch.
Teilweise kann man wohl nach wie vor Devices an Module knüpfen (wie bei Kernel <= 2.4). Aber der ganze udev Kram stört. alias TYP-major-MAJOR[-MINOR] MODUL [..]
Für einen Touchscreen war es wiederum notwendig, die nicht in der richtigen Reihenfolge geladenen Treiber dafür (hid...) in einem runlevel-Script zu entladen und anschließend neu zu laden - da half keine blacklist und auch keine udev-Regel...
Da hilft eine Abhängigkeit (Kernel <= 2.4) oder eine install-Regel (Kernel >= 2.5): ==== $ echo 'below foo bar' | ./modprobe_gen ==== ### below foo bar install foo {\ /sbin/modprobe bar;\ }; /sbin/modprobe --ignore-install foo remove foo /sbin/modprobe --ignore-remove --remove foo && {\ /sbin/modprobe --remove bar;\ } ==== Das AWK-script modprobe_gen habe ich mir geschrieben, um die bequemen "above"/"below" Befehle der <= 2.4 modules.conf in die install-Konstrukte der modprobe.conf zu übersetzen. Die Regeln "simulieren" Abhängigkeiten unter den Modulen, wenn die Abhängigkeiten nicht "automatisch" definiert sind. Z.B. kann das SCSI-Disk/CDROM/Generic Modul auf viele SCSI-Controller aufsetzen, welcher der vielen Treiber zu laden ist, kann man prima via "below" definieren. Ich habe (hatte) hier u.a.: below sd_mod sata_sil below sr_mod ide-scsi below sg g_NCR5380 ide-scsi Oder eben über entsprechende install-Regeln in der modprobe.conf (bzw. einer von dieser eingebundenen Datei). Die "below" Regel (bzw. deren Übersetzung, s.o.) sorgt dafür, daß das Modul bar "below" foo vor foo geladen wird. Wenn z.B. hid_aaa immer vor hid_zzz geladen werden soll, schreibe das folgende in eine passende Datei unter /etc/modprobe.d/ ==== ### below hid_zzz hid_aaa install hid_zzz {\ /sbin/modprobe hid_aaa;\ }; /sbin/modprobe --ignore-install hid_zzz remove hid_zzz /sbin/modprobe --ignore-remove --remove hid_zzz && {\ /sbin/modprobe --remove hid_aaa;\ } ==== und künftig wird jedesmal, wenn hid_zzz geladen wird, vorher hid_aaa geladen. Ob und wann hid_zzz geladen wird, wird "normal" via udev oder "bei Devicezugriff" (über die alias Definitionen, s.o.) geregelt, wobei ich bei letzterem nicht sicher bin, ob das immer noch so klappt. Das ganze ist das Thema, das mich an Kernel >= 2.5 und modernen Distris so ziemlich am meisten stört... HTH, -dnh, der Kernel 2.4.x verwendet, und bei dem Module automagisch erst beim Zugriff auf das jew. Device geladen werden, z.B. die ganzen Module für v4l, für SCSI, u.a.m... Ohne Zugriffe ist die Ausgabe von lsmod äußerst übersichtlich: # lsmod Module Size Used by Not tainted # Allerdings sind hier normal mind. die Sound- und Firewall-Module geladen, und erstere lassen sich auch nicht mehr entladen (die Soundkarte ist ne ISA-Karte von 1994 oder so ;) Jedenfalls werden die Module erst bei Bedarf und (bis auf ipt_conntrack*) vollautomatisch geladen. Und nein, mit ner opensuse geht das nicht out-of-the-box, da ein distri-Kernel einiges notwendige nur als Modul mitbringt (Festplattentreiber z.B.) -- 91: Emacs Eight Megabytes And Continously Swapping -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
David Haller -
Klaus Rehberg -
Martin Hofius