From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 20 14:54:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6100BD4B for ; Thu, 20 Jun 2013 14:54:40 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 327EF1E7F for ; Thu, 20 Jun 2013 14:54:40 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so7219786obc.6 for ; Thu, 20 Jun 2013 07:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RFz8CFuSxofMRPgFhLSnivq+BkRGRbSO91TeTjJYb+o=; b=OGbogBq8oC0J3P3VIbCpmMTKTh/8PEfJIoEhG2MGVYZ/BAZ7qU7jwgH3jJtyTzageW 9XVohiIX8ZLHmbq1NNF0ke7JR0+eeGEefehm2YtJVijPhruDXb/KaiCrZcF1Tr2ffEvQ aENCVJ8RzUv2jzomdwBsYpJhhqMqolOPZVjF+88l+RLVp+M5e8HdUbVvxVhCTAEujZrP Re52d/n1d4G1avAoZwfkIOkbbOKxr/Jwdv+nP4HuEH7bkO1owBw42+7Wqu/GmKLI7aVY Gqi44v0XUSMA2Yq7guBGB3yoWMjv0wQPVMw+kBCDiq9D/nvCZxF3mG4fvsvUGYc1XPlM H8ew== MIME-Version: 1.0 X-Received: by 10.182.225.134 with SMTP id rk6mr1647596obc.40.1371740079798; Thu, 20 Jun 2013 07:54:39 -0700 (PDT) Received: by 10.76.123.76 with HTTP; Thu, 20 Jun 2013 07:54:39 -0700 (PDT) Date: Thu, 20 Jun 2013 10:54:39 -0400 Message-ID: Subject: BUS_PROBE_NOWILDCARD behaviour doesn't seem to match DEVICE_PROBE(9) From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 14:54:40 -0000 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?