[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240425114200.3effe773@kernel.org>
Date: Thu, 25 Apr 2024 11:42:00 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: netdev@...r.kernel.org, netdev-driver-reviewers@...r.kernel.org
Subject: [ANN] 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!
Powered by blists - more mailing lists