Hello, Kay. On Thu, Jun 09, 2011 at 02:36:54PM +0200, Kay Sievers wrote: > On Thu, Jun 9, 2011 at 13:54, Tejun Heo <htejun@xxxxxxxxx> wrote: > > Maybe we can tag events which were generated during open(2) with the > > pid of the opener so that udev can reliably filter them? I think it > > would be nice if we can somehow make it uni-directional (ie. no extra > > information from userland to kernel during open > > It's a cool idea. > > But I fear in reality it gets messy pretty fast. We would need to > track and remember all pids from tools executed by udev rules. > > With the fully async/queued nature of these events, we might not even > have read the events from the kernel after the event and the called > tools have long finished their work. > > We could use the session id or process group, but that sounds like > asking for trouble. I've been playing with the device a bit and this thing really is an abomination and reports new media whenever asked. :( I've been trying to come up with a way to work around the problem. The only thing we can do from kernel is somehow suppressing event generation on open (or mark it to be ignored) - be it timing or opener based; however, there's no way to acheive that in a race-free way. * Kernel must check whether media is changed upon open. * If at least one MEDIA_CHANGE event is not generated after device indicated the event, we risk losing events. ie. Media change can race against open() and userland may end up with stale information. The race window is quite short compared to usual tray actions tho. I think it would be better to avoid penalizing sane devices and let timer-based throttling take care of crazy ones. I don't know how udev handles it from userland but does it need to keep track of all the separate events? Can't it just track the pending states (ie. one bit for each event) and throttle propagation accordingly? Also, another thing is that as userland is now in charge of tray locking, maybe it's safe to ignore MEDIA_CHANGE while the device is known to be locked from userland? But, then again, I would be surprised if there isn't a device which is crazy enough to avoid such safe guard and still trigger weird behavior. :( Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
