Raphael H. Becker wrote:
> Ob das Kind jetzt devfs heisst oder irgendwie anders: Mir
> ging es um den Unterschied zwischen der Loesung und einem
> Workaround. Wenn mknod tatsaechlich die LOeSUNG ist, dann will
> ich das ja garnicht infragestellen, lediglich mein Erstaunen,
> dass auf aktuellen Systemen damit noch gearbytet wird.
/dev/console ist da ein Spezialfall. Der Kernel selber oeffnet
/dev/console, noch bevor irgend ein Userspace die Chance hatte zu
laufen, also vor /sbin/init und den Startskripten. Wenn man also udev
verwendet oder devfs von einem Startskript mounten laesst, dann muss
/dev/console im Root-Dateisystem (sei das nun ein HDD-Dateisystem, eine
initrd oder ein initramfs) vorhanden sein, bevor der Kernel gestartet
wird, sprich es muss bei der Installation bzw. beim Erstellen der initrd
/ des initramfs per mknod angelegt werden. Wenn devfs vom Kernel
gemountet wird (CONFIG_FS_DEVFS_MOUNT oder so aehnlich), dann sorgt devfs
fuer das Erzeugen von /dev/console.
Warum der Kernel ueberhaupt die Datei /dev/console oeffnet und das ganze
nicht einfach "intern" regelt, hat aber so richtig noch niemand
vernuenftig erklaeren koennen.
Ein zweiter Kandidat ist uebrigens /dev/null, denn viele Startskripte
verwenden Umleitungen nach /dev/null, um Ausgaben zu unterdruecken, auch
Skripte, die eventuell vor dem Mounten von devfs bzw. vor dem Start von
udev laufen.
BTW: udev macht auch nichts anderes, als fuer jedes gefundene Geraete
mknod aufzurufen (-; Allerdings nicht das Programm sondern die
Bibliotheksfunktion gleichen Namens.
jwm