tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Specifying names for tap interfaces



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.

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.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981


Home | Main Index | Thread Index | Old Index