Re: [patch] kernel sysfs events layer

[Greg KH <greg@kroah.com>]

On Tue, Sep 14, 2004 at 09:48:30PM -0700, Tim Hockin wrote:
> On Tue, Sep 14, 2004 at 08:42:29PM -0700, Greg KH wrote:
> > > Well, it will be what it will be, I think.  I know several people who
> > > wanted it to be more than it is turning out to be, but that's not
> > > unexpected.  Of course we can cope with what it is.
> > 
> > Who are those people?  What did people want it to be that it now is not?
> > Will they not speak up publicly?  If not, how do they expect it to
> > address things they want?
> 
> 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 :)

> > > What I think we'll find is that fringe users will hack around it.  It will
> > > become a documentum that the "insert" event of a Foo really means
> > > something else.  People will adapt to the limited "verbs" and overload
> > > them to mean whatever it is that they need.
> > 
> > Since when did I ever state that the verbs would be "limited"?  One of
> > the original issues that people were worried about was the possiblity of
> > a typo in a verb that we would be forced to live with.  The patch I just
> > proposed fixes that issue.
> 
> Sorry, don't get me wrong - I fully agree with amking it an enum or some
> such.  In fact, I think I suggested that in the first draft, too.  But
> adding a dozen enum verbs, of which each are used once in one single
> 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.

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

"No, not this API."

Seriously, that's not what this interface is for.  This is a simple
event notification interface.

> > > I'd like to have a standardized way to spit things like ECC errors up to
> > > userspace, but I don't think that's what Greg K-H wants these used for.
> > 
> > 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.

> For buffering, I could live with "all events with no listener get
> printk()ed and they get buffered in dmesg".  Now all we need to solve is
> the payload issue.
> 
> 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.

> > > I'd like to ACPI events move to a standardized event system, but they
> > > *require* a data payload.
> > 
> > Great, that also would be wonderful.  Create such a event system for
> > ACPI if you desire.  I think the ACPI developers are still working on
> > bigger issues currently.
> 
> 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.

> I'd love to see it use this.  It has mostly the same behaviors,
> except it has a data payload (a string and couple unsigned ints, if I
> recall).  If this API can't handle that, then we have to keep ACPI's
> current event system.  Wouldn't it be nicer to remove code and encourage
> migrating towards standard(ish) APIs?
> 
> Again, other than payload, why NOT use this API for ACPI?

Again, the payload is the big thing, right?

thanks,

greg k-h