Adding new media types to if_media.h

[Mike Karels]

> On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote:
> > I think I'd go along with Mike, keeping it simpler seems like a good idea.
> > 
> > Jack

> If the userland ABI impact isn't too broad I think this is fine.  Mike, do you
> know off hand how many user-facing things would be affected?

I didn't know off hand, but I have a glimpse index at $WORK (it's for McAfee
Firewall Enterprise, aka Sidewinder, based on 8.2).  I found 45 references to
if_media.h at user level, including "ports" that we use, and excluding our
own software.  The list includes libpcap, snmpd, dhclient, quagga, xorp,
atm, devd, and rtsold.  fwiw, I found about 260 inclusions of if_media.h
in the kernel.

This suggests that we should preserve a backward-compatible user API, even
if it has limits.  Unfortunately, the media word I mentioned is a plain int,
not a typedef.  I would propose a similar API that is not limited, but easy
to convert (e.g. using a new typedef).  I'd be willing to sketch out something
like that.

> > On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels <mike at karels.net> wrote:
> > > > Any other thoughts, or should I start looking at seeing what I can take
> > > > copy from net80211?
> > > > 
> > > > Also adding -net, since this is pretty relevant.
> > > 
> > > I had the same reaction as Adrian initially, as an int with numerous
> > > fields
> > > seems really messy.  However, I don't think we have the challenges of
> > > 802.11,
> > > and the only real problem is that the subtype field has run out of bits.
> > > And both ifconfig and the drivers are cast in the form of a scalar "media
> > > word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T |
> > > IFM_FDX
> > > (assuming that all the bits are in a scalar).
> > > 
> > > Instead, I would propose that we simply change the media word from 32 bits
> > > to 64, and move the subtype from its current location to a new field (e.g.
> > > 16 bits) in the new space.  I believe this can be KPI compatible, and it
> > > is relatively easy to provide a backward-compatible ABI.  There should be
> > > a reserved subtype for "other" that can be encoded in the existing field
> > > for use when the subtype can't fit in the old field.  This seems much
> > > easier,
> > > can be KPI compatible, and will make it much easier to backport drivers.
> > > A backport could simply define the new subtypes as "other", and the KPI
> > > would still be compatible.
> > > 
> > > Thoughts?
> > > 
> > >                 Mike

> -- 
> John Baldwin

		Mike