dev.* analogue for interfaces
rwatson at FreeBSD.org
Wed Feb 20 11:18:39 UTC 2008
On Tue, 19 Feb 2008, John-Mark Gurney wrote:
> Dag-Erling Smrgrav wrote this message on Tue, Feb 19, 2008 at 18:43 +0100:
>> 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.
>> I'm open to objections and suggestions...
> My concern is that slowly adding them for each interface type could create
> some conflicts in both naming and location...
We also support interface renaming... Does newbus mind if you rename the
devices in its tree?
> Are the interface sysctl nodes going to be the same/mirrored for hardware
> devices? Does dev.msk.0 get duplicated in the interface area? or does it
> have to decide to put ethernet interface related items in the if sysctl
> node, and other hardware related (hi/low water marks for DMA) in the
> seperate tree? How does someone know where to look if they are in different
> locations for the same device?
> We should probably create a newbus tree node off the nexus for psuedo
> devices that are not backed by hardware, and put all of these style devices
> under them... This will help enforce non-conflicting names, and limit the
> number of locations where sysctl can be located for devices... This would
> mean that ifnet would/should grow a device_t and can either get stored w/
> one provided in the hardware case, or one get automaticly created if one
> isn't provided... This would enable all psuedo devices to have a single
> location, and you not have to search to remeber, oh, there's net.if, dev.,
> tty.if, disk., or some other set of random psuedo devices...
> I'm all for making it easier for devices to export configuration
> information, I just want to ensure that it's easy to find and locate, since
> documentation usually comes last... (I still need to write a man page for
> my bktrau device driver. :) )
I'm not sure how I feel about creating newbus device trees for all network
interfaces. I like the idea of a unified bus topology but wonder about the
constraints -- among other things, we have no Giant requirement for network
stack interface allocation. Perhaps the problem is that I feel uncomfortable
with the assumption that creating a 1:1 mapping between hardware device nodes
and logical interface nodes is the right thing to do.
And, about interface renaming: right now, the newbus nodes for the physical
device have a constant name, we just change the administrative name of the
interface used in the network stack. I don't think we want the
hardware-related nodes to be renamed, but under what situations is a MIB entry
going to be associated with the stack name, and under what situations the
hardware name? Perhaps we should have an entirely seperate if.* subtree in
order to keep the two notions distinct.
Another thought: historically, things like link layer administration, etc,
have used the stack name for an interface and stack management tools -- that
is, ioctl and the interface identifier. While I'm not a big fan of ioctl,
this has been a relatively consistent approach for dealing with administering
everything but global protocol settings (which sometimes go via sysctl). I'm
not sure I'd like to see that change on the basis that, while possibly not
entirely better, at least it is consistent.
Robert N M Watson
University of Cambridge
More information about the freebsd-arch