Hello,

Sorry for perhaps being somewhat superficial below -- I've been rather
busy lately and didn't yet have time to look more closely at "high level"
PM problems.

# Garrett D'Amore 2006-07-18:
> 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.

What tools? I can only see apm(8) and apmd(8) in base. Maybe something
in pkgsrc?

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

Agreed.

Somewhat aside -- given that various PM related states/levels are going
to be MD (or even {device,bus}-specific -- I'd like to resume my work on
per-device PM soon, BTW), there's probably not much point in trying to
abstract things too much. We should just use reasonably self-descriptive
strings to refer to power states and document them somewhere in .4
manual pages. Plain integers would work just as nicely.

> Then the /dev/apm node could handled from sysmon directly.

Mm, just make all apm-centric interfaces subject to COMPAT_APM (or
whatever) and register with sysmon unconditionally.

> This means adding registration entry points for all the APM/ACPI-ish
> things that we want to have.

Yup, if you mean "registration with sysmon".

> (Ultimately, this probably also means
> replacing the sysctl ACPI hooks for triggering suspend/sleep, etc.)

Sure, those were meant as temporary interface AFAIR.

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

I don't think this would be terribly useful. If the user sets COMPAT_APM
in his kernel config, then he really wants APM compatibility and doesn't
want to be warned about it's use. If he doesn't set COMPAT_APM, any
access to /dev/apm would fail so a console warning sounds redundant. :-)

	-- Jachym