Re: Specifying names for tap interfaces

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

On Sun, Jun 24, 2012 at 12:38:28AM +1000, Darren Reed wrote:
> >> Because it means nothing to the user.
> >> It only means something to the kernel.
> > 
> > It depends of the user. It means something to me.
> 
> 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.

> > Can you give examples ?
> 
> For example, "lanscan" from HP-UX.
> 
> A good example of its output is here:
> http://jreypo.wordpress.com/2010/02/09/playing-with-lanadmin-lanscan/

not sure how this would be usefull for me.

> >> For example, I would love to see drivers and/or networking
> >> populate a sysctl tree with information about each network
> >> interface. Driver name, instance number, PHY and MII information
> >> might be a good place to start?
> > 
> > I don't think sysctl is a good place for that; I suspect this information
> > is already available and drvctl can (partially) provide it. drvctl could
> > be improved for that.
> 
> drvctl is doing what it does.
> 
> If what you're saying is that more information should be exported
> via properties, ok, but the tool to summarise it should be something
> else and not drvctl. There's nothing to be gained by putting network
> specific things into drvctl.
> 
> On the other hand, if you were going to add something to drvctl to
> simply output the entire device tree, along with device names
> (similar to Solaris's "prtconf"), that would kind of fit in with
> drvctl's raison d'etre.

This was what I meant. I misunderstood what you would use sysctl for.
I still think sysctl is the wrong place for what you want, but
it could be part of ifconfig

> 
> >> I suppose where I'm coming from is why can't we have something
> >> like this:
> >>
> >> # ifconfig tap create name proxy0
> >>
> >> ... where rather creating "tap0" or tap15", the interface gets
> >> created as "proxy0" and "tap" with a number is never seen.
> > 
> > But I want a easy way to know that proxy0 is a tap and not something
> > else. And we're back to something specific to cloning devices, where
> > a more general mechanism would be useful.
> 
> So on the one hand you want to create proxy0 or some other label
> and for people to use that because it is more meaningful but on
> the other hand, you don't like abstract names like that because
> they don't tell you anything about the driver.

No, I didn't say that. I said that if we go with dynamic names instead of
labels, I want to have the driver name and instance number in ifconfig
output so I can find the information.

> 
> The only way you get that is by having the name be something
> like "wm_proxy0" or something like that.
> 
> If I have to run a command, such as ifconfig, or something else
> to get an understanding of what "proxy0" is then it doesn't matter
> if "proxy0" is just a label for wm6 or wm6 renamed.

It's just a matter of what we want to provide as primary information:
proxy0 or wm6. As proxy0 could also be
some_very_long_name_because_there_s_lot_of_interfaces
then I think we should stay with wm6 as the primary information
(or output of things like netstat will be awfull).

> 
> >> Rinse and repeat for use with xvif.
> >>
> >> Ultimately, doesn't the "xvif" part become just an implementation
> >> detail of what's required to talk to the domU?
> > 
> > It is. But it's a user-visible detail.
> 
> Why does a user need to be aware of an implementation detail?
> Or why does it need to remain exposed?

Because it's a network interface of the system and we don't have anything
better to display in network tools ?

> 
> >> # ifconfig tun0 create
> >>
> >> The problem for scripts is that they need to handle errors in case of
> >> tun0 being in use already. It might even be better to allow something
> >> like this:
> >>
> >> # ifconfig tun create
> >> tun4
> >>
> >> where the output of ifconfig is the name of the interface created.
> >>
> >> This might be a worthwhile change independent of labels.
> > 
> > I see. It doens't apply to xvif because they're not created with
> > a userland tool.
> 
> So how are the xvif interfaces created?

When a new network backend appears in the domain's tree in the xenstore
(usually network backends are in domain0, but they could be in some
other domains - the Xen architecture allows that - so the interface
is not always created in the domain where xm create was run).

> 
> And why can't it benefit from more dynamic interface creation?

I'm not sure what you mean with "more dynamic"

> > Why ? I can understand that some chars are troubesome in scripts,
> > but not all of them are.
> 
> Because for Un*x the name needs to fit in with applications that
> expect a name that refers to a network interface following the
> rather generic rule of "name" followed by "number".

By this rule the name can't be "team-foo-vlan". From there, it doesn't
matter much if the tool is not happy with a label prefix, it can't be
used anyway and the tool needs to be fixed.

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