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

[Icenowy Zheng]

在 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?