Early boot issues (WAS: Christmas list for the kernel)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2005-11-22 at 12:49 -0800, Greg KH wrote:
> On Tue, Nov 22, 2005 at 01:31:16PM -0500, Jon Smirl wrote:
> > 
> > 4) Merge klibc and fix up the driver system so that everything is
> > hotplugable. This means no more need to configure drivers in the
> > kernel, the right drivers will just load automatically.
> 
> What driver subsystem is not hotplugable and does not have automatically
> loaded modules today?
> 
> There are a few issues around PnP devices that I know of, and PCMCIA
> needs some seriously love, but other than that I think we are well off.
> Or am I missing something big here?

Well, there is at least one big problem :) We tend to call hotplug for
new devices way too early during boot, before it's even sane to try to
run userland. For example, we may well try to run it before we
created /dev/null or /dev/zero ... In some cases (PCI on various
platforms typically), devices are instanciated, then all sorts of
necessary fixups are applied, and it's assumed no driver will kick in
before those fixups are finished, etc...

I think it is be rather very unsafe to have /sbin/hotplug be called
before the system finishes with all initcalls...

There is a very similar problem lurking around the corner with
suspend/resume. Since during a machine suspend cycles, from the moment
we start suspending devices to the moment we have finished waking them
all up, any try to run userland things is doomed. The disk may be spun
down & locked, all other processes frozen, etc....

This is actually a real life problem with drivers using the
request_firmware interface nowadays: Some of them call it on resume, but
heh, it's too early, your disk may not be resumed yet ! Some of them
call it at more "normal" times, but in general, drivers have no way to
knwo that a machine suspend/resume cycle is in progress (the disk may
have been suspended already but the that other driver suspend not called
yet).

In fact, there is even a problem with GFP_KERNEL allocations :) In fact,
as soon as the suspend process is started, all allocations should be
silently turned into GFP_NOIO at the very least ...

Ben.