From owner-freebsd-arch@FreeBSD.ORG Tue Feb 22 21:32:44 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 E460616A4CE for ; Tue, 22 Feb 2005 21:32:44 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E700A43D2F for ; Tue, 22 Feb 2005 21:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j1MLWUlP015564 for ; Tue, 22 Feb 2005 14:32:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 22 Feb 2005 14:32:30 -0700 (MST) Message-Id: <20050222.143230.41648746.imp@bsdimp.com> To: arch@freebsd.org From: Warner Losh X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 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: Tue, 22 Feb 2005 21:32:45 -0000 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 :-)