From owner-acpi-jp@jp.freebsd.org  Fri Dec 15 21:41:12 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id VAA60973;
	Fri, 15 Dec 2000 21:41:12 +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 VAA60964;
	Fri, 15 Dec 2000 21:41:04 +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 eBFCf0k33691;
	Fri, 15 Dec 2000 21:41:00 +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: <200012151002.eBFA2Ro02884@mass.osd.bsdi.com>
References: <20001215160054A.iwasaki@jp.FreeBSD.org>
	<200012151002.eBFA2Ro02884@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: <20001215214059Z.iwasaki@jp.FreeBSD.org>
Date: Fri, 15 Dec 2000 21:40:59 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 68
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 976
Subject: [acpi-jp 976] 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

> > Yes, I think it's one of the advantages from the other.  I just
> > enumerated kqueue as one of the event notification mechanisms.
> 
> Kqueue is really the only sensible way to implement this.

OK :-)

> > One thing I'm concerning about using kqueue is API
> > compatibility/portability among *BSDs.  I'm not sure this is FreeBSD
> > specific API or they've had it already or have any plan to implement
> > kqueue(2) or not.  Does anyone know this?
> 
> I would expect the other BSDs to pick up kqueue before they pick up ACPI 
> support.

Maybe true because I heard that OpenBSD already support kqueue.

> > If kqueue is (or become) common BSD API, it would be a good choice.
> > If not, we'd better to use traditional API and have dedicated control
> > file(s) as mentioned.
> 
> Even with a traditional API, multiplexing ACPI events onto a single 
> control file is the only sensible way to do this.  It would even be 
> trivial to emulate ACPI's use of kqueue using this technique on 
> non-kqueue systems.
> 
> In case it's not obvious, I am *very* strongly opposed to having anything 
> more than a single ACPI control device in /dev.  I would really prefer, 
> in fact, to have a more generalised power-management interface, but I 
> don't think that we have enough experience yet to decide how it should be 
> done.

OK, let's start to try it otherwise we wouldn't experience anything :-)

To make things simple as possible, I'd like to suggest that we have the
target APM application to be ported to use ACPI, let say, wmapm.
Our goal is to make efforts minimize for this porting for the time being.

This application needs only these information from APM.

            my_cur_info.ac_line_status     = (int)temp_info.ai_acline;
            my_cur_info.battery_status     = (int)temp_info.ai_batt_stat;
            my_cur_info.battery_percentage = (int)temp_info.ai_batt_life;
            my_cur_info.battery_time       = (int)temp_info.ai_batt_time

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?
 - How does the generalised power-management interface determine which
   device driver (APM or ACPI) to be used actually?  by some sort of 
   configuration utility?
 - When and how should generalised power-management interface get
   information?  Push (from actual driver when status changed)
   or pull on demand?

Also this application invokes apm(8) to put the system standby/suspend.
Maybe we can make new integrated utility (and maybe 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.

Hmmm, above things look interesting to me :-)
Any comments welcome, thanks!
