From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 18:09:51 2005 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 76C7416A4CF for ; Wed, 23 Feb 2005 18:09:51 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDF0343D49 for ; Wed, 23 Feb 2005 18:09:50 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24415 invoked from network); 23 Feb 2005 18:09:50 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 23 Feb 2005 18:09:49 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1NI9d82024140; Wed, 23 Feb 2005 13:09:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 23 Feb 2005 12:57:12 -0500 User-Agent: KMail/1.6.2 References: <20050222.143230.41648746.imp@bsdimp.com> In-Reply-To: <20050222.143230.41648746.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502231257.12798.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org Subject: Re: Better device probe values 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: Wed, 23 Feb 2005 18:09:51 -0000 On Tuesday 22 February 2005 04:32 pm, Warner Losh wrote: > Greetings, > > >From time to time, the concept of a binary driver has been floated. > > The idea would be that a vendor could put out a binary driver disk > when there were bugs in the drivers for a specific release so that > users impacted by those bugs could still, for example, install that > specific release. > > However, most of the drivers in the base system do not allow this to > happen because they return 0. > > At the same time, we have a number of generic drivers in the tree that > have been using ad-hoc values to make sure that the right driver gets > attached (see for example pci and acpi pci, and friends). We also > have some drivers that overlap ranges of devices (eg, ncr and sym > drivers). > > So, I'd like to standardize on some names, and thought I'd post here > my first cut at the names. Let's not get too far off in the weeds, > since names is a prime bike-shed topic[*]. I'll likely ignore most of > that part of the discussion, and focus on the more technical and/or > political side of things. If possible, I'd like to have this wrapped > up in time for 5.4, but I do understand that time is extremely short > for that. > > /** > * Some convenience defines for probe routines to return. These are > * just suggested values, and there's nothing magical about them. > * BUS_PROBE_SPECIFIC is for devices that cannot be reprobed, and that > * no possible other driver may exist (typically legacy drivers who > * don't fallow all the rules, or special needs drivers). BUS_PROBE_VENDOR > * is the suggested value that vendor supplied drivers use. This is > * for source or binary drivers that are not yet integrated into the > FreeBSD * tree. Its use in the base OS is prohibited. BUS_PROBE_DEFAULT > is * the normal return value for drivers to use. It is intended that > nearly * all of the drivers in the tree should return this value. > * BUS_PROBE_LOW_PRIORITY are for drivers that have special requirements > * like when there are two drivers that support overlapping series of > * hardware devices. In this case the one that supports the older part > * of the line would return this value, while the one that supports the > newer * ones would return BUS_PROBE_DEFAULT. BUS_PROBE_GENERIC is for > drivers * that wish to have a generic form and a specialized form, like is > done * with the pci bus and that acpi pci bus. BUS_PROBE_HOOVER is for > those * busses that implement a generic device placeholder for devices on > the * bus that have no more specific driver for them (aka ugen). > */ > #define BUS_PROBE_SPECIFIC 0 /* Only I can use this device */ > #define BUS_PROBE_VEDNOR (-10) /* Vendor supplied driver */ > #define BUS_PROBE_DEFAULT (-20) /* Base OS default driver */ > #define BUS_PROBE_LOW_PRIORITY (-40) /* Older, less desirable drivers */ > #define BUS_PROBE_GENERIC (-100) /* generic driver for dev */ > #define BUS_PROBE_HOOVER (-500) /* Generic dev for all devs on bus */ > > Comments? > > Warner > > [*] And I really don't like the idea of there being a 20 message > sub-thread on HOOVER vs VACUUM vs KIRBEE or is that KIRBE, and it was > really so and so that invented the vacuum, etc. Please disappoint me > by not having one :-) Several typos, but that's minor. Sounds ok to me. Note that I think BUS_PROBE_GENERIC might not really be enough though (PCI bridge drivers are actually somewhat tricky, on x86 for PCI-PCI you have ACPI, PCIBIOS, MPTable, and generic for example), but for more tricky cases we can still use numeric values. s/HOOVER/ROOBA/ :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org