On Tue, Aug 14, 2007 at 12:26:46PM -0600, Mark J. Nelson wrote: > > > >> 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? >
because the devices we're trying to differentiate between are actually the same device? the case we're actually trying to handle is when one of these devices is connected a bridge/bus that we deem "special". ed _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
