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. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
