Adding new media types to if_media.h

[John Baldwin]

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?

> 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