Adding new media types to if_media.h

[Rui Paulo]

On Dec 9, 2014, at 01:05, Eric Joyner <erj at erj.cc> wrote:
> 
> This is a continuation of a discussion from off the list:
> 
> ixgbe needs to support devices with media types that aren't in if_media.h;
> for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we're
> running into the issue that there is no room for all of these types under
> the IFM_ETHER category; there's only room for two more (and per John
> Baldwin, only one more if one of those two unused types is to be used for a
> reserved type). Long term, there are going to be tons of media types for
> future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already
> supports media types that aren't in if_media.h, either.
> 
> So, something needs to change. Does anyone have any thoughts on what should
> happen? I've thought of a few things, but I don't have an adequate grasp of
> what the pros/cons of each are:
> 
> 1. Add a new media category (like IFM_ETHER) and change kernel code to
> treat it like the existing IFM_ETHER. This creates ~28 new media types we
> can use, but it may just be delaying the inevitable for a short time.
> 
> 2. Extend media value from 32-bits to 64-bits. I don't have a good idea of
> what the consequences are of this on architectures that aren't amd64.
> 
> 3. (Initially suggested by Adrian) would be to create a new media type
> struct (instead of using an int value) or adding an extra value to the
> existing ifmedia/ifmedia_entry struct for this. This sounds like the best
> solution to me, but I don't know how much effort it would take to implement
> -- does ifconfig need a lot of changing to handle this?

ifconfig is a macro-intensive application, so maybe it's not that much work.

> Thoughts? Any previous discussions worth looking at?

Hmm, it looks like you're limited in the number of bits because of how the word was laid out. We can't simple remove token ring and get more bits for ethernet...  We could create another IFM_40GETHERNET type to replace token ring but that would be ugly (the IFM_TYPE() macro could handle this idiosyncrasy).

I think if_media should probably be a structure with unions to store the subtypes.  net80211 has the same problem with MCS rates and we ended up storing them outside if_media because of this. 

--
Rui Paulo