Background:  I have a SPARC (no ACPI or APM native!) laptop that has
battery and power management support that I'd like to support ACPI-like
interfaces on.

Right now I have implemented some subset of this by talking to sysmon. 
But there are bits that I'd like to expand upon, like battery status, etc.

Apparently a lot of the user tools talk to /dev/apm, which is pretty
PeeCee-specific.  I'd prefer not to have to reimplement code to support
both /dev/apm and sysmon.

Complicating this is Christos' recent addition to acpi, to add a
compatibility layer.  I.e. acpi exports an apm compatibility layer.  The
problem is that it is really pretty ACPI specific, because it has things
like acpi suspend support coded up in it.  So it isn't directly usable
by me.

So we need to think a bit about this design going forward, I think.

My suggestion is to have sysmon act as the clearing house for _all_ this
stuff.  Power management, suspend/resume state, etc.  To effect this,
ACPI would register with sysmon, as would real APM (assuming the user
has it).  Then the /dev/apm node could handled from sysmon directly.

This means adding registration entry points for all the APM/ACPI-ish
things that we want to have.  (Ultimately, this probably also means
replacing the sysctl ACPI hooks for triggering suspend/sleep, etc.)

I'd also like to have a kernel warning issued the first time some code
_not_ using the compat interfaces  accesses /dev/apm   ("WARNING:
program XXX is using obsolete APM interface") at least in verbose if not
even all boot flags.  I don't know if we can distinguish a program using
the compat layer ioctls vs. normal ioctls (being largely ignorant of how
compat_xxx works. :-)

Thoughts?

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