* [ANN] Differentiating "Supported" and "Maintained" drivers on something other than $$$
@ 2024-04-25 18:42 Jakub Kicinski
2024-04-25 20:22 ` Andrew Lunn
0 siblings, 1 reply; 3+ messages in thread
From: Jakub Kicinski @ 2024-04-25 18:42 UTC (permalink / raw)
To: netdev, netdev-driver-reviewers
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!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [ANN] Differentiating "Supported" and "Maintained" drivers on something other than $$$
2024-04-25 18:42 [ANN] Differentiating "Supported" and "Maintained" drivers on something other than $$$ Jakub Kicinski
@ 2024-04-25 20:22 ` Andrew Lunn
2024-04-25 21:10 ` Jakub Kicinski
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Lunn @ 2024-04-25 20:22 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, netdev-driver-reviewers
> 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.
Do we have any drivers which today fulfil the Supported requirements?
Any which are close?
Andrew
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [ANN] Differentiating "Supported" and "Maintained" drivers on something other than $$$
2024-04-25 20:22 ` Andrew Lunn
@ 2024-04-25 21:10 ` Jakub Kicinski
0 siblings, 0 replies; 3+ messages in thread
From: Jakub Kicinski @ 2024-04-25 21:10 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, netdev-driver-reviewers
On Thu, 25 Apr 2024 22:22:28 +0200 Andrew Lunn wrote:
> > 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.
>
> Do we have any drivers which today fulfil the Supported requirements?
> Any which are close?
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!)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-25 21:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-25 18:42 [ANN] Differentiating "Supported" and "Maintained" drivers on something other than $$$ Jakub Kicinski
2024-04-25 20:22 ` Andrew Lunn
2024-04-25 21:10 ` Jakub Kicinski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).