Steven M. Bellovin wrote:
> On Fri, 30 Jun 2006 18:30:09 -0700, "Garrett D'Amore"
> <garrett_damore@tadpole.com> wrote:
>
>  
>   
>> What you are talking about is the userland framework.  Funny thing is,
>> we have something kind of like this Tadpole's Solaris tree.  NetBSD also
>> has powerd, which is a "start".
>>
>> I'm more concerned at the moment, about how the kernel code passes the
>> raw data for these events to userland.  Figuring out how to react to
>> them in userland is probably somewhat easier - because it can more
>> readily be simulated, and doesn't have to deal with 18 gazillion
>> different kinds of power controllers.
>>
>> I would strongly, strongly prefer to avoid naming things "acpi" or
>> "apm".  A lot of real systems don't use anything like these, and it
>> would be nice not to have to pretend your SPARC workstation was a PeeCee
>> to deal with power related events. :-)
>>
>>     
> I'm not so much naming things 'acpi'; rather, I'm planning to use the
> names returned by envstat/envsys, hence the name 'envstatd'.  What I wanted
> was a more general framework than powerd -- powerd responds to events; I
> want something that responds to conditions.
>
> You're quite right that I'm looking at userland.  I don't have strong
> opinions on the kernel interface, save that I want it to be fairly
> general.  As always, put mechanism in the kernel and policy at user level.
> If your new kernel interface passes back different names, my code should
> remain more or less unchanged, save for the replacement of the envsys()
> calls with something new.
>   

This sounds reasonable.  It would be nice to have standard names (or
"types") so that your scripts might be portable to different kinds of
hardware... :-)

I'm 100% in agreement that there should be no (well almost no) policy in
the kernel.  The only exception I make for this is that when there is no
userland daemon running, it might be reasonable to have things like the
power button do something sane.  This already is done in sysmon, btw.

    -- Garrett
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191