From owner-acpi-jp@jp.freebsd.org  Sun Dec 17 00:48:19 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id AAA44459;
	Sun, 17 Dec 2000 00:48:19 +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 AAA44451;
	Sun, 17 Dec 2000 00:48:16 +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 eBGFmDk08605;
	Sun, 17 Dec 2000 00:48:13 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org, msmith@freebsd.org
Cc: iwasaki@jp.freebsd.org
In-Reply-To: <200012160739.eBG7d4O01273@mass.osd.bsdi.com>
References: <20001215214059Z.iwasaki@jp.FreeBSD.org>
	<200012160739.eBG7d4O01273@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: <20001217004810P.iwasaki@jp.FreeBSD.org>
Date: Sun, 17 Dec 2000 00:48:10 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 71
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 980
Subject: [acpi-jp 980] 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

> > I think the same kind of other APM applications also are similar to
> > this.  ACPI can provide the same info. so we can have common framework
> > for this, but some considerations would be required.  For example;
> >  - How does the application get this information?  /dev/pminfo instead of
> >    /dev/apm would be suitable?
> 
> /dev/pminfo or /dev/pmcontrol might be suitable if we want to put the 
> whole interface into the kernel.  I'm not sure if we want to do that, or 
> have a libpowermanagement which knows how to provide a more generalised 
> interface.

OK, to get power management information, we create a libgpm and
provide a more generalised interface to applications.  /dev/pminfo (or
/dev/pmcontrol or simply /dev/gpm) will be hidden from any applications
and accessed via only functions in library.
Library will includes various functions on power management such as;
 - existence of power management system
 - type of power management system
 - ac-line status
 - battery status
 - additional info. depends on type of power management system

Enough?  and naming OK?

> >  - How does the generalised power-management interface determine which
> >    device driver (APM or ACPI) to be used actually?  by some sort of 
> >    configuration utility?
> 
> There should only be one of APM or ACPI active at any point in time, so 
> this is not really an issue.

Some exclusive intervention will be required before device probing for this.
# I personally need both until ACPI S[2-4] is supported though :-)

> >  - When and how should generalised power-management interface get
> >    information?  Push (from actual driver when status changed)
> >    or pull on demand?
> 
> I think that both should be possible.  An application should be able to 
> poll for current status, but it should also be able to request 
> notification of status changes.

Yes.  I found that executing AML methods is higher cost operation than
I expected when I unplugged and acpi_cmbat_notify_handler() was called
frequently.  So I prefer the latter.

How about pseud device driver the for generalised power management interface?
Maybe sys/dev/gpm/ ?  APM or ACPI driver inform gpm(4) the pwer management
driver is enabled and requests from userland are passed to the actual driver
via gpm(4).

> > Also this application invokes apm(8) to put the system standby/suspend.
> > Maybe we can make new integrated utility (and maybe library?).
> 
> I think so, yes.

OK, this also can be included in the new library.  New utility will be
a application of the library.

> > And one more thing, I don't like that this kind of application keep
> > getting APM status very frequently (mostly about every seconds!).
> > I think one of the reasons for this is there is no way to get 'status
> > changed' event notifications from the applications.  Prividing common
> > event notification mechanism would be a good solution for this.
> 
> Agreed.

I'll try to make a simple prototype on PM info. in a few days.
Any other things to be considered?

Thanks!
