IIUC, I think it is kernel policy that if you change some kernel API and break its consumers, you are responsible for fixing those consumers. (correct me if this is wrong.) So in theory DMA devs may need to touch Rust code if they make changes to the DMA subsystem.
Edit: this is wrong/inaccurate, see comments below.
That's the general policy, but Rust is currently an exception to that policy: maintainers are not required to keep Rust bindings working when they change C code. The Rust-for-Linux folks will come along and fix them later.
how does this ecosystem accept any patches if any possible changes could make the system worse? I understand the implication about languages, I'm just struggling to understand how any changes are possible at all.
Not a kernel developer, but I assume that it's done by having relatively stable/long lived APIs, and some form of deprecation process where both a new and old version coexist for a relatively long time.
Well linux has obviously failed this—their abi is notoriously unreliable and relative to the distro you're using. There's a reason why game development is so reliant on wine.... microsoft actually has a stable ABI.
Linux: permanently stuck in the shittiest part of the nineties.
This is entirely a glibc and desktop Linux problem, the Linux kernel itself has a a very stable public syscall API (e.g. the mantra "don't break userspace" unfortunately only applies to Linux itself, but not to 'GNU/Linux' or desktop distros in general).
> This is entirely a glibc and desktop Linux problem,
Ah, so just everything developers interact with and need to deal with. God forbid glibc develop a stable ABI and globally lock development? Thank god their lives are easier, nobody else matters.
It's offtopic for the discussion, since this is strictly about the Linux kernel.
Also, you can just ignore the glibc and link statically with MUSL instead - this is useful for distro-agnostic cmdline tools but won't help much for UI programs, since all desktop functionality is inside DLLs (the X11 and GL DLLs might actually be more stable than the glibc though).
FWIW Windows had that same problem with the MSVC runtime DLLs until not too long ago. Only the traditional Win32 DLLs are guaranteed to exist on each Windows installation and with a stable API.
Edit: this is wrong/inaccurate, see comments below.