From owner-acpi-jp@jp.freebsd.org  Sat Dec 16 16:29:19 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id QAA23568;
	Sat, 16 Dec 2000 16:29:19 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.osd.bsdi.com (dhcp242.osd.bsdi.com [204.216.28.242])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id QAA23561;
	Sat, 16 Dec 2000 16:29:15 +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 eBG7d4O01273;
	Fri, 15 Dec 2000 23:39:05 -0800 (PST)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200012160739.eBG7d4O01273@mass.osd.bsdi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
cc: acpi-jp@jp.FreeBSD.org
In-reply-to: Your message of "Fri, 15 Dec 2000 21:40:59 +0900."
             <20001215214059Z.iwasaki@jp.FreeBSD.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 15 Dec 2000 23:39:04 -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 979
Subject: [acpi-jp 979] 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

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

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

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

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

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

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


