Re: [patch] kernel sysfs events layer

[Greg KH]

On Tue, Sep 14, 2004 at 08:17:06PM -0700, Tim Hockin wrote:
> On Tue, Sep 14, 2004 at 10:10:29PM -0400, Robert Love wrote:
> > > I don't have any concrete examples right now, but it seems that this is
> > > being locked down pretty tightly for no real reason...
> > > 
> > > Just a passing thought.
> > 
> > I am fearful of the overly strict lock down, too.  I mean, we already
> > ditched the entire payload.
> 
> Yeah, it's much reduced in flexibility from where it started.

That's because the original proposal was not very well defined at all.

> > But so long as you can always add a new action, what complaint do you
> > have?  In other words, all this does is force the use of the enum, which
> > ensures that we try to reuse existing actions, prevent typos, and so on.
> 
> 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?

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

All new "verbs" will be submitted to the same kind of review that any
other portion of the kernel code would be subjected to.  Nothing wrong
with that, right?

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

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

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

> There are *way* too many places (IMHO) where we throw a printk() and punt,
> or do something which is less than ideal.  If I had my druthers, we would
> examine most places that call printk() at runtime (not startup, etc) and
> figure out if an event makes more sense.

Please do.

> This model serves well for "eth0 has a link" and "hda1 was mounted" sorts
> of events. [Though namespaces make mounting a lot of fun.  Which namespace
> was it mounted on?  Why should my app in namespace X see an event about
> namespace Y?]

Yeah, namespaces are interesting :)

> If that is all it's good for, then it is better than nothing, though not
> as good as it might be.

Patches are always welcome.

thanks,

greg k-h
-
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/