Re: [patch] kernel sysfs events layer

Tim Hockin
2004-09-15T06:22:42Z

On Tue, Sep 14, 2004 at 10:09:04PM -0700, Greg KH wrote:
> > Well, I knew several groups at Sun who could have benefitted from "driver
> > hardening" event-logging stuff. Things like IPMI, evlog, etc are what are
> > being used today.
>
> Yes, it's a wide range of stuff that all should be consolidated.
>
> But I haven't seen many people step up to do the work, that's my biggest
> complaint. I know I don't have the time to do it either :)

Yeah, Sun wasn't really good about committing people to fix things that
it needed, they just like to find things they need.

> > driver is just not going to fly. The barrier to creating a new "verb" is
> > not high, but there is a slight barrier. Rather than deal with the
> > barrier, I fear (and I could be wrong) that people will just overload
> > existing verbs.
>
> We'll see how it gets used. If people start to do this, we'll
> reconsider the kernel code. The interface to userspace will still be
> the same, so we aren't painting ourselves into a corner right now.

True, and a fair answer.

> > > > As much as we all like to malign "driver hardening", there is a *lot* that
> > > > can be done to make drivers more robust and to report better diagnostics
> > > > and failure events.
> > >
> > > I agree. But this interface is not designed or intended for that.
> >
> > Right. I originally asked Robert if there was some way to make this
> > interface capable of handling that, too. Maybe the answer is merely "no,
> > not this API".
>
> Seriously, that's not what this interface is for. This is a simple
> event notification interface.

Well, this API is not far from "good enough". It's meant to be a "simple
event system" but with a few expansions, it can be a full-featured event
system :) And yes, I know the term "feature creep".

> > > You are correct. I also would like to see a way ECC and other types of
> > > errors and diagnostics be sent to userspace in a common and unified
> > > manner. But I have yet to see a proposal to do this that is acceptable.
> >
> > Well, let's open that discussion, then! :) What requirements do you see?
> >
> > Basically, they need to be exactly like this, except there needs to be
> > some amount of buffering of messages (somehow) and they need a data
> > payload.
>
> Sounds good to me.

So what if the actual event system had a payload, and simple events don't
use it, and complex events do? Or what if there were an exactly analogous
API for messages with payloads?

> > Really, other than payload, why NOT use this API for ECC and driver
> > faults?
>
> The payload is a pretty good reason why to not use this right now. No
> one has proposed a way to handle such a payload in a sane manner.

What's insane about a string payload? Or rather, what are your objections
to saying that the payload string format is entirely dependant on the
{source, event} tuple?

ACPI events might come out of a kobject "/sys/devices/acpi" with an event
"event" and payload "button/power 00000000 00000001" or whatever the
actual values work out to be.

What's insane about that? Currently we have a separate /proc/acpi/event
file which spits out "button/power 00000000 00000001".

> > ACPI *has* it's own event system. It's fine, but it's Yet Another Event
> > System.
>
> Yeah, it's pretty old too, that's why it is the way it is.

But semantically, it's the same as this new API (I think), just less
elegant.

> > Again, other than payload, why NOT use this API for ACPI?
>
> Again, the payload is the big thing, right?

Yes, the payload is the big thing (that I see). I'm not sure if you're
posing this as in "See, it needs a payload so we don't want it." or "If we
find a way to do a payload sanely, will you shut up?".

:)

Cheers,
Tim