In article <199901260340.TAA25683@lestat.nas.nasa.gov>,
Jason Thorpe  <thorpej@nas.nasa.gov> wrote:
> The kevent framework has the notion of `event servers' and `event clients'.
> Things which wait for events to happen are clients.  Things which notify
> the clients that the event has occured are servers.

The names could be clearer (one could just as well say that a client is
something that needs an event handled, so it dispatches a message to a
server, and use the terms the other way around.) Talker/listener,
sender/receiver, ort something along those lines would be better.

> network driver may be waiting for "power-status" events.  A "power-status"
> event message may include one of the following message payloads:
> 
> 	"suspend"
> 	"resume"
> 	"line"
> 	"battery"
> 	"level" <int:72>
[...]
> 	It is intended that userland programs may be clients of the
> 	framework, as well.

It would be nice to have a way for userland to be able to act as a
server as well, so things like pwoer events could be sent from userland
too (for a UPS system, for example). 

[Also, though I know this was just an example to illustrate the use of
the kevents subsystem, the format of power events needs more thought. 
What about a laptop on a UPS? Maybe power messages should include a
"distance" argument, to allow for a chain of power suppliers. Anyway,
that's another thread...]

Anyway, sounds cool!