tech-net archive

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

Re: Specifying names for tap interfaces

On 27/06/2012 6:48 PM, Manuel Bouyer wrote:
> On Wed, Jun 27, 2012 at 11:25:50AM +1000, Darren Reed wrote:
>> On 26/06/2012 7:10 PM, Manuel Bouyer wrote:
>>> On Tue, Jun 26, 2012 at 01:25:11PM +1000, Darren Reed wrote:
>>>>> But I don't want "proxy0". I want "proxy". Or some other name with
>>>>> more than 16 chars, in some case.
>>>> It doesn't work.
>>> This is why user-settable names are not so great.
>>>> Network interfaces should have one name that is used by all of
>>>> the regular TCP/IP tools. That name needs to fit in with the
>>>> expectations of various tools that exist today. It also needs
>>>> to fit in with what administrators will expect to use but most
>>>> importantly, the name used is the same for both input and output.
>>>> Always.
>>> This is where I disagree. I don't propose to replace the name with
>>> something else, I propose to add an alternate lookup mechanism.
>> An alias like this has no place being supported by the kernel.
>> Any model for names associated with network interfaces must
>> revolve around the same name being used on output as on input.
>> Whether it be virtual devices, device layering, cloned devices
>> or real devices, there should be only one name that is used for
>> it on both command lines, inputs and outputs.
>> The addition of extra names or aliases that are used in some
>> circumstances and not others complicates the interfaces for
>> NetBSD rather than makes them simpler and easier to use.
> I disagree. You don't have to use the extra names/aliases if
> you don't want to.

It's not just about whether or not you use them.

It's about whether the system supports it and what the
overall design is.

The problem is that this label is nothing more than a
convenience. It doesn't add to the design or the overall
architecture of NetBSD's networking.


Home | Main Index | Thread Index | Old Index