From owner-acpi-jp@jp.freebsd.org  Tue Aug  7 02:48:19 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id CAA19569;
	Tue, 7 Aug 2001 02:48:19 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.dis.org (mass.dis.org [216.240.45.41])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id CAA19563
	for <acpi-jp@jp.freebsd.org>; Tue, 7 Aug 2001 02:48:18 +0900 (JST)
	(envelope-from msmith@mass.dis.org)
Received: from mass.dis.org (localhost [127.0.0.1])
	by mass.dis.org (8.11.4/8.11.3) with ESMTP id f76Hp7i01472;
	Mon, 6 Aug 2001 10:51:07 -0700 (PDT)
	(envelope-from msmith@mass.dis.org)
Message-Id: <200108061751.f76Hp7i01472@mass.dis.org>
X-Mailer: exmh version 2.1.1 10/15/1999
To: John Baldwin <jhb@FreeBSD.org>
cc: Mike Smith <msmith@FreeBSD.org>, acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Mon, 06 Aug 2001 08:33:07 PDT."
             <XFMail.010806083307.jhb@FreeBSD.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 06 Aug 2001 10:51:07 -0700
From: Mike Smith <msmith@freebsd.org>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010328
X-Sequence: acpi-jp 1215
Subject: [acpi-jp 1215] Re: kqueue stuff(revised) 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org

> We use minor numbers for labels and slices, not different units, and slices a
> nd
> labels are related items, whereas batteries have nothing to do with lid
> switches. :(  I guess I'd rather us have a real /dev/batt0 with a generic
> battery API which can be backed by ACPI, but also can be backed by something
> else other than ACPI, so that we don't tie ourselves too tightly to just ACPI
> .

I want to do this as well, FWIW.  I'm prettymuch settled on the battery 
abstraction, just need to cut battery_if.m and try implementing it.

And yes, I take your point.  One reason I don't want a proliferation of 
acpi_foo devices with their own kqueues is that I don't want to tie our 
PM too tightly to ACPI.  Hence wanting a single ACPI event queue; 
the "generic" devices should have "generic" events, not ACPI events.

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


