Subject: Re: The right place for doshutdownhooks()
To: None <>
From: Greg Hudson <ghudson@MIT.EDU>
List: tech-kern
Date: 11/20/1995 00:49:37
Perry wrote:
> If my floppy drive has been spinning for an hour, thats clearly not
> acceptable. There is no way to know how long it will take for the
> user to hit a key, by which time the damage may have been long since
> done. All sorts of things can have been left in bad states.

> What would the point of shutting down the console driver only to
> have the machine reboot again in a moment be? The answer to this
> question is simple -- don't shut down the console driver with
> shutdown hooks on ports that go into a loop in order to fake a halt.

We obviously have a different conception of what shutdown hooks are to
be used for.  In the i386 port, the (only) use we've had for shutdown
hooks is to turn off interrupt handling on devices which cause the
machine to fail to reboot properly if they're left on.  (Yes, these
are hardware bugs, but they often don't happen under DOS and we have
to deal with them.)  Such a device could as easily be a serial
controller as anything else, and it may thus be necessary to disable a
serial console in the shutdown hooks.

If you want to want to use shutdown handlers to stop the floppy drive
spinning, you might reasonably argue that shutdown handlers need to be
run before waiting for the keypress.  Is this actually necessary on
some ports?

> The message printed in boot.c says that the machine is down. That
> means that THE MACHINE IS DOWN.

So by this reasoning, we can't be willing to accept a keypress,
because a machine that's down obviously can't respond to keypresses.

This is a poor argument by semantics.  Obviously, the hardware of the
machine must be able to function to some degree (at least, on the
i386), and if shutdown handlers are used to disable various hardware
capabilities, you don't want to run them until you're done using the

Chris wrote:
>        (1) it's not guaranteed that all shutdown handlers can
>                actually print things to the console, which
>                i think is a big bummer, and,

So you're saying that you want some of the hardware to be active when
other pieces of hardware are being shut down.  If you really want
thus, rather than pretending that you could never need to disable the
console before rebooting, add that functionality to the shutdown

>        (2) you can't ever honestly say "the system is now halting."

This is equivalent to Perry's argument that "THE MACHINE IS DOWN."

> the alpha port says "halted." or "rebooting..." right before it
> transfers control to the firmware.  If you add a (potentially
> infinite) amount of code between then and when you actually _do_
> halt or reboot, it makes debugging the halt/reboot process that much
> harder.  (in particular, for a long time i was tracking down a
> problem that caused the console firmware to crash(!!), and if there
> were a lot of code between the "halting" message and the return to
> the firmware, it would have been harder to track down.)

This seems like an overdramatization.  If you want to rely on the
"halting" message as a landmark while debugging (it seems more likely
that you'd just set a breakpoint in ddb), you could easily add a
"transferring control to firmware " message just before transferring
control to firmware while you were debugging.  It might take you a
minute or two longer, but I don't see it making debugging harder.

I still side with the i386 port's positioning.