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: <07c447b77bdac1f8ade1f93456f853f89d4842ee.camel@icenowy.me>
Date: Mon, 10 Feb 2025 17:41:30 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Hector Martin <marcan@...can.st>, 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.)

在 2025-02-08星期六的 17:31 +0900，Hector Martin写道：
> 
> 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.

Well, at least some Mesa drivers are developed against some "vendor"
(even not community downstream) kernel drivers, e.g. powervr one;
although in the Asahi case there's no such vendor thing (because the HW
vendor is Darwin-only). In addition, I think at least some early
etnaviv development is based on drm/etnaviv drivers w/ in-kernel
version code earlier than the first in-kernel-tree version code (Well
drm version code rarely changes, but I think in the case of etnaviv it
really represents the UAPI).

Furtherly, the monorepo nature of Linux kernel means to refactor an
interface, it's usually the person changing the callee that need to
change all callers to satify the interface change; having Rust code in
tree calling the interface effectively means adding the responsibility
of fixing the Rust code when the interface changes, which could be not
acceptable by the C-only maintainers. In regards of adding a
maintainer, having more maintainers means more communication. The
situation of the current problem really shows how difficult
communication is, right?