Steven M. Bellovin wrote:
> On Fri, 30 Jun 2006 17:28:15 -0700, "Garrett D'Amore"
> <garrett_damore@tadpole.com> wrote:
>
>   
>> Well, I've made the mistake of looking at what we currently have in
>> NetBSD.  And comparing it with some real (our) hardware.
>>
>> There are few quick points for discussion:
>>
>> 1) there doesn't seem a clear way to indicate powerfail for a low
>> battery condition in sysmon.  Should I just be sending init some signal?
>>
>> 2) No way to indicate overtemp status either
>>
>> 3) Currently it isn't clear whether you should be registering with APM,
>> sysmon, or something else for things like battery status, etc.  It would
>> be really, really good if drivers didn't have to do _both_ of these
>> things.  Can we maybe have a sysmon APM compatibility layer?  (I guess
>> there are some userland apps that "know" about APM.  Bletch.)
>>
>> 4) We need some userland tools to talk to sysmon in base, I think. 
>> (E.g. to query batteries, etc.)
>>
>> 5) In many respects, sysmon looks like a good start.  I've coded a quick
>> power management driver for the Ultrabook IIi (okay, it was mostly a
>> port from Solaris), and it basically works for things like lid switch,
>> AC power cord un/plug, and power button.
>>
>>     
> I've been thinking similar thoughts.  I have a paper design for (what I
> had tentatively called) envstatd.  The config file would look something
> like this:
>
> 	acpibat0         <.04      /bin/shutdown -p now
> 	temp=acpitemp	 >70*2	   /bin/shutdown -p now
>
> where the *2 indicates that it has to happen twice in a row.  A few more
> frills, like shell variables for each config line -- the 'temp' means that
> a script would be run with envstatd_temp set to the value.  A | at the
> start of the command would create a pipeline that would be fed the value
> on stdin, to permit easy real-time graphing programs.
>
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>   

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. :-)

    -- Garrett

-- 
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