BUS_PROBE_NOWILDCARD behaviour doesn't seem to match DEVICE_PROBE(9)

Ian Lepore ian at FreeBSD.org
Mon Jul 29 14:52:09 UTC 2013


On Thu, 2013-06-20 at 10:54 -0400, Ryan Stone wrote:
> http://www.freebsd.org/cgi/man.cgi?query=DEVICE_PROBE&apropos=0&sektion=0&manpath=FreeBSD%208.2-RELEASE&format=html
> 
> DEVICE_PROBE(9) has this to say about BUS_PROBE_NOWILDCARD:
> 
> The driver expects its parent to tell it which children to manage and no
> probing is really done. The device only matches if its parent bus
> specifically said to use this driver.
> 
> 
> I interpreted this as meaning that if BUS_ADD_CHILD() is called with the
> name parameter specifying a driver then if that driver's probe method
> returns BUS_PROBE_NOWILDCARD the driver will match that device.  However
> the logic in subr_bus.c is more strict; it will only match if the unit
> number if also specified.  This seems overly strict to me, and there
> appears to be at least one case in-tree where a driver will never match due
> to this behaviour:
> 
> http://svnweb.freebsd.org/base/head/sys/dev/iicbus/iicsmb.c?revision=227843&view=markup
> 
> The iicsmb driver calls BUS_ADD_CHILD() from its identify method with a
> wildcarded unit number (-1) but the driver specified.  It then returns
> BUS_PROBE_NOWILDCARD from its attach method(intending that it only claim
> the device created in the identify method), but that won't match.
> 
> I want to use the exact same pattern in a new driver.  The following patch
> allows this to work:
> 
> diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c
> index 1f3d4e8..7e48b0e 100644
> --- a/sys/kern/subr_bus.c
> +++ b/sys/kern/subr_bus.c
> @@ -2015,7 +2015,7 @@ device_probe_child(device_t dev, device_t child)
>                                  * in stone by the parent bus.
>                                  */
>                                 if (result <= BUS_PROBE_NOWILDCARD &&
> -                                   child->flags & DF_WILDCARD)
> +                                   !(child->flags & DF_FIXEDCLASS))
>                                         continue;
>                                 best = dl;
>                                 pri = result;
> 
> This should be safe to do, as all devices that specified a unit number must
> have specified a driver, so this can't cause any devices to suddenly fail
> to match.  I supposed that it theoretically could cause a driver to match a
> device that previously it wouldn't have, but I'm having trouble seeing how
> somebody could add a device of type "foo" and not expect the "foo" driver
> to attach.
> 
> Any objections if I commit this?

I know this is pretty long after the fact, but it looks like this never
got committed.  I recently had to port some drivers written for freebsd
4 and 6 to 8.2, and some of them have no real probe mechanism and
attached themselves to, like, *everything* (serial and parallel ports
and so on).  They're instantiated based on hints that are definitive, so
I switched to returning BUS_PROBE_NOWILDCARD and sanity returned.

Then I remembered this email, so I applied your patch and re-tested and
everything still worked perfectly.  Not exactly an exhaustive test, but
at least a positive datapoint.

-- Ian




More information about the freebsd-hackers mailing list