FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

>>> Please direct replies to freebsd-arch <<<

FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
and remove them in FreeBSD 13 to reduce the burden of maintaining and
improving the network stack. We have discussed this within the
core team and intend to move forward as proposed. We are solictiting
feedback on the list of drivers to be excepted from removal.

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

The criteria for exception are:
- Popular in applications where it is likely to be deployed beyond the
support lifetime of FreeBSD 12 (late 2023).
- 5 reports of uses in the wild on machines running FreeBSD 12 will be
deemed satisfy the "popular"
requirement.
- Required to make a well supported embedded or emulation platform usable.
- Ported to use iflib (reducing future maintenance cost.)

Please reply to this message with nominations to the exception list.

The full FCP-0101 is included below.

-- Brooks

---
authors: Brooks Davis <***@freebsd.org>
state: feedback
---

# FCP 101: Deprecation and removal of 10/100 Ethernet drivers

Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
FreeBSD 13.

## Problem Statement

Each network driver creates drag for the project as we attempt to
improve the network stack or provide new features such as expanded
32-bit compatibility. For example, the author has edited every single
NIC driver more than once in the past year to update management (`ioctl`)
interfaces. We could improve this situation by converting drivers to
iflib, but each additional driver takes work.

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.

For at least a decade, most systems (including small embedded
systems) have shipped with gigabit Ethernet devices and virtual
machines commonly emulate popular gigabit devices. We wish to
retain support for popular physical and virtual devices while
removing support for uncommon ones. With a few exceptions these
drivers are unlikely to be used by our user base by the time FreeBSD
12 is obsolete (approximately 2024).

## Proposed Solution

We propose to deprecate devices which are not sufficiently popular. This
will entail:
- (October 2018) Send this list to freebsd-net and freebsd-stable.
- (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
attach routines for each device to be removed and merge those changes
to FreeBSD 12.
- (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
freebsd-net and freebsd-stable users of pending deletion.
- (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
devices.

Through out this process, solicit feedback on additions to the exception
list and update this document as required. For a device to be placed on
the exception list the device must meet one of the following criteria:
- Popular in applications where it is likely to be deployed beyond the
support lifetime of FreeBSD 12 (late 2023).
- 5 reports of uses in the wild on machines running FreeBSD 12 will be
deemed satisfy the "popular"
requirement.
- Required to make a well supported embedded or emulation platform usable.
- Ported to use iflib (reducing future maintenance cost.)

### Exceptions to removal

Device | Reason
-------|-------------------------------------------------
ffec | Onboard Ethernet for Vybrid arm7 boards
fxp | Popular device long recommended by the project.
dc | Popular device for CardBus card.
hme | Built in interface on many supported sparc64 platforms.
le | Emulated by QEMU, alternatives don't yet work for mips64.
sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
vr | Soekris Engineering net5501, some Asus motherboards.
xl | Popular device for CardBus card.

Note: USB devices have been excluded from consideration in this round.

### Device to be removed

ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
ste, tl, tx, txp, vx, wb, xe

## Final Disposition

TBD

[Robert Clausecker]

I request that ed(4) be kept as well as that's the driver for NE2000
compatible cards, the most common kind of ethernet card for the ISA bus.
In case anybody wants to run FreeBSD on a system with just an ISA bus,
this kind of card would be the easiest way to get networking to work.

It's also a commonly emulated card by virtual machines, e.g. by QEMU.

Yours,
Robert Clausecker

On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> >>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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
>
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> Please reply to this message with nominations to the exception list.
>
> The full FCP-0101 is included below.
>
> -- Brooks
>
> ---
> authors: Brooks Davis <***@freebsd.org>
> state: feedback
> ---
>
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
>
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
>
> ## Problem Statement
>
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility. For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces. We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
>
> 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.
>
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices. We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones. With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
>
> ## Proposed Solution
>
> We propose to deprecate devices which are not sufficiently popular. This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> attach routines for each device to be removed and merge those changes
> to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
> freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
> devices.
>
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required. For a device to be placed on
> the exception list the device must meet one of the following criteria:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> ### Exceptions to removal
>
> Device | Reason
> -------|-------------------------------------------------
> ffec | Onboard Ethernet for Vybrid arm7 boards
> fxp | Popular device long recommended by the project.
> dc | Popular device for CardBus card.
> hme | Built in interface on many supported sparc64 platforms.
> le | Emulated by QEMU, alternatives don't yet work for mips64.
> sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
> vr | Soekris Engineering net5501, some Asus motherboards.
> xl | Popular device for CardBus card.
>
> Note: USB devices have been excluded from consideration in this round.
>
> ### Device to be removed
>
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
>
> ## Final Disposition
>
> TBD



--
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments

[Jakub Lach]

I request to keep rl(4) as it's the standard ethernet card in PIII era PCs.
Moreover, it's emulated by QEMU too.



--
Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-arch-f4152488.html

[Warner Losh]

Do you have any machines running FreeBSD 12.0 with this interface? The
requirement is that we have at least 5 real users of the interface on
FreeBSD 12.

Many of the P III era PCs aren't beefy enough to run FreeBSD very well
(specifically, they typically lack adequate memory).

QEMU also emulates newer NICs, so you wouldn't be left w/o a solution. The
NE-2000 is still supported, as well E1000 (em/igb) interfaces.

Warner

On Wed, Oct 3, 2018 at 5:36 PM Jakub Lach <***@mailplus.pl> wrote:

> I request to keep rl(4) as it's the standard ethernet card in PIII era PCs.
> Moreover, it's emulated by QEMU too.
>
>
>
> --
> Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-arch-f4152488.html
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>

[Jakub Lach]

Thanks for all replies.

I personally have one PIII-S system somewhere, as this CPU was relatively
popular in certain applications, others might want to use it still.
Regarding memory that's quite true of typical setup at the time, but Intel
440BX can use 1024MB, which should be ok.

I would certainly like to update this system to something more recent time
permitting, though I admit it has already felt behind and haven't seen
anything like 11-STABLE or 12.



--
Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-arch-f4152488.html

[Warner Losh]

On Wed, Oct 3, 2018 at 3:54 PM Robert Clausecker <***@fuz.su> wrote:

> I request that ed(4)


How many FreeBSD 12.0 machines do you have running with this interface?

QEMU does support this interface, but also supports the Intel E1000 series
(em/igb), so it's not necessarily needed for QEMU.

Warner

[Robert Clausecker]

I have a machine with FreeBSD 2.2.8 running with such an interface, but
none with FreeBSD 12, so you do have a point here. However, I am not
sure if it's a good idea to kill this driver; it's good for over 100
different cards according to the man page, so surely there are some
users left.

Yours,
Robert Clausecker

On Wed, Oct 03, 2018 at 05:45:18PM -0600, Warner Losh wrote:
> On Wed, Oct 3, 2018 at 3:54 PM Robert Clausecker <***@fuz.su> wrote:
>
> > I request that ed(4)
>
>
> How many FreeBSD 12.0 machines do you have running with this interface?
>
> QEMU does support this interface, but also supports the Intel E1000 series
> (em/igb), so it's not necessarily needed for QEMU.
>
> Warner

--
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments

[Warner Losh]

Well, I'd wager its 100 cards that nobody is currently using (ed) has no
value. Even 1000 different cards or 10,000. The ed(4) driver likely
supported in excess of 1000 different cards because so many people made
ne-2000 compatible cards... in the early 1990s. However, since nobody has
ISA or PC Card (not CardBus) interfaces anymore (those machines topped out
around 32-64MB, which FreeBSD no longer works well on), the benefit to the
project is quite low. Even the 'newer' PC Card versions that were 10/100
couldn't get more than about 10-12Mbps due to ISA/PC Card bus speed
limitations. The PCI versions were never popular (I had to hunt a bunch for
them 10 years ago when I was finishing up my activities on the driver for
my vast PC Card collection to find an example to test), and even it had
trouble beyond 20Mbps because it wasn't DMA'd. The ED driver was a solid
driver last time I tried it, but when I can plug in dozens of 100Mbps or
1Gbps cards into the same CardBus slot and those cost < $10 now, there's
very little return on programmer time to keeping this one going.

However, having said all that, if we can document 5 real users of this card
on machines running FreeBSD 12, it will meet the criteria for remaining,
just like any other driver.... So far we've found 0, while we have found
many other users of other drivers.

Warner

On Thu, Oct 4, 2018 at 8:27 AM Robert Clausecker <***@fuz.su> wrote:

> I have a machine with FreeBSD 2.2.8 running with such an interface, but
> none with FreeBSD 12, so you do have a point here. However, I am not
> sure if it's a good idea to kill this driver; it's good for over 100
> different cards according to the man page, so surely there are some
> users left.
>
> Yours,
> Robert Clausecker
>
> On Wed, Oct 03, 2018 at 05:45:18PM -0600, Warner Losh wrote:
> > On Wed, Oct 3, 2018 at 3:54 PM Robert Clausecker <***@fuz.su> wrote:
> >
> > > I request that ed(4)
> >
> >
> > How many FreeBSD 12.0 machines do you have running with this interface?
> >
> > QEMU does support this interface, but also supports the Intel E1000
> series
> > (em/igb), so it's not necessarily needed for QEMU.
> >
> > Warner
>
> --
> () ascii ribbon campaign - for an 8-bit clean world
> /\ - against html email - against proprietary attachments
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>

[Cy Schubert]

I have a laptop (used for i386 testing) with that NIC. The plan is to move rl(4) to ports until I no longer need to test i386 on real hardware.

Will this help?

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Warner Losh
Sent: 03/10/2018 16:45
To: Jakub Lach
Cc: freebsd-***@freebsd.org
Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Do you have any machines running FreeBSD 12.0 with this interface? The
requirement is that we have at least 5 real users of the interface on
FreeBSD 12.

Many of the P III era PCs aren't beefy enough to run FreeBSD very well
(specifically, they typically lack adequate memory).

QEMU also emulates newer NICs, so you wouldn't be left w/o a solution. The
NE-2000 is still supported, as well E1000 (em/igb) interfaces.

Warner

On Wed, Oct 3, 2018 at 5:36 PM Jakub Lach <***@mailplus.pl> wrote:

> I request to keep rl(4) as it's the standard ethernet card in PIII era PCs.
> Moreover, it's emulated by QEMU too.
>
>
>
> --
> Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-arch-f4152488.html
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Warner Losh]

Well, we're at 1 maybe 2 now. Only 3 more to go for a reprieve. :) You're
running FreeBSD-current on that i386 laptop, right?

Warner

On Wed, Oct 3, 2018 at 6:01 PM Cy Schubert <***@cschubert.com>
wrote:

> I have a laptop (used for i386 testing) with that NIC. The plan is to move
> rl(4) to ports until I no longer need to test i386 on real hardware.
>
> Will this help?
>
> ---
> Sent using a tiny phone keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top post. Apologies.
>
> Cy Schubert
> <***@cschubert.com> or <***@freebsd.org>
> The need of the many outweighs the greed of the few.
> ---
> ------------------------------
> From: Warner Losh
> Sent: 03/10/2018 16:45
> To: Jakub Lach
> Cc: freebsd-***@freebsd.org
> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
>
> Do you have any machines running FreeBSD 12.0 with this interface? The
> requirement is that we have at least 5 real users of the interface on
> FreeBSD 12.
>
> Many of the P III era PCs aren't beefy enough to run FreeBSD very well
> (specifically, they typically lack adequate memory).
>
> QEMU also emulates newer NICs, so you wouldn't be left w/o a solution. The
> NE-2000 is still supported, as well E1000 (em/igb) interfaces.
>
> Warner
>
> On Wed, Oct 3, 2018 at 5:36 PM Jakub Lach <***@mailplus.pl> wrote:
>
> > I request to keep rl(4) as it's the standard ethernet card in PIII era
> PCs.
> > Moreover, it's emulated by QEMU too.
> >
> >
> >
> > --
> > Sent from:
> http://freebsd.1045724.x6.nabble.com/freebsd-arch-f4152488.html
> > _______________________________________________
> > freebsd-***@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> > To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
> >
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>
>

[Rick Macklem]

Warner Losh wrote:
>Well, we're at 1 maybe 2 now. Only 3 more to go for a reprieve. :) You're
>running FreeBSD-current on that i386 laptop, right?
>
>Warner
>
>On Wed, Oct 3, 2018 at 6:01 PM Cy Schubert <***@cschubert.com>
>wrote:
>
>> I have a laptop (used for i386 testing) with that NIC. The plan is to move
>> rl(4) to ports until I no longer need to test i386 on real hardware.
>>
>> Will this help?
My main development machine has a bfe in it, so I will definitely be
keeping a driver for it going. I don't care if it goes away from head/current.
(I can leave the driver somewhere for anyone else that wants it, although
I'm not a ports guy, so someone else would have to put it in ports.)
The other box I run FreeBSD on is an fxp, so I'll be doing the same for it, if/when it gets deleted. I find these machines work fine, but I don't do ZFS.
[stuff snipped]

rick

[Konstantin Belousov]

On Thu, Oct 04, 2018 at 12:21:13AM +0000, Rick Macklem wrote:
> My main development machine has a bfe in it, so I will definitely be
> keeping a driver for it going. I don't care if it goes away from head/current.
> (I can leave the driver somewhere for anyone else that wants it, although

I have CoreM/1.5G laptop which netboots whatever I need for testing,
the machine has bfe in it. It is i386 machine, this is Cores which did
not yet have long mode. The machine is one of my bare metal i386 crash
boxes. Am I qualified ?

Anyway, count of 5 looks quite arbitrary.

[Kim Shrier]

On Oct 3, 2018, at 6:09 PM, Warner Losh <***@bsdimp.com> wrote:
>
> Well, we're at 1 maybe 2 now. Only 3 more to go for a reprieve. :) You're
> running FreeBSD-current on that i386 laptop, right?
>

I am also using rl(4) on my home firewall machine. Yes, it is built out of
ancient hardware but it works just fine.

Are we up to 3?

Kim

[A. Wilcox]

On 10/03/18 21:28, Kim Shrier wrote:
> On Oct 3, 2018, at 6:09 PM, Warner Losh <***@bsdimp.com> wrote:
>>
>> Well, we're at 1 maybe 2 now. Only 3 more to go for a reprieve. :) You're
>> running FreeBSD-current on that i386 laptop, right?
>>
>
> I am also using rl(4) on my home firewall machine. Yes, it is built out of
> ancient hardware but it works just fine.
>
> Are we up to 3?
>
> Kim


I have three machines left that run FreeBSD. One has 1x hme (which
seems safe), one 2x rl (which hopefully may be safe), and the last has
1x pcn 1x ed (ouch! this one probably will end up going to NetBSD).

They all run 11, only because none of them are up to the task of
building current. Plans to upgrade to 12 over the US November holiday
times have already been made.

Funny enough, I've been looking at bringing up a FreeBSD machine or two
for PowerPC work, so that number may go up to four or five. I believe
all my PowerPCs capable of booting FreeBSD have gigE, however, so no
issues are likely.

--arw


--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/

[Cy Schubert]

Yup.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Warner Losh
Sent: 03/10/2018 17:11
To: Cy Schubert
Cc: Jakub Lach; freebsd-***@freebsd.org
Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Well, we're at 1 maybe 2 now. Only 3 more to go for a reprieve. :) You're running FreeBSD-current on that i386 laptop, right?



Warner



On Wed, Oct 3, 2018 at 6:01 PM Cy Schubert <***@cschubert.com> wrote:





I have a laptop (used for i386 testing) with that NIC. The plan is to move rl(4) to ports until I no longer need to test i386 on real hardware.

Will this help?

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---



From: Warner Losh
Sent: 03/10/2018 16:45
To: Jakub Lach
Cc: freebsd-***@freebsd.org
Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Do you have any machines running FreeBSD 12.0 with this interface? The
requirement is that we have at least 5 real users of the interface on
FreeBSD 12.

Many of the P III era PCs aren't beefy enough to run FreeBSD very well
(specifically, they typically lack adequate memory).

QEMU also emulates newer NICs, so you wouldn't be left w/o a solution. The
NE-2000 is still supported, as well E1000 (em/igb) interfaces.

Warner

On Wed, Oct 3, 2018 at 5:36 PM Jakub Lach <***@mailplus.pl> wrote:

> I request to keep rl(4) as it's the standard ethernet card in PIII era PCs.
> Moreover, it's emulated by QEMU too.
>
>
>
> --
> Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-arch-f4152488.html
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Rodney W. Grimes]

> >>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting

Since when did a FCP become a core only process???? Why was this
dicussed within core and not within the larger community?

> feedback on the list of drivers to be excepted from removal.

I am going to strongly object to the whole thing,
as this is NOT how the FCP process is suppose to work it
is not for core to dictate this type of policy to
the developers.

> 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
>
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> Please reply to this message with nominations to the exception list.
>
> The full FCP-0101 is included below.
>
> -- Brooks
>
> ---
> authors: Brooks Davis <***@freebsd.org>
> state: feedback
> ---
>
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
>
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
>
> ## Problem Statement
>
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility. For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces. We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
>
> 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.
>
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices. We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones. With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
>
> ## Proposed Solution
>
> We propose to deprecate devices which are not sufficiently popular. This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> attach routines for each device to be removed and merge those changes
> to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
> freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
> devices.
>
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required. For a device to be placed on
> the exception list the device must meet one of the following criteria:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> ### Exceptions to removal
>
> Device | Reason
> -------|-------------------------------------------------
> ffec | Onboard Ethernet for Vybrid arm7 boards
> fxp | Popular device long recommended by the project.
> dc | Popular device for CardBus card.
> hme | Built in interface on many supported sparc64 platforms.
> le | Emulated by QEMU, alternatives don't yet work for mips64.
> sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
> vr | Soekris Engineering net5501, some Asus motherboards.
> xl | Popular device for CardBus card.
>
> Note: USB devices have been excluded from consideration in this round.
>
> ### Device to be removed
>
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
>
> ## Final Disposition
>
> TBD
-- End of PGP section, PGP failed!

--
Rod Grimes ***@freebsd.org

[Warner Losh]

On Wed, Oct 3, 2018 at 7:58 PM Rodney W. Grimes <
freebsd-***@pdx.rh.cn85.dnsmgr.net> wrote:

> > >>> Please direct replies to freebsd-arch <<<
> >
> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > improving the network stack. We have discussed this within the
> > core team and intend to move forward as proposed. We are solictiting
>
> Since when did a FCP become a core only process???? Why was this
> dicussed within core and not within the larger community?
>

Core hasn't approved this FCP, we're in the community discussion phase now.
If you have substantive comments, please comment. It's a proposal, and it's
being discussed now.


> > feedback on the list of drivers to be excepted from removal.
>
> I am going to strongly object to the whole thing,
> as this is NOT how the FCP process is suppose to work it
> is not for core to dictate this type of policy to
> the developers.
>

We've just started the process. The FCP is a draft for discussion. Core
hasn't approved it, since there's no discussion to look at to weigh what
consensus might be and add whatever oversight we may need to. The
conversation has just started.

Warner


> > 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
> >
> > The criteria for exception are:
> > - Popular in applications where it is likely to be deployed beyond the
> > support lifetime of FreeBSD 12 (late 2023).
> > - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> > deemed satisfy the "popular"
> > requirement.
> > - Required to make a well supported embedded or emulation platform
> usable.
> > - Ported to use iflib (reducing future maintenance cost.)
> >
> > Please reply to this message with nominations to the exception list.
> >
> > The full FCP-0101 is included below.
> >
> > -- Brooks
> >
> > ---
> > authors: Brooks Davis <***@freebsd.org>
> > state: feedback
> > ---
> >
> > # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
> >
> > Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> > FreeBSD 13.
> >
> > ## Problem Statement
> >
> > Each network driver creates drag for the project as we attempt to
> > improve the network stack or provide new features such as expanded
> > 32-bit compatibility. For example, the author has edited every single
> > NIC driver more than once in the past year to update management (`ioctl`)
> > interfaces. We could improve this situation by converting drivers to
> > iflib, but each additional driver takes work.
> >
> > 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.
> >
> > For at least a decade, most systems (including small embedded
> > systems) have shipped with gigabit Ethernet devices and virtual
> > machines commonly emulate popular gigabit devices. We wish to
> > retain support for popular physical and virtual devices while
> > removing support for uncommon ones. With a few exceptions these
> > drivers are unlikely to be used by our user base by the time FreeBSD
> > 12 is obsolete (approximately 2024).
> >
> > ## Proposed Solution
> >
> > We propose to deprecate devices which are not sufficiently popular. This
> > will entail:
> > - (October 2018) Send this list to freebsd-net and freebsd-stable.
> > - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> > attach routines for each device to be removed and merge those changes
> > to FreeBSD 12.
> > - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
> > freebsd-net and freebsd-stable users of pending deletion.
> > - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete
> deprecated
> > devices.
> >
> > Through out this process, solicit feedback on additions to the exception
> > list and update this document as required. For a device to be placed on
> > the exception list the device must meet one of the following criteria:
> > - Popular in applications where it is likely to be deployed beyond the
> > support lifetime of FreeBSD 12 (late 2023).
> > - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> > deemed satisfy the "popular"
> > requirement.
> > - Required to make a well supported embedded or emulation platform
> usable.
> > - Ported to use iflib (reducing future maintenance cost.)
> >
> > ### Exceptions to removal
> >
> > Device | Reason
> > -------|-------------------------------------------------
> > ffec | Onboard Ethernet for Vybrid arm7 boards
> > fxp | Popular device long recommended by the project.
> > dc | Popular device for CardBus card.
> > hme | Built in interface on many supported sparc64 platforms.
> > le | Emulated by QEMU, alternatives don't yet work for mips64.
> > sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
> > vr | Soekris Engineering net5501, some Asus motherboards.
> > xl | Popular device for CardBus card.
> >
> > Note: USB devices have been excluded from consideration in this round.
> >
> > ### Device to be removed
> >
> > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> > ste, tl, tx, txp, vx, wb, xe
> >
> > ## Final Disposition
> >
> > TBD
> -- End of PGP section, PGP failed!
>
> --
> Rod Grimes
> ***@freebsd.org
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>

[Brooks Davis]

On Wed, Oct 03, 2018 at 08:18:15PM -0600, Warner Losh wrote:
> On Wed, Oct 3, 2018 at 7:58 PM Rodney W. Grimes <
> freebsd-***@pdx.rh.cn85.dnsmgr.net> wrote:
>
> > > >>> Please direct replies to freebsd-arch <<<
> > >
> > > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > > improving the network stack. We have discussed this within the
> > > core team and intend to move forward as proposed. We are solictiting
> >
> > Since when did a FCP become a core only process???? Why was this
> > dicussed within core and not within the larger community?
>
> Core hasn't approved this FCP, we're in the community discussion phase now.
> If you have substantive comments, please comment. It's a proposal, and it's
> being discussed now.

As Warner says, this FCP isn't approved. Core's discussion centers on
two points. First, we'd like to encourage the use the FCP process to
solicit feedback and document decisions. That means using it so we can
grind the sharp edges off and understand what works and doesn't work.
Second, core believes that we support too much stuff and do a bad job of
removing old things. Threads like this are a way to get more data prior
to adding deprecation annotations (another way to collect data).

Thus far we've found some that clearly should be on the exception list
which is exactly as expected.

-- Brooks

[Andy Farkas]

On 04/10/2018 07:05, Brooks Davis wrote:
>>>> Please direct replies to freebsd-arch <<<
> 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
>

I do not see:

de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:00:c0:bf:6a:e4
inet 172.22.2.34 netmask 0xfffffff0 broadcast 172.22.2.47
inet6 fe80::200:c0ff:febf:6ae4%de0 prefixlen 64 scopeid 0x1
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet 10base2/BNC
status: active

on the list.

FreeBSD 10.3-RELEASE-p5 #0: Thu Jun 30 03:52:15 UTC 2016
(yes, a very old version, but you know.... if it ain't broke, don't fix it)

-andyf

[Warner Losh]

On Wed, Oct 3, 2018 at 9:50 PM Andy Farkas <***@andyit.com.au> wrote:

> On 04/10/2018 07:05, Brooks Davis wrote:
> >>>> Please direct replies to freebsd-arch <<<
> > 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
> >
>
> I do not see:
>
> de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> ether 00:00:c0:bf:6a:e4
> inet 172.22.2.34 netmask 0xfffffff0 broadcast 172.22.2.47
> inet6 fe80::200:c0ff:febf:6ae4%de0 prefixlen 64 scopeid 0x1
> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> media: Ethernet 10base2/BNC
> status: active
>
> on the list.
>
> FreeBSD 10.3-RELEASE-p5 #0: Thu Jun 30 03:52:15 UTC 2016
> (yes, a very old version, but you know.... if it ain't broke, don't fix it)
>

Are you planning on upgrading?

de should have been on the list to go.... Its a fairly uncommon NIC....

Warner

[Andy Farkas]

On 04/10/2018 13:54, Warner Losh wrote:
>
>
> On Wed, Oct 3, 2018 at 9:50 PM Andy Farkas <***@andyit.com.au
> <mailto:***@andyit.com.au>> wrote:
>
> On 04/10/2018 07:05, Brooks Davis wrote:
> >>>> Please direct replies to freebsd-arch <<<
> > 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
> >
>
> I do not see:
>
> de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> mtu 1500
> ether 00:00:c0:bf:6a:e4
> inet 172.22.2.34 netmask 0xfffffff0 broadcast 172.22.2.47
> inet6 fe80::200:c0ff:febf:6ae4%de0 prefixlen 64 scopeid 0x1
> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> media: Ethernet 10base2/BNC
> status: active
>
> on the list.
>
> FreeBSD 10.3-RELEASE-p5 #0: Thu Jun 30 03:52:15 UTC 2016
> (yes, a very old version, but you know.... if it ain't broke,
> don't fix it)
>
>
> Are you planning on upgrading?
>
> de should have been on the list to go.... Its a fairly uncommon NIC....
>
>

I guess I won't be upgrading. I tried, but PC-BSD won't update anymore.

I use this box to MOP boot my Vaxen, with tftp and bootparamd.

NetBSD is looking like the option for me.

-andyf

[A. Wilcox]

On 10/03/18 16:05, Brooks Davis wrote:
> We propose to deprecate devices which are not sufficiently popular. This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> attach routines for each device to be removed and merge those changes
> to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2019) Remind
> freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
> devices.


[ ... ]


> For a device to be placed on
> the exception list the device must meet one of the following criteria:

[ ... ]

> - Ported to use iflib (reducing future maintenance cost.)


So, does that mean that the window for porting to iflib is between now
and January? Or would the driver need to be ported before the FCP is
passed?

Sorry, just wondering for clarification's sake, since I have a pcn and
rl hanging around and if I have any free time I could potentially look
at porting, if that'd help.

--arw


--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/

[Warner Losh]

On Wed, Oct 3, 2018 at 10:05 PM A. Wilcox <***@wilcox-tech.com> wrote:

> So, does that mean that the window for porting to iflib is between now
> and January? Or would the driver need to be ported before the FCP is
> passed?
>

I believe the notion was between now and the removal time.


> Sorry, just wondering for clarification's sake, since I have a pcn and
> rl hanging around and if I have any free time I could potentially look
> at porting, if that'd help.
>

That would be awesome.

Warner

[Eugene Grosbein]

04.10.2018 4:05, Brooks Davis wrote:

>>>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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

"fxpl" should have been "fxp" here, I suppose.

While I have no objection for general direction, I have doubts about removal of ste(4) and especially rl(4).
These are cheap 100Mbit VERY popular NICs sold in enourmous values in certain markets
by vendors like D-Link and TP-Link using various trade names.

Lack of support for such popular 100M cards won't be good for FreeBSD, I suppose.

[Vladimir Terziev]

I also call for keeping of the ste(4) driver.

We use several 4-head D-Link DFE-580TX cards. Removing their support would incur serious expenses for us for replacement hardware.


> On 4 Oct 2018, at 09:03, Eugene Grosbein <***@grosbein.net> wrote:
>
> 04.10.2018 4:05, Brooks Davis wrote:
>
>>>>> Please direct replies to freebsd-arch <<<
>>
>> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
>> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
>> and remove them in FreeBSD 13 to reduce the burden of maintaining and
>> improving the network stack. We have discussed this within the
>> core team and intend to move forward as proposed. We are solictiting
>> feedback on the list of drivers to be excepted from removal.
>>
>> 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
>
> "fxpl" should have been "fxp" here, I suppose.
>
> While I have no objection for general direction, I have doubts about removal of ste(4) and especially rl(4).
> These are cheap 100Mbit VERY popular NICs sold in enourmous values in certain markets
> by vendors like D-Link and TP-Link using various trade names.
>
> Lack of support for such popular 100M cards won't be good for FreeBSD, I suppose.
>
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-***@freebsd.org"

[Luciano Mannucci]

On Thu, 4 Oct 2018 13:03:01 +0700
Eugene Grosbein <***@grosbein.net> wrote:
> > The current list of drivers that will STAY in the tree is:
> >
> > dc, ffec, fxpl, hme, le, sis, vr, xl
>
> "fxpl" should have been "fxp" here, I suppose.
>
> While I have no objection for general direction, I have doubts about removal
> of ste(4) and especially rl(4). These are cheap 100Mbit VERY popular NICs
> sold in enourmous values in certain markets by vendors like D-Link and
> TP-Link using various trade names.
>
> Lack of support for such popular 100M cards won't be good for FreeBSD, I
> suppose.
+ 1

I have a lot of them in production systems. It would be a pity that they
will never get a 12.x or newer version ever. I can replace few de cards
but not everything...

Luciano.
--
/"\ /Via A. Salaino, 7 - 20144 Milano (Italy)
\ / ASCII RIBBON CAMPAIGN / PHONE : [phone] FAX: [phone]
X AGAINST HTML MAIL / E-MAIL: ***@sublink.sublink.ORG
/ \ AND POSTINGS / WWW: http://www.lesassaie.IT/

[Warner Losh]

On Thu, Oct 4, 2018 at 6:53 AM Luciano Mannucci <***@vespaperitivo.it>
wrote:

> On Thu, 4 Oct 2018 13:03:01 +0700
> Eugene Grosbein <***@grosbein.net> wrote:
> > > The current list of drivers that will STAY in the tree is:
> > >
> > > dc, ffec, fxpl, hme, le, sis, vr, xl
> >
> > "fxpl" should have been "fxp" here, I suppose.
>

Yes.


> > While I have no objection for general direction, I have doubts about
> removal
> > of ste(4) and especially rl(4). These are cheap 100Mbit VERY popular NICs
> > sold in enourmous values in certain markets by vendors like D-Link and
> > TP-Link using various trade names.
>

Enough people are using rl that it's off the list by my count.


> > Lack of support for such popular 100M cards won't be good for FreeBSD, I
> > suppose.
>
> I have a lot of them in production systems. It would be a pity that they
> will never get a 12.x or newer version ever. I can replace few de cards
> but not everything...
>

To be clear, the proposal is that 12.x be the last branch they are
supported in and not in 13. So while we'd remove them from current soon,
they'd still be in 12 for the life of the 12.x branch, so into the early
2020's.

Warner

[Kevin Day]

> On Oct 4, 2018, at 7:58 AM, Warner Losh <***@bsdimp.com> wrote:
>
> On Thu, Oct 4, 2018 at 6:53 AM Luciano Mannucci <***@vespaperitivo.it>
> wrote:
>
>>> While I have no objection for general direction, I have doubts about
>> removal
>>> of ste(4) and especially rl(4). These are cheap 100Mbit VERY popular NICs
>>> sold in enourmous values in certain markets by vendors like D-Link and
>>> TP-Link using various trade names.
>>
>
> Enough people are using rl that it's off the list by my count.

If you need any extra data, rl is the only one that I'd be sad to lose as well. We have a lot of embedded devices that are still shipping today with rl chips. I could chip in a little to sponsor someone to modernize the driver if needed.

[Brooks Davis]

On Thu, Oct 04, 2018 at 11:21:03AM -0500, Kevin Day wrote:
>
>
> > On Oct 4, 2018, at 7:58 AM, Warner Losh <***@bsdimp.com> wrote:
> >
> > On Thu, Oct 4, 2018 at 6:53 AM Luciano Mannucci <***@vespaperitivo.it>
> > wrote:
> >
> >>> While I have no objection for general direction, I have doubts about
> >> removal
> >>> of ste(4) and especially rl(4). These are cheap 100Mbit VERY popular NICs
> >>> sold in enourmous values in certain markets by vendors like D-Link and
> >>> TP-Link using various trade names.
> >>
> >
> > Enough people are using rl that it's off the list by my count.
>
> If you need any extra data, rl is the only one that I'd be sad to lose as well. We have a lot of embedded devices that are still shipping today with rl chips. I could chip in a little to sponsor someone to modernize the driver if needed.

It's definitly on the STAY list at this point. If you could help get it
update that would be great, especially if it's still shipping (a very
useful datapoint).

-- Brooks

[Joel Dahl]

On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> >>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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

I have several of these nics, some used in machines running FreeBSD 10 or 11
and a few just laying around as spare. Please keep the following drivers:

ae
bfe
ed
pcn
rl
vx

Most machines will be upgraded to 12+ in the future.

(I actually have 9 machines with rl nics so I think they are quite common
still)...

--
Joel

[Alexey Dokuchaev]

On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12

Holy shit! OK I guess I can understand removing 10 (I personally haven't
seen one in a very long time) but 100 are omnipresent and most of my NICs
are in fact 100.

> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack.

Looking at the commits they require near zero maintenance. What exactly
is the burden here? Another question: why the fuck FreeBSD likes to kill
non-broken, low-volatile and perfectly working stuff? We offer probably
the best NIC driver support on the block, yet you're proposing to shrink
one of the few areas where we shine. WTF?!

> 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

ae(4) was used in Asus EeePC 701/900 which are still popular among hackers.
My home router uses sf(4) happily. It's a dual-port card and I don't want
to look for expensive and completely needless replacement. Other people
have already told you about ed/rl/etc.

> Please reply to this message with nominations to the exception list.

As it can be seen this list tends to cover nearly all 100 cards, yet no
one (pardon me if I missed those) asks for 10. So how about making this
proposal cover only 10 cards, if you can't resist the itch to remove
something from the tree?

./danfe

[Trev]

> On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. >
> 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
>
> Please reply to this message with nominations to the exception list.

Sill using my Asus EeePC 701 (just bought a new battery pack) for
FreeBSD with ae nic (and I do not foresee discontinuing its use any time
soon as its serial port comes in handy for talking to other serial devices).

[Christoph Moench-Tegeder]

## Alexey Dokuchaev (***@FreeBSD.org):

> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
>
> Holy shit! OK I guess I can understand removing 10 (I personally haven't
> seen one in a very long time) but 100 are omnipresent and most of my NICs
> are in fact 100.

Don't panic - they're talking about removing the 100 MBps NICS, not
the 100 GBps NICs.

Jokes aside - obviously there are very different populations of NICS.
Here, the only 100MBps interface is in the IP phone, and I would guess
that even most consumer hardware comes with a GBps interface on board
(heck, even RPis have a GBit interface, even if can't use more than 30%
of it's bandwith). Checking with a hardware-dealer: very few NICs in
their catalog are 100MBps, most are gigabit-grade.
I would have expected that things look different in the embedded world...
On the other hand, some data centers I know routinely use 10GBps, and
1 GBps is considered "legacy" there.

So, perceptions are very different... let's keep this rational and
make a list of cards still in use.

Regards,
Christoph

--
Spare Space

[Jamie Landeg-Jones]

Remember, it's not simply deprecating cards less than 1Gig.

I have a card that is 10/100 only, but works fine with the gigabit alc driver:

alc0: <Atheros AR8162 PCIe Fast Ethernet> port 0x2000-0x207f mem 0xe0500000-0xe053ffff irq 16 at device 0.0 on pci1

cheers, jamie

[Brooks Davis]

On Fri, Oct 05, 2018 at 04:18:22PM +0100, Jamie Landeg-Jones wrote:
> Remember, it's not simply deprecating cards less than 1Gig.
>
> I have a card that is 10/100 only, but works fine with the gigabit alc driver:
>
> alc0: <Atheros AR8162 PCIe Fast Ethernet> port 0x2000-0x207f mem 0xe0500000-0xe053ffff irq 16 at device 0.0 on pci1

There are no plans to touch such drivers.

-- Brooks

[Jamie Landeg-Jones]

Brooks Davis <***@freebsd.org> wrote:

> On Fri, Oct 05, 2018 at 04:18:22PM +0100, Jamie Landeg-Jones wrote:
> > Remember, it's not simply deprecating cards less than 1Gig.
> >
> > I have a card that is 10/100 only, but works fine with the gigabit alc driver:
> >
> > alc0: <Atheros AR8162 PCIe Fast Ethernet> port 0x2000-0x207f mem 0xe0500000-0xe053ffff irq 16 at device 0.0 on pci1
>
> There are no plans to touch such drivers.

Yep, sorry I wasn't clear. That's what I meant - I was responding to someone
who was worried that the support was being dropped for 100Mbps cards.

cheers, Jamie

[Dag-Erling Smørgrav]

Alexey Dokuchaev <***@FreeBSD.org> writes:
> Looking at the commits they require near zero maintenance.

Please do not confuse “nobody is maintaining them” with “they don't need
maintenance”, because they do. And please assume good faith. Brooks
asked for people to speak up if they care about some of the drivers he
proposed to remove; all you had to do was say “I still use this driver”.
There was no need to attack him, much less to swear.

DES
--
Dag-Erling Smørgrav - ***@des.no

[Warner Losh]

On Thu, Oct 4, 2018 at 2:45 AM Alexey Dokuchaev <***@freebsd.org> wrote:

> Looking at the commits they require near zero maintenance. What exactly
> is the burden here?
>

I believe that characterization is incorrect. There's a burden. And it's
death of a thousand cuts. And many of those cuts have been inflicted on
***@.

Most of these drivers have had dozens or hundreds of commits each over the
years to keep up with the API changes. This acts as a tax on innovation
because it's such a pain in the back side to change all the drivers in the
tree. I did a back of the envelope computation that this is on the order of
hundreds of hours of time, spread across all the drivers over all the years
we've supported them. Some of these drivers are clearly unused, and so
that's 100% wasted effort. Most of these drivers are on machines that most
likely won't be able to run 13.0 well when it comes out in 2 years due to
increased memory demands that it will almost certainly have. The declining
use means we anticipate that if we were to maintain them until 13, it would
be wasted effort for at least some on the list.

That's why that one way to get the driver off the list is to convert to
iflib. That greatly reduces the burden by centralizing all the stupid,
common things of a driver so that we only have to change one place, not
dozens.

At the root of this problem is the community's long resistance to having
data reported back to the project data about the machines running FreeBSD.
Absent any real and significant data, the only way to know if things are
unused is to ask. We cannot have the act of merely asking cause people to
freak out and hurl expletives all over the place. That's significantly not
cool.

Warner

[Poul-Henning Kamp]

--------
In message <CANCZdfpFXs_Ed-gMZnnSs2eAxYh8hdwr-***@mail.gmail.com>
, Warner Losh writes:

>Most of these drivers have had dozens or hundreds of commits each over the
>years to keep up with the API changes. This acts as a tax on innovation
>because it's such a pain in the back side to change all the drivers in the
>tree.

As one who has been there, a couple of times: SECONDED!

It is particular unpleasant when you have no way to test the changes.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Rick Macklem]

Warner Losh wrote:
[lots of stuff snipped]
>That's why that one way to get the driver off the list is to convert to
>iflib. That greatly reduces the burden by centralizing all the stupid,
>common things of a driver so that we only have to change one place, not
>dozens.

I can probably do this for bfe and fxp, since I have both.
Can someone suggest a good example driver that has already been converted,
so I can see what needs to be done?

Again, I don't care if they stay in the current/head tree.

[more stuff snipped]

rick

[Mark Linimon]

On Thu, Oct 04, 2018 at 08:44:11AM +0000, Alexey Dokuchaev wrote:
> OK I guess I can understand removing 10 (I personally haven't seen
> one in a very long time) but 100 are omnipresent and most of my NICs
> are in fact 100.

Sigh. If you really plan to still be using i386 and 10/100 ether in
2024, perhaps you should consider NetBSD.

You can buy used core i5 laptops for around $20 if you shop around.

mcl

[Alexey Dokuchaev]

On Thu, Oct 04, 2018 at 02:26:44PM +0000, Mark Linimon wrote:
> On Thu, Oct 04, 2018 at 08:44:11AM +0000, Alexey Dokuchaev wrote:
> > OK I guess I can understand removing 10 (I personally haven't seen
> > one in a very long time) but 100 are omnipresent and most of my NICs
> > are in fact 100.
>
> Sigh. If you really plan to still be using i386 and 10/100 ether in
> 2024, perhaps you should consider NetBSD.

I don't quite understand why are you grouping 10/100 vs. 1000 rather than
10 vs. 100/1000.

./danfe

[Warner Losh]

On Thu, Oct 4, 2018 at 8:40 AM Alexey Dokuchaev <***@freebsd.org> wrote:

> On Thu, Oct 04, 2018 at 02:26:44PM +0000, Mark Linimon wrote:
> > On Thu, Oct 04, 2018 at 08:44:11AM +0000, Alexey Dokuchaev wrote:
> > > OK I guess I can understand removing 10 (I personally haven't seen
> > > one in a very long time) but 100 are omnipresent and most of my NICs
> > > are in fact 100.
> >
> > Sigh. If you really plan to still be using i386 and 10/100 ether in
> > 2024, perhaps you should consider NetBSD.
>
> I don't quite understand why are you grouping 10/100 vs. 1000 rather than
> 10 vs. 100/1000.
>

As far as I know, none of the drivers listed could do 1Gbps. They were all
specifically 10Mbps or 10/100Mbps. Support for 10Mbps or 100Mbps isn't
being removed from the tree: there's still dozens of GigE drivers that can
do those speeds that have PCI or better bus attachments.

Warner

[Alexey Dokuchaev]

On Thu, Oct 04, 2018 at 08:43:33AM -0600, Warner Losh wrote:
> As far as I know, none of the drivers listed could do 1Gbps.

Right. My point was that original proposal put 10/100 drivers into one
basket, which is IMHO not fair: 10Mbps cards are rarely seen and used,
100mbps are not, just like 1000bps ones.

That said, I'm okay with deorbiting NICs that cannot do more than 10mbps.
Cards that can do at least 100mbps should stay. Following up on Ricks'
question, seeing a good example of modernization a certain driver would
help interested people/hw owners to keep drivers for their cards viable.

./danfe

[Eugene Grosbein]

04.10.2018 21:26, Mark Linimon wrote:

> You can buy used core i5 laptops for around $20 if you shop around.

And plus even more for overseas delivery.

[Peter Jeremy]

On 2018-Oct-04 08:44:11 +0000, Alexey Dokuchaev <***@FreeBSD.org> wrote:
>Looking at the commits they require near zero maintenance. What exactly
>is the burden here?

As various others have stated, this isn't true. All the code in FreeBSD has
an ongoing maintenance cost and is an impediment to adding new features.
There is no point in spending valuable developer effort to update drivers
and test them with unusual/obsolete hardware unless those drivers are going
to actually be used.

>Another question: why the fuck FreeBSD likes to kill
>non-broken, low-volatile and perfectly working stuff?

That language is uncalled for.

>We offer probably
>the best NIC driver support on the block, yet you're proposing to shrink
>one of the few areas where we shine. WTF?!

Supporting NICs that no-one uses doesn't benefit anyone. No-one is talking
about removing NICs that are in active use.

>ae(4) was used in Asus EeePC 701/900 which are still popular among hackers.

Those netbooks are more than a decade old now and I don't expect many are
still functional. Will people still expect to use them with FreeBSD 13 in 5
years time?

>As it can be seen this list tends to cover nearly all 100 cards, yet no
>one (pardon me if I missed those) asks for 10. So how about making this
>proposal cover only 10 cards,

What is the purpose in keeping unused FastEthernet cards in the tree?

>if you can't resist the itch to remove
>something from the tree?

Again, that language is uncalled for.

--
Peter Jeremy

[Philip Paeps]

On 2018-10-03 23:05:16 (+0200), Brooks Davis wrote:
>>>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD
> 12 and remove them in FreeBSD 13 to reduce the burden of maintaining
> and improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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

ae is still popular in many cheap Asian laptops (Asus, Acer, etc).
rl is still popular in many cheap PCI adapters.

I've not encountered any of the others in a very long time.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

[Alex Kozlov]

On Thu, Oct 04, 2018 at 11:45:26AM +0200, Philip Paeps wrote:
> On 2018-10-03 23:05:16 (+0200), Brooks Davis wrote:
> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > improving the network stack. We have discussed this within the core
> > team and intend to move forward as proposed. We are solictiting
> > feedback on the list of drivers to be excepted from removal.
> >
> > 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
>
> ae is still popular in many cheap Asian laptops (Asus, Acer, etc).
> rl is still popular in many cheap PCI adapters.
+1 for ae and rl


--
Alex

[tech-lists]

On 03/10/18 22:05, Brooks Davis wrote:
> We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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

Please do not remove rl. I have two rl interfaces in a machine built in
2011 still in daily use. One rl interface is an aftermarket card bought
new in *2016*. The other one is built into the motherboard. That's just
the stuff I personally own. rl is in lots of machines which will
probably still be running a decade from now.

I'm astonished you're considering removing rl given how common it is.

--
J.

[Michelle Sullivan]

tech-lists wrote:
>
> I'm astonished you're considering removing rl given how common it is.
>

I'll second that comment - though no disrespect to Brooks. Brooks as
far as I can see is just the messenger.

--
Michelle Sullivan
http://www.mhix.org/

[Warner Losh]

On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan <***@sorbs.net>
wrote:

> tech-lists wrote:
> >
> > I'm astonished you're considering removing rl given how common it is.
> >
>
> I'll second that comment - though no disrespect to Brooks. Brooks as
> far as I can see is just the messenger.
>

Absent good data, one has to make one's best guesses. I guessed wrong here
in my comments to Brooks about which ones were must keeps. I knew it was
popular back in the day (~2000), but had thought it's popularity had waned
much more than it apparently has. I last deployed systems with rl in them
around 2007, and at the time it was trailing edge gear (the SBCs we used at
Timing Solutions tended to use popular, but ~5-year-old technology because
that market segment wanted longevity of spare availability...).

Warner

[Warner Losh]

On Thu, Oct 4, 2018 at 11:26 AM Ian Lepore <***@freebsd.org> wrote:

> On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote:
> > On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan <***@sorbs.net>
> > wrote:
> >
> > >
> > > tech-lists wrote:
> > > >
> > > >
> > > > I'm astonished you're considering removing rl given how common it is.
> > > >
> > > I'll second that comment - though no disrespect to Brooks. Brooks as
> > > far as I can see is just the messenger.
> > >
> > Absent good data, one has to make one's best guesses. I guessed wrong
> here
> > in my comments to Brooks about which ones were must keeps. I knew it was
> > popular back in the day (~2000), but had thought it's popularity had
> waned
> > much more than it apparently has. I last deployed systems with rl in them
> > around 2007, and at the time it was trailing edge gear (the SBCs we used
> at
> > Timing Solutions tended to use popular, but ~5-year-old technology
> because
> > that market segment wanted longevity of spare availability...).
> >
> > Warner
>
> 11 years later, we (Timing Solutions, now a division of Microchip) are
> still using SBCs with rl(4) hardware and still shipping software
> updates with that driver built into the kernel. We build systems with a
> lifespan in the field of 20 years or more, and the stability and
> compatibility across OS upgrades over that kind of span is a BIG reason
> to use freebsd rather than linux for such things.
>

OK. I'd have thought those SBCs would have gone out of production years
ago.... It's a good datapoint to know that there's multiple users of
FreeBSD using these parts in products that are still shipping. That's a
clear and compelling benefit to the project that offsets the efforts that
it's taken them to keep things current with rl.

In this case, though, rl is off the list, so that hardware should still be
good. The only other SBC I was aware of at Timing Solutions was one that
had an 'ed' chip on it (an ISA realtek part IIRC) that was used in around
2001, but in a 'one off' custom setup that I don't think will ever be
upgraded.... But I have to ask since I know how things worked during my
time there and systems that 'would never be upgraded' often times were
later...

I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
which I doubt are in use in any FreeBSD system of any age today.

Warner

[Warner Losh]

On Thu, Oct 4, 2018 at 11:47 AM Ian Lepore <***@freebsd.org> wrote:

> On Thu, 2018-10-04 at 11:38 -0600, Warner Losh wrote:
> > On Thu, Oct 4, 2018 at 11:26 AM Ian Lepore <***@freebsd.org> wrote:
> >
> > >
> > > On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote:
> > > >
> > > > On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > tech-lists wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > I'm astonished you're considering removing rl given how common
> it is.
> > > > > >
> > > > > I'll second that comment - though no disrespect to Brooks. Brooks
> as
> > > > > far as I can see is just the messenger.
> > > > >
> > > > Absent good data, one has to make one's best guesses. I guessed wrong
> > > here
> > > >
> > > > in my comments to Brooks about which ones were must keeps. I knew it
> was
> > > > popular back in the day (~2000), but had thought it's popularity had
> > > waned
> > > >
> > > > much more than it apparently has. I last deployed systems with rl in
> them
> > > > around 2007, and at the time it was trailing edge gear (the SBCs we
> used
> > > at
> > > >
> > > > Timing Solutions tended to use popular, but ~5-year-old technology
> > > because
> > > >
> > > > that market segment wanted longevity of spare availability...).
> > > >
> > > > Warner
> > > 11 years later, we (Timing Solutions, now a division of Microchip) are
> > > still using SBCs with rl(4) hardware and still shipping software
> > > updates with that driver built into the kernel. We build systems with a
> > > lifespan in the field of 20 years or more, and the stability and
> > > compatibility across OS upgrades over that kind of span is a BIG reason
> > > to use freebsd rather than linux for such things.
> > >
> > OK. I'd have thought those SBCs would have gone out of production years
> > ago.... It's a good datapoint to know that there's multiple users of
> > FreeBSD using these parts in products that are still shipping. That's a
> > clear and compelling benefit to the project that offsets the efforts that
> > it's taken them to keep things current with rl.
> >
> > In this case, though, rl is off the list, so that hardware should still
> be
> > good. The only other SBC I was aware of at Timing Solutions was one that
> > had an 'ed' chip on it (an ISA realtek part IIRC) that was used in around
> > 2001, but in a 'one off' custom setup that I don't think will ever be
> > upgraded.... But I have to ask since I know how things worked during my
> > time there and systems that 'would never be upgraded' often times were
> > later...
> >
> > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> > which I doubt are in use in any FreeBSD system of any age today.
> >
> > Warner
>
> I checked all our various kernel configs, and the only one on the list
> we still use appears to be rl.
>
> One driver I was surprised to see was not on the list was vte. So I'll
> just preemptively mention that we do use that one too.
>

I'll assume that you've deployed more than 5 of these systems and that you
may someday upgrade them as well? Which of the Vortex86 processors are you
using, if you can answer that...

Warner

[Ian Lepore]

On Thu, 2018-10-04 at 11:58 -0600, Warner Losh wrote:
> On Thu, Oct 4, 2018 at 11:47 AM Ian Lepore <***@freebsd.org> wrote:
>
> >
> > On Thu, 2018-10-04 at 11:38 -0600, Warner Losh wrote:
> > >
> > > On Thu, Oct 4, 2018 at 11:26 AM Ian Lepore <***@freebsd.org>
> > > wrote:
> > >
> > > >
> > > >
> > > > On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote:
> > > > >
> > > > >
> > > > > On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > tech-lists wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I'm astonished you're considering removing rl given how
> > > > > > > common
> > it is.
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > I'll second that comment - though no disrespect to
> > > > > > Brooks.  Brooks
> > as
> > >
> > > >
> > > > >
> > > > > >
> > > > > > far as I can see is just the messenger.
> > > > > >
> > > > > Absent good data, one has to make one's best guesses. I
> > > > > guessed wrong
> > > > here
> > > > >
> > > > >
> > > > > in my comments to Brooks about which ones were must keeps. I
> > > > > knew it
> > was
> > >
> > > >
> > > > >
> > > > > popular back in the day (~2000), but had thought it's
> > > > > popularity had
> > > > waned
> > > > >
> > > > >
> > > > > much more than it apparently has. I last deployed systems
> > > > > with rl in
> > them
> > >
> > > >
> > > > >
> > > > > around 2007, and at the time it was trailing edge gear (the
> > > > > SBCs we
> > used
> > >
> > > >
> > > > at
> > > > >
> > > > >
> > > > > Timing Solutions tended to use popular, but ~5-year-old
> > > > > technology
> > > > because
> > > > >
> > > > >
> > > > > that market segment wanted longevity of spare
> > > > > availability...).
> > > > >
> > > > > Warner
> > > > 11 years later, we (Timing Solutions, now a division of
> > > > Microchip) are
> > > > still using SBCs with rl(4) hardware and still shipping
> > > > software
> > > > updates with that driver built into the kernel. We build
> > > > systems with a
> > > > lifespan in the field of 20 years or more, and the stability
> > > > and
> > > > compatibility across OS upgrades over that kind of span is a
> > > > BIG reason
> > > > to use freebsd rather than linux for such things.
> > > >
> > > OK. I'd have thought those SBCs would have gone out of production
> > > years
> > > ago.... It's a good datapoint to know that there's multiple users
> > > of
> > > FreeBSD using these parts in products that are still shipping.
> > > That's a
> > > clear and compelling benefit to the project that offsets the
> > > efforts that
> > > it's taken them to keep things current with rl.
> > >
> > > In this case, though, rl is off the list, so that hardware should
> > > still
> > be
> > >
> > > good. The only other SBC I was aware of at Timing Solutions was
> > > one that
> > > had an 'ed' chip on it (an ISA realtek part IIRC) that was used
> > > in around
> > > 2001, but in a 'one off' custom setup that I don't think will
> > > ever be
> > > upgraded.... But I have to ask since I know how things worked
> > > during my
> > > time there and systems that 'would never be upgraded' often times
> > > were
> > > later...
> > >
> > > I'd also suggest that rl stands in stark contrast to the cs, wb,
> > > sn, smc,
> > > sf, tl, tx and vr drivers, which nobody has mentioned in this
> > > thread, and
> > > which I doubt are in use in any FreeBSD system of any age today.
> > >
> > > Warner
> > I checked all our various kernel configs, and the only one on the
> > list
> > we still use appears to be rl.
> >
> > One driver I was surprised to see was not on the list was vte. So
> > I'll
> > just preemptively mention that we do use that one too.
> >
> I'll assume that you've deployed more than 5 of these systems and
> that you
> may someday upgrade them as well?  Which of the Vortex86 processors
> are you
> using, if you can answer that...
>
> Warner

It's a DM&P Vortex86DX on a PCA-6743 board, which you can still buy.

32-bit only, BTW, which is why I hate hearing recent mumblings about
discarding 32-bit x86 support in freebsd.

-- Ian

[Eugene Grosbein]

05.10.2018 0:38, Warner Losh wrote:

> I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> which I doubt are in use in any FreeBSD system of any age today.

vr(4) mentioned in the STAY list or else I would be first yelling as
it is still very common in embedded solutions (including integrated ports in my home router).

[Warner Losh]

On Thu, Oct 4, 2018 at 12:18 PM Eugene Grosbein <***@grosbein.net> wrote:

> 05.10.2018 0:38, Warner Losh wrote:
>
> > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> > which I doubt are in use in any FreeBSD system of any age today.
>
> vr(4) mentioned in the STAY list or else I would be first yelling as
> it is still very common in embedded solutions (including integrated ports
> in my home router).
>

Sorry, I'd meant to type vx. :) It's for the first generation of 3com cards
after the 3C5x9 ones supported by the ep driver.

Warner

[Joel Dahl]

On Thu, Oct 04, 2018 at 12:23:17PM -0600, Warner Losh wrote:
> On Thu, Oct 4, 2018 at 12:18 PM Eugene Grosbein <***@grosbein.net> wrote:
>
> > 05.10.2018 0:38, Warner Losh wrote:
> >
> > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> > > which I doubt are in use in any FreeBSD system of any age today.
> >
> > vr(4) mentioned in the STAY list or else I would be first yelling as
> > it is still very common in embedded solutions (including integrated ports
> > in my home router).
> >
>
> Sorry, I'd meant to type vx. :) It's for the first generation of 3com cards
> after the 3C5x9 ones supported by the ep driver.

I mentioned vx. Working fine here:

vx0: <3COM 3C590 Etherlink III PCI> port 0x1100-0x111f irq 20 at device 0.0 on pci16

--
Joel

[Michael Schmiedgen]

> I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> which I doubt are in use in any FreeBSD system of any age today.


vr(4) here in im PCEngines ALIX board running OPNsense.

Michael

[Eric Joyner]

Being an Ethernet driver maintainer and being at most 4 years old when Fast
Ethernet was introduced makes me biased to the point of irrelevant here,
but I absolutely am all for drivers for old 100M-only devices being removed.

I just can't really understand the support. I'd be incredibly annoyed if
anything I owned was 100M-at-most (like my Wi-Fi router), and Intel is
already dropping support left and right for 100M speeds on newer things.
Maybe it just comes down to money.

- Eric

On Fri, Oct 5, 2018 at 10:28 AM Michael Schmiedgen <***@gmx.net>
wrote:

>
> > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> > which I doubt are in use in any FreeBSD system of any age today.
>
>
> vr(4) here in im PCEngines ALIX board running OPNsense.
>
> Michael
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>

[Michael Schmiedgen]

>
> 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
>

I have vr(4) on my PCEngines APU board, so good to keep it.

But I am rather surprised that you want to remove ed(4) and rl(4),
because I have seen lots of them over the years, and I can imagine
that these are built into even not-so-old cheapo NICs and boards.

Michael

[Claude Buisson]

On 10/03/2018 23:05, Brooks Davis wrote:
>>>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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
>

Of these, I still use: bfe

CBu

[Joel Dahl]

On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.

Why doesn't reports of uses on machines running FreeBSD 10/11 count? I don't
get it. 12.0 isn't even out yet, and most of our users are probably not
running CURRENT. As I wrote in an earlier email, I have lots of these cards
running in production - and most of them are on FreeBSD 11. They'll
likely be upgraded to 12.1 in the future (but probably not 12.0 - I usually
skip .0 releases). But doing the jump to CURRENT/12 now is just out of the
question - these are production systems after all.

--
Joel

[Brooks Davis]

On Thu, Oct 04, 2018 at 05:07:20PM +0200, Joel Dahl wrote:
> On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> > The criteria for exception are:
> > - Popular in applications where it is likely to be deployed beyond the
> > support lifetime of FreeBSD 12 (late 2023).
> > - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> > deemed satisfy the "popular"
> > requirement.
>
> Why doesn't reports of uses on machines running FreeBSD 10/11 count? I don't
> get it. 12.0 isn't even out yet, and most of our users are probably not
> running CURRENT. As I wrote in an earlier email, I have lots of these cards
> running in production - and most of them are on FreeBSD 11. They'll
> likely be upgraded to 12.1 in the future (but probably not 12.0 - I usually
> skip .0 releases). But doing the jump to CURRENT/12 now is just out of the
> question - these are production systems after all.

For the current poll, good faith intent to upgrade is fine.

-- Brooks

[Rodney W. Grimes]

> On Thu, Oct 04, 2018 at 05:07:20PM +0200, Joel Dahl wrote:
> > On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> > > The criteria for exception are:
> > > - Popular in applications where it is likely to be deployed beyond the
> > > support lifetime of FreeBSD 12 (late 2023).
> > > - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> > > deemed satisfy the "popular"
> > > requirement.
> >
> > Why doesn't reports of uses on machines running FreeBSD 10/11 count? I don't
> > get it. 12.0 isn't even out yet, and most of our users are probably not
> > running CURRENT. As I wrote in an earlier email, I have lots of these cards
> > running in production - and most of them are on FreeBSD 11. They'll
> > likely be upgraded to 12.1 in the future (but probably not 12.0 - I usually
> > skip .0 releases). But doing the jump to CURRENT/12 now is just out of the
> > question - these are production systems after all.
>
> For the current poll, good faith intent to upgrade is fine.

What I am finding very bothersome at this point is that a great
miss understanding has been conveyed onto the users by the
statement that "core has discussed this and we plan to proceed
as proposed"

From a posting by Warner that statement is incorrect, this WHOLE
fcp-101 is up for discussion and shaping. Right here above is an example
of one thing that needs to be corrected in the FSP, the criteria
is incorrectly stated if infact as "good faith intenet to upgrade
is fine."

I also saw another person state that the "5" user number appears
to be very arbitrary. I agree.

We should NOT be taking the pole until the FCP itself is approved...
as altering the FCP could greatly effect the outcome of that pole.

--
Rod Grimes ***@freebsd.org

[Warner Losh]

On Thu, Oct 4, 2018 at 9:35 AM Rodney W. Grimes <
freebsd-***@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Thu, Oct 04, 2018 at 05:07:20PM +0200, Joel Dahl wrote:
> > > On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> > > > The criteria for exception are:
> > > > - Popular in applications where it is likely to be deployed beyond
> the
> > > > support lifetime of FreeBSD 12 (late 2023).
> > > > - 5 reports of uses in the wild on machines running FreeBSD 12
> will be
> > > > deemed satisfy the "popular"
> > > > requirement.
> > >
> > > Why doesn't reports of uses on machines running FreeBSD 10/11 count? I
> don't
> > > get it. 12.0 isn't even out yet, and most of our users are probably not
> > > running CURRENT. As I wrote in an earlier email, I have lots of these
> cards
> > > running in production - and most of them are on FreeBSD 11. They'll
> > > likely be upgraded to 12.1 in the future (but probably not 12.0 - I
> usually
> > > skip .0 releases). But doing the jump to CURRENT/12 now is just out of
> the
> > > question - these are production systems after all.
> >
> > For the current poll, good faith intent to upgrade is fine.
>
> What I am finding very bothersome at this point is that a great
> miss understanding has been conveyed onto the users by the
> statement that "core has discussed this and we plan to proceed
> as proposed"
>
> From a posting by Warner that statement is incorrect, this WHOLE
> fcp-101 is up for discussion and shaping.


For the record, I never said anything to the contrary. Stop putting words
in my mouth. It's not helpful. I said it was in the community feedback
phase. That's part of the process: changing things as the community gives
feedback.


> Right here above is an example
> of one thing that needs to be corrected in the FSP, the criteria
> is incorrectly stated if infact as "good faith intenet to upgrade
> is fine."
>

That's part of the community feedback process. We add things, we adjust
things. I never once said anything to the contrary in this thread.


> I also saw another person state that the "5" user number appears
> to be very arbitrary. I agree.
>

It's totally arbitrary. What's your point? We have to start somewhere, and
so far the data is splitting nicely between 0 or 1 users and > 5 if my
counts are correct. It appears, so far, to be a useful first order sorting
function.


> We should NOT be taking the pole until the FCP itself is approved...
> as altering the FCP could greatly effect the outcome of that pole.
>

I disagree. We can run the two in parallel unless we hit something major.
So far, I've seen nothing that suggests the polling done so far is invalid.

Warner

[Mark Linimon]

On Thu, Oct 04, 2018 at 08:34:30AM -0700, Rodney W. Grimes wrote:
> What I am finding very bothersome at this point is that a great
> miss understanding has been conveyed onto the users by the
> statement that "core has discussed this and we plan to proceed
> as proposed"

I really don't understand why people don't assume good faith anymore.

I read it as "core has discussed setting up an FCP".

Warner could have just posted something to -current saying "I'm going
to delete these on xyz2019 unless they're updated to use iflib." It
would have been a lot less work and stress on his part than trying
to do things The Right Way.

Having people look through every single word in every single post
looking for hidden meanings is one of the things that is absolutely
taking all the fun out of FreeBSD. Frankly if I wanted to have
everything gone over with a fine-tooth-comb I'd go back into the
workforce. tl;dr: no, thanks. I liked the old "shut up and code"
days better.

ob. disclaimer: don't assume that Warner and I agree on much of anything,
but IMHO he's trying to go about things the right way this timee.

mcl

[Cy Schubert]

I'm willing to help out with rl(4) as I have one here. Others, not scheduled for removal, that I can help one way or another are are NICs, including wireless, currently installed here.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Poul-Henning Kamp
Sent: 04/10/2018 07:03
To: Warner Losh
Cc: Alexey Dokuchaev; Brooks Davis; FreeBSD-STABLE Mailing List; FreeBSD Net; freebsd-***@freebsd.org; freebsd-***@freebsd.org
Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

--------
In message <CANCZdfpFXs_Ed-gMZnnSs2eAxYh8hdwr-***@mail.gmail.com>
, Warner Losh writes:

>Most of these drivers have had dozens or hundreds of commits each over the
>years to keep up with the API changes. This acts as a tax on innovation
>because it's such a pain in the back side to change all the drivers in the
>tree.

As one who has been there, a couple of times: SECONDED!

It is particular unpleasant when you have no way to test the changes.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Warner Losh]

On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert <***@cschubert.com>
wrote:

> I'm willing to help out with rl(4) as I have one here. Others, not
> scheduled for removal, that I can help one way or another are are NICs,
> including wireless, currently installed here.
>

There's an iflib man page that's a decent place to start. The API has
evolved over time, so corrections to the man page would be welcome (and
committed as quickly as the freeze allows). I'm reading through the current
iflib drivers to see which one would be best to recommend.

Warner

[John-Mark Gurney]

Warner Losh wrote this message on Thu, Oct 04, 2018 at 09:53 -0600:
> On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert <***@cschubert.com>
> wrote:
>
> > I'm willing to help out with rl(4) as I have one here. Others, not
> > scheduled for removal, that I can help one way or another are are NICs,
> > including wireless, currently installed here.
> >
>
> There's an iflib man page that's a decent place to start. The API has
> evolved over time, so corrections to the man page would be welcome (and
> committed as quickly as the freeze allows). I'm reading through the current
> iflib drivers to see which one would be best to recommend.

Can you recommend one? It'd be nice to just document which driver you
should use as a reference in the iflib man page...

I looked briefly at converting awg over to iflib,
but the iflib man pages were very sparce in any text to describe what
each function needs to do... It says it in very high level, which is
useful if you already know what needs to be done.. for example:
ifdi_tx_queues_alloc()
Mandatory function that is called during iflib_attach to allocate
transmit queues. vaddrs and paddrs are arrays of virtual and
physical addresses respectively of the hardware transmit queues.
ntxqs is the number of queues per qset. ntxqsets is the number of
qsets.

It says it allocates memory for the queue, but upon allocation where
does it put the values? It sounds like vaddrs and paddrs arrays are
already allocated and you just use these addresses... But there is no
way I can write code from this description...

Also, lots of terminology is missing, like what is a qset?

--
John-Mark Gurney Voice: [phone]

"All that I will do, has been done, All that I have, has not."

[Cy Schubert]

I have rl, fxp, xl, dc, bge (which I have an uncommitted patch for), nfe, and sk. Not all are scheduled for removal but this is my inventory for which I can test and am willing to help out with. Add iwn and ath too.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Rick Macklem
Sent: 04/10/2018 07:41
To: Warner Losh; Alexey Dokuchaev
Cc: FreeBSD Net; freebsd-***@freebsd.org; Brooks Davis; FreeBSD-STABLE Mailing List; freebsd-***@freebsd.org
Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Warner Losh wrote:
[lots of stuff snipped]
>That's why that one way to get the driver off the list is to convert to
>iflib. That greatly reduces the burden by centralizing all the stupid,
>common things of a driver so that we only have to change one place, not
>dozens.

I can probably do this for bfe and fxp, since I have both.
Can someone suggest a good example driver that has already been converted,
so I can see what needs to be done?

Again, I don't care if they stay in the current/head tree.

[more stuff snipped]

rick

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Charles Sprickman via freebsd-arch]

> On Oct 4, 2018, at 11:52 AM, Cy Schubert <***@cschubert.com> wrote:
>
> I have rl, fxp, xl, dc, bge (which I have an uncommitted patch for), nfe, and sk. Not all are scheduled for removal but this is my inventory for which I can test and am willing to help out with. Add iwn and ath too.

I also have a stack of old stuff (almost certain there’s at least one vx in there - VORTEX power!). If anyone needs cards, please contact me and if I have it, I’ll send it your way. Also have some old video (AGP), sound (ISA), SATA (PCI-X) and other total rando stuff.

One place I see the older cards are in some firewall boxes that are in SFF boxes. Old PCI 10/100 NICs are more than adequate for backup WAN purposes (xDSL, cable, etc.) and some of the SFF boxes have one pci-e plus one pci slot and that’s it.

Charles

>
> ---
> Sent using a tiny phone keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top post. Apologies.
>
> Cy Schubert
> <***@cschubert.com> or <***@freebsd.org>
> The need of the many outweighs the greed of the few.
> ---
>
> -----Original Message-----
> From: Rick Macklem
> Sent: 04/10/2018 07:41
> To: Warner Losh; Alexey Dokuchaev
> Cc: FreeBSD Net; freebsd-***@freebsd.org; Brooks Davis; FreeBSD-STABLE Mailing List; freebsd-***@freebsd.org
> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
>
> Warner Losh wrote:
> [lots of stuff snipped]
>> That's why that one way to get the driver off the list is to convert to
>> iflib. That greatly reduces the burden by centralizing all the stupid,
>> common things of a driver so that we only have to change one place, not
>> dozens.
>
> I can probably do this for bfe and fxp, since I have both.
> Can someone suggest a good example driver that has already been converted,
> so I can see what needs to be done?
>
> Again, I don't care if they stay in the current/head tree.
>
> [more stuff snipped]
>
> rick
>
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-***@freebsd.org"

[Rodney W. Grimes]

> On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert <***@cschubert.com>
> wrote:
>
> > I'm willing to help out with rl(4) as I have one here. Others, not
> > scheduled for removal, that I can help one way or another are are NICs,
> > including wireless, currently installed here.
> >
>
> There's an iflib man page that's a decent place to start. The API has
> evolved over time, so corrections to the man page would be welcome (and
> committed as quickly as the freeze allows). I'm reading through the current
> iflib drivers to see which one would be best to recommend.

Nothing in the current state of the "freeze" would block a
man page correction.

--
Rod Grimes ***@freebsd.org

[Warner Losh]

On Thu, Oct 4, 2018 at 9:59 AM Rodney W. Grimes <
freebsd-***@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert <***@cschubert.com>
> > wrote:
> >
> > > I'm willing to help out with rl(4) as I have one here. Others, not
> > > scheduled for removal, that I can help one way or another are are NICs,
> > > including wireless, currently installed here.
> > >
> >
> > There's an iflib man page that's a decent place to start. The API has
> > evolved over time, so corrections to the man page would be welcome (and
> > committed as quickly as the freeze allows). I'm reading through the
> current
> > iflib drivers to see which one would be best to recommend.
>
> Nothing in the current state of the "freeze" would block a
> man page correction.
>

All commits, no matter how trivial, require re@ approval. That necessarily
slows things down, hence my phrase "as quickly as the freeze allows."

Warner

[Cy Schubert]

Not that I'm arguing to keep ed(4), I have three ne2000 PCI cards in my desk here. Sure one could insert one in a current machine, but why?

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Warner Losh
Sent: 04/10/2018 07:45
To: ***@fuz.su
Cc: freebsd-***@freebsd.org
Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

Well, I'd wager its 100 cards that nobody is currently using (ed) has no
value. Even 1000 different cards or 10,000. The ed(4) driver likely
supported in excess of 1000 different cards because so many people made
ne-2000 compatible cards... in the early 1990s. However, since nobody has
ISA or PC Card (not CardBus) interfaces anymore (those machines topped out
around 32-64MB, which FreeBSD no longer works well on), the benefit to the
project is quite low. Even the 'newer' PC Card versions that were 10/100
couldn't get more than about 10-12Mbps due to ISA/PC Card bus speed
limitations. The PCI versions were never popular (I had to hunt a bunch for
them 10 years ago when I was finishing up my activities on the driver for
my vast PC Card collection to find an example to test), and even it had
trouble beyond 20Mbps because it wasn't DMA'd. The ED driver was a solid
driver last time I tried it, but when I can plug in dozens of 100Mbps or
1Gbps cards into the same CardBus slot and those cost < $10 now, there's
very little return on programmer time to keeping this one going.

However, having said all that, if we can document 5 real users of this card
on machines running FreeBSD 12, it will meet the criteria for remaining,
just like any other driver.... So far we've found 0, while we have found
many other users of other drivers.

Warner

On Thu, Oct 4, 2018 at 8:27 AM Robert Clausecker <***@fuz.su> wrote:

> I have a machine with FreeBSD 2.2.8 running with such an interface, but
> none with FreeBSD 12, so you do have a point here. However, I am not
> sure if it's a good idea to kill this driver; it's good for over 100
> different cards according to the man page, so surely there are some
> users left.
>
> Yours,
> Robert Clausecker
>
> On Wed, Oct 03, 2018 at 05:45:18PM -0600, Warner Losh wrote:
> > On Wed, Oct 3, 2018 at 3:54 PM Robert Clausecker <***@fuz.su> wrote:
> >
> > > I request that ed(4)
> >
> >
> > How many FreeBSD 12.0 machines do you have running with this interface?
> >
> > QEMU does support this interface, but also supports the Intel E1000
> series
> > (em/igb), so it's not necessarily needed for QEMU.
> >
> > Warner
>
> --
> () ascii ribbon campaign - for an 8-bit clean world
> /\ - against html email - against proprietary attachments
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"
>
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Cy Schubert]

People need to submit patches then. OTOH, they can all be moved to ports. IMO, when pkgbase becomes a reality, much of this will become moot. People will be able to mix and match base and ports packages.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Alexey Dokuchaev
Sent: 04/10/2018 08:11
To: Warner Losh
Cc: Mark Linimon; freebsd-***@freebsd.org; freebsd-***@freebsd.org; FreeBSD-STABLE Mailing List; FreeBSD Net
Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

On Thu, Oct 04, 2018 at 08:43:33AM -0600, Warner Losh wrote:
> As far as I know, none of the drivers listed could do 1Gbps.

Right. My point was that original proposal put 10/100 drivers into one
basket, which is IMHO not fair: 10Mbps cards are rarely seen and used,
100mbps are not, just like 1000bps ones.

That said, I'm okay with deorbiting NICs that cannot do more than 10mbps.
Cards that can do at least 100mbps should stay. Following up on Ricks'
question, seeing a good example of modernization a certain driver would
help interested people/hw owners to keep drivers for their cards viable.

./danfe
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Brooks Davis]

>>> Please direct replies to freebsd-arch <<<

A few points of clarification:

Rod correctly points out that this message makes it look like the FCP is
a done deal as written. This is not the case and we welcome feedback
on the entire proposal. IMO, soliciting input on the list of drivers
along with the proposed process is a way to keep discussion concrete so
we will proceed with both.

It was asked: when does iflib conversion need to occur to save a driver?
My proposed plan it to proceed with deprecation notices of otherwise
unpopular drivers, but conversion can come in and remove those notices
at and upto (or even after) removal from the tree.

In an effort to save some email, we will be moving rl(4) to the list of
drivers to STAY as it has proved itself to be popular. A few others
appear to be well on their way so keep the reports coming.

Thanks,
Brooks

P.S. As a person who has edited every driver in the tree multiple times
in the last year (mostly in an external tree), I will consider this
process successful even if we keep the majority of listed drivers in the
tree.

On Wed, Oct 03, 2018 at 09:05:16PM +0000, Brooks Davis wrote:
> >>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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
>
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> Please reply to this message with nominations to the exception list.
>
> The full FCP-0101 is included below.
>
> -- Brooks
>
> ---
> authors: Brooks Davis <***@freebsd.org>
> state: feedback
> ---
>
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
>
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
>
> ## Problem Statement
>
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility. For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces. We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
>
> 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.
>
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices. We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones. With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
>
> ## Proposed Solution
>
> We propose to deprecate devices which are not sufficiently popular. This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> attach routines for each device to be removed and merge those changes
> to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
> freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
> devices.
>
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required. For a device to be placed on
> the exception list the device must meet one of the following criteria:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> ### Exceptions to removal
>
> Device | Reason
> -------|-------------------------------------------------
> ffec | Onboard Ethernet for Vybrid arm7 boards
> fxp | Popular device long recommended by the project.
> dc | Popular device for CardBus card.
> hme | Built in interface on many supported sparc64 platforms.
> le | Emulated by QEMU, alternatives don't yet work for mips64.
> sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
> vr | Soekris Engineering net5501, some Asus motherboards.
> xl | Popular device for CardBus card.
>
> Note: USB devices have been excluded from consideration in this round.
>
> ### Device to be removed
>
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
>
> ## Final Disposition
>
> TBD

[Eugene Grosbein]

04.10.2018 23:22, Brooks Davis wrote:

> In an effort to save some email, we will be moving rl(4) to the list of
> drivers to STAY as it has proved itself to be popular. A few others
> appear to be well on their way so keep the reports coming.

And ste(4) please, as these are hardly replaceable two- and four-ports cards.
In many cases it is impossible to replace them without replacement of whole boxes
that have no extra PCI slots.

[Bakul Shah]

On Wed, 03 Oct 2018 21:05:16 -0000 Brooks Davis <***@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?

> 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?

[Warner Losh]

On Thu, Oct 4, 2018 at 11:25 AM Bakul Shah <***@bitblocks.com> wrote:

> On Wed, 03 Oct 2018 21:05:16 -0000 Brooks Davis <***@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?


> > 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.

Warner

[Bakul Shah]

On Thu, 04 Oct 2018 11:30:35 -0600 Warner Losh <***@bsdimp.com> wrote:
>
> On Thu, Oct 4, 2018 at 11:25 AM Bakul Shah <***@bitblocks.com> wrote:
>
> > On Wed, 03 Oct 2018 21:05:16 -0000 Brooks Davis <***@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.

[Brooks Davis]

On Thu, Oct 04, 2018 at 10:24:13AM -0700, Bakul Shah wrote:
> On Wed, 03 Oct 2018 21:05:16 -0000 Brooks Davis <***@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?

They weren't considered and nothing changes unless someone points them
and proposes some action. The document points out that USB devices
were skipped. Not mentioned were NICs tied to specific architectures.

> > 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?

I've touched every single Ethernet driver by hand multiple times in
that past year in our research tree. We'll never know how much
modernization isn't being done because it's a pain. iflib does reduce
this cost, but conversion isn't trivial. We should work to migrate
drivers that are used and stop wasting time on ones that aren't.

-- Brooks

[Poul-Henning Kamp]

--------

>FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)

Can I open a FCP to rename FCP to FBS (for FreeBSD BikeShed) ?

Guys... most if not all of these emails could have been sent to
directly Brooks without Cc'ing four mailing lists.

Then Brooks could revise his tallies and scores to match informed
reality and _then_ we could discuss if the criteria were sound
on the list(s).

Poul-Henning (singing an almost 20 year old refrain again)

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Cy Schubert]

In message <11826345-1B82-46CB-894C-***@bway.net>, Charles
Sprickman v
ia freebsd-fcp writes:
>
>
> > On Oct 4, 2018, at 11:52 AM, Cy Schubert <***@cschubert.com> wrote:
> >
> > I have rl, fxp, xl, dc, bge (which I have an uncommitted patch for), nfe, a
> nd sk. Not all are scheduled for removal but this is my inventory for which I
> can test and am willing to help out with. Add iwn and ath too.
>
> I also have a stack of old stuff (almost certain there’s at least one vx in
> there - VORTEX power!). If anyone needs cards, please contact me and if I h
> ave it, I’ll send it your way. Also have some old video (AGP), sound (ISA)
> , SATA (PCI-X) and other total rando stuff.
>
> One place I see the older cards are in some firewall boxes that are in SFF bo
> xes. Old PCI 10/100 NICs are more than adequate for backup WAN purposes (xDSL
> , cable, etc.) and some of the SFF boxes have one pci-e plus one pci slot and
> that’s it.

My firewall has most of them. It has 2 sk(4), 2 nfe(4), fxp(4), and
xl(4), with xl and fxp connected to my ISP and the others on my
internal network. My testbed has sk(4), nfe(4), and dc(4), connected to
my DMZ, for ipfilter testing. My main build machine and my current
laptop have sk(4), nfe(4), bge(4), while my i386 testbed (an old
laptop) has rl(4).

I have a spare motherboard (in case something breaks, while I purchase
a replacement) with nv(4). All parts, including CPUs, are
interchangeable.



--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.

[Doug Hardie]

I have a number of production servers that only have bge and I don't see that listed in either category. None of them are running FreeBSD 12 yet as it has not been released. Also there are some with rl. Those are add-on boards so they could be changed, but would require extensive effort as the machines are about a 4 hour drive from here and would require reconfiguration (an error prone process when you are tired).

I also have two production machines with ue devices. There is no provision for replacing them. They are running an early version of 12 as 11 doesn't run on those machines. I don't see ue listed in either category.

-- Doug

> On 3 October 2018, at 14:05, Brooks Davis <***@freebsd.org> wrote:
>
>>>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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
>
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> Please reply to this message with nominations to the exception list.
>
> The full FCP-0101 is included below.
>
> -- Brooks
>
> ---
> authors: Brooks Davis <***@freebsd.org>
> state: feedback
> ---
>
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
>
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
>
> ## Problem Statement
>
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility. For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces. We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
>
> 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.
>
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices. We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones. With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
>
> ## Proposed Solution
>
> We propose to deprecate devices which are not sufficiently popular. This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> attach routines for each device to be removed and merge those changes
> to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
> freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
> devices.
>
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required. For a device to be placed on
> the exception list the device must meet one of the following criteria:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> ### Exceptions to removal
>
> Device | Reason
> -------|-------------------------------------------------
> ffec | Onboard Ethernet for Vybrid arm7 boards
> fxp | Popular device long recommended by the project.
> dc | Popular device for CardBus card.
> hme | Built in interface on many supported sparc64 platforms.
> le | Emulated by QEMU, alternatives don't yet work for mips64.
> sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
> vr | Soekris Engineering net5501, some Asus motherboards.
> xl | Popular device for CardBus card.
>
> Note: USB devices have been excluded from consideration in this round.
>
> ### Device to be removed
>
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
>
> ## Final Disposition
>
> TBD

[Julian H. Stacey]

> >>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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

I have many hosts using ed & rl, several using ep, & at least one
using xe or ex. That's just from memory, maybe other drivers in peril.

Unless the functionality of drivers is sub-sumed in to other drivers,
stripping all those drivers would motivate some to never upgrade
again, or dump FreeBSD for a more conservative BSD, or fork FreeBSD etc.

Stripping dead code helps developers play easier, but stripping
live code is offensive. Some who periodicaly propose code demolitions
forget that many users of FreeBSD don't subscribe lists, except
maybe announce, as too busy, maintaining FreeBSD on networks ...
until their nets don't work.

Cheers,
Julian
--
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
Brexit: 3,700,000 stolen votes in 1st referendum inc. 700,000 from Brits in EU
Campaign lies & criminal funding, economy & pound down: New referendum needed.
http://exitbrexit.uk

[Warner Losh]

On Fri, Oct 5, 2018 at 8:46 AM Julian H. Stacey <***@berklix.com> wrote:

> > >>> Please direct replies to freebsd-arch <<<
> >
> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > improving the network stack. We have discussed this within the
> > core team and intend to move forward as proposed. We are solictiting
> > feedback on the list of drivers to be excepted from removal.
> >
> > 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
>
> I have many hosts using ed & rl, several using ep, & at least one
> using xe or ex. That's just from memory, maybe other drivers in peril.
>

Later in the thread rl was removed from the list.

What systems are you running ed, ex and/or xe on? So far I've heard no
reports of people using the latter two in about a decade.

Unless the functionality of drivers is sub-sumed in to other drivers,
> stripping all those drivers would motivate some to never upgrade
> again, or dump FreeBSD for a more conservative BSD, or fork FreeBSD etc.
>

You could also create a port/pkg for them and assume the burden of
maintenance yourself.


> Stripping dead code helps developers play easier, but stripping
> live code is offensive. Some who periodicaly propose code demolitions
> forget that many users of FreeBSD don't subscribe lists, except
> maybe announce, as too busy, maintaining FreeBSD on networks ...
> until their nets don't work.
>

I think in this case there will be plenty of warning. They will upgrade to
12, one assumes, and see the deprecation message in their new kernel logs.
There's going to be about a 6 month window between when this is announced
and when it happens to collect evidence that removal is unwarranted, to
show they are still in use by enough people to justify their on-going (yes
non-zero) cost to keep in the tree. There's over 2 years before they will
be removed from a released version: also plenty of time to build a case
that they are in use and/or upgrade to different, supported NICs. If you
look at the rest of the thread, you'll see several people have made
compelling cases and/or provided evidence of continued use into the future
to keep the drivers in the tree. Evidence will save them, but harsh words
will not.

I think expecting people to blindly maintain code on the off chance someone
is still using is offensive as well. We must weigh the costs of continuing
with the benefits those cost provide. We don't have good sources of data
for what's still in use and what's not, so we have to rely on these
periodic calls for data to ensure we aren't wasting our time on hardware
that's no longer used.

Warner


> Cheers,
> Julian
> --
> Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix,
> Munich
> Brexit: 3,700,000 stolen votes in 1st referendum inc. 700,000 from Brits
> in EU
> Campaign lies & criminal funding, economy & pound down: New referendum
> needed.
> http://exitbrexit.uk
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fcp
> To unsubscribe, send any mail to "freebsd-fcp-***@freebsd.org"
>

[Andrew Turner]

> On 3 Oct 2018, at 22:05, Brooks Davis <***@freebsd.org> wrote:
>
>>>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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

smc is found in the Arm models (simulators) [1]. I’ve seen it in the Foundation and Architecture Envelope Models. I assume it’s also in the other models, but don’t have a license for them to check.

Andrew

[1] https://developer.arm.com/products/system-design/fixed-virtual-platforms

[Warner Losh]

On Fri, Oct 5, 2018 at 9:05 AM Andrew Turner <***@fubar.geek.nz> wrote:

>
> > On 3 Oct 2018, at 22:05, Brooks Davis <***@freebsd.org> wrote:
> >
> >>>> Please direct replies to freebsd-arch <<<
> >
> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > improving the network stack. We have discussed this within the
> > core team and intend to move forward as proposed. We are solictiting
> > feedback on the list of drivers to be excepted from removal.
> >
> > 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
>
> smc is found in the Arm models (simulators) [1]. I’ve seen it in the
> Foundation and Architecture Envelope Models. I assume it’s also in the
> other models, but don’t have a license for them to check.
>

Do we currently support those simulators? I see it is in the VERSATILEPB
simulator that QEMU provides. Does that still work?

Warner

[Andrew Turner]

> On 5 Oct 2018, at 16:19, Warner Losh <***@bsdimp.com> wrote:
>
>
>
> On Fri, Oct 5, 2018 at 9:05 AM Andrew Turner <***@fubar.geek.nz <mailto:***@fubar.geek.nz>> wrote:
>
> > On 3 Oct 2018, at 22:05, Brooks Davis <***@freebsd.org <mailto:***@freebsd.org>> wrote:
> >
> >>>> Please direct replies to freebsd-arch <<<
> >
> > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md <https://github.com/freebsd/fcp/blob/master/fcp-0101.md>)
> > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > improving the network stack. We have discussed this within the
> > core team and intend to move forward as proposed. We are solictiting
> > feedback on the list of drivers to be excepted from removal.
> >
> > 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
>
> smc is found in the Arm models (simulators) [1]. I’ve seen it in the Foundation and Architecture Envelope Models. I assume it’s also in the other models, but don’t have a license for them to check.
>
> Do we currently support those simulators? I see it is in the VERSATILEPB simulator that QEMU provides. Does that still work?

Yes, I boot FreeBSD/arm64 on them in a local Jenkins instance.

Andrew

[Julian H. Stacey]

Thanks for the reply warner,

Warner Losh wrote:
> On Fri, Oct 5, 2018 at 8:46 AM Julian H. Stacey <***@berklix.com> wrote:
>
> > > >>> Please direct replies to freebsd-arch <<<
> > >
> > > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> > > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> > > and remove them in FreeBSD 13 to reduce the burden of maintaining and
> > > improving the network stack. We have discussed this within the
> > > core team and intend to move forward as proposed. We are solictiting
> > > feedback on the list of drivers to be excepted from removal.
> > >
> > > 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
> >
> > I have many hosts using ed & rl, several using ep, & at least one
> > using xe or ex. That's just from memory, maybe other drivers in peril.
> >
>
> Later in the thread rl was removed from the list.

That's a partial relief.


> What systems are you running ed, ex and/or xe on? So far I've heard no
> reports of people using the latter two in about a decade.

I can look more later, but for a quick partial reply:
I keep an incomplete ad hoc occasionaly/rarely updated list of logs,
useful for odd questions such as this, so I can run quick checks

cd ~/tech/log/dmesg ; grep ed0: * */* | grep port # ... vi
dual film flip lapn loft slim wind
cd ~/tech/log/ifconfig ; grep ed0: * */*
dual film flip lapl loft park rain snow wall wind

cd ~/tech/log/dmesg ; grep xe0: * */*
lapd lapo
cd ~/tech/log/ifconfig ; grep xe0: * */*
nothing

cd ~/tech/log/dmesg ; grep ex0: * */*
nothing
cd ~/tech/log/ifconfig ; grep ex0: * */*
nothing

Hosts above are custom PCs no model numbers, but these are standard laptops:
xe: lapd: Digital HiNote Ultra2000 http://www.berklix.com/~jhs/hardware/digital/
ed: lapl: Toshiba Libretto 70CT http://www.berklix.com/~jhs/hardware/toshiba/libretto/
ed: lapn: Dell Latitude XPi P133ST http://berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st
xe: lapo: Novatech (MiTAC) 8355 http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/

( PS ed0 is also used by Hewlett Packard Network ScanJet 5 a multi sheet
feeder with FreeBSD built inside, however that's stuck on a seriously
old release, still a great device though - http://berklix.com/scanjet/ )

PS My master kernel config from pre 4.11 to current:
http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/sys/amd64/conf/HOLZ

So quick summary:
ex: I dont seem to use
ed: I use on many of my hosts, not just those above, & I have some spare
to stick in to any PCI or ISA box I work on if needed.
ed & xe I also have on pcmcia & cardbus, so they move around between laptops.


> Unless the functionality of drivers is sub-sumed in to other drivers,
> > stripping all those drivers would motivate some to never upgrade
> > again, or dump FreeBSD for a more conservative BSD, or fork FreeBSD etc.
> >
>
> You could also create a port/pkg for them and assume the burden of
> maintenance yourself.

Didn't know drivers could be farmed out to ports/, sounds like a
recipe for breakage sooner or later.


> > Stripping dead code helps developers play easier, but stripping
> > live code is offensive. Some who periodicaly propose code demolitions
> > forget that many users of FreeBSD don't subscribe lists, except
> > maybe announce, as too busy, maintaining FreeBSD on networks ...
> > until their nets don't work.
> >
>
> I think in this case there will be plenty of warning. They will upgrade to
> 12, one assumes, and see the deprecation message in their new kernel logs.
> There's going to be about a 6 month window between when this is announced
> and when it happens to collect evidence that removal is unwarranted, to
> show they are still in use by enough people to justify their on-going (yes
> non-zero) cost to keep in the tree. There's over 2 years before they will
> be removed from a released version: also plenty of time to build a case
> that they are in use and/or upgrade to different, supported NICs. If you
> look at the rest of the thread, you'll see several people have made
> compelling cases and/or provided evidence of continued use into the future
> to keep the drivers in the tree. Evidence will save them, but harsh words
> will not.
>
> I think expecting people to blindly maintain code on the off chance someone
> is still using is offensive as well. We must weigh the costs of continuing
> with the benefits those cost provide. We don't have good sources of data
> for what's still in use and what's not, so we have to rely on these
> periodic calls for data to ensure we aren't wasting our time on hardware
> that's no longer used.
>
> Warner

Yes, needs careful balance.

Cheers,
Julian
--
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
Brexit: 3,700,000 stolen votes in 1st referendum inc. 700,000 from Brits in EU
Campaign lies & criminal funding, economy & pound down: New referendum needed.
http://exitbrexit.uk

[Nikita Druba]

04.10.2018 0:05, Brooks Davis пишет:
>>>> Please direct replies to freebsd-arch <<<
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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
>
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> Please reply to this message with nominations to the exception list.
>
> The full FCP-0101 is included below.
>
> -- Brooks
>
> ---
> authors: Brooks Davis <***@freebsd.org>
> state: feedback
> ---
>
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
>
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
>
> ## Problem Statement
>
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility. For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces. We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
>
> 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.
>
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices. We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones. With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
>
> ## Proposed Solution
>
> We propose to deprecate devices which are not sufficiently popular. This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> attach routines for each device to be removed and merge those changes
> to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
> freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
> devices.
>
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required. For a device to be placed on
> the exception list the device must meet one of the following criteria:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> ### Exceptions to removal
>
> Device | Reason
> -------|-------------------------------------------------
> ffec | Onboard Ethernet for Vybrid arm7 boards
> fxp | Popular device long recommended by the project.
> dc | Popular device for CardBus card.
> hme | Built in interface on many supported sparc64 platforms.
> le | Emulated by QEMU, alternatives don't yet work for mips64.
> sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
> vr | Soekris Engineering net5501, some Asus motherboards.
> xl | Popular device for CardBus card.
>
> Note: USB devices have been excluded from consideration in this round.
>
> ### Device to be removed
>
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
>
> ## Final Disposition
>
> TBD
Hello!

My servers use rl and bfe devices from deprecated list. Also I have some
ed devices for replacement failed adapters.

Also I can try do convertion to iflib for bfe, rl and ed devices, but
still no one not showed good example driver that has already been
converted...

P.S. So late, because I was away and just returned.

[Matthieu Volat]

On Wed, 3 Oct 2018 21:05:16 +0000
Brooks Davis <***@freebsd.org> wrote:

> >>> Please direct replies to freebsd-arch <<<
>
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack. We have discussed this within the
> core team and intend to move forward as proposed. We are solictiting
> feedback on the list of drivers to be excepted from removal.
>
> 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
>
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> Please reply to this message with nominations to the exception list.
>
> The full FCP-0101 is included below.
>
> -- Brooks
>
> ---
> authors: Brooks Davis <***@freebsd.org>
> state: feedback
> ---
>
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
>
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
>
> ## Problem Statement
>
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility. For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces. We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
>
> 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.
>
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices. We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones. With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
>
> ## Proposed Solution
>
> We propose to deprecate devices which are not sufficiently popular. This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
> attach routines for each device to be removed and merge those changes
> to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
> freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
> devices.
>
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required. For a device to be placed on
> the exception list the device must meet one of the following criteria:
> - Popular in applications where it is likely to be deployed beyond the
> support lifetime of FreeBSD 12 (late 2023).
> - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
>
> ### Exceptions to removal
>
> Device | Reason
> -------|-------------------------------------------------
> ffec | Onboard Ethernet for Vybrid arm7 boards
> fxp | Popular device long recommended by the project.
> dc | Popular device for CardBus card.
> hme | Built in interface on many supported sparc64 platforms.
> le | Emulated by QEMU, alternatives don't yet work for mips64.
> sis | Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
> vr | Soekris Engineering net5501, some Asus motherboards.
> xl | Popular device for CardBus card.
>
> Note: USB devices have been excluded from consideration in this round.
>
> ### Device to be removed
>
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
>
> ## Final Disposition
>
> TBD

Would it be possible to set a wiki page/section in 12 that display the current status of removal of those devices? That might be easier for people to look at their hardware actual state rather than try to trace every answer to this thread...

Thanks a lot!

[Warner Losh]

On Wed, Oct 17, 2018 at 11:52 AM Matthieu Volat <***@alkumuna.eu> wrote:

> Would it be possible to set a wiki page/section in 12 that display the
> current status of removal of those devices? That might be easier for people
> to look at their hardware actual state rather than try to trace every
> answer to this thread...
>

The FCP is being updated and will be uploaded when that's done. At
this point, it seems that we have all the data to make the right decisions,
at least to tag the drivers deprecated for the 12.0 release when I'm sure
will get us additional data.

Warner

[Matthieu Volat]

On Wed, 17 Oct 2018 12:27:48 -0600
Warner Losh <***@bsdimp.com> wrote:

> On Wed, Oct 17, 2018 at 11:52 AM Matthieu Volat <***@alkumuna.eu> wrote:
>
> > Would it be possible to set a wiki page/section in 12 that display the
> > current status of removal of those devices? That might be easier for people
> > to look at their hardware actual state rather than try to trace every
> > answer to this thread...
> >
>
> The FCP is being updated and will be uploaded when that's done. At
> this point, it seems that we have all the data to make the right decisions,
> at least to tag the drivers deprecated for the 12.0 release when I'm sure
> will get us additional data.
>
> Warner


Thanks for the info!

[Julian H. Stacey]

> I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> which I doubt are in use in any FreeBSD system of any age today.

vr is used by my TV driver laptop:
http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
ether 00:40:d0:5e:26:38
inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
status: active

Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
when I also configure it to receive from a raspberry-pi TV VPN server.

Cheers,
Julian
--
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich.
Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU.
Campaign lies, criminal funding, economy & pound down. Time for an honest ref.
http://exitbrexit.uk https://www.peoples-vote.uk/petition
https://eci.ec.europa.eu/002/public/#/initiative

[Brooks Davis]

On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> > which I doubt are in use in any FreeBSD system of any age today.
>
> vr is used by my TV driver laptop:
> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> ether 00:40:d0:5e:26:38
> inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
> status: active
>
> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
> when I also configure it to receive from a raspberry-pi TV VPN server.

The above was a typo. vr is on the the STAY list.

-- Brooks

[Julian H. Stacey]

Doug Hardie wrote:
> I have a number of production servers that only have bge and I don't see that listed in either category. None of them are running FreeBSD 12 yet as it has not been released. Also there are some with rl. Those are add-on boards so they could be changed, but would require extensive effort as the machines are about a 4 hour drive from here and would require reconfiguration (an error prone process when you are tired).

bge is also used by my main laptop with current Oct 15 18:33 /boot/kernel/kernel

bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
media: Ethernet autoselect (1000baseT <full-duplex>)

Doug, I think bge must be safe as man 4 bge:
"bge - Broadcom BCM57xx/BCM590x Gigabit/Fast Ethernet driver"
& Brooks proposal was ... "a plan to deprecate most 10/100 Ethernet drivers"

Cheers,
Julian
--
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich.
Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU.
Campaign lies, criminal funding, economy & pound down. Time for an honest ref.
http://exitbrexit.uk https://www.peoples-vote.uk/petition
https://eci.ec.europa.eu/002/public/#/initiative

[Julian H. Stacey]

Hi, Reference:
> From: Brooks Davis <***@freebsd.org>
> Date: Tue, 23 Oct 2018 22:10:37 +0000

Brooks Davis wrote:
>
> --lrZ03NoBR/3+SXJZ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, sm=
> c,
> > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, a=
> nd
> > > which I doubt are in use in any FreeBSD system of any age today.
> >=20
> > vr is used by my TV driver laptop:
> > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> > vr0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
> 00
> > options=3D82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > ether 00:40:d0:5e:26:38
> > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> > media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rx=
> pause,txpause>)
> > status: active
> >=20
> > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
> > when I also configure it to receive from a raspberry-pi TV VPN server.
>
> The above was a typo. vr is on the the STAY list.

Great, Thanks.

Cheers,
Julian
--
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich.
Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU.
Campaign lies, criminal funding, economy & pound down. Time for an honest ref.
http://exitbrexit.uk https://www.peoples-vote.uk/petition
https://eci.ec.europa.eu/002/public/#/initiative

[Rodney W. Grimes]

> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> > > which I doubt are in use in any FreeBSD system of any age today.
> >
> > vr is used by my TV driver laptop:
> > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> > vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > ether 00:40:d0:5e:26:38
> > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> > media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
> > status: active
> >
> > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
> > when I also configure it to receive from a raspberry-pi TV VPN server.
>
> The above was a typo. vr is on the the STAY list.
>
> -- Brooks
Brooks,
Is there a public revised version of FCP-0101 that reflects the
feedback which is what core is voting on?

--
Rod Grimes ***@freebsd.org

[Warner Losh]

On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
freebsd-***@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn,
> smc,
> > > > sf, tl, tx and vr drivers, which nobody has mentioned in this
> thread, and
> > > > which I doubt are in use in any FreeBSD system of any age today.
> > >
> > > vr is used by my TV driver laptop:
> > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> > > vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> 1500
> > > options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
> > > ether 00:40:d0:5e:26:38
> > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255
> > > media: Ethernet autoselect (100baseTX
> <full-duplex,flowcontrol,rxpause,txpause>)
> > > status: active
> > >
> > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
> > > when I also configure it to receive from a raspberry-pi TV VPN server.
> >
> > The above was a typo. vr is on the the STAY list.
> >
> > -- Brooks
> Brooks,
> Is there a public revised version of FCP-0101 that reflects the
> feedback which is what core is voting on?
>

Its on github, just like it's been the whole time for anybody to see,
submit pull requests against and track:

https://github.com/freebsd/fcp/blob/master/fcp-0101.md

Warner