[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Specifying names for tap interfaces
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
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
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
Main Index |
Thread Index |