Better device probe values

[John Baldwin]

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 <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org