← Back to context

Comment by GolDDranks

1 day ago

The maintainer of the DMA subsystem, Christoph Hellwig seems to vehemently oppose having an mixed-language codebase, and is using the confusion whether he as a maintainer has a say against the consumers of his APIs, to further his cause.

There was indeed some confusion about this, because the normal rule of kernel development is that if you change an API, you also fix the downstream users. (A standard-ish monorepo rule.)

However, because R4L is an experiment, the rule seems to be different: it's up to the R4L team to fix the Rust side if things break, so the upstream C devs don't need to care about Rust if they don't want to. (And conversely, they can't then weaponize their reluctance against Rust. That blade cuts both ways!)

However, apparently there wasn't sufficient clarity about this rule. Well, now there is.

logistically, how would this work in a monorepo? if you merge an API change and don't fix downstream users, isn't the build broken for everyone? or is there a deprecation process where the old API remains functional for a period?

  • Rust is behind a flag that defaults off, so it's only broken for people who flip the flag.

    • More generally, the Linux kernel and its build system are pretty modular in spite of being maintained in a single repo, so a bug somewhere usually isn't a showstopper for everyone, everywhere. Code that won't compile only affects configurations that try to compile that code. No real-world configs could enable compiling every optional piece of code in the kernel tree.