linux-kernel - Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z6bdCrgGEq8Txd-s@home.goodmis.org>
Date: Fri, 7 Feb 2025 23:26:50 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: "Dr. Greg" <greg@...ellic.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Hector Martin <marcan@...can.st>, Dave Airlie <airlied@...il.com>,
	Jason Gunthorpe <jgg@...dia.com>,
	Greg KH <gregkh@...uxfoundation.org>, phasta@...nel.org,
	Christoph Hellwig <hch@....de>, Danilo Krummrich <dakr@...nel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Abdiel Janulgue <abdiel.janulgue@...il.com>,
	daniel.almeida@...labora.com, aliceryhl@...gle.com,
	robin.murphy@....com, rust-for-linux@...r.kernel.org,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Bj??rn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,
	Valentin Obst <kernel@...entinobst.de>,
	open list <linux-kernel@...r.kernel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>, airlied@...hat.com,
	"open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>,
	DRI Development <dri-devel@...ts.freedesktop.org>
Subject: Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma
 coherent allocator abstraction.)

On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
> 
> Not sure what the fix is, from a project management perspective the
> technology industry has never faced a challenge like this.  The fork
> model, which was the classic protection in open-source, doesn't work
> at this scale.

Maybe not quite a fork, but I wonder if the Rust project did something similar
to what PREEMPT_RT did. That was to keep an out of tree patch. The full patch
was just merged last September after being out of tree for a good 20 years.

In the beginning there was a few things in that patch that Christoph was
against, but over time he became accepting of it.

Yes, being out of tree is very difficult because you have to constantly rebase
(we actually found quilt being a better tool than git in this case!). But it
also gives you full flexibility to try new approaches. Just because something
is out of tree doesn't mean it can't be published and used. Red Hat and SUSE,
as well as many others shipped PREEMPT_RT while it was out of tree.

Note, even though PREEMPT_RT started in 2004 and wasn't fully merged until
2024, it slowly did creep in bit by bit. For example, here's a few things that
came from the RT patch, and each was rewritten at least 3 times to become
acceptable by the upstream maintainers:

  - NOHZ
  - High res timers
  - threaded interrupts
  - mutex code (yes, before RT everything used a semaphore)
  - lockdep
  - ftrace
  - generic interrupt code
  - generic timer code
  - priority inheritance
  - SCHED_DEADLINE
  - RT push/pull scheduling

and more.

Point being, if you are having issues with getting code upstream, don't be
afraid to make it out of tree. Just make it easy for others to use. And slowly
move your code into mainline. This is also a way to prove beyond a doubt how
useful your code is. The number of users is a technical argument. Linus does
pull things in when there is a large user base, even over other maintainer's
objections (see sched_ext).

It worked for us, it can work for you ;-)

-- Steve