On Sat, 11 Jun 2011, 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
> >
> > Not feasible.  usb-storage has no idea whether or not a device it
> > controls has a mounted filesystem.  (All it does is send SCSI commands
> > to a device and get back the results.)  Since that's the main use
> > case you're interested in, this part of the proposal seems destined to
> > fail.
> >
> 
> This is not completely true, I cannot rmmod usb-storage as long as
> disks using it are mounted. I know this is done through the global
> module usage count, so this is not per usb-storage device. But extending
> the ref counting to be per usb-storage device should not be hard.
> 
> All the accounting is already done for this.

It would be harder than you think.  All the accounting is _not_ already
being done.  What you're talking about would amount to a significant
change in the driver model core and the SCSI core.  It isn't just a USB
thing.

> > But userspace _does_ know where the mounted filesystems are.
> > Therefore userspace should be responsible for avoiding programs that
> > want to take control of devices holding these filesystems.  That's the
> > reason why usbfs device nodes are owned by root and have 0644 mode;
> > there're can be written to only by programs with superuser privileges
> > -- and such programs are supposed to be careful about what they do.
> >
> 
> Yes, and what I'm asking for is for an easy way for these programs to
> be careful. A way for them to ask the kernel, which in general is
> responsible for things like this and traditionally does resource
> management and things which come with that like refcounting: "unbind
> the driver from this device unless the device is currently in use".

Sure.  At the moment the kernel does not keep track of whether a device 
is currently in use -- at least, not in the way you mean.

I'm not saying this can't be done.  But it would be a bigger job than 
you think, and this isn't the appropriate thread to discuss it.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to