Re: Specifying names for tap interfaces

[Darren Reed <darrenr%netbsd.org@localhost>]

On 23/06/2012 8:26 PM, Manuel Bouyer wrote:
> On Sat, Jun 23, 2012 at 07:56:17PM +1000, Darren Reed wrote:
>> On 23/06/2012 1:42 AM, Manuel Bouyer wrote:
>>> On Fri, Jun 22, 2012 at 10:13:30PM +1000, Darren Reed wrote:
>>>>> Right now, the unique identifier of an interface is its name, which is
>>>>> set by the system when the interface is discovered. I don't think we 
>>>>> should
>>>>> change this part, because we are used to the names as they are now, and it
>>>>> also carry some information (wm0 is an intel adapter, tap0 is a pseudo
>>>>> interface, xvif5-0 is a Xen PV backend interface connected to the 
>>>>> interface
>>>>> of index 0 in the guest id 5, etc).
>>>>
>>>> The naming of interfaces is dependent on the driver, not the user.
>>>
>>> Yes. I don't see this as a problem.
>>
>> 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.

>>>> The point here is that the driver based interface name conveys some
>>>> coded information that is meaningful to people that know which drivers
>>>> use which abbreviations and that's it. That is unless there is some
>>>> magical way in which random people equate "wm" with "Intel" (yes I know,
>>>> "man wm".) But note that the user or administrator never gets any choice
>>>> in whether it is "fxp0" or "wm0", it's decided by programmers that
>>>> write the drivers.
>>>
>>> But precisely, 'man wm' is usefull, and a way to associate an interface
>>> name with its driver name is a must have. Actually this is done with
>>> the name. If we allow the name to change at runtime, there has to be
>>> a way to find this information (other than "dmesg |grep name", precisely
>>> because name can change).
>>
>> Yes and I think that pursuing a way to find that information will
>> hopefully lead us to developing a tool that delivers more useful
>> information, not just that "lan0 is wm4".
> 
> 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/

>>>> To me this screams out for better management of network interfaces.
>>>> Something that allows the strings output at bootup to be reported
>>>> via the CLI, perhaps including how it is attached (but maybe that
>>>> is going just a bit too far.)
>>>>
>>>>> But sometimes we'd like to have more, user-defined information easily
>>>>> available for interfaces, on systems with lots of interfaces.
>>>>
>>>> Definitely.
>>>>
>>>>> example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
>>>>> domU 5 ? I have to use xm list to match the id against a domU's name.
>>>>> example 2: I have a system with 2 quad-port intel. I know wm6 is
>>>>> the third port of the second quad-port adapter, but what is it connected 
>>>>> to ?
>>>>
>>>> There's two of issues here that we can address:
>>>> - why can't xvif5-0 be a more meaningful name?
>>>
>>> Because the kernel (which creates the interface) doesn't have easy access to
>>> this information.
>>
>> Yes, this is a fault with the interface cloning interfaces
>> and perhaps more generally, network interface naming on
>> NetBSD.
> 
> No. In this specific case it's because of the way Xen works.
> A xvif interface is created because an entry is written to the
> xenstore for it. We have to work with the informations available in
> the xenstore; when the entry for the xvif is written the guest's name
> may not be availble yet. We have to live with that.

I see.

>> 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.

>> 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.

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.

>> 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?

>> # 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?

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

>>>> On top of that, you'll probably find various parsers will treat
>>>> the above string as not being an interface name as colons are
>>>> often used to separate parameters.
>>>
>>> another separator can be used (label,team-foo-vlan, or label/team-foo-vlan)
>>
>> The name used for network interfaces should be limited to
>> [a-z], [A-Z], [0-9] and maybe "-" and/or "_".
> 
> 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".

Darren