Re: Specifying names for tap interfaces

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

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.

Roger.