Re: [patch] kernel events layer

[Robert Love <rml@ximian.com>]

On Sun, 2004-07-25 at 11:11 -0700, Tim Hockin wrote:

> yeah.  I suppse that's true.  What's the meaning of the 'source' object,
> generically?

The source of the signal.  The object, in fact - very similar to kobject
in concept, but we cannot use that since one does not exist for all uses
(plus, Greg tells me it would be expensive to constantly build the
kobject path for each event).

The only hard requirement is that it is unique, like any URI.  But it
would be nice if it was self-descriptive and double nice if it looked
like URI's used by other object systems.  The "drivers/char/cdrom" style
fits that bill.

> So, when I was at Sun (no, I'm not at Sun anymore) there was lots of talk
> of driver hardening and fault management.  At the time, the team in
> question looked at the various event systems that currently exist in the
> kernel or in some patches.  This list might be incomplete, but it's off
> the top of my head.
> 
> - Netlink
> - ACPI (/proc/acpi/event)
> - hotplug
> - IPMI (not merged maybe?)
> - relayfs (not merged)
> - evlog (last I saw, this was in big flux)
> 
> Now you're proposing netlink as the kevent subsystem.
> 
> Wouldn't it be nice if everything could converge?  Ok maybe not
> EVERYTHING, but some of these?

Yup.

So the last two are not being merged.  It seems unlikely that they will
be, but if they were, we could use them as the backbone of the event
system.  The medium is not really what interests me (or you, either - I
think we both are interested in the results, right?).  Technically
speaking, though, netlink does seem the best choice.  I look at kevent
as serving the same purpose as these last two.

I don't know much about IPMI, but I thought it was a hardware spec.  I'm
not sure it counts here.  If it communicates with user-space, it would
be nice if it used netlink or /proc or even kevent and not its own
thing.

So that leaves ACPI and hotplug.  ACPI absolutely should switch to using
kevent.  It is the perfect user, right?  Send the ACPI events out via
kevent.  You wouldn't even need acpid - just have policy agents
listening on D-BUS or directly on the netlink socket or whatever.

As for hotplug, I'll leave that one to Greg.  He has some thoughts here.

> These are the things I can see kevents being used for:
> 
> - Stateless messages which only matter if someone is listening.  Examples
>   of this are "media changed" and stuff like that.
> 
> - Fault and error that matter no matter what, and can not afford to be
>   dropped.  Examples are things like ECC errors, significant
>   driver/subsystem errors, etc.
> 
> - System state messages, which really do want someone to be listening, but
>   are otherwise discoverable.  Examples of this are "disk full" and
>   similar.
> 
> So can kevents be used for all of these?  The fact that netlink does not
> buffer events if there are no listeners (not saying it should..) makes it
> unreliable for fault events.  Can these all be converged?

I think kevents can (and should) be used for all of these.  But the lack
of buffering is something we need to look into.

> Sorry for rambling - kernel events has been on my mind for some time.

Mine too.  All good input, thanks.

	Robert Love