Date: Thu, 14 Aug 2003 11:01:13 -0400 From: Eric Jacobs <eaja@erols.com> To: freebsd-current@freebsd.org Subject: Re: usbd does not use detach Message-ID: <20030814110113.4d238ddd.eaja@erols.com> In-Reply-To: <1060504397.777.15.camel@syrenna.deep-ocean.local> References: <1059835661.1198.7.camel@Twoflower.liebende.de> <1060185309.676.1.camel@Twoflower.liebende.de> <1060504397.777.15.camel@syrenna.deep-ocean.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Aug 2003 14:30:06 +0000
Olivier Cortes <olive@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030814110113.4d238ddd.eaja>