[lkml]   [2005]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectEarly boot issues (WAS: Christmas list for the kernel)
    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

    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 ...


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-23 08:16    [W:0.034 / U:38.852 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site