[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Specifying names for tap interfaces
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
>>>>> 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?
Main Index |
Thread Index |