From owner-acpi-jp@jp.freebsd.org  Fri Dec 22 00:16:41 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id AAA43493;
	Fri, 22 Dec 2000 00:16:41 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (daemon@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id AAA43478
	for <acpi-jp@jp.freebsd.org>; Fri, 22 Dec 2000 00:16:39 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.11.1+3.4W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id eBLFGYk50934
	for <acpi-jp@jp.freebsd.org>; Fri, 22 Dec 2000 00:16:34 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org
In-Reply-To: <200012210553.eBL5rTc00562@mass.osd.bsdi.com>
References: <20001218005716Q.iwasaki@jp.FreeBSD.org>
	<200012210553.eBL5rTc00562@mass.osd.bsdi.com>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001222001625L.iwasaki@jp.FreeBSD.org>
Date: Fri, 22 Dec 2000 00:16:25 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 94
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 988
Subject: [acpi-jp 988] 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: iwasaki@jp.freebsd.org

Hi, mike

> > I've created simple gpm driver, library and application.  Currently
> > only APM has the interface for it, but I think it would be enough to
> > start with.
> > 
> > Any comments welcome.  Thanks!
> 
> A couple of thoughts:

Thanks for your comments.

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

How about "genpm" ?

>  - This is just wrong:
> 
> +dev/gpm/gpm.c          count gpm 

Ah yes, it's not necessary to be `count'.  I was lazy :-)
I think these two lines seems OK for now.

dev/gpm/gpm.c          optional apm
dev/gpm/gpm.c          optional acpi

>    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).
I want to reduce FreeBSD specific part as much as possible, and to have
simpe and reasonable ioctl handler registering interface.
Any improvements are welcome :-)

>  - I'm not sure that a single structure is enough yet.  There's a really 
>    good argument for a very simple, generic power management interface,
>    and also a good argument for a much more complex one.  I think the 
>    current structure is trying to be both.

Sorry I couldn't get this.  My idea is that generalized PM provides
common (and maybe minimum) interface to the applications by having
glue layer, and we can handle PM specific requests in the library...

> Thinking about the generic power management interface...
> 
> It should be possible to do the following things:
> 
>  - 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?

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

> The "specialised" interface is probably going to be *much* more complex, 
> and perhaps we're better off just having per-management-style control 
> tools for that.

I think having per-management-style control tools is also reasonable.
It makes the design of generic power management interface (in kernel)
easier.  Also we can have specialised interface to the applications in
library level if need.

> On the whole though, it looks pretty good!

Thanks!  I've begun to understand what I want to do :-)
