On Tue, 2007-08-14 at 14:22 -0700, Edward Pilatowicz wrote:
> 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
My original proposal was to have this code live in genunix. But I'm
happy to be able to do something like this in probe(9e):
/* check if device is really for us... */
if (is_an_rtls_8139c) { /* we really should use rge here */
ddi_rename_node(dip, "SUNW,rge");
return (DDI_RENAMED);
}
Which would cause the kernel to reprobe if the node name changed,
possibly loading a different driver based upon the
contents /etc/driver_aliases.
This "hack" allows drivers to "hand off" (or, perhaps, defer) to another
node. (Possibly the DDI_RENAMED return value is not necessary...
ddi_rename_node could just set a bit in the devinfo node...)
It does require the drivers to conspire to do this, but I'm OK with
that.
I'm also OK if the initial versions of this are consolidation-private
only, while we experiment.
-- Garrett
>
>
> 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
