Mailinglist Archive: opensuse-de (1985 mails)
| < Previous | Next > |
Re: 2.6er Kernel, /dev-FS ohne /dev/cdrom und gmplayer - Wie macht man es richtig?
- From: Andreas Koenecke <akoenecke@xxxxxxxxxxxx>
- Date: Wed, 1 Feb 2006 16:22:24 +0100
- Message-id: <20060201152224.GA14026@xxxxxxxxxxxxxxxxxx>
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
--
* 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
--
| < Previous | Next > |