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