Adding new media types to if_media.h

[Mike Karels]

> On Wed, Feb 25, 2015 at 02:42:16PM -0800, Eric Joyner wrote:
> E> Tbh, I respect Gleb's approach, but developing such a thing would take a
> E> while; the fix Mike proposed would be a fix now.
> E> 
> E> I mean, I'd like to see a decoupling of media types and speeds from
> E> "standard" names, and maybe have both an ability to query what modules a
> E> device supports and what speeds it supports given its current module,
> E> instead of relying on the clunky media type list now. And then it'd be nice
> E> to set flow control from ifconfig, too, without having to couple those
> E> modes to media types. I'm still all for having a new system in the future.
> E> 
> E> But in changing the KPI so much, it'd be important to consider the "do we
> E> need an ethtool-equivalent" discussion.
> E> 
> E> And I think we've lost a bunch of people who were in the original
> E> discussion from the to:/cc: list.

> Actually the amount of code for my approach is approximately the same
> as with Mike's. The only thing we must sit down and think without a hurry
> are the required and spare fields for new if_media. We definitely need
> input from Adrian on his net80211 requirements, and input from all involved
> parties.

I'm not sure what would be different about your approach; you mentioned "n"
versions rather than "x" versions of the ioctls, but I don't know what you
have in mind for encoding.  Any compatible version would be limited to int.

In terms of a "real" fix ("ripping the bandaid off"), I think that
if_media is basically wrong, and widening it won't fix it.  There should
be a generic structure that reports the media type (e.g. Ethernet),
perhaps the speed and some generic status ("active").  Then there should
be media-specific structures that encode the appropriate things including
attachment type.  802.11 apparently already has an extension, and Ethernet
should have a similar extension.  The KPI should be media-type-specific.
I don't see something like this being designed soon, and certainly wouldn't
be able to be MFC'd.  Meanwhile, many of us need to support 40 Gb/s Ethernet
on non-current (or non-future) systems.

> I'm willing to code this if we all agree on the topic, so that you will
> code all done and commited before 10.2-RELEASE.

I'd be interested in a sketch or more extended description sometime before
10.2.

Back on the subject of the review: the VFAST entries should be removed, and
the other entries should be moved down.

		Mike