[lkml]   [2003]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] call drv->shutdown at rmmod
    Russell King <> writes:

    > On Thu, Aug 14, 2003 at 09:50:05AM -0600, Eric W. Biederman wrote:
    > > Russell King <> writes:
    > > > That's likely to remove the keyboard driver, and some people like
    > > > to configure their box so that ctrl-alt-del halts the system, and
    > > > a further ctrl-alt-del reboots the system once halted.
    > >
    > > Hmm. That is a very weird case. Semantically the keyboard driver
    > > and everything else should be removed in any case.
    > I don't view it as "really weird" - it's something I've always done
    > with 2.2 and 2.4, and in fact the first thing I do when I get a machine
    > is to modify the inittab to halt the machine on ctrl-alt-del.
    > It's far safer than hitting ctrl-alt-del and trying to power the machine
    > off at the exact moment it reboots.
    > However, sometimes you want it to reboot, and in this case its far
    > simpler to wait for the machine to halt, and then use ctrl-alt-del
    > again. It's something that's been supported by both the kernel and
    > init for eons.

    This sounds reasonable. Something that needs to happen is we need
    to distinguish clearly, between the semantics of a halt and reboot.

    For a soft reboot to be safe we need to shutdown all of the drivers.

    However what does it mean to call halt?
    There are two possibilities.
    - A frozen in amber state where the kernel just sits in a busy loop,
    and possibly the system is powered off, nothing new can be stared
    but a few remaining things continue on.
    - Everything happens like a reboot except we don't transition to
    any other code.

    So to be clear the cases we have to get semantics straight for are.

    /* This is a reboot and things are fairly clear */

    /* This is the reboot case and it is fairly clear what needs to
    * happen there. Of the two this case is biased towards
    * returning to the firmware if there need to be any differences.

    /* this is the generic halt case and the most confusing.

    /* This is the power off case and similarly confusing. */

    I think my vote goes for a frozen in amber state where the drivers
    do nothing except for the little bit of code in machine_halt or
    machine_power_off, which are practically noops, on x86. And as long
    as input is event interrupt driven you can do something with it.

    I like it because doing absolutely nothing is very much KISS and easy
    to get right.

    > > After device_shutdown is called it is improper for any driver
    > > to be handling interrupts because the are supposed to be in a quiescent
    > > state. And if they are not it is likely to break a soft reboot.
    > I guess then this is another bug we need to add to the list of bugs
    > introduced during 2.5 into 2.6 then...

    If the kernel should just go into some form of busy loop when halt
    is called, I agree that calling device_shutdown on halt is a bug.
    If a halt is just a reboot where we don't do anything afterwards then
    2.6 is correct, and the init example is unsupportable.

    Possibly what is required is another case of sys_reboot so we can have
    both semantics but that feels like over kill.

    > If it is changing, then someone needs to get that information into
    > davej's document.

    I will have to look, I am not up to speed on that one.

    > > Russell do you have any objects to always calling shutdown before
    > > remove? I don't think this looses knowledge and in most cases it should
    > > work, but if there are bus devices were we need to do things significantly
    > > differently I am open to other solutions.
    > The way I'm treating ->shutdown at present is that it is the final call
    > to the device driver. Once this call has been made, the bus driver
    > puts the bus into the correct state for reboot, and the device driver
    > must not attempt to access it.

    I agree with that interpretation of ->shutdown. And that is why
    I contend it is wrong to access the keyboard controller after
    device_shutdown is called. Because device_shutdown calls ->shutdown
    on every device. In that case all ->remove could legitimately do in
    remove is to free the device data structures.

    I think calling ->shutdown, ->remove when a device goes away or when
    we remove the module is compatible with the current semantics of
    ->shutdown. Although we might need to update a driver or two of the
    set that has already implemented a ->shutdown method. But I don't
    think that case is terribly likely to cause problems in practice.

    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-03-22 13:47    [W:0.025 / U:15.952 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site