>From the recent discussions it seems that there's some disagreement over exactly what device state should be preserved across suspend and resume. Is there a policy written down anywhere that tells what to do in situations like these?
For simple devices like mice and webcams, it's fine to just disconenct when suspending and re-enumerate on resume. Printers and scanners can be considered simple devices--I don't think it's reasonable to expect your printer to resume printing if you suspend your computer in the middle of a job. HOWEVER, all attached devices do need to keep their device nodes. They cannot re-order themselves arbitrarily while the machine is asleep. >From my limited tests, it appears that this is currently the case. Is there code in place that guarantees this? What if I move my printer from one hub to another one while the machine is asleep? If I re-order devices, but don't plug any new ones in or out, should that cause device nodes to switch? I don't have any USB devices that share device nodes so I can't test this now. Network devices are a bit more complex because they need to keep connections across suspend and resume. PCMCIA does this currently, but it only does it if devices are NOT reordered while the machine is asleep. If I have multiple devices and I reorder them while the machine is asleep, they will often get bound to different interfaces (eth1 and eth0 will be swapped). Open connections are still associated with the old interface, so now they're associated with a different device. If I quickly swap them back, the connections still work fine. This might be an obscure security risk...? Is this behavior acceptable for USB? If devices are re-ordered while the machine is asleep, then can it just enumerate the moved devices from scratch? That seems acceptable to me provided, of course, that all open connections are closed before associating an existing interface with a different device. Is there any way to bind a specific network connection to a specific device, so that it doesn't matter what order I plug the device in or out, or move it, all connections follow it and wait for it to be plugged in again? This would be very useful for both PCMCIA and USB. Finally, problem of storage devices is very similar to that of network devices, isn't it? Mount points (/mnt/filestick) are like network interfaces (eth0). Open connections are like open files. Both interfaces and mount points need to be set up when the device is inserted. So, if the networking issues above are completely solved, then are the storage issues completely solved too? Are these guidelines reasonable to use and reasonable to implement? - Scott _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
