Date: Thu, 21 Feb 2008 10:07:08 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: arch@freebsd.org, John-Mark Gurney <jmg@funkthat.com> Subject: Re: dev.* analogue for interfaces Message-ID: <20080221100156.V52922@fledge.watson.org> In-Reply-To: <86ablvuzgx.fsf@ds4.des.no> References: <86odacc04t.fsf@ds4.des.no> <20080219233217.GS27248@funkthat.com> <20080220111157.H44565@fledge.watson.org> <86ablvuzgx.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Feb 2008, Dag-Erling Smørgrav wrote: > Robert Watson <rwatson@FreeBSD.org> writes: > >> We also support interface renaming... Does newbus mind if you rename the >> devices in its tree? > > I'm not sure whether you're replying to my proposal or to Julian's > interpretation / extrapolation of it... but I have no intention of hooking > interfaces into newbus. I just want a sysctl tree for struct ifnet like we > have a sysctl tree for device_t, to access interface parameters which are > not easily accessible through ifconfig. 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. 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 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? 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. 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?20080221100156.V52922>