On Tue, Mar 19, 2013 at 7:56 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 18 Mar 2013, Greg Kroah-Hartman wrote: > > > On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote: > > > > Why can't you just revert this in userspace? Isn't that easier than > > > > doing a kernel patch and providing an option that we need to now > > > > maintain for pretty much forever? > > > > > > I could solve it in userspace, but that really feels like a hacky > > > workaround and not a long term solution. It would mean that every new > > > device starts with persist enabled and stays that way for a few > > > milliseconds (maybe up to seconds if it's connected on boot), until > > > userspace gets around to disable it again... opening the possibility > > > for very weird race conditions and bugs with drivers/devices that > > > don't work with persist. > > > > What drivers/devices don't work with persist? We need to know that now, > > otherwise all other distros and users have problems, right? > > > > > This default is a policy that really resides in the kernel, it has > > > changed in the past, and since there is no definitive better choice > > > for all cases I thought making it configurable is the right thing to > > > do. > > > > Too many options can be a bad thing. > > > > I think Alan made this a "always on" option, so I'd like to get his > > opinion on it. Alan? > > Originally the "persist" attribute defaulted to "off". Linus disliked > this (at least, he disliked it for mass-storage devices) and so at his > request the default was changed to "on". There didn't seem to be any > reason to treat other devices differently from mass-storage devices; > consequently the default is now "on" for everything. > > Julius's commit message mentions the disadvantage of "persist": Resume > times can be increased. But it doesn't mention the chief advantage: > Filesystems stored on USB devices are much less likely to be lost > across suspends. > > The races mentioned above don't seem to be very dangerous. How likely > is it that the system will be suspended within a few milliseconds of > probing a new USB device? For laptops, if the suspend/resume is triggered by the lid open/close detection, this is somewhat likely and bit us in the past : the classical use case I have encountered is a back-to-back suspend triggered by the user opening the lid then closing it again in the next 2 or 3 seconds because he has changed is mind (damn user...), might be also triggered by lid hall sensor missing proper debouncing (but in that case, the mechanical time constant is often shorter than the latency of resuming USB devices). > > As for buggy devices and drivers that can't handle persist, we have > better ways of dealing with them. Buggy devices can get a quirk flag > (USB_QUIRK_RESET). Buggy drivers should be fixed. > > Alan Stern > -- Vincent -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
