[lkml]   [2003]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] call drv->shutdown at rmmod
On 14 Aug 2003 10:26:47 -0600 (Eric W. Biederman) wrote:

| Patrick Mochel <> writes:
| > > At the kexec BOF at OSDL there was some discussion on calling the
| > > device shutdown method at module remove time, in addition to calling
| > > it during reboot. The driver was the observation that the primary
| > > source of problems in booting linux from linux are drivers with bad
| > > or missing drv->shutdown() routines. The hope is this will increase
| > > the testing so people can get it right and kexec can become more
| > > useful. In addition to making normal reboots more reliable.
| > >
| > > The following patch is an implementation of that idea it calls drv->shutdown()
| >
| > > before calling drv->remove(). If drv->shutdown() is implemented.
| >
| > I like the idea behind the patch, but we shouldn't be calling it
| > unconditionally. We're bound to run into some suprises that could really
| > kill us this late in the 2.6 game.
| >
| > I do think it should go in, as long as there is a flag telling the core
| > whether or not to call shutdown for that particular device. I think it
| > could also be extended to include a power state, so the core could suspend
| > the device before removing the module.
| Assuming the device driver can get a device out of the suspend state
| when the module is loaded. This has been one of the biggest problem areas
| with the e100 driver. It's init code cannot bring the device out of a low
| power state.
| > The default would always be 'Do Nothing', but with a per-device sysfs
| > file, a developer/user/gui app could be used to set the policy from user
| > space.
| Possibly. But this is getting complicated. And while I do support things
| being complicated enough to handle the problem this part of the API feels
| like it is excessively complicated. Which is why I was trying to simply
| it by always calling shutdown on a device before we remove it.

Can it just be a (kernel hacking/debug) CONFIG_DRIVER_SHUTDOWN build

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.078 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site