From owner-acpi-jp@jp.freebsd.org  Tue Dec 26 23:29:41 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id XAA90996;
	Tue, 26 Dec 2000 23:29:41 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.osd.bsdi.com (adsl-63-202-177-107.dsl.snfc21.pacbell.net [63.202.177.107])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id XAA90991
	for <acpi-jp@jp.freebsd.org>; Tue, 26 Dec 2000 23:29:40 +0900 (JST)
	(envelope-from msmith@mass.osd.bsdi.com)
Received: from mass.osd.bsdi.com (localhost [127.0.0.1])
	by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eBQEeZj86154
	for <acpi-jp@jp.freebsd.org>; Tue, 26 Dec 2000 06:40:35 -0800 (PST)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200012261440.eBQEeZj86154@mass.osd.bsdi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Fri, 22 Dec 2000 00:16:25 +0900."
             <20001222001625L.iwasaki@jp.FreeBSD.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 26 Dec 2000 06:40:35 -0800
From: Mike Smith <msmith@freebsd.org>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 999
Subject: [acpi-jp 999] Re: Generalised power-management interface (was Re: Some power device driver. ) 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org

> >  - Calling the library 'gpm' is going to seriously confuse people that 
> >    immediately think of the Linux "gpm" mouse stuff.  I think "ospm" is 
> >    better, but that's probably ACPI infecting my brain.
> 
> OK, understood.  I agree to changing the name, but the name "ospm"
> seems to have somewhat problem for APM.
> OSPM is short for `Operating System Directed Power Management' in the
> ACPI world, then APM is not Operating System Directed...

Well, "OSPM" is just "operating system power management", referring to 
the OS component in the power management scheme.  I don't like the name 
much either, but it's not really incompatible with APM per se.

> Also I've been considering to integrate UPS too into this framework in future.
> # Yes it would be more difficult, but has some advantages in terms of
> # application program development effort, I believe.

I could see useful ways in which UPS support might want to integrate with 
generic platform power management, certainly.

> How about "genpm" ?

/dev/power ?

> >    We should use a linker set to find ospm ioctl handlers.  The linker
> >    set entry should also have a flag to indicate whether the ospm handler
> >    is active, and a string pointer to its name/description.
> 
> It's possible and nicer, but I would say no.  linker_set seems to be
> unavailable in other BSDs (even in compat_linux of NetBSD).

Then these other BSD's can use their own way of doing things.  FreeBSD 
uses linker sets for this; they can patch main() or however they do it.

> I want to reduce FreeBSD specific part as much as possible, and to have
> simple and reasonable ioctl handler registering interface.
> Any improvements are welcome :-)

You could probably just make a function call to register the ioctl 
handler.

> >  - set power consumption policy to "high" or "low"
> 
> Yes.  I don't know the reason of stop calling apm_cpu()/apm_idle(),
> but should we make it configurable?

This is an APM-specific quirk, and should be configured with an 
APM-specific tool.

> >  - put the system into a "suspend" and/or a "sleep" state
> 
> Yes, I think it's easy.
> 
> > The following information should be available:
> > 
> >  - the status of AC power
> >  - the charge state of attached batteries
> >      o percentage (optional)
> >      o high/low/etc (optional)
> >      o charging in progress (optional)
> > 
> > I think the interface that's been proposed actually covers almost all of 
> > this, so perhaps it's not really too specialised either.
> 
> OK, I think having event notification mechanism would be enough for 
> the generic power management interface adding to this.

Event notification is definitely worth having, yes.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E


