Date: Wed, 20 Feb 2008 11:18:38 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no>, arch@freebsd.org Subject: Re: dev.* analogue for interfaces Message-ID: <20080220111157.H44565@fledge.watson.org> In-Reply-To: <20080219233217.GS27248@funkthat.com> References: <86odacc04t.fsf@ds4.des.no> <20080219233217.GS27248@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080220111157.H44565>