Re: Specifying names for tap interfaces

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

On 21/06/2012 5:31 PM, Roger Pau Monné wrote:
> On Thu, Jun 21, 2012 at 3:12 AM, Darren Reed <darrenr%netbsd.org@localhost> 
> wrote:
>>>> Say I give fxp0 an alias of net0 and I then do
>>>> "ifconfig net0 1.2.3.4". Now if I do "ifconfig net0" that
>>>> IP address will show up as assigned to it. But if I do
>>>> "netstat -nrf inet", net0 is nowhere to be seen. Why?
>>>
>>> You will get an error when doing an ifconfig net0, something like
>>> ifconfig <keywork>:net0 should be used, to clearly differentiate
>>> between real interfaces an aliases. So if you use the alias to
>>> configure it you should be aware that it is an alias (or an
>>> alternative name, since alias has other meaning in network
>>> terminology).
>>
>> If I can't use it with tools like ifconfig then what
>> is the point of having the alternative name at all?
> 
> You can use it with all the tools, but you need to know it's an
> alternative name, so a keyword must be used to differentiate it from
> physical interfaces. I think this prevents confusion, since there's a
> clear difference between a real interface, and an "alias" or
> "alternative name" of an interface.

Sorry, you have completely failed to convince me of this idea
because you're introducing more complexity for very questionable
benefit.

On 21/06/2012 6:05 PM, Manuel Bouyer wrote:
> You can use it with ifconfig, or any other tool. Just use
> '<keywork>:net0' instead of 'net0' as the name.

Why would I want to ever use the altname when it just makes
the command string for ifconfig longer?

On 21/06/2012 7:43 PM, Martin Husemann wrote:
...
> It sounds to me like xen would have a config file to fire up the domU,
> and there could be an entry saying "this domU will use tap14".

And the domU never sees "tap#".

On 21/06/2012 8:01 PM, Roger Pau Monne wrote:
> While this is true if you give a name to the interface on the config
> file, but how can the toolstack (xl, that launches Qemu) choose an
> interface name and pass it to Qemu when no one is specified? Well,
> we might be able to search for a free tap device and pass this as the
> desired name, but this is a really racy solution, as someone else might
> request a tap device while we are launching Qemu, and take our chosen
> tap device behind our back, so we will end up failing to create that
> domain.
>
> Also, I don't think there's anyway to create vifs interfaces with a
> specific name, which I think will also be an interesting feature to
> have.

So in that second paragraph you've identified the real problem.
Solving that doesn't require altname or aliases. Further, using
altnames or aliases doesn't solve the race conditions that you
mention in the first paragraph.

Another question - is there some reason why the name can't be created
in a more dynamic fashion and the name of the created device used as
part of the configuration rather than requiring the name to be a
static part of the configuration? Regardless of device name aliases,
etc, this seems to be the better way to approach the problem from a
perspective of having a network interface name made available that
does not conflict with any existing names.

On 21/06/2012 8:17 PM, Martin Husemann wrote:
...
> Note that I am not objecting to fix the more general problem of
> creating aliases or rename support. However, of everything I saw
> discussed so far, only the FreeBSD variant has (a) clearly defined
> semantics and (b) is very simple to implement. It is so simple, it
> wouldn't hurt as a stopgap/intermediate solution.
>
> Everything else, at least from my understanding, needs *a lot* more
> thought and design work - which does not mean it is the wrong way to
> go in the long term.

I'd rather see time spent on implementing something that will be kept
around for the long term rather than to see time and effort wasted on
code that is for a feature that is regarded as "stop gap" and will be
thrown away.

As well as developer time, it is also harmful for users as they have
to eventually unlearn this stop-gap thing.

There's also the chance that whoever does the work to do it right will
have to create a solution that is more complex in order to be compatible
with this stop gap thing because that has become an established interface.

And of course if the stop-gap gets accepted there there is less
motivation to fix the problem properly because the aggravation is gone.

Do it right and do it once.

Darren