From owner-freebsd-current@FreeBSD.ORG Thu Aug 14 21:46:49 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AA3737B407 for ; Thu, 14 Aug 2003 21:46:49 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7BD443F85 for ; Thu, 14 Aug 2003 21:46:46 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h7F4kIFN024677; Thu, 14 Aug 2003 22:46:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 14 Aug 2003 22:37:35 -0600 (MDT) Message-Id: <20030814.223735.103163505.imp@bsdimp.com> To: eaja@erols.com From: "M. Warner Losh" 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> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: usbd does not use detach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 04:46:49 -0000 In message: <20030814110113.4d238ddd.eaja@erols.com> Eric Jacobs 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