Re: [PATCH 12/12] usb: use IRQ watching

[Greg KH]

On Tue, Jun 15, 2010 at 07:36:12PM +0200, Tejun Heo wrote:
> Hello,
> 
> On 06/15/2010 03:36 PM, Kay Sievers wrote:
> > Yeah, I'm pretty sure that's not what we want. We want structured
> > data, and a generic channel to pass all sort of errors through, and a
> > userspace part to handle it in a sane way. Many error sources may also
> > not have a device path in /sys, and therefore no uevent to send.
> > Uevents/udev just seem so convinient because it's already there, but I
> > think, has too many limitations to provide the needed functionality.
> > Besides the fact that nothing listens to these events in userspace
> > today -- it's a lot more to think through and work on than passing
> > things through uevents, especially some generic classification and
> > structured data passing, which is needed, instead of the current
> > free-text 'dmsg' or the property-based stuff in uevents. I'm very sure
> > it's the wrong facility to use.
> 
> Yeah, well, if you say so.  It would be very nice to have report this
> type of critical events in somewhat formatted way so that they can be
> processed automatically and presented to the user in more accessible
> manner.  I doubt requiring strict structure would work in the long
> run.  It'll likely end up being able to cover only portion of what's
> originally designed and and stagnate in time.  I think control
> information including identification and severity + free form string
> would be much more manageable.
> 
> It would really be great to have something like that.  I can easily
> think of several libata events the user should be notified of from the
> top of my head but currently are buried in dmesg.

That is what Andi Kleen and others are working on at the moment.  I
think he's posted to lkml about it, and there are going to be more talks
about it at the Plumbers conference this year.

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/