Re: Specifying names for tap interfaces

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

On Thu, Jun 21, 2012 at 10:50:26PM +1000, Darren Reed wrote:
> [...]
> 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?

it'll be longer anyway, because the point of aliases (beside fixing
xen problems) is to give meaningfull names. typing 'team-foo-dmz' will
always be longer than 'wm0'. prefixing it with keywork: isn't a big
deal.

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

No, of course. the problem is in dom0. 

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

I dissagree that this is the real problem. There is a desired feature:
being able to tag an interface with a user-provided string, and
using this string instead of its name for various task. This is not
restricted to xen xvif or tap devices, I have other use cases too
(on a system with lots of interface, having a meaningfull string
for them would be helpfull). But I don't think remplacing the actual
interface name with a user-specified string is the way to go. This
user-specified string should add information, not replace existing
information.

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

Seconded.

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