Hi, On Fri, Jun 10, 2011 at 02:19:20PM +0200, Hans de Goede wrote: > >>>>So what do we need to make this situation better: > >>>>1) A usb_driver callback alternative to the disconnect callback, > >>>> I propose to call this soft_disconnect. This serves 2 purposes > >>>> a) It will allow the driver to tell the caller that that is not > >>>> a good idea by returning an error code (think usb mass storage > >>>> driver and mounted filesystem > >>> > >>>I'm not sure you even need a driver callback for that. Should we leave > >>>that to Desktop manager ? > >> > >>Not sure what you mean here, but we need for a way for drivers to say > >>no to a software caused disconnection. See my usb mass storage device > >>which is still mounted getting redirected to a vm example. This cannot > > > >in that case, why don't you just flush all data and continue ? Also, > >desktop manager knows that a particular device mounted, so it could also > >ask the user if s/he wants to continue. > > > >I'm not sure preventing a disconnect is a good thing. > > I assume you are sure preventing data loss is a good thing? Because in > this example the 2 are the same. > > Also note I'm not suggestion at always preventing the disconnect, I'm > suggesting to add a new try_disconnect ioctl, which apps which want > to behave nicely can use instead of the regular disconnect ioctl, and > then drivers can prevent the disconnect. Apps using the old ioctl will > still get an unconditional disconnect as before. I'm just not sure if this should sit in the kernel. You can easily have some sort of device manager (much like udisks for storage) to track this down for ya. So instead of calling usbfs straight, you need to go via the "device manager". This device manager should know that before calling 'disconnect' it must be sure there's nothing pending. > >>One could also argue that making the existing disconnect ioctl return > >>-EBUSY in some cases now is an ABI change. > > > >OTOH, if the user really wants to move the usb device to the guest OS, > >he has just requested for that, so should we prevent it ? what we need > >is for the applications to be notified to exit cleanly and release the > >device because the user has requested to do so. No ? > > We are talking about a device with a mounted file system on it here, > any process could be holding files open on there, and there currently > exists no mechanism to notify all apps to exit cleanly and release > the files. Even if there were some method for a desktop environment > like gnome to ask apps to release those files, and all gnome apps > where to be modified to support that mechanism, then there are still > 1000-s of non gnome (or kde, xfce, whatever) apps which will not > support that. Still, I'm not sure this is argument good enough to add another sort of conflicting ioctl to the kernel. It won't prevent apps from calling the other disconnect anyway. And besides, if an app can be modified to use the try_disconnect ioctl, they can be modified for the system notification (on userland) too, can't they ? > We already have a mechanism to cleanly close down a filesystem, it > is called unmount. And it will fail if apps have files open. All I'm > suggesting is forwarding this ebusy failure to the application > trying to disconnect the driver from the usb mass storage interface. > > Simply removing the filesystem from under apps holding files open will > lead to io errors, and very unhappy apps. Correct, but does the solution _have_ to sit in kernel ? I'm not sure. If you add the try_disconnect ioctl and all applications one your desktop, except one, are playing nice, you will still have problems. To me, it sounds much nicer to add such things on userland alone, in a way such that it doesn't matter if it's a usb storage, mmc card, or eSATA drive. That should be hidden from apps IMHO. -- balbi
Attachment:
signature.asc
Description: Digital signature
