From owner-freebsd-current@FreeBSD.ORG Thu Aug 14 08:02:07 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 4ED7E37B407 for ; Thu, 14 Aug 2003 08:02:07 -0700 (PDT) Received: from smtp.goamerica.net (ny-mx-02.goamerica.net [208.200.67.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id E379743FDD for ; Thu, 14 Aug 2003 08:02:03 -0700 (PDT) (envelope-from eaja@erols.com) Received: from localhost (165.sub-166-141-30.myvzw.com [166.141.30.165]) by smtp.goamerica.net (8.12.8/8.12.8) with SMTP id h7EF1kvT019664 for ; Thu, 14 Aug 2003 11:01:48 -0400 (EDT) Date: Thu, 14 Aug 2003 11:01:13 -0400 From: Eric Jacobs To: freebsd-current@freebsd.org 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> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-portbld-freebsd4.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Thu, 14 Aug 2003 15:02:07 -0000 On Thu, 14 Aug 2003 14:30:06 +0000 Olivier Cortes 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