On Tuesday 26 February 2008, David Newall wrote: > > Hardware can be inserted and removed while we're in a suspend state; and > there's nothing that we can do about it until we resume. Is it fair to > say, then, that having started suspend, we could reasonably ignore any > device insertion and removal, and handle it on resume?
"Ignore" seems a bit strong; those events may be wakeup triggers, which would cause the hardware to make it a very short suspend state. "Defer handling" is more to the point, be it by hardware or software. > Presumably we need to scan for hardware changes on resume. Not on most busses I work with; the hardware issues notifications whenever the devices are removable. Which is a Good Thing ... scanning, as you suggest, is inherently not reliable. If a mouse is swapped, it likely doesn't matter a lot whether it's the "same" or not. But ... how about if some removable storage media was taken out, updated on a different system, then restored before the resume? Not many filesystems handle that sanely. You *really* want to have hardware which reports disconnect/reconnect events, or which physically prevents them (locked case etc). - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
