On Sun, 7 Dec 2008 18:39:48 +0100 "Kay Sievers" <kay.sievers@xxxxxxxx> wrote: > On Sun, Dec 7, 2008 at 18:28, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > >> > /dev/console is a logical mapping to a device which may well be > >> > different, loaded after PCI is initialised and dependant on PCI. > >> > >> So wrong. If no driver is associated, like early, in that case, we > >> must return -ENODEV, instead of calling modprobe in a loop. It's a > >> built-in device, and it's easy to fix. > > > > You've clearly no idea how initrd even works have you ? > > Not sure, if you understand the real problem. A kernel forked binary > is allowed to access /dev/console, but it triggers a kernel bug. If there is a hotplug load for the console device then it cannot. Just as a request for the driver for /dev/hda cannot open /dev/hda* again. > Nonsense. The kernel calls /sbin/modprobe directly, no hotplug involved. Its up to you if the kernel calls modprobe and what your modprobe is > The kernel calls modprobe for something, modprobe tries to log an > error, and the kernel calls modprobe again. Bug! No hotplug involved. A modprobe to load the console device shouln't open /dev/console. Very simple and always been true. > > Kernel issues hotplug message > > ..... > > Kernel detects this is stuck > > Kernel replies with -ENODEV/-ENXIO to try > > and rescue itself from buggy initrd scripts > > Totally wrong, It never was that way Funny but its been that way for many many years. Just as it cannot try and syslog an error when loading the AF_UNIX socket family. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
