dev.* analogue for interfaces

[Dag-Erling Smørgrav]

Robert Watson <rwatson at FreeBSD.org> writes:
> Hmm.  When I look at net/if.c, I don't see renaming support, so
> perhaps this was just a proposal I was thinking of and not actual
> code.

no, it's there, check ifconfig(8)

> In either case, I think the question stands: in a world where
> interface renaming is supported, is your plan to also rename the if.X
> sysctl tree created for the interface? Does sysctl have a facility to
> do this?

I will have to investigate.  I think it can be arranged in some way.

> I assume that somehow the details of your plan involve automatically
> creating a root node for the interface in if_attach and then exposing
> the node to the driver, possibly via a new pointer in struct ifnet?

Via two functions (ifnet_get_sysctl_{context,root}() or something like
it) which internally use extra members in struct ifnet, yes (or wherever
it makes sense to place them without breaking the ABI)

> I'm certainly fine with such a notion, but think we should establish,
> for devices with a number of sysctl trees (i.e., dev.em vs if.em,
> dev.da0 vs disk.da0, etc), a general philosophy for placing nodes in
> one or the other somewhat deterministically.

Hardware-related things go in dev, network-related things go in if.  If
you want to tune the number of DMA queues or whatever, do it in dev; if
you want to allow traffic through a specific interface to bypass pfil,
do it in if (this may be something we want to do centrally for all
interfaces)

What happened when dev was introduced was that certain settings which
were previously system-wide for all instances of the same driver
(e.g. all fxp devices) became per-device instead.  I expect the same
will happen with if, for instance:

net.link.bridge.ipfw
net.link.bridge.log_stp
net.link.bridge.pfil_local_phys
net.link.bridge.pfil_member
net.link.bridge.pfil_bridge
net.link.bridge.ipfw_arp
net.link.bridge.pfil_onlyip

would go into

if.bridge.0.ipfw
if.bridge.1.ipfw

etc.

so we will actually gain functionality while in all likelihood reducing
the amount of code (and code duplication)

DES
-- 
Dag-Erling Smørgrav - des at des.no