per-device sysctls

John Baldwin john at baldwin.cx
Thu Feb 26 14:21:33 PST 2004


On Thursday 26 February 2004 03:02 pm, M. Warner Losh wrote:
> In message: <xzphdxdk690.fsf at dwp.des.no>
>
>             des at des.no (Dag-Erling Smørgrav) writes:
> : Robert Watson <rwatson at freebsd.org> writes:
> : > Having a unified and managed namespace for device sysctls sounds like a
> : > generally good idea to me, as more and more devices require some of
> : > another tweaking.  Have you had any thoughts on how to name sysctls and
> : > kernel environment variables on a per-driver basis, rather than a
> : > per-device basis?  I.e., fxp and some other device drivers have
> : > configuration settings that affect all instances of devices, rather
> : > than specific instances.
> :
> : It should be easy to add a per-devclass_t or per-driver_t sysctl
> : context and tree.  These things are disgustingly easy to create; the
> : only hard part is figuring out when and where to create them.
>
> You'd need to have devclass as well as dev trees, but that's easy to
> do.  We have hw.tsc.<driver>.<stat> sysctls for all the drivers at
> work, and it would be nice to have a more general framework to put
> stuff like that into.
>
> It would be nice if there was some kind of tie-in to tunables as well,
> since many drivers have tunables that are global, but might want to be
> less global.

Maybe 'dev.foo0.bar0' for devices, and 'driver.foo' are things specific to the 
foo driver, though really that would have to be devclass.foo.  Drivers can 
have the same names, so that gets harder.  E.g., we have multiple pci(4) 
drivers and multiple pcib(4) drivers.  So you couldn't just have a 
'driver.pci'.  You could have a 'devclass.acpi/pci' and a 'devclass.pci/pci' 
though for class-wide things perhaps.  Drivers are a much harder nut to crack 
given that they don't really have a sensible uniquifier.

-- 
John Baldwin <john at baldwin.cx>  <><  http://www.baldwin.cx/~john/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-arch mailing list