Re: Specifying names for tap interfaces

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jun 26, 2012 at 03:50:10AM +1000, Darren Reed wrote:
> On 24/06/2012 4:28 AM, Manuel Bouyer wrote:
> > On Sun, Jun 24, 2012 at 03:55:54AM +1000, Darren Reed wrote:
> >> On 24/06/2012 1:13 AM, Manuel Bouyer wrote:
> >>>> Yes, but you're a developer.
> >>>> Not everyone is a developer.
> >>>
> >>> Administrators can understand this too. Users usually don't deal with
> >>> interface names directly, they use some high-level tool.
> >>
> >> Such as?
> > 
> > I don't know, I'm an admin, I use ifconfig and route :)
> > But I know there are graphical tools out there to manage network. 
> > I just don't use them.
> 
> And if they're not bundled with NetBSD, how will they ever
> work with labels if labels require special fields be used?

We can add patches in pkgsrc and submit upstream. This is usually
how we deal with things like this (and it woudln't be the first time).


> 
> >> One of the more useful pieces of information available from
> >> lanscan is the "Path". This represents the device tree to
> >> which the network interface is connected. Thus it is easier
> >> to determine if "wm2" is on the same piece of hardware as "wm0",
> > 
> > This would be drvctl's job. This is the kind of informations you may want
> > to any device, not only network interface.
> 
> Some of that information, yes, but other aspects of it, no.
> drvctl shouldn't inherit network specific tasks or outputs
> just like it shouldn't do so for disk.
> 
> Presently we have dkctl for disks but there is no analogue for
> network devices.

For me it looks like dkctl is equivalent of ifconfig for disks.
This is what you use to configure wedges, for example.

> 
> However the primary task here would be to make that information
> available. Once that is done then it is a simpler matter of
> writing some tools to either extract it directly or layer on
> top of drvctl.

I suspect drvctl can already extract the interface (not directly,
but by ful device listing and matching the one we're looking for).

> 
> >> NetBSD needs to seriously look at the command set for network
> >> interface administration and enhance the model beyond being
> >> centered around ifconfig.
> >>
> >> Trying to keep shoe horning everything into ifconfig is just
> >> going to make ifconfig more and more unwieldly as time goes by.
> > 
> > This is possible. I don't care much as long as I get the infos I want.
> 
> Which information do you need/want?

What I actually have with 'wm0': this is the first instance of the
wm(4) driver. Extra infos (location in device tree, attached PHYs)
would be usefull too, of course.

> >> [...]
> >>
> >> then if I don't see a "192.168.1.0/24" route in the routing
> >> table next to "newprojectvlan0",  I'm going to be awfully
> >> confused.
> > 
> > You won't see "newprojectvlan0", you'll see "newprojectv". This is
> > a typical example where long names will be a problem. For anything that
> > uses a tabular display, you need short names.
> 
> "Need" short names?
> 
> Is there something holy about the tabular display that means it
> can't shift to allow longer fields? Notice the behaviour of vmstat
> for one. Does it start truncating fields because a line gets too
> long? No. IPv6 broke the 80 column barrier long ago for netstat

Yes, and it's annoying.

> >> Being able to use both the label and some other name for
> >> the network interface simultaneously will end up just creating
> >> confusion because there will be some instances where you can
> >> use the label and some where you can't,
> > 
> > If there are place where it can't this has to be fixed
> 
> So you have already said that the network interface should
> only be used on output but here you're arguing the reverse?

output != input. output uses the interface name. input uses either name
or label, with a syntax which makes it clear that it's a label and not
a name. 

> 
> Additionally this goes back to the 3rd party software issue.

Which is not a big issue (actually, less an issue than using long names
which don't end with a number I guess).

> 
> >> some where it is
> >> output and some where it isn't.
> > 
> > No: the interface name should always be used for output, not the label.
> 
> This is a bad model. The same name should always be available
> to be used with administration tools regardless if it is for
> output or input. No ifs or buts. If that isn't possible then
> something else new is needed.

But the same name is always availble, it's the name, precisely.
You don't have to use labels if you don't want to.

> 
> What you're proposing is now sounding more like an alias, not
> a label, because an alias is typically a one way mapping of
> one name to another.

Yes, it's how I called it initially. But calling it 'alias' is
confusing with address aliases. So I prefer "label".

> 
> To put some more light on this, what you're saying is that
> the administration model would be like this:
> 
> # ifconfig label,proxy 1.2.3.4
> # netstat -nrf inet | grep wm6
> 
> I can't see how NetBSD could accept that kind of administration
> model for network interfaces. If you can rename interfaces then
> the following is possible:
> 
> # ifconfig proxy0 1.2.3.4
> # netstat -nrf inet | grep proxy0
> 
> and that is a whole lot more sensible.

But I don't want "proxy0". I want "proxy". Or some other name with
more than 16 chars, in some case.

> 
> >> And none of those decisions
> >> about where or when it is or isn't used will be under the
> >> user's control.
> >>
> >> In light of that, if a more meaningful name for a network
> >> device is desired, it is simpler in every way for there to
> >> be one name that is used everywhere and to provide the means
> >> to not only assign the name to a device but to also see what
> >> names have been assigned to what devices.
> > 
> > If some tools can't use "label,mylabelname" they're likely to also
> > be problems with arbitrary interface names.
> 
> Not likely.
> 
> By creating a naming mechanism that uses something other
> than if_xname to store the interface name in, the cost of
> porting networking software to NetBSD properly goes up
> unless this would be a feature that nothing in pkgsrc used.

Do userland softwares see if_xname at all ? I though it was in-kernel
only.

> 
> If arbitrary names are allowed through renaming and those
> names are always presented in struct ifnet with if_xname
> then there should be no problems as long as the name
> complies with the expected format of <name><number>.

Which is a restriction in itself.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--