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