Re: Specifying names for tap interfaces

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

On 19/06/2012 7:56 PM, Roger Pau Monne wrote:
> Darren Reed wrote:
>> On 19/06/2012 1:51 AM, Greg Troxel wrote:
>>>    Anything that we can control, like tap-%domid.%devid would be good
>>>    though. It doesn't have to follow any specific nomenclature, but it
>>>    will be good to be able to specify two integers, one that corresponds
>>>    to the domain id, and another one that identifies the specific network
>>>    card inside that domain.
>>>
>>> So there's no need to change the /dev/tapN, or the device number, but
>>> just the name of the interface.   As far as I know that's just a string
>>> in the struct ifnet, and it's compared when one searches by name, so it
>>> should be changeable.  I had thought setting the interface name would
>>> change more and be more intrusive, but maybe it's not so bad.
>>> (It does make sense to require it to start with 'tap' to avoid
>>> collisions.)
>>>
>>> It seems easy enough to add the ioctl and see if things blow up...
>>
>> This should be done differently.
>>
>> Rather than just change the name of the interface, create a layer
>> that maps a real device name to a network interface name.
>>
>> Otherwise if you rename "tap0" to "fxp3", how do you easily
>> determine that "fxp3" is actually a tap device and not a fxp?
> 
> I would like to add this functionality to the kernel, but can someone
> provide a little bit more of technical information/steps about how to do it?

The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.

What can be changed is where "struct ifnet" gets its name from.

For network interfaces, what's required here is another data
structure that connects a "struct ifnet" with the device itself.
This structure needs to remain an internal implementation detail
and any interfacing to it via ioctls should be done via proplists.
A new CLI tool is required to manage this interface, maybe call
it nicctl. For now, all that it would do is display what NICs are
present in the system, their device name, instance number and the
name to be used in "struct ifnet".

This CLI tool also needs to be able to add and remove device name
mappings. So, for example, it needs to let me assign the name
"fxp0" to "fxp,3" or some such. This naming information also needs
to be stored in a file somewhere so that when the system boots,
it can use that information to instruct the kernel. Obviously this
needs to be invoked early in rc, i.e. before ifconfig is used to
set the interface IP addresses. What format that file takes is up
to the person doing the implementation. It could be straight text,
maybe it is XML. Whatever.

When a device driver calls if_initname(), if_initname() needs to
see if the new device that is being named should go by another
name. To do this it would be looking at the information stored
in the kernel mentioned above. If so, that name gets copied into
if_xname, else if_xname is composed from <name,unit>.

At some point, network interface initialisation needs to handle
a failure if one device attempts to attach to the system with a
name that is already in use. Similarly, the rename needs to also
be able to fail if the user tries to rename fxp0 to fxp1 when
fxp0 already exists.

The CLI tool used to do interface renaming might also want to
be aware of whether or not the interface is a cloning device
or not. The reason for this is that a cloning device is not
going to be present when the system boots, so any renaming
operation needs to be thought of as being transient and thus
it may not warrant being stored permanently.

For example, I might want to change the name of "ppp0" to
"internet0" after PPP on an ADSL modem link. The ppp0 will
not exist at boot and it is not unreasonable to expect that
there will be another ppp device, so "internet0" may not
always be "ppp0" - some days it may be "ppp1" - so there
is questionable benefit from having a permanent renaming
operation stored for ppp0 -> internet0. Further to this,
it may be worthwhile having changes to pppd to allow the
name to be changed as the interface is created, so that
ppp# is never created, rather orange0 is always created
or some such.

Darren