usbd does not use detach

[Eric Jacobs]

On Thu, 14 Aug 2003 14:30:06 +0000
Olivier Cortes <olive at deep-ocean.org> wrote:

> Le Mer 06/08/2003 à 17:55, Jan Stocker a écrit :
> > Does nobody has this problem or does noone use this feature?
> 
> the problem i see with detach is the "utility" of the command.
> 
> example: my digital photo recorder.
> i have an attach script to mount automatically the partition on the
> cooresponding umass/da device. works great, and this helps.
> 
> but when detaching, the umount part should be done BEFORE detaching, not
> after. i can't find any good use for the detach hook. most of things
> should have been done before detaching, and i can't see how to do it
> without user interactivity, thus avoiding use of the detach hook.

The problem with this is that the system will be asking the FS to
e.g. flush buffers to a disk which it knows doesn't exist anymore, which
is an error (and will cause errors).

My proposal is that we need to amend newbus somewhat like this:

#
# Detach a device.  This can be called if the user is replacing the
# driver software or if a device is about to be physically removed 
# from the system (e.g. for pccard devices).  Returns 0 on success.
#
# The flags argument provides more information about the cause of
# the detach and the expected behavior of this function. Possible
# values:
#
#    DETACH_NORMAL: Detach succeeds only if no clients would be
#        affected by removing this device from the system. May
#        return EBUSY otherwise.
#
#    DETACH_FORCE: Clients using the device must be disconnected,
#        typically by revoking open file descriptors. May not
#        return EBUSY due to client activitiy, but may return
#        that or other errors due to hardware problems or
#        limitations.
#
#    DETACH_EJECTED: This call is made from a lower-level bus   
#        driver when the device has been physically removed from
#        the system. Like DETACH_FORCE, except that drivers can
#        avoid attemping (and failing) to reset the hardware
#        state. This request must succeed.
#
METHOD int detach {  
        device_t dev;
        int flags;
};

where each detach method call will now have a flags parameter
that provides enough information to handle the hot plug
scenarios you're describing.

In addition, the DETACH_FORCE and DETACH_EJECTED flags could
be mapped to appropriate flag values for the other subsystems, such
as MNT_FORCE and (a new) MNT_EJECTED flag for VFS.

> i once included a umount -f in the detach hook. after unplugin' the
> device, it resulted in a panic. i don't remember if the umount was
> causing it or if it was right after, when accessing the mount point or
> repluging the digital recorder.

Right, VFS needs to be clued in that the underlying device simply
isn't there anymore.

> anyway, i learned that umount -f is not
> meant to be used often... perhaps not on top of usb. for now.

umount -f is fine; however, it is not the same as the new 
DETACH_EJECTED condition that I'm proposing, which would handle this.

> i manually umount the device before unpluging it.

That is the only safe way to do it for now.

Eric