Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Specifying names for tap interfaces



On Wed, Jun 20, 2012 at 9:49 PM, Darren Reed <darrenr%netbsd.org@localhost> 
wrote:
> On 21/06/2012 6:08 AM, Manuel Bouyer wrote:
>> On Thu, Jun 21, 2012 at 06:03:21AM +1000, Darren Reed wrote:
>>> On 21/06/2012 5:34 AM, Manuel Bouyer wrote:
>>>> On Thu, Jun 21, 2012 at 05:08:13AM +1000, Darren Reed wrote:
>>>>> No, this is not the right approach and I don't think that a short cut
>>>>> solution like this belongs in NetBSD.
>>>>>
>>>>> As you noticed, this requires changes to other utilities in order to work.
>>>>
>>>> beside ifconfig, I'm not sure.
>>>>
>>>>>
>>>>> If your project requires any changes to brconfig, netstat, ifconfig, ipf,
>>>>> npf, tcpdump, etc, then you've got the wrong solution in hand. Each 
>>>>> network
>>>>> interface should have one name and one name only as far as userland is
>>>>> concerned. If there are userland programs (aside from device management)
>>>>
>>>> I'm not happy with the "one name and one name only".
>>>
>>> Why aren't you happy?
>>>
>>>> I think some use case
>>>> will want the name, some other will want the alias (and you may need both
>>>> at the same time).
>>>
>>> Such as...?
>>
>> I saw some people being unhappy with the idea of interface rename
>> ("once you're renamed it to foobar you don't know anymore if it's a
>> wm(4) or a tap(4), or possibly a bridge(4)")
>
> That's simply a matter of observability.
>
> It would be a simple matter to use nicctl or drvctl or some
> other tool to display a mapping between hardware devices and
> network interface names.
>
>> and I also like being
>> able to classify interfaces looking  at their name,
>
> Right, you like being able to see the driver name.
>
> See above for observability.
>
>> But I also see a need to be able to refer to them using a different name.
>> But this is different from a rename.
>
>> I really think the feature we want is "alias", not "rename".
>
> I'm not so sure.
>
> A network interface name is an entity in the BSD kernel that
> has a relationship with a list of addresses. Similarly those
> addresses have a relationship with a single interface name.
> That's a very simple model that doesn't allow for any
> confusion or problems. There is a strict 1 to 1 relationship
> between address and interface name.
>
> Aliases break that.
>
> Say I give fxp0 an alias of net0 and I then do
> "ifconfig net0 1.2.3.4". Now if I do "ifconfig net0" that
> IP address will show up as assigned to it. But if I do
> "netstat -nrf inet", net0 is nowhere to be seen. Why?

You will get an error when doing an ifconfig net0, something like
ifconfig <keywork>:net0 should be used, to clearly differentiate
between real interfaces an aliases. So if you use the alias to
configure it you should be aware that it is an alias (or an
alternative name, since alias has other meaning in network
terminology).

> Who wants to explain to users that NetBSD has two different
> classes of network interface names that can be used, one of
> which is real and one of which isn't real? Isn't it easier
> to just have one?
>
> Yes, aliases are easy to make work but I'm hard pressed to accept
> that they have more upsides than downsides, not the least of which
> is that they add more complexity to ifconfig and ifconfig's output.
>
> But if enough people are convinced you need alias then go for it.
>
> Darren


Home | Main Index | Thread Index | Old Index