usb: use IRQ watching
in [Kernel]
|
Prev: [PATCH 19/30] workqueue: make single thread workqueue shared worker pool friendly
Next: [PATCH 13/30] workqueue: reimplement work flushing using linked works
From: Jean Delvare on 15 Jun 2010 07:10 On Tue, 15 Jun 2010 12:30:00 +0200, Kay Sievers wrote: > On Tue, Jun 15, 2010 at 00:19, Tejun Heo <tj(a)kernel.org> 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. > > 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. :) > > 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. Random idea of the day (I don't know anything about it all): let the kernel connect to D-Bus and use it somehow? -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 15 Jun 2010 07:30 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 15 Jun 2010 09:40 On Tue, Jun 15, 2010 at 13:20, Tejun Heo <tj(a)kernel.org> wrote: > 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? 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. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 15 Jun 2010 09:40 On Tue, Jun 15, 2010 at 13:05, Jean Delvare <khali(a)linux-fr.org> wrote: > On Tue, 15 Jun 2010 12:30:00 +0200, Kay Sievers wrote: >> On Tue, Jun 15, 2010 at 00:19, Tejun Heo <tj(a)kernel.org> 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. >> >> 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. :) >> >> 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. > > Random idea of the day (I don't know anything about it all): let the > kernel connect to D-Bus and use it somehow? Yeah, D-Bus is an peer-to-peer IPC mechanism/protocol. The D-Bus daemon can filter and multiplex/distibute messages. It's very similar to what we can do with netlink. The netlink multicast stuff can even provide lots of the functionality the D-Bus daemon provides. I think we should avoid the D-Bus complexity for the very low-level stuff. Very much like udev is not using it, but has efficient in-kernel message filtering based on Berkeley Packet Filters, and multiple listeners event subscription/distribution based on netlink multicast functionality. Not sure if netlink is the right answer here, but it's surely easier to handle than D-Bus, and would provide a very similar functionality. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 15 Jun 2010 13:40
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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |