> 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 <m...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
