>But i've had some experience with handling similar issues under
>Linux. One thing i learnt is that calling out to specific scripts just
>does not scale very well.

Well, I'm certainly open to new ideas.  I had thought about it a bit
beforehand.

The reason I implemented it this way was that it seemed to fit very well
into the toolbox approach that Unix has used successfully for a long time.
Another reason is that this makes the policy very customizable - something
which is not so easy when you put it into the kernel.  Maybe I _don't_
want my disks to spindown, no matter what.  All I have to do is edit
a script.  Maybe I want to do bizarre stuff like edit root's crontab so
the "at" job doesn't run and keep appended stuff to cron's log file when
on battery power.

>I think a better answer (something netbsd strives for, right?)  is a
>generalized event-notification mechanism, plus a *protocol* for
>sending events:
>
>   a) from the kerenl to userland, in response to hardware events.
>   b) from userland to the kernel, in response to user requests.

Okay, I can definately see the need for that.  My only hesitation is
that (as mentioned before) it seems to lack customizability.  I'd want
to be able to have more knobs from userland so that I could set things
like the behavior of wd0 on battery power.  I think doing event queues
probably could work; I just would like to make sure the right functionality
is built into it from the beginning.

>For instance, i'd really like to see APM integrated with PCMCIA so
>that one can, for instance, configure PCMCIA NICs to go into ``sleep
>mode'' (or poweroff) if you go onto battery power, and powering them
>up if you go onto mains power.  And  similar tricks if you have a
>multi-homed laptop.

AFAIK, you can do that with the apm stuff today; just "ifconfig" the
interface down in your "battery" script, and "ifconfig" it up in "line".

You said before that the Linux approach (which I guess is similar to
this) doesn't scale.  Can you give more specifics?  I'm really curious.

--Ken