From owner-freebsd-current@FreeBSD.ORG Fri Aug 15 10:58:39 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 24D9537B416 for ; Fri, 15 Aug 2003 10:58:36 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 720DC43F3F for ; Fri, 15 Aug 2003 10:58:35 -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 h7FHwWFL029943; Fri, 15 Aug 2003 11:58:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 15 Aug 2003 12:00:07 -0600 (MDT) Message-Id: <20030815.120007.82100259.imp@bsdimp.com> To: eaja@erols.com From: "M. Warner Losh" In-Reply-To: <20030815110016.00c00356.eaja@erols.com> References: <20030814110113.4d238ddd.eaja@erols.com> <20030814.223735.103163505.imp@bsdimp.com> <20030815110016.00c00356.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 17:58:40 -0000 In message: <20030815110016.00c00356.eaja@erols.com> Eric Jacobs writes: : > 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. : : How does one do this check? It is not obvious, which may explain why : there are so many dumb drivers in this regard. # # Is the hardware described by _child still attached to the system? # # This method should return 0 if the device is not present. It should # return -1 if it is present. Any errors in determining should be # returned as a normal errno value. Client drivers are to assume that # the device is present, even if there is an error determining if it is # there. Busses are to try to avoid returning errors, but newcard will return # an error if the device fails to implement this method. # METHOD int child_present { device_t _dev; device_t _child; } DEFAULT bus_generic_child_present; It is recently added. : 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. Well, somebody has to talk to hardware, and that somebody has to cope. And the problem is we can : 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 aren't making things easier. You have: switch (foo) { case DETACH_FORCE: flush(); /* fall through */ case DETACH_EJECT: ... } vs if (bus_child_present(dev)) flush(); ... : > : 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. If this is true, then no driver work should be necessary at all for disk devices. However, the upper layers don't deal too well with errors flushing. And it does nothing for network drives that have similar problems. Warner