Hallo. * Mittwoch, 01. Februar 2006 um 05:16 (+0100) schrieb David Haller:
Am Wed, 01 Feb 2006, Andreas Koenecke schrieb:
Das ist bei dir doch noch übersichtlich, hier (SUSE 10.0):
kocom:~ # ls /dev | wc -l 7556
aber das reicht noch nicht:
kocom:~ # ls -R /dev | wc -l 14859
*UARGS* Das ist uebel! Was zum Geier muellt dir dein /dev/ so zu?
Allein 20 "hd?" mit je 64 möglichen Partitionen sind schon 1280 Einträge und so geht das munter weiter...
Ich denke, es geht dabei weniger um den Platzbedarf als um die Übersichtlichkeit in /dev/.
Das wurde ja schon durch die Unterverzeichnisse gehandhabt, vgl. /dev/usb/ und /dev/pts/ z.B. und das ganz ohne devfs/udev.
Aber ein konsequenter Einsatz von Unterverzeichnissen in /dev/ müsste von allen Programmen unterstützt werden. Das kann dauern. Und in der "Übergangszeit" müssen dann doch Symlinks von /dev/ nach /dev/Unterverzeichnis/ angelegt werden.
In proc geht's doch auch.
IMHO hat /proc/ aber auch eine andere Historie: /proc/ war schon immer hierarchisch organisiert, /dev/ nicht.
Na gut, dann doch das Beispiel mit 2. Scanner oder externem SCSI-CD-Brenner am SCSI-Bus... ;-)
Wird nach SCSI BUS-ID-LUN einsortiert. Odr?[0] Ich hab hier zuwenig SCSI Kram.
Ja, aber es kommt halt darauf an, welches der externen Geräte eingeschaltet ist und in welcher Reihenfolge die Busse gescannt werden. Ein Grund, warum ich einem Mechanismus wie udev positiv gegenüberstehe, ist, dass ich ein "gebranntes Kind" bin: Ich hatte hier mal ein reines (gewachsenes) SCSI-System: in der letzten Ausbaustufe 2 SCSI-Controller, 4 Festplatten, 2 interne CD-Roms, 1 externe CD-Brenner und 1 Scanner. Ein Problem war, dass ich mir um die Vergabe nicht ausreichend Gedanken gemacht habe (Ja, ich weiss: Selbst schuld!), so dass ich bei jedem Booten darauf achten musste, dass sowohl Scanner als auch externer CD-Brenner eingeschaltet sein mussten, sonst gerieten die "cdrom?"-Symlinks auf scd? und der "scanner"-Symlink auf sg? völlig durcheinander. Ein weiteres Problem waren die Treiber-Module: Beide Controller waren NCR/Symbios Logic-Karten, 1x FAST-SCSI und 1x UW-SCSI. Im Laufe ihres Lebens wurden sie von verschiedenen Treibern bedient: Mal jede Karte ein eigener Treiber, mal ein gemeinsamer Treiber und dann mal wieder 2 eigene Treiber usw. Die Treiber waren fest im Kernel und eine Kernel-Version hat zuerst den FAST-SCSI-Karte und die andere Kernel-Version zuerst den UW-SCSI-Karte erkannt. Oder der gemeinsame Treiber hat je nach Version gerne mal die eine Karte "nach vorne" gebracht, mal die andere... Ging alles, aber so richtig schön war das nicht...
Und ansonsten hilft ein kl. shell-script mit z.B. 'sgcheck', 'awk' und 'ln -s /dev/sgX /dev/scanner/MODEL'. Ja, ist nicht so elegant wie udev, loest das Problem aber ebenfalls und das _ohne_ Aenderungen am Kernel.
Warte mal, was ändert denn udev am Kernel?
Zum Beispiel liesse sich als "post-install" von 'sg' folgendes fuer meinen Brenner ausfuehren:
sgcheck | awk '/^\/.*DVDRAM/{print "ln -sf "$1" /dev/BRENNER/"$NF;}' ln -sf /dev/sg0 /dev/BRENNER/GSA-4163B
Ist das wirklich anschaulicher/weniger komplex/übersichtlicher als eine udev-Regel wie z.B. SUBSYSTEM=="block", ENV{ID_MODEL}=="*DVDRAM*", SYMLINK+="dvdram cdrecorder \ dvdrecorder"
Ich seh bei solch einfachen Loesungen einfach keine Notwendigkeit gross am Kernel rumzuschrauben.
?
Versteh' mich nicht falsch, fuer USB und so Zeugs mag das ja gut sein, aber dafuer reicht sowas wie hotplug/usbdevfs.
Naja, die "alten" hotplug-Agents und -Skripte waren ja noch unübersichtlicher und komlexer als udev. Da ist udev IMO wesentlich übersichtlicher und stringenter.
Da muss man nicht gleich das ganze /dev/ umkrempeln.
IIRC hätte man /dev/ mittelfristig sowieso "umgekrempelt": Entweder devfs oder eben ein Userspace-Lösung wie udev.
*hurhur* Justiere mal deinen Zynismusdetektor. Das Fragezeichen oben expandiert zu: " hat es nicht anders verdient. *MUAHAHAHAHA*"
:-)
Aber OK, das Beispiel ist vielleicht sehr konstruiert.
Ja.
Aber siehe meine "Leidensgeschichte" oben...
Hm, wie wäre es mit dem User-tauglichen "Ich habe mir eine weitere Netzwerkkarte (mit gleichem Chipsatz) für meinen DSL-Rechner eingebaut, um dem Rechner meiner Frau den Internetzugang zu ermöglichen und jetzt geht gar kein Internet mehr." (Das kommt aber häufig vor...)
Da hilft die MAC zusammen mit PERSISTENT_NAME in /etc/sysconfig/network/ifcfg-eth-id* -- oder so, IIRC.
Wobei das aber AFAIK mit udev realisiert wird. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --