Re: Specifying names for tap interfaces

[Roger Pau Monne <roger.pau%citrix.com@localhost>]

David Young wrote:
> On Wed, Jul 04, 2012 at 06:05:02PM +0100, Roger Pau Monne wrote:
> > Darren Reed wrote:
> > > On 30/06/2012 2:47 AM, Roger Pau Monné wrote:
> > > ...
> > > > > > For example being able to name Xen virtual interfaces in the
> > > > > > Dom0 with a user defined name, but I'm sure other users will come up with
> > > > > > other uses. What would you require for this functionality?
> > > > > At the very last, being able to get the driver name and instance
> > > > > number in a convenient way (e.g. in ifconfig output).
> > > > Ok, I will take a look at that, which I guess will require the
> > > > introduction of a new ioctl and a corresponding field in ifnet.
> > > > You could always find the original name in dmesg, since everytime
> > > > the name changes a line is printed, but I agree it might be
> > > > confusing and difficult if you perform a lot of renames.
> > > Start with making the information available through drvctl
> > > as part of the property list for the driver and don't worry
> > > about ifconfig.
> > >
> > > Darren
> > The attached patch adds a new ioctl to perform the rename and
> > propagate that rename to the associated device_t and sysctl entries.
> > Please review this patch and check that the use of the spls is
> > correct. I also had to change a part of the code of bpf_setif in
> > bpf.c to allow the use of interfaces that doesn't end with a number.
>
> I'm concerned that already you have had to patch a lot of code in order
> to make this change, and it seems to me that the end may not be in
> sight.
>
> Name changes need to be observable by user programs.  The userland needs
> to be able to identify the interface whose name used to be wm0 with its
> new name, lan0.

In my opinion, if a user changes the name of an interfaces that has for 
example a dhcp client running, the user is the responsible for that 
change, and he should understand that user-space programs depending on 
the interface name will probably no longer work correctly. What doesn't 
make sense in my opinion is that you can still refer to an interface 
with it's previous name (and the new one).

Ideally interface renaming should be done before anything else.

> If a long-running user program refers to sysctl MIB entries belonging
> to wm0 using MIB names in string form, it seems that those names
> will stop working after the rename.  Because a rename tears down and
> re-establishes the sysctl tree, the sysctl tree may change numeric MIB
> name, too.  So a user program that resolves the string form of a sysctl
> MIB entry to the numeric form, once, and subsequently uses the numeric
> form to get/set MIB entries, may not refer to the same entries after a
> rename as before.  Today this is a problem even without renames---maybe
> I have unplugged one wm(4) and replaced it with a second wm(4) that is
> assigned the same name as the old---but renames make it a more pressing
> problem to solve.
>
> Both drivers and protocols establish sysctl entries using the device_t
> and ifnet names.  For example, drivers register event counters
> (evcnt(9)) using their device_t name.  If you strive for the name to
> change everywhere that it occurs, then you need some help from the
> drivers and the protocols.  In the SIOCSIFNAME case, ifioctl_common()
> should probably return ENOTTY so that if a driver isn't rename-capable,
> it won't end up with a mixture of old and new names.
>
> Those are just some of the rename problems that I can think of off the
> top of my head.
>
> I'm not keen on interface rename.  In thinking about interface rename,
> however, some deficiencies in the kernel are apparent.  For example,
> there is the problem that the same name may refer to a different
> interface at one time than another.  It would be nice if userland could
> refer to an interface by some name that is guaranteed to be unique, such
> as an (ifindex, generation number) pair.

I think this is an issue that the user should keep in mind when renaming 
interfaces, if you make use of this feature you should keep in mind that 
some problems might occur. The system should not automatically rename 
interfaces.