Re: CPU Hotplug: Hotplug Script And SIGPWR

[Rusty Russell <rusty@rustcorp.com.au>]

In message <400D6A33.6020108@myrealbox.com> you write:
> (At some point, linux may want to suspend itself after inactivity.  Both 
> RT tasks and some interactive tasks may want to supress that.)  Why not 
> add a SIGPM signal, which is only sent if handles, and which indicates 
> that PM event is happening.  Give usermode some method of responding to 
> it (e.g. handler returns a value, or a new syscall), and let 
> /sbin/hotplug handle events for tasks that either ignore the signal or 
> responded that they were uninterested.  This seems be close to optimal 
> for every case I can think of.

This was my original idea too.  AIX has this, but in reality the
control ends up all in userspace for non-trivial uses.  ie. some
"workload manager" program consults with all the interested parties
*before* telling the kernel what to do.

The async and non-consultive nature of hotplug is policy for good
reason.  Giving someone 30 seconds to respond to a signal can always
fail, and making it configurable is just a bandaid.

I have nothing against SIGRECONFIG (think memory hotplug), but the AIX
guys indicated from their experience it seems that non-toy users don't
use it anyway (they have a hotplug-style script system, too).

So: trying to cover every corner case isn't worthwhile in practice, it
seems.  I like the signal for RC5 challenge etc, but that's about it.

Cheers,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.