[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081207150856.7c0aed6a@lxorguk.ukuu.org.uk>
Date: Sun, 7 Dec 2008 15:08:56 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: "Kay Sievers" <kay.sievers@...y.org>
Cc: "Evgeniy Polyakov" <zbr@...emap.net>, linux-kernel@...r.kernel.org
Subject: Re: Runaway loop with the current git.
> No, we have not. It is fine for modprobe doing that, as it is for any
> other binary too. It's also the usual glibc behavior for syslog(). Any
> userspace binary can access /dev/console any time. The kernel is not
> supposed to call modprobe to make /dev/console availabe.
Yes it is. The hotplug interface is designed to handle dynamic loading of
devices including the console. Likewise your hard disk interfaces you can
access at any time - guess what, those need loading too and if you put
your modprobe on a disk you've not got a driver loaded for that doesn't
work either.
> We are not reordering, we provide a registered /dev/console driver
> core device, not touching any driver, just to prevent the kernel
> module loader from going crazy.
You are reordering things.
The kernel module loader isn't going crazy either. The kernel module
loader is doings its job. The userspace then goes silly and the kernel
module loader correctly traps the problem, logs an error and tries to
continue things, but the initrd is it seems too broken to handle that
anyway.
Note that last small rather important detail - the kernel does detect
runaway modprobe loops already.
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