Re: [patch] kernel sysfs events layer

[Tim Hockin]

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.

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

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.

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

I'd like to ACPI events move to a standardized event system, but they
*require* a data payload.

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.

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?]

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

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/