dev.* analogue for interfaces
Julian Elischer
julian at elischer.org
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.
>
> DES
More information about the freebsd-arch
mailing list