Message-ID: <1e8452ab-613a-4c85-adc0-0c4a293dbf50@marcan.st>
Date: Sat, 8 Feb 2025 17:31:04 +0900
From: Hector Martin <marcan@...can.st>
To: Steven Rostedt <rostedt@...dmis.org>, "Dr. Greg" <greg@...ellic.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 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 2025/02/08 13:26, Steven Rostedt wrote:
> 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.

By kernel and mesa policy, while a drm/ kernel driver is not merged with
a stable UAPI, the mesa side cannot be merged/enabled either. That means
that every day the driver isn't upstream, our users suffer due to
various container technologies not shipping the driver in userspace
since they ship upstream mesa.

The process is *designed* to encourage upstreaming early and *punish*
downstream trees.

It's not just distros shipping, or even typical container technologies
like Flatpak (we have a workaround for that specific one). We'd need to
get stuff like Android/AOSP to ship the patched userspace driver so it
works in Waydroid, which some people want to use. It is an impossible task.

Never mind that distros aren't, in fact, inclined to ship out-of-tree
kernels. PREEMPT_RT was an exception due to its general usefulness, and
even then was not available everywhere, and had a reasonable excuse for
being out-of-tree so long due to its intrusiveness in core code. Rust
and the Rust drivers aren't even remotely as intrusive, they just stay
off to the side in their own directories. Nobody wants to ship
downstream kernels just for random hardware support.

Out of tree doesn't work. People, both in the kernel and out of the
kernel, want things in tree.

- Hector

Powered by blists - more mailing lists