[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081207175118.09c633e8@lxorguk.ukuu.org.uk>
Date: Sun, 7 Dec 2008 17:51:18 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: "Kay Sievers" <kay.sievers@...y.org>
Cc: "Evgeniy Polyakov" <zbr@...emap.net>,
"Herbert Xu" <herbert@...dor.apana.org.au>,
linux-kernel@...r.kernel.org,
"Linux Crypto Mailing List" <linux-crypto@...r.kernel.org>
Subject: Re: Runaway loop with the current git.
On Sun, 7 Dec 2008 18:39:48 +0100
"Kay Sievers" <kay.sievers@...y.org> wrote:
> On Sun, Dec 7, 2008 at 18:28, Alan Cox <alan@...rguk.ukuu.org.uk> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists