Re: Specifying names for tap interfaces

[Darren Reed <darrenr%fastmail.net@localhost>]

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

Darren