so in both the case of the rtls/rge and the hme/qfe, these
drivers special dependancies on eachother.
having the kernel randomly try multiple driver's doesn't really
make much sense. it sounds like you want multiple driver to be
able to probe a device and say "well, on a scale of 1 to 10,
i could drive this device at 7" and then we choose the driver
that says it's the best.
furthermore adding common code to driver binding to support
operations like:
if (pciid == blah) {
if (system("grep SUNW,qfe /dev/fcode") != 0))
use qfe
else
use hme
would also seems a little crazy.
so in the first there was an example piece of code,
check_rtl8139(). where does this code live? does it live in
one driver? so that it can had off to another driver? how
does the first driver know that the second driver is actually
installed? (the administrator may not want to use closed source
drivers so they may have uninstalled the second driver.) what's
the failure scenario? what if there are two second drivers?
in both cases of these driver pairs you have one driver that really
drives the device but want's to hand the device off to some other
driver if it is installed. this type of driver interdependancies
only exist because you've decided to have two seperate drivers
that now live as a pair.
that said, if we really want to have two seperate drivers, i guess
we could expand the path-oriented binding support to allow for
re-binding after the driver probe callback has been invoked.
(chris horne would have more insight into if this is even possible.)
probe is run for all devices, so if we did this one driver could
try handing off to another driver and just hoping for the best?
ed
On Tue, Aug 14, 2007 at 01:50:59PM -0700, Artem Kachitchkine wrote:
>
> > We could allow multiple drivers to be associated with a compatible name
> > and try to attach them one by one. In case of "not identified",
> > attach(9e) would return something other than generic DDI_FAILURE. Might
> > be worth exploring this direction.
>
> ... attach or probe, whatever is more suitable, but is not essential.
> What needs thought is whether multiple drivers associated with one
> device can break anything in a big way.
>
> -Artem
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
