Date: Thu, 14 Aug 2003 22:37:35 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: eaja@erols.com Cc: freebsd-current@freebsd.org Subject: Re: usbd does not use detach Message-ID: <20030814.223735.103163505.imp@bsdimp.com> In-Reply-To: <20030814110113.4d238ddd.eaja@erols.com> References: <1060185309.676.1.camel@Twoflower.liebende.de> <1060504397.777.15.camel@syrenna.deep-ocean.local> <20030814110113.4d238ddd.eaja@erols.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20030814110113.4d238ddd.eaja@erols.com>
Eric Jacobs <eaja@erols.com> writes:
: # 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.
These two are redundant. Devices can already ask the bridge driver if
the device is still present on the bus. Smart drivers already do
this, but most of the drivers in the tree are dumb. You also have to
deal with device disappearance in ISRs since it is possible for the
device to go away while the device is in the middle of the ISR. Some
bus technologies also allow interrupt entry when a card/device is
ejected.
: 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.
The problem is that when you are detaching a device, it is gone when
you return from the detach routine. It can be hard to know what
buffers (disk, network, etc) in the system refer a given newbus device
because there's not a one to one mapping for the device_t to dev_t
that the rest of the system uses. Devices may or may not know about
buffers that are outstanding. Work would be needed in the buf/bio
system to reference cound the dev_t so that when the driver destroys
it, it doesn't go completely away until the reference count goes to
zero. However, doing that may have unfavorable performance impacts.
: > i manually umount the device before unpluging it.
:
: That is the only safe way to do it for now.
Agreed.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030814.223735.103163505.imp>