Differentiating "Supported" and "Maintained" drivers on something other than $$$

Hi!

tl;dr - MAINTAINERS lists the following Status options:

S: *Status*, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [...]

Currently there's no process difference between Maintained and Supported, the only distinction is whether maintainer is paid.

We would like to change that for Ethernet NICs, starting with Linux v6.12, to require the netdev CI to be run against any driver which wants the "Supported" status. Drivers which don't will get "downgraded" from "Supported" to "Maintained"- but again, this has no impact on the process or code acceptance, it's just a badge of honor.

The core networking stack itself is "Maintained", not "Supported".

---

*Background on Supported*

The Supported status in MAINTAINERS is most likely a historic attempt to give developers working on Linux commercially (for pay) some leverage to justify time spent on upstream work. Companies like having their products listed as “Supported”, but in exchange developers can point to the “company pays someone to work on this” rule to be allowed to work on Linux on company time. This hopefully explains why the “Supported” status exists, even though it’s rather meaningless from the upstream process perspective. That is to say, it’s fairly obvious what the difference between Maintained, Orphan or Odd fixes is. It’s much harder to define the difference in expectations between codebase under the “Maintained” status vs the “Supported” status.

Over the years Linux dominated some parts of the industry, and for example for data center products companies need to provide solid Linux support purely for business reasons. Regardless of the status of the codebase, devices such as high speed NICs not working well with upstream Linux reflect poorly on the company. This led to a situation where the Supported status had lost its intended additional value to the community. What’s worse, community members who work on Linux in their own time may feel discouraged by the fact that the Supported status (broadly seen as superior to Maintained), is unattainable to them.

This situation does not apply to most parts of the kernel, but in places where Supported lost its value we should either (a) stop using Supported; or (b) more clearly define the expectations so that the status continues to serve its intended goal of increasing upstream participation. One part of the development process where upstream is lacking in terms of collaboration between companies is driver testing. This proposal puts forward a new requirement for Ethernet NIC drivers that their owners must participate in netdev CI in order to earn the Supported status.

*Plan and requirements*

1. Require all netdev Ethernet drivers listed as Supported in MAINTAINERS to periodically run netdev CI tests.

2. Must run all tests under drivers/net and drivers/net/hw targets of Linux selftests. Running and reporting private / internal tests is welcome.

3. The minimum run frequency is once every 12 hours. Must test the designated branch from the selected branch feed.

4. Note that branches are auto-constructed and exposed to intentional malicious patch posting, so the test systems must be isolated.

5. Drivers supporting multiple generations of devices must test at least one device from each generation. A testbed manifest (exact format TBD) should describe the device models tested.

6. The driver maintainer may arrange for someone else to run the test, there is no requirement for the person listed as maintainer (or their employer) to be responsible for running the tests.

7. The tests must run reliably and failing to do so will result in losing the Supported status.

8. Test failures due to bugs or incompatibility (rather than inadequate / buggy infrastructure) are not a basis for losing Supported status.

9. netdev CI will maintain an official page of supported devices, listing their recent test results.

a. Collaboration between vendors, hosting GH CI, other repos under
linux-netdev, etc. are most welcome.

*Timeline*

May 1st - official announcement and notifying driver maintainers

The new guidance will take effect starting with Linux v6.12. This means that any new driver merged for v6.12 (i.e. merged into net-next during v6.11 release cycle) will need to come with running CI to be considered Supported. During the v6.12 merge window all Ethernet drivers under Supported status without CI will be updated to the Maintained status.

The exact dates in the Linux release process are somewhat unreliable, but the current prediction is that these events should roughly translate to any new driver requiring CI to be Supported starting on August 11th 2024, and existing drivers without CI being changed during the second week of October 2024.

Feedback welcome!

Do we have any drivers which today fulfil the Supported requirements? Any which are close?

Andrew

We only started adding tests this month, so not really no ;) But v6.12 is 5 months out, hopefully that's enough time to put a machine in a DMZ and write a python script?

I was actually looking at SBCs with multiple NIC ports over the weekend to start running these tests myself, but I stopped myself. I don't scale :(

As I said the Supported status itself doesn't have much _practical_ meaning, so hopefully there isn't much downside to trying to nudge people. If we get one company to run the CI, that's good enough in my book. If someone is actually currently using the status as leverage to make their employer let them work upstream on NIC drivers - putting more requirements in place would be a concern (LMK on or off list!)