Garrett D'Amore writes: > driver.conf seems like a hack to expose things to the framework, whereas > normal driver.conf would be for non-global tunables for the driver (e.g. > per instance configurables, etc.)
It does seem sort of backwards (driver giving values to the framework rather than the other way around), but I think it makes some sense here. > I'm not sure that this is a stopper for this case, but I'd like the ARC > to consider whether or not some more general registry (ala > the /etc/driver_aliases, etc. registries) is perhaps better suited to > this kind of purpose. The problem with those registries is with upgrade. You have to support packaging scripts that may run on version N-2 (so, no new management utilities will work) and way too many people seem to get the update-central-file script wrong, breaking upgrade. As long as it's not too expensive in terms of performance to scan all those files on a cache miss, I think this is simpler to manage. Another way to do it would be in the ELF file itself (looking for a reference to ddi_devid_register or for some new _depends_on or -Nfoo/bar type thing), but that might be overkill. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
