Date: Wed, 20 Feb 2008 15:46:09 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: arch@freebsd.org Subject: Re: dev.* analogue for interfaces Message-ID: <20080220234609.GB96595@funkthat.com> In-Reply-To: <86skznyf2a.fsf@ds4.des.no> References: <86odacc04t.fsf@ds4.des.no> <20080219233217.GS27248@funkthat.com> <86skznyf2a.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smrgrav wrote this message on Wed, Feb 20, 2008 at 13:42 +0100:
> John-Mark Gurney <jmg@funkthat.com> writes:
> > My concern is that slowly adding them for each interface type could
> > create some conflicts in both naming and location...
>
> each interface type? this would be done in if_attach() / if_detach(),
> everything is taken care of centrally for all interfaces.
I'm talking about any type of psuedo device. Virtual web cams from
the network, tty, disks, etc. Any kernel interface that has a logical
view to the user that is not backed by hardware....
> > Are the interface sysctl nodes going to be the same/mirrored for hardware
> > devices? Does dev.msk.0 get duplicated in the interface area?
>
> No, there's if.* for interface stuff and dev.* for hardware stuff. Some
> nodes might move from one tree to the other, but I suspect that most
> won't. Like I said, some interfaces already do this "manually" under
> net.*.
And now new hardware devices could start using one or the other causing
confusion in the future.. we should not allow that... I know this isn't
python, but python has some good guiding principals and one of them is:
There should be one-- and preferably only one --obvious way to do it.
this adds two obvious ways to handle network interface backed by hardware
sysctl data..
> > 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?
>
> Not all interfaces are devices. That is the whole point...
I'm confused about this, since below you say they are.
> > 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...
>
> Uh, no.
>
> Devices that aren't backed by hardware are still devices, they still
> have a device_t, and they still have dev.* nodes; nexus is not backed by
Oh, they do? I don't see a dev.lo0 tree, or are we now talking about
other devices?
> hardware, for instance, it's just a convenient top-level device that
> serves as parent for all other devices.
But I don't see the device for lo0 under nexus... You just said:
"Devices that aren't backed by hardware are still devices"
and:
"parent for all other devices"
other devices than nexus? or other devices that are real?
> Basically, there is a dev.* node for every device_t in the system.
exactly, and I want a device_t for all devices (including psuedo
interfaces, etc.) in the system...
> I want to have an if.* node for every struct ifnet.
If all devices have a device_t and a dev.* node, then this isn't
necessary, my point...
> > This will help enforce non-conflicting names,
>
> I don't see why you're so hung up on conflicting names. It's a non-
> issue. Every interface has a unique name.
I'm not hung up on conflicting names, I was pointing out a side benifit
of this proposal. Where else have a talked about conflicting names
before?
I'm simply saying that if all network interfaces, psuedo or not had a
device_t, then they would have a dev.* entry, and we would not need
to make ifnet have it's own sysctl tree.
Robert does point out that we don't require locks to add an interface,
but there are things call taskqueues that we could make use of to
add/create device_t's w/ Giant w/o having to add it to the if_attach
function.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080220234609.GB96595>