4 ms·
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 thi
by nialv7 2y ago
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.
- taurknaut 2y agohow 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.
- kreetx 2y agoNot 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.
- taurknaut 2y agoWell 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.
- flohofwoe 2y agoThis 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).
- taurknaut 2y ago> 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.
- flohofwoe 2y agoIt'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.
- cozzyd 2y agoInternal APIs break all the time, which is why out of tree drivers are so annoying
- AlotOfReading 2y agoC maintainers are not required to consider RfL currently as a compromise to minimize the burden.
- JoshTriplett 2y agoThat'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.