Skip site navigation (1)Skip section navigation (2)
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>