Date: Wed, 25 Feb 2015 14:17:44 -0800 From: Jack Vogel <jfvogel@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Mike Karels <mike@karels.net>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Adding new media types to if_media.h Message-ID: <CAFOYbc=Zw7S70d=rjTXdnfajM8cmbCNVH4QPfEBz=HkjRc0wMw@mail.gmail.com> 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
So we have products coming soon that need to extend the media, if you have grandiose plans in the future you can worry about things then, Linux can handle the extended media TODAY, wouldn't it be nice to do so as well? Also, this solution is something that can be MFC'd into 10 STABLE, if you do something big in the 11 stream I will be that wont be possible, so I'd say lets do this as a first step. Jack On Wed, Feb 25, 2015 at 2:11 PM, Gleb Smirnoff <glebius@freebsd.org> 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. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFOYbc=Zw7S70d=rjTXdnfajM8cmbCNVH4QPfEBz=HkjRc0wMw>