On Mon, 14 May 2007, Oliver Neukum wrote: > > > I agree. Hibernation with a mounted fs on usb sucks, no matter what > > > you do. > > > > Don't forget that "persistence" applies to network interfaces just as much > > as to block devices. > > Yes, but it is not problematic, as you run no additional risk. The worst > thing that could happen is that you assign an IP to the wrong interface. > But if the driver can't tell apart devices, neither can udev. > So you've got nothing to lose and a lot to gain.
A driver has more information available to it than usbcore does. With a network interface, the driver might be able to distinguish two devices based on their MAC addresses, even when usbcore can't tell them apart. (I really should add Serial Number string checking to the config_descriptors_changed() routine...) However I admit it's hard to think up a scenario where this would matter significantly. > > > I suggest a setting per interface in sysfs. > > > > That approach isn't feasible. For one thing, "persistence" applies to > > entire devices, not to interfaces. For another, we can't make a device > > persistent unless we also make all its ancestor hubs persistent. (If a > > hub disappears during resume then its children are destroyed too.) > > Well, we have again a distinction between device and interface > persistance. Some drivers and therefore interfaces will be unable > to support persistance. It must be possible to resurrect only some > interfaces of a device. In other words, it must be possible for a driver's post_reset() method to fail. That's a separate email thread. > On the core side persistance is asked for if a devices's interface or > a device lower in the tree want persistance. > > > While a per-device flag might be workable, I think the most > > straightforward approach is a single system-wide On/Off setting. > > Why? Treating a hard drive differently than a floppy seems very > reasonable to me. Maybe so, but you're putting a burden on both the core and the user. The core would have to check, when resuming a hub, whether _any_ of the hub's descendants want to be persistent. It can be done but it's messy. And then the user has to decide, for every device that gets attached, whether or not it should be persistent. You know, this problem isn't even unique to USB. Suppose you have an IDE CDROM drive, with a disc loaded and mounted, when you hibernate. Suppose a different disc gets put in the drive before you resume -- then what happens to your mounted filesystem? It's a general problem and it needs to be handled at the filesystem layer. Adding USB persistence doesn't really make it any worse. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
