dev.* analogue for interfaces

Julian Elischer julian at
Tue Feb 19 18:45:05 UTC 2008

Dag-Erling Smørgrav wrote:
> Four years ago, I created the dev.* sysctl tree for device drivers.
> Every time a device is registered, a sysctl context is automatically
> created, and a node is created under dev (e.g. dev.cpu.0), with some
> standardized nodes under it (%driver, %parent, %desc etc.) plus any node
> the driver - or even another driver - wants to add.
> However, not everything in Unix is a device.  Specifically, network
> interfaces aren't.
> Some network interfaces are also devices, so they have a sysctl node in
> dev.*:
> % sysctl dev.msk
> dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x02
> dev.msk.0.%driver: msk
> dev.msk.0.%parent: mskc0
> Others don't: bridge, faith, lo, pflog, vlan etc.
> What I propose is to add a similar sysctl tree for interfaces.  It would
> look a little different.  For instance, some interfaces (bridge, vlan)
> have parents or children, but most don't.
> Just as it is for devices, creation and destruction of the interface's
> sysctl node and context would be hidden inside if_{attach,detach}() and
> completely transparent to the driver, and there will be an API that
> drivers can use if they want to add their own nodes.
> Since interfaces don't all have parents, the API will include a function
> to specify one for those that do.
> This is *not* intended to replace ifconfig; it is intended for infor-
> mation which isn't available through ifconfig and which it wouldn't be
> natural to place there.  For instance, every wlan interface already has
> a sysctl tree under net.wlan.
> Drivers that already have sysctl nodes will require less code to create
> them, and no code at all to destroy them, since if_detach() will take
> care of that (all nodes in the interface's context are automatically
> destroyed when the context is destroyed).
> I'm unsure whether this should go under net.if, or just if.  I think I
> prefer the latter.
> I'm open to objections and suggestions...

the usual things apply:

a) If you do the work most people would go along. :-)

b) being able to compile it without the bloat might be a good idea for
    embeded systems.


More information about the freebsd-arch mailing list