Re: Specifying names for tap interfaces

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

Linux uses one specific policy by default to name network devices
using the MAC address as a key so that moving the card around in
the system means the name follows the card. Whether or not that
is the desired result by a user... is up for discussion.

However that is not the only way to assign a name to a network
interface card. You can also use the NetBSD approach where the
name of a card is a product of the driver and the order in which
it is probed. In this instance, changing the ordering of cards
inside the computer changes the name. We all accept that in the
same way that the Linux folks accept their behaviour.

Another policy might be to say that the first network card that
is found in the system is foo0 and that each card is named in
an incremental fashion from that point on. With this method the
MAC problem with Linux goes away but the moving around of cards
inside the computer can change card names.

With virtual machines, it is a rather complete decoupling of
data from the CPU, where you can very easily create clones of
the system by copying virtual disks. However if you've done
so and already installed the system to the point of networking
then the clone may very well have a new MAC address, giving
rise to the Linux problems above.

Similarly, why shouldn't I be able to take a virtual disk from
a VMWare installation and have it boot into full functionality
under VirtualBox? The catch here that prevents this is the
network interface: VMWare emulates different network interfaces
than does VirtualBox, so a NetBSD virtual disk created under one
environment can never boot up with functioning networking
on the other. Is that really a desirable outcome?

What we need to recognise is that the network interface naming
policy that NetBSD currently uses isn't the only policy that
we can support and that different policies are attractive in
different environments. Nor is the Linux model the only solution.

Darren