Re: Specifying names for tap interfaces

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

On 13/07/2012 6:51 PM, Roger Pau Monne wrote:
> Darren Reed wrote:
>> On 6/07/2012 10:44 PM, Roger Pau Monne wrote:
>>> Darren Reed wrote:
>>>> On 6/07/2012 12:05 AM, Roger Pau Monne wrote:
>>>>> Christos Zoulas wrote:
>>>>>> On Jul 5,  9:37am, roger.pau%citrix.com@localhost (Roger Pau Monne) 
>>>>>> wrote:
>>>>>> -- Subject: Re: Specifying names for tap interfaces
>>>>>>
>>>>>> ...
>>>>>> | I haven't tried yet, but I assume passing the fd to Qemu will work, and
>>>>>> | I plan on using that to fix the Qemu problem. Anyway I had this half
>>>>>> | done, because I think it's an interesting feature, not only as a fix to
>>>>>> | the Qemu issue.
>>>>>>
>>>>>> Yes, but it is a solution looking for a problem. Until we actually have
>>>>>> a use that makes this feature necessary, we should not add it just to 
>>>>>> avoid
>>>>>> creeping featurism and complexity.
>>>>>>
>>>>>> | For example being able to name Xen virtual interfaces in
>>>>>> | the Dom0 with a user defined name (both tap and vif), but I'm sure 
>>>>>> other
>>>>>> | users will come up with other uses.
>>>>>>
>>>>>> Yes, that's nice, but purely cosmetic.
>>>>> It allows users to have persistent interfaces, even after Dom0/DomU 
>>>>> reboot, so you can for example graph the traffic a single guest is using, 
>>>>> which is not possible now.
>>>> Being able to specify the name of a network interface is
>>>> useful but I don't think the qemu case is the killer example.
>>>>
>>>> The Virtual Network Stacks project that's listed the NetBSD
>>>> wiki would benefit greatly from this because it will allow
>>>> each network stack to have its own "lo0" (for example) whilst
>>>> the underlying system sees lo0, lo1, etc.
>>>>
>>>> Being able to rename a network device into the name of another
>>>> also has advantages. For example, if you replace your fxp0 with
>>>> a wm0, it may be easier to tell the system to use a different
>>>> name than to adjust the myriad of things in /etc/rc.conf that
>>>> use fxp0.
>>>>
>>>> One of the big beneficiaries of being able to rename network
>>>> interfaces is when you have a system policy to name everything
>>>> as "ethX" or "netX" or "lanX" because then your PXE image that
>>>> you install doesn't need to do any tricks to work out which NIC
>>>> is the primary one, it is always the same on all hardware. On
>>>> top of that, if the automatic naming policy does not follow the
>>>> mac id then replacing the first network interface with something
>>>> else does not cause disruption if a different driver is used.
>>> So you want to push this forward, and create an automatic naming policy? If 
>>> I understand this right, you will no longer get bnxX or fxpX, but all 
>>> network interfaces will be named as ethX, lanX or whatever?
>> The naming policy would be set in /etc/rc.conf and applied early during boot.
>>
>> I can think of at least the following naming policies:
>> - macid (names follow a MAC address)
>> - path (names are associated with a device's path)
>> - none (there is no renaming - i.e. current behaviour)
>> - fill (tries to ensure that there are no gaps in the number space "X" and 
>> ignores macid/path)
>> and probably default to "none" so that the natives aren't upset.
>>
>>>> But all of these use cases require a solution that is much more
>>>> substantial than what has currently being put forward but by
>>>> the same token, properly solving this will enable the Xen
>>>> problem to be addressed. I think there is more to gain by doing
>>>> this once and doing it properly than by allowing a partial
>>>> solution.
>>> Yes, I don't have any objection in working on a better solution.
>>>
>>>> As a related issue, if the output of ifconfig is going to
>>>> contain names that do not directly relate to physical devices
>>>> then it needs to be easier to discover them all that by doing
>>>> "drvctl -p<nic>" on each of them.
>>> Should the output from ifconfig include something like?
>>>
>>> driver: bnx
>>> device index: 0
>>>
>> I think a better line would be something like:
>> attached as: bnx0
> Thanks for the comments, I will try to address them ASAP.
>
> I'm quite sure I won't have time to work on this again for the following
> two weeks at least, I'm currently focusing on getting the upcoming
> version of Xen and NetBSD to work. After that I will continue with this,
> I'm just saying it so that you know I have not forgotten, and I will
> come back when I have finished.

That's ok. Apart from the "attached as" line, the other represents
a not insignificant amount of design and coding.

Darren