On Sun, Jun 12, 2011 at 14:28, Tejun Heo <htejun@xxxxxxxxx> wrote: > I've been playing with the device a bit and this thing really is an > abomination and reports new media whenever asked. :( Yeah, it looks pretty broken. > 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. Right, and both are not easy to manage. An open flag is hard to decide when to use it, especially for tools shared by udev and possibly other callers. The timer based solution is kinda weird inside the kernel. And unfortunately, we still have userspace polling, which currently triggers this behaviour once a second. > * Kernel must check whether media is changed upon open. Sure. We follow GET_EVENT_STATUS_NOTIFICATION now. Can't we always force TUR when we open() the device from userland? That's what we did in the past, didn't we? The in-kernel polling would still not need to do that, and the periodic usespace polling is about to die pretty soon. > * 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. That would be pretty hard to debug, I guess. :) > 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? It's just a queue of events. Every event currently generates 3 new ones in the kernel from the open() in the event event handler. We would need to ratelimit that and discard all already queued events when we decide that it's a loop. We can not generally coalesce events in udev, as they might carry different properties added from subsystems we need to read. This loop would be triggered from new once a second with the current tools. > 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. Â:( Guess we need to make it work with current stuff too, and not rely on the door lock. Kay -- 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
