--cmojth4sdaU3VRJa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 01, 2007 at 05:25:17PM +0200, Julio M. Merino Vidal wrote:
[...]
> AIUI, as genfb returns 5 during match and intvid returns 1, autoconf =20
> should simply discard intvid and use genfb, isn't it?  It should =20
> behave as if intvid's match returned 0, as the last test I did.  But =20
> for some reason there seems to be a problem in this.  Or is my =20
> reasoning wrong?

No, and yes.

Not that anyone should blame you here.  autoconf(9) is very confusing,
and in my work-in-progress renewal of the API, I chose to make direct
and indirect configuration unmistakenly distinct.

obio(4) is not a direct configuration bus.  That means that the bus
doesn't know its children exist.  This is the same as isa(4).  Therefore
the "match" function of a driver is really a "probe" function.  A direct
configuration bus uses one of the variant of config_search(9) to attach
its children.

config_search(9) is driven by the kernel configuration file, and _not_
the hardware.  It helps the parent bus enumerates its potential (per the
configuration file) children, and let the drivers _probe_ for devices.
And each time a driver says it found a device (i.e., "match" function
returning non zero), the parent bus lets said driver attach.

If there are two drivers for a given device, then they have to
co-operate, because the parent bus has no way to know they probed the
same actual device.

You have ways around that:  for instance, you could use config_defer(9)
in intvid(4) so that it doesn't do any actual work if a genfb(4) has
attached to obio(4).

In the case of direct configuration, things are of course very
different:  the parent knows there is a device, and indeed wants the
best driver for it.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

--cmojth4sdaU3VRJa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iQEVAwUBRtmZF9goQloHrPnoAQI9uAgAixy0ZeSjejOphmOgEBqstG63AAbIDumK
20anbnEfw0LI0X1h0KMq2LzOjzalnsoguA/zBy1fYekJADJqg4shfDLXpaLon2oq
Vsu4IrAALa8IlUUFVgEbErbHAZLmkii8ULUDCXBil1zKk2KgtA7v/si4DQOsIsyK
0D98PJqU0rl0o4e2019Ty9U497Kr6npEY/rbCmAAsqMwC9clvWtgFVyAd/0tNnKB
b2eHfYPPSA8Su82MPZqELbaFPgUdZs+nFLdCnLWPXlyziE/iun2YKfQI+gXbrF62
PZRfRCnLAjDgoiO2vCGXo5MoctQZ6fEw7uuBnHs2JN4yxQ9wU6pxMA==
=D6+j
-----END PGP SIGNATURE-----

--cmojth4sdaU3VRJa--