From owner-freebsd-arch Sun Jun 23 16:12:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 7120237B400 for ; Sun, 23 Jun 2002 16:12:17 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g5NNCGY71951 for ; Sun, 23 Jun 2002 17:12:16 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g5NNCFG46255 for ; Sun, 23 Jun 2002 17:12:15 -0600 (MDT) (envelope-from imp@village.org) Date: Sun, 23 Jun 2002 17:12:00 -0600 (MDT) Message-Id: <20020623.171200.96231110.imp@village.org> To: arch@freebsd.org Subject: It is time to admit that removable devices exist From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Please find enclosed the beginnings of a patch to make removable devices better represented in the system. Right now all it adds is a mechanism by which client drivers can ask if the device is still really there or not. The new bus_if method would be "child_present". The default, implemented in the nexus, would return "yes." However, busses that can have their devices removed, and can have knowledge of such an event, are expected to override the bus_child_present method. In that method, they are expected to make the determination, by direct inspection of the hardware if possible, if the device is really there or not. child_present is expected to return 0 when the device is gone, and a -1 when the device is present. This also happens to be binary compatible with old releases since when you call a method that isn't in a device's method table, it return ENXIO. This is non-zero and is the most compatible thing you can return. Drivers that wish to cope on their own with systems too old to have this call can check for 0 or -1 directly and if not one of those two methods, they are free to adopt their own ad-hoc methods for dealing. I expect there to be no such drivers, but it never hurts to design for them. Most client drivers will check for == 0 or != 0. Why do we need this? Many device drivers do not properly deal with device gone conditions. When the device disappears, they either loop forever waiting for a bit to clear, or they have some kind of kludge that prevents this from happening (0xff is magic, limits on the number of loops, etc). It would be much cleaner if a device had a bus-independent way to ask these questions. I plan to implement this for both OLDCARD/NEWCARD soon, and also to MFC it into -stable since it is useful and also backwards compatible. It will likely be one of the last things that I do to OLDCARD. Comments? See http://www.freebsd.org/~imp/dev-gone.20020623 for a diff. Warner P.S. I just noticed that I don't have nexus driver changes for each of our platforms. Of course I'll do that before I commit the code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message