I know this has been batted around a bit already, and I'm trying to be objective about the whole thing, but I can't see
the grand purpose behind changing interface nomenclature in io-pkt.
I'm trying to understand, why is it so desirable to have interface names based on chip architecture rather than the old
sequential numbering method? (Not to mention that someone felt it necessary to add device name mapping capability in
select areas.)
As this pertains to our own platforms, the new architecture seems quite problematic. We have a platform with multiple
network interfaces that the end-user configures sort of like a router, i.e., specifying an interface name and giving it
an IP address, speed, duplex, etc. The interfaces are currently named en0-enX where X depends on the model, but can go
as high as 9.
We have gone to some lengths to always ensure that the interface names are sequentially numbered across the system and
have gone so far as to actually silk-screen the names en0, en1, etc. on the front panel.
Over the years, we've used four different chip families, and early next year, we'll be adding 10G Ethernet. So with
this new architecture, not only can we not generically specify the interface names, on some platforms, there is a
mixture of architectures, e.g., some speedo ports and some Intel gigabit ports.
Obviously, the physical labelling of the ports will be incorrect, not to mention that it's very difficult to explain
what the actual interface names will be to a customer! In some environments, if someone replaces, for example, a
Broadcom card with an Intel card, the functionality is the same, but the interface name changes and therefore the whole
configuration may be invalid including "sliding" some of the interface names around. And changing the interface names
depending on whether the driver is old or new is even harder to explain to the end user.
By comparison, on a Cisco router, they do specify interface names based on the physical type of port (e.g., Ethernet,
FastEthernet, GigabitEthernet, TenGigabitEthernet), but never based on the underlying MAC architecture. However, even
this is sort of academic because they also specify a slot/port number and they don't generally mix different types of
ports on a slot.
Anyway, point being, I would have understood naming interfaces based on their physical type/speed a lot better than
naming them based on the underlying software model.
It sure would be nice if every driver supported an option to specify its prefix name. Then, if people want to call
everything "en" they could do that, or if they want them named based on speed, they could do that too, or if they like
the current model based on MAC type, that would still be available. Seems like the best of all worlds?
While we have no particular use for the new naming convention, I can understand that some people may think this is a
wonderful new feature, although I have yet to understand why. My only request is that there should be a fully
functional method of using the old names. (If I understand it correctly, the current name mapping function applies only
to certain types of usage and is not universal.)
Thanks for your consideration,
lew