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