FCP-0101: Deprecating most 10/100 Ethernet drivers

Bakul Shah bakul at bitblocks.com
Thu Oct 4 17:52:13 UTC 2018


On Thu, 04 Oct 2018 11:30:35 -0600 Warner Losh <imp at bsdimp.com> wrote:
>
> On Thu, Oct 4, 2018 at 11:25 AM Bakul Shah <bakul at bitblocks.com> wrote:
>
> > On Wed, 03 Oct 2018 21:05:16 -0000 Brooks Davis <brooks at freebsd.org>
> > wrote:
> > >
> > > The current list of drivers slated for REMOVAL is:
> > >
> > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> > > ste, tl, tx, txp, vx, wb, xe
> > >
> > > The current list of drivers that will STAY in the tree is:
> > >
> > > dc, ffec, fxpl, hme, le, sis, vr, xl
> >
> > What is the disposition of drivers not on either list?
> >
>
> Apart from de, what are they?

I have re on on the motherboard on one machine.

Granted this is a very dumb test but...

cd /usr/src/dev
for a in *; do if [ -e $a/if_$a.c ] ; then echo $a; fi; done | wc -l
      86

> > > 10 and 100 megabit Ethernet drivers are largely irrelevant today
> > > and we have a significant number of them in the tree.  The ones that
> > > are no longer used and/or are not known to be working need to be
> > > removed due to the significant ongoing 'tax' on new development.
> >
> > I don't understand why there is a "significant ongoing 'tax'
> > on new development" for old NICs.  Can the internal MI<->MD
> > interface be evolved in the direction where the MD drivers for
> > old h/w "just work"? Or is it a hopeless task?
> >
>
> There's two problems. One is that the current APIs are very much setup for
> cut and paste driver construction. This leads to many drivers needing to be
> changed more often than necessary as the APIs are evolved. The second is
> the nature of the hardware has changed. We've gone from devices that can
> handle at most a single packet at the same time to drives that can handle
> thousands with some of the TCP stack offloaded into the card. This wide
> range of hardware is difficult to program for with the current stack. iflib
> is supposed to help (which is the MI/MD thing you're talking about), but in
> the end it can likely help only so much before support for old cards holds
> back adaptation of new features for new cards. Taken together, the old NICs
> in the tree represent a real burden to people trying to innovate (or even
> just bug fix) in this area. Add to that the inability to actually test the
> hardware in any meaningful way, and you have a situation that needs to
> change.

Thanks for the explanation.


More information about the freebsd-arch mailing list