On Mon, Feb 16, 2009 at 11:22:08AM -0500, Alan Stern wrote: > On Mon, 16 Feb 2009, Jiri Kosina wrote: > > > On Sun, 15 Feb 2009, Phil Dibowitz wrote: > > > > > > I believe we should at least try to send "eject" command to these > > > > devices once they are detected, as that is sufficient to switch the > > > > mode for most of them, and I don't think it has potential to break > > > > anything. And we could simply. > > > An eject command doesn't work, and in fact there's userspace tools to switch > > > the mode. See the thread on linux-usb with the hardware manufacturer. > > > > Yes, I am aware of the tool. Quite unfortunate that we can't do this is > > kernel, it's very inconvenient for users. Oh well, just another proof that > > hardware vendors are ... uhm ... creative bunch of people. > > By the way, do any of you think it would help to have a userspace > utility program for sending an Eject command to a USB mass-storage > device even when that device wasn't bound to the usb-storage driver? I > could write such a utility without too much trouble. > Hmm, interesting idea. Well, wait, actually, I don't see how that would by us anything. In the current scenario we have nothing to blacklist and the user has to eject. If that tool exists, users expect us to blacklist these devices... and they still have to eject.... Am I missing something? -- Phil Dibowitz phil@xxxxxxxx Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
Attachment:
signature.asc
Description: Digital signature
