Date: Fri, 12 Dec 2014 15:31:06 -0500 From: John Baldwin <john@baldwin.cx> To: freebsd-arch@freebsd.org Cc: Adrian Chadd <adrian@freebsd.org>, Mike Karels <mike@karels.net>, Rui Paulo <rpaulo@me.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Eric Joyner <erj@erj.cc>, Jack Vogel <jfvogel@gmail.com> Subject: Re: Adding new media types to if_media.h Message-ID: <2116096.l1vR0RuKRU@ralph.baldwin.cx> In-Reply-To: <CAFOYbcnKF45O86cqo2scGeOncQjBQYQtyd1xmpisBdvNXZJDHA@mail.gmail.com> References: <CA%2Bb0zg-Q%2Br7nfzJJt8BEwvPdOD2SFp1GGKp-G_JmUCt16XKRUQ@mail.gmail.com> <201412121439.sBCEdVRU071168@mail.karels.net> <CAFOYbcnKF45O86cqo2scGeOncQjBQYQtyd1xmpisBdvNXZJDHA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2116096.l1vR0RuKRU>