"Rafael J. Wysocki" <rjw@xxxxxxx> writes: > On Saturday 12 September 2009, Chris Ball wrote: >> Hi, >> >> > Well system could check basic card ids if they match after resume >> >> No. That (arguably) guarantees that it's the same card, but not that >> it wasn't modified in another machine during the suspend. > > Generally speaking, we'd also need to check superblocks for this to work. > >> > if some users wants to crash his card by randomly swapping it >> > during suspend/resume - I'd have no problem with that.... >> >> You should have a problem with it. Taking a card from a suspended >> machine and working on it with a different machine is not a bizarre >> thing to want to do. > > Agreed. Um... What happen if we moved remove event to resume sequence? I.e. The resume generates remove and insert event (or such revalidate). With this, I hope the suspend is not bothered by complex one, and the resume just ignores (if needed) previous state and notify it to userland by remove/insert event. And, userland process should unmount for removal devices before suspend process (as part of userland preparation)? If we assumed the removable device can be changed before resume, fs would need to recover process, to make sure in-core and on-disk state has consistent. Um..., for now, I feel the umount before suspend is only safe way. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
