Better integration with power management scripts

[Peter Jones]

On Thu, 2006-04-20 at 18:25 +0200, Stefan Seyfried wrote:
> On Tue, Apr 18, 2006 at 07:48:13PM -0400, David Zeuthen wrote:
>  
> > My position is that if a module needs to be unloaded and loaded again
> > there is a bug in the module that needs to be fixed. We should never do
> > this but providing the infrastructure for OS vendors, hardware/driver
> > vendors and users is fine. After all, we all know it takes time to fix
> > this.
> 
> One note:
> Modules are not only unloaded because of broken drivers, but because it
> is sometimes a convenient way to assert a certain system state.
> Example: i am advising the unloading of usb-storage and sbp2, simply to
> make sure that no stupid things are happening (mounted external disk is
> unplugged during suspend => filesystem hosed)

Er, that still loses.  If the module doesn't have refcount bugs, it will
fail to unload unless everything is unmounted correctly.  In that case,
removing it accomplishes nothing.  If it does have refcount bugs, then
you've removed a driver underneath the filesystem, possibly with IOs
pending.  Either way, the only way to make it better is to unmount
before you suspend.  But if you've done that, there's no point to
unloading the module.

>  Otherwise an plug/unplug
> event during suspend would get lost (and no, "fixing" the drivers to always
> rescan the bus and redetect all devices on suspend / resume might be the
> wrong thing for some setups, where bus state is actually preserved
> over a suspend cycle, if the module is _not_ unloaded IIUC).

Huh?  AFAIK, all of our truly hot-pluggable storage buses have to
re-enumerate on resume anyway.  The others, such as normal scsi, won't
give a hot-add/remove event unless you do e.g. "echo scsi
add-single-device 7 0 0 0 > /proc/scsi/scsi".  So that case is just like
without hotplug -- if you don't unmount and tell the driver, you're
doing something wrong.

If you need to load and unload a module for this, it's *broken*.

> And the same applies here. As long as Linux is a general purpose OS it
> might actually make more sense (and be less complicated) to just stop
> and start some services before / after suspend instead of designing every
> oh so esoteric service to be suspend-aware.

Very few services need to be suspend aware.  In fact, all of the
services we're currently starting and stopping fit into one of these
categories:

1) just plain broken (i.e. ntpd)
2) holds a reference to a broken module (bluetooth has with deps on
   hci_usb, which doesn't suspend right)

That's it.

-- 
  Peter