From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 22:30:33 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 16E7A16A4BF for ; Thu, 11 Sep 2003 22:30:33 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C8C44400E for ; Thu, 11 Sep 2003 22:30:32 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 823 invoked from network); 12 Sep 2003 05:30:31 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Sep 2003 05:30:31 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8C5UR6Y051473; Fri, 12 Sep 2003 01:30:28 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030911.153929.44983352.imp@bsdimp.com> Date: Fri, 12 Sep 2003 01:30:27 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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 05:30:33 -0000 On 11-Sep-2003 M. Warner Losh wrote: > In message: > John Baldwin writes: >: I have thought about this as well, but instead of a placeholder flag, >: just doing this for any driver that returned a probe value != 0. >: This relies on very simple probes however, since ideally you would >: want to execute the new driver's probe and if it matches better, then >: you detach the old driver and attach the new one. This requires >: that the new driver's probe not try to alloc resources or dink with >: the hardware though. > > I've thought seriously about just detatching the older driver, if > possible. If that succeeds, we reprobe. This has the advantage of > being easy to implement, but does cause a fair amount of churn. 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. > 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/