Re: [patch] kernel sysfs events layer
From: Tim Hockin
Date: Wed Sep 15 2004 - 01:25:50 EST
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
-
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/