Date: Fri, 15 Aug 2003 11:00:16 -0400 From: Eric Jacobs <eaja@erols.com> To: freebsd-current@freebsd.org, imp@bsdimp.com Subject: Re: usbd does not use detach Message-ID: <20030815110016.00c00356.eaja@erols.com> In-Reply-To: <20030814.223735.103163505.imp@bsdimp.com> References: <1060185309.676.1.camel@Twoflower.liebende.de> <1060504397.777.15.camel@syrenna.deep-ocean.local> <20030814110113.4d238ddd.eaja@erols.com> <20030814.223735.103163505.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Aug 2003 22:37:35 -0600 (MDT) "M. Warner Losh" <imp@bsdimp.com> wrote: > 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. How does one do this check? It is not obvious, which may explain why there are so many dumb drivers in this regard. Another factor that aggravates this is that in some cases, the driver itself may not care about this check, but its clients will. For example, umass may well not need to do anything different depending on whether it was unloaded or its device was unplugged. But the layers below it, CAM, GEOM, and VFS, may still need that information. And they aren't going to know what the USB device is, much less how to query for its existence. It seems to me that the solution for "dumb" drivers is to make it as easy for them to be smart, by doing as much as possible in the bus driver. > 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. Right. I haven't looked at the code extensively, but I believe the GEOM "orphanage" concept handles this well. When the disk_destroy is called during the device detach, it means that GEOM will take over returning errors to clients who still may be trying to use the device, so that those requests won't get sent to the device, and the device would be safe to delete. > 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. This exists in GEOM, see struct g_bioq and the nstart and nend fields of struct g_consumer. I don't know if it actually handles the hot-unplug scenario, though. The design should be able to handle it. > : > i manually umount the device before unpluging it. > : > : That is the only safe way to do it for now. > > Agreed. > > Warner Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815110016.00c00356.eaja>