lkml.org 
[lkml]   [2002]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: alternate event logging proposal
Date
> To what level would you see this going?

Not sure - someone talked about receiving all sorts of device events.
Certainly do-able, but it may be desirable to really limit the domain.

> 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

So I'd say this level of heavy traffic probably deserves it's own event
mechanism that is more lightweight than eventd. The more generic it is, the
more each event costs (currently O(n) - 1 regex comparison for each
client/config). Putting high volume mouse/kb events would likely suck.

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

This eventd I'm speaking of is what currently exists as acpid. It reads
ACPI events and does just that - runs some user-defined handlers and alerts
processes on a UNIX socket.

It does make it possible to do things like not modify DHCP client at all,
and just thump it with a HUP. It also means everyone needs to be running
eventd. And then you still have the 'need-an-edge' problem. If DHCP starts
and hangs because it can't find the network (assume an unplugged NIC),
nothing is going to come along and tell it there is no link because there
was no edge.

By making something like (just for argument) /netdevfs/eth0/link, dhcp could
read that, find a "0" and go to sleep on a poll() of that same fd. But you
need to modify DHCP.

Advantages and disadvantages to all models. Which is why I brought it up
for debate. IFF it is even attainable for 2.5.x. It certainly is for just
netif style events. On a broader scope? Maybe not. Another drawback of
the generic event file is that you now have a lot more people to please with
a generic enough protocol.

Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.042 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site