Jachym Holecek wrote:
> 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?
>   

I think that is the concern.  The GUI tools that monitor battery status
and such.

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

self-descriptive strings are better, IMO.

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

That sounds good.

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

Yes.

>   
>> (Ultimately, this probably also means
>> replacing the sysctl ACPI hooks for triggering suspend/sleep, etc.)
>>     
>
> Sure, those were meant as temporary interface AFAIR.
>   

Right.

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

If we use COMPAT_APM, then I'm happy, because the user has already made
the appropriate changes.

This is, IMO, another case where good library interfaces could have
shielded the applications from change underneath in the kernel layer. 
Oh well....

    -- Garrett

> 	-- Jachym
>   


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