cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h

[Scott Long]

Maxime Henrion wrote:

> Scott Long wrote:
> 
>>Maxime Henrion wrote:
>>
>>>mux         2004/06/02 15:52:18 PDT
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>>   sys/dev/fxp          if_fxp.c if_fxpvar.h 
>>> Log:
>>> Use the device sysctl tree instead of rolling our own.  Some of the
>>> sysctls were global (hw.fxp_rnr and hw.fxp_noflow), all of them are
>>> now per-device.  Sample output of "sysctl dev.fxp0" with this patch,
>>> with the standard %foo nodes removed :
>>> 
>>> dev.fxp0.int_delay: 1000
>>> dev.fxp0.bundle_max: 6
>>> dev.fxp0.rnr: 0
>>> dev.fxp0.noflow: 0
>>> 
>>> Revision  Changes    Path
>>> 1.213     +18 -24    src/sys/dev/fxp/if_fxp.c
>>> 1.31      +2 -2      src/sys/dev/fxp/if_fxpvar.h
>>
>>Not having the ability to deal with global settings is a bit
>>of a pain.  I had envisioned that something like this would
>>be:
>>
>>dev.fxp.N.instance_variable
>>
>>dev.fxp.global_variable
> 
> 
> It doesn't matter for the rnr sysctl, which is just a counter of RNR
> events.  It used to be read/write though, but that was bogus because
> it's never read in the code, and only incremented, so I changed it to
> be read-only.
> 
> The noflow sysctl is actually a tunable so most of the time people
> using it are already forced to use it per-device since AFAIK, tunables
> are only per-devices.  It's however a read/write sysctl because since
> it's read in fxp_init(), it could be useful to set it to 1 and just
> run "ifconfig fxp0 down; ifconfig fxp0 up" so that it's used.  But
> once you know you need this, you'll want to set it as a tunable
> anyway.
> 
> Now I think you're raising a problem that we're likely to have in a
> near future when more drivers are converted to use the device sysctl
> tree, and when those drivers have settings that are likely to be
> useful globally.  I already pondered having devinfo(8) renamed to
> devctl(8) and handle settings we want to do on devices via the
> sysctl device tree.  Taking the detour through a userland program
> would allow us to have more elaborated features, like setting
> something on all devices at once.
> 

Yes, but that doesn't work if you need to tweak a tunable from the
loader in order to get the machine to boot.  Although the tunable
tree and the sysctl aren't exactly married together, it is common
to have them mirror their nodes for consistency.

Scott