[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Specifying names for tap interfaces
On 23.06.2012 19:55, Darren Reed wrote:
> On 24/06/2012 1:13 AM, Manuel Bouyer wrote:
>> On Sun, Jun 24, 2012 at 12:38:28AM +1000, Darren Reed wrote:
>>>>> Because it means nothing to the user.
>>>>> It only means something to the kernel.
>>>> It depends of the user. It means something to me.
>>> Yes, but you're a developer.
>>> Not everyone is a developer.
>> Administrators can understand this too. Users usually don't deal with
>> interface names directly, they use some high-level tool.
> Such as?
>>>> Can you give examples ?
>>> For example, "lanscan" from HP-UX.
>>> A good example of its output is here:
>> not sure how this would be useful for me.
> Because it presents network interface information in a much
> easier to parse format than does ifconfig.
> In addition to HP-UX's lanscan there is Solaris's dladm,
> which is better again for administering network interfaces.
> One of the more useful pieces of information available from
> lanscan is the "Path". This represents the device tree to
> which the network interface is connected. Thus it is easier
> to determine if "wm2" is on the same piece of hardware as "wm0",
Although Solaris' /devices (or Linux sysfs) are interesting systems, I
would clearly favor this sort of output but not restricted to interfaces.
I think that this should be presented the other way around though
(sysctl tree maybe?), where we have devices => hw path/locators, instead
of hw path/locators => devices.
Leaves are the interesting parts of the system (disks, NICs, USB hubs,
ports...) and are the primary entities with which users interact.
> ifconfig is becoming a bigger and bigger mess. Whilst it started
> out life as a tool predominately focused on configuring layer 3
> network addresses (plus some layer 1 things like up/down), it is
> now used for everything from layer 4 to "layer 0" (it creates
> network interface instances and I don't know how to put that in
> the OSI model other than at "layer 0".)
> NetBSD needs to seriously look at the command set for network
> interface administration and enhance the model beyond being
> centered around ifconfig.
> Trying to keep shoe horning everything into ifconfig is just
> going to make ifconfig more and more unwieldly as time goes by.
Is that a matter of UI or a matter of implementation? And what do you
Linux' ip(8) has been present for nearly a decade, and I seldom find
people using it instead of the age old ifconfig(8)...
Main Index |
Thread Index |