>> To have "qfe" devices properly represented by the "qfe" driver, while >> allowing for "hme" devices to be seen by the "hme" driver, we need some >> code. The only differences between these two devices are: >> >> 1) qfe has a specific parent PCI bridge >> 2) different Fcode >> >> The point is that admins don't want to rename the devices for qfe to >> hme, because it will cause major conversion headaches. And on x86, it >> would be "nice" if qfe devices were still qfe (as they are on sparc) >> rather than being known by "hme" in the x86 hardware.
> Both examples sound too special to warrant for any change in the core > kernel, imho. I think if any quirks need to be implemented, they should > be confined within the driver modules. At least when devices EOL, the > ugliness goes away with the drivers; if you let ugliness into the DDI, > it's forever. In the update_drv(1M) manpage, we see that: > -a Add a permission, aliases, privilege > or policy entry. > > With the -a option specified, a per- > mission entry (using the -m option), > or a driver's aliases entry (using the > -i option), a device privilege (using > the -P option) or a a device policy > (using the -p option), can be added or > updated. If a matching minor node per- > missions entry is encountered (having > the same driver name and the minor > node), it is replaced. If a matching > aliases entry is encountered (having a > different driver name and the same > alias), an error is reported. ...the point being that "the binding mechanism doesn't know how to handle this situation." You can't fix this in the driver, because you can't bind multiple drivers to the same alias. Why is it ugly to extend the binding mechanism to allow greater differentiation between devices? --Mark _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
