Re: Specifying names for tap interfaces

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

On 5/07/2012 7:59 PM, Roger Pau Monne wrote:
> Darren Reed wrote:
>> On 5/07/2012 5:34 AM, Manuel Bouyer wrote:
>>> On Wed, Jul 04, 2012 at 06:34:36PM +0100, Roger Pau Monne wrote:
>>>>> if I did read it properly, there's no way to know the driver and unit 
>>>>> number
>>>>> once the name has been changed ?
>>>> Yes it is, drvctl -p<new_name>, will print the driver and unit number.
>>> OK, I see.
>>>
>>>>> Also, there is a change to bpf that looks unrelated. As it changes the
>>>>> semantic, this should at last be documented.
>>>> The change to bpf is explained in the email. It is changed to accept
>>>> interfaces not ending in a number, so you can use for example
>>>> foo2bar as an interface name.
>>> Dareen pointed out that such name would cause problems with various tools.
>>> I guess bpf is not the only place that needs to be fixed.
>>
>> It is far better to accept "<name><number>" as a naming
>> constraint than to try and "fix" all of the code that in
>> one way or another expects it to be like that.
> 
> So far I haven't found any problem with removing this
> constrain in bpf, ifconfig, route, netstat, dhcp and
> ipf seem to be ok with that. Do you know of code which
> might expect interfaces to follow the <name><number> convention?

I haven't looked at every networking application that has been
written for Un*x to know and nor is it possible to do so.

Do you want to check every perl script, etc, that's ever been
written by a system admin to analyse output from various commands
with the above naming expectation?

Darren