Date: Thu, 26 Feb 2015 01:11:21 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: 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: <20150225221120.GC17947@FreeBSD.org> In-Reply-To: <201502170150.t1H1ouxM020621@mail.karels.net> References: <BC6AB805-B699-438E-9EC6-015C005D6B1D@neville-neil.com> <201502170150.t1H1ouxM020621@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150225221120.GC17947>