lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ