In place kexec

[Andrew Vasquez]

On Fri, 30 Jul 2010, Eric W. Biederman wrote:

> "H. Peter Anvin" <hpa at zytor.com> writes:
> 
> > On 07/30/2010 09:30 AM, Eric W. Biederman wrote:
> >> 
> >>>> That said it looks like the code to do the shutdown is in
> >>>> qla2x00_remove_one so it should be too hard if someone cared to
> >>>> extract just the hardware bits.
> >>>
> >>> Charming.  Code is there, just not hooked up.
> >> 
> >> Using the .remove method in reboot is a fight a lost long ago.
> >> 
> >
> > Could you elucidate, please?
> 
> My original proposal was for device_shutdown to call the .remove
> methods as those are well exercised and tested in development. aka
> rmmod.
> 
> It was argued (with some merit) that for a system reboot we don't want
> to perform all of the subsystem registration work, to make it more
> likely that reboot -f will reboot even if there is a kernel oops.
> 
> What I proposed and unfortunately failed to write the patch for at the
> time is was to have the device remove path call shutdown before calling
> remove, so drivers wouldn't have to code it all up twice.
> 
> A lot of the disk drivers implement .shutdown these days and there aren't
> may bug reports about kexec failing.  So I would be reluctant to change
> things other than on a driver by driver basis unless I had a lot of time
> for testing etc.
> 
> It might be worth playing with adding a pci_clear_master in
> pci_device_shutdown.  It has the potential to break things like usb
> keyboards, so I would be careful.  If it doesn't break fundamental
> things like usb a pci_clear_master when shutting down devices should
> improve reliability somewhat.
> 
> And of course there is the old staple of work arounds: "rmmod <driver>"
> before calling kexec --exec.

Looking through all these emails, what's the upshot here?  Is the
expectation, for all storage drivers to starting to implement some
'minimal' level of shutdown with the hardware/firmware during the
.shutdown callback?


--
Andrew Vasquez