Re: [patch] kernel events layer

[Daniel Stekloff]

On Sun, 2004-07-25 at 12:08, Robert Love wrote:
> On Sun, 2004-07-25 at 11:11 -0700, Tim Hockin wrote:
> > 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.


There are other issues that we may need to look into as well, like:

1) How do we handle events that occur in a hardware interrupt context?
One thing that has been suggested in the past was to delay broadcast and
schedule a tasklet to do the broadcast. Or, can we make the netlink
broadcast interrupt safe?

2) What about the recent thread on firmware errors for ppc64 systems?
They have errors at early boot and those error messages may be in binary
format? Should we buffer messages until netlink becomes available and
then send the messages and remove the buffer? As for the binary format,
should we change kevents so format and args are kept separate to User
Space? This would have other benefits as well.

Just some thoughts....

Thanks,

Dan

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