From owner-acpi-jp@jp.freebsd.org  Mon Jul 30 15:10:31 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id PAA49032;
	Mon, 30 Jul 2001 15:10:31 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.dis.org (sat.dis.org [216.240.44.14])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id PAA49027
	for <acpi-jp@jp.freebsd.org>; Mon, 30 Jul 2001 15:10:29 +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 f6U6C8r02834
	for <acpi-jp@jp.freebsd.org>; Sun, 29 Jul 2001 23:12:09 -0700 (PDT)
	(envelope-from msmith@mass.dis.org)
Message-Id: <200107300612.f6U6C8r02834@mass.dis.org>
X-Mailer: exmh version 2.1.1 10/15/1999
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Sat, 28 Jul 2001 09:02:59 +0900."
             <200107280002.JAA99307@shidahara1.planet.sci.kobe-u.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 29 Jul 2001 23:12:08 -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 1201
Subject: [acpi-jp 1201] Re: CFR:ACPI kqueue stuff 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org


Sorry that I have taken so long to get around to this.

> >I would like to think about this a bit more before you commit it.
> >
> >In particular, I'm not happy with the small size of the KNOTE stuff, and 
> >I'm sure about some other implications.  Please give me some time to 
> >sleep and work tomorrow before I reply...
> 
> There is a way to be able to distingiush more event:create device node 
> with different minor number and wait the event on it,
> which was refused by you in message [acpi-jp 903] .

ie. use the device node as a multiplexor on the event queue contents?  
Yuck!  That's *terrible*. 8)

> And I think the problem I mentioned in [acpi-jp 977] is not *BASICALLY* 
> changed (though, for EVFILT_READ/EVFILT_WRITE/EVFILT_VNODE, kqueue filter
> attached to device node can be installed dynamically).

Ok.  There are two basic problems with this proposal.

First - there aren't enough significant bits in the knote word.  You can 
work around this in a couple of ways; the best will be to change the way 
the word works, so that eg. the high 2 bytes are the subsystem reporting 
the event and the low 2 bytes are an event parameter.

This may not interact well with the way that kevent works; I need to read 
up on how filters are constructed.  If they can only be installed in a 
bitmask fashion, then we may have to have a compromise.  If someone else 
that knows kqueue better can comment here, that'd be useful.

Second - the interface only provides a mechanism for reporting new 
events, it can't be used to collect status information.  So we still need 
other interfaces to collect this data.

This means that, for example, there is no point in having 8 different 
battery events for the 8 possible batteries.  One event, "battery status 
changed" is enough; anything that is interested can then go check the 
battery status it cares about.

Regards,
Mike

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


