Date: Wed, 25 Feb 2015 18:11:14 -0500 From: Alfred Perlstein <bright@mu.org> To: Gleb Smirnoff <glebius@FreeBSD.org>, Mike Karels <mike@karels.net> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, George Neville-Neil <gnn@neville-neil.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Adding new media types to if_media.h Message-ID: <54EE5692.5070402@mu.org> In-Reply-To: <20150225221120.GC17947@FreeBSD.org> References: <BC6AB805-B699-438E-9EC6-015C005D6B1D@neville-neil.com> <201502170150.t1H1ouxM020621@mail.karels.net> <20150225221120.GC17947@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/25/15 5:11 PM, Gleb Smirnoff wrote: > On Mon, Feb 16, 2015 at 07:50:56PM -0600, Mike Karels wrote: > M> Well, I developed the prototype as I had planned, using a 64-bit media > M> word, and found that I got about 100 files in GENERIC that didn't compile; > M> they attempted to store "media words" in an int. My kingdom for a typedef. > M> That didn't meet my goal of KPI compatibility, so I went to Plan B. > M> > M> Plan B is to steal an unused bit (RFU) to indicate an "extended" media > M> type. I then used the variant/subtype field to store the extended type. > M> Effectively, the previously unused bit doubles the effective size of the > M> subtype field. Given that the previous 5-bit field lasted us 18 years, > M> I figured that doubling it would last a while. I also changed the > M> SIOGGIFMEDIA ioctl, splitting it for binary compatibility; extended > M> types are all mapped to IFM_OTHER (31) using the old interface, but > M> are visible using the new one. > M> > M> With these changes, I modified one driver (vtnet) to use an extended type, > M> and the rest of GENERIC is happy. The changes to ifconfig are also fairly > M> small. The patch is appended, where email programs will screw it up, > M> or at ftp://ftp.karels.net/outgoing/if_media.patch. > M> > M> The VFAST subtype is a throw-away for testing. > M> > M> This seems like a reasonably pragmatic change to support the new 40 Gb/s > M> media types until someone wants to design an improved but non-backward- > M> compatible interface. I think it meets the goal of suitability for > M> back-porting; it could be MFCed. > > I will dare to vote against the crowd. > > We can't and don't plan to preserve the driver KPI for the 11 branch. The > plan, that I hope to accomplish by 11 is to provide a driver KPI, where > drivers do not about struct ifnet, and other network stack stuff. Of > course, that's a huge change in KPI. But we do it for the sake to avoid > future changes. > > So, all this tricks with one extra bit seem unnecessary to me. I'd suggest > to introduce new 'struct ifmedia' with enough space, and of course put extra > space in there. Give a new value to SIOCGIFMEDIA. Write a new clear code > to handle it, without any extended bit tricks. > > For the sake of userland API, save old current 'struct ifmedia' as > 'struct oifmedia', and take old value of ioctl to OSIOCIGIFMEDIA. > Write a function under BURN_BRIDGES that handles OSIOCIGIFMEDIA and > tries to convert from ifmedia to oifmedia, > > To summarise: the patch adds tricks to just double the ifmedia name space, > not solving the problem forever. New API is introduced, but old limited one > doesn't have foreseable obsolete plan, since new is tied to it. All tricks > are performed for the sake of driver KPI stability, which isn't planned > to be kept for this major release cycle. +1, rip the bandaid off. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54EE5692.5070402>