Re: alternate event logging proposal

[Brad Hards <bhards@bigpond.net.au>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 25 Sep 2002 10:47, Tim Hockin wrote:
> > > a single device_event file that a daemon reads and dispatches events (I
> > > like this one because the daemon is already written, just poorly named
> > > - acpid)
> >
> > Couldn't you just have the message sent to every process that has
> > opened the file (and have every interested process open the file and
> > read it in a non-blocking or blocking mode?)
>
> Sure, but then every process that is concerned with a single event has to
> not only receive every event, but parse every event.  And if this is to be
> truly generic, that could be a lot of events.
To what level would you see this going?
I'm currently doing some documentation work on the input subsystem, and it 
produces events (/dev/input/eventX) for every mouse movement, every key press 
(and release), etc. Now most of the application interested in those events 
will get them via X (we just need to interface the input subsystem event 
interface to the X event interface). I see this as a separate daemon or 
daemons. 
Basically you get eventd on every system, and inputd for each console (in a 
multiheaded, multiuser setup).

> > That seems to negate the need for something like acpid, but it does
> > not preclude it's use.
>
> True, and if a dev_event file were created, I'd consider doing it that way.
> But in that case it's easier for apps to talk to eventd (nee acpid) and get
> only the messages they want.
I think that the eventd advantage is that it is easy to do integration with 
non-event aware apps. Example: eventd re-writes the config file and SIGHUPs 
the application.

Brad

- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Aust. Tickets booked.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9kQ4NW6pHgIdAuOMRAtEyAKC2t5lKponBvUHH14bONYfjbSWFxgCeMh1O
9pjS0UjK627edrI8WJDBXp0=
=V0sd
-----END PGP SIGNATURE-----