From owner-freebsd-arch@FreeBSD.ORG Fri Sep 12 00:39:18 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB09F16A4BF; Fri, 12 Sep 2003 00:39:18 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A59C43FE3; Fri, 12 Sep 2003 00:39:17 -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 h8C7dFTX039915; Fri, 12 Sep 2003 01:39:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 12 Sep 2003 01:39:11 -0600 (MDT) Message-Id: <20030912.013911.13774129.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20030911.153929.44983352.imp@bsdimp.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: arch@freebsd.org Subject: Re: When to burn those bridges X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2003 07:39:18 -0000 In message: John Baldwin writes: : How do you know which drivers to detach? Are you going to detach : the generic PCI ATA driver on every kldload? Are you going to : detach the generic PCI-PCI bridge driver for PCI-PCI bridges on : add-on cards for every kldload of a PCI driver? That would be : freaking insane. The problem is that you don't know what devices : a new driver might be more suitable for than existing drivers. This does suck. : > Besides, proble routines on self enumerating devices should look at : > the IDs that anybody can look at at any time. However, there are some : > issues with some drivers that have old/new versions or that need to : > ask the hardware what kind of thing it really is before making the : > call. These drivers are rare, thankfully, and even rarer are those : > that have different levels. owi/wi is the only one I know of that : > fits this bill, and the only reason owi is there is to help fix wi, so : > I don't think we should necessarily design to make this sort of thing : > too easy.... : : rl(4) and re(4)? Several drivers still allocate resources in probe(), : which would break things. yea, but that's a bit of a pathological case. first, rl/re attach to a specific driver, and not override. So maybe we could mandate that drivers that are generic and return negative return values should be constrained to only look at the plug and play info and are not allowed to look at resources. owi/wi is the only pair that does this evilness. Warner