On Wed, 2007-08-22 at 14:45 -0400, James Carlson wrote:
> 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.
Why not allow the driver itself to set a property. THe framework can
see the property being created, and maintain the master registry on the
driver's behalf, rather than requiring packaging scripts to "do the
right thing".
-- Garrett
