Hello, Kay. On 06/15/2010 12:30 PM, Kay Sievers wrote: >> Hmm... maybe what we can do is generating an uevent when an IRQ is >> confirmed to be bad and then let udev notify the user. That way we'll >> probably have better chance of getting bug reports and users have >> whiny but working system. > > Not really, uevents are not picked up by anything that could report an > error to userspace, they are just seen by udev. Also uevents are > usually not the proper passing method. They are not meant to ever > transport higher frequency events, or structured data. They cause to > run the entire udev rule matching machine, and update symlinks and > permissions with every event. Oh, these will be very low frequency event. At most once per irq_expect or irqaction. e.g. on a machine with four hard drives, it can only happen four times after boot unless the driver is unloaded and reloaded, so from frequency standpoint it should be okay. > We will need some better error reporting facility. On Linux you don't > even get notified when the kernel mounts your filesystem read-only > because of an error. It will only end up in 'dmesg' as a pretty much > undefined bunch of words. :) That one is a very low frequency too. > We will need some generic error reporting facility, with structured > data exported, and where userspace stuff can subscribe to. > Uevents/udev can not really properly provide such infrastructure. > Maybe that can be extended somehow, but using kobject_uevent() and > trigger the usual udev rule engine is not what we are looking for, for > sane error reporting. It's true that there are higher frequency events which will be horrible to report via kobject_uevent(). Hmmm... but the thing is that events which should annoy the user by userland notification can't be definition high freq. There's only so many users can recognize and respond, so the frequency limitation of uevent might actually fit here although it would be nice to have some kind of safety mechanism. Still no go for uevent? 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
