On Friday 30 December 2005 14:26, Alan Stern wrote: > On Fri, 30 Dec 2005, Dmitry Torokhov wrote: > > > > There may indeed be other devices like that. If you can't handle device > > > removal while the system is running normally, why should you be able to > > > handle device removal while the system is suspended? > > > > > > > Because I can? > > > > > Conversely, even if the resume routine does detect somehow that the device > > > was removed, there's nothing it can do with that information if you don't > > > have a mechanism in place for handling device removals. > > > > > > > The subsystem can handle device removal, its just hardware does not > > give any notification when device is removed so subsystem has to rely > > on some external event (such as resume process) to query the device > > and check if it is still present. > > In that case, I would say that it is appropriate to use keventd or some > other worker thread to handle device removal detected during resume. > Since these threads will be frozen along with everything else, the > unregister calls wouldn't be made until the system was once again awake. > Input (well, actually serio) devices are already handled via kseriod thread, but that's because it was already there. I was saying that driver core should not require a reaper thread if there isn't one yet. > If you were really serious about it, you could even set up a work queue > to query each input device once per minute (say), to see whether it had > gotten removed. But that's probably overkill. Not only this is overkill but there are many devices with different ways to check for presence and quite often queies may disturb the device (i.e. right when you decide to tap on your touchpad my thread will decide that it is time for querying and will disable it, query and re-enable and that tap will be lost). -- Dmitry
