5 ms·
You're right that this is generally a golden rule. But rules can have exceptions, and this seems to be one of them; the Linux kernel is now so large and complex
by lambdaone 2y ago
You're right that this is generally a golden rule. But rules can have exceptions, and this seems to be one of them; the Linux kernel is now so large and complex, and C so obviously outdated now, that it's worth the pain to start writing drivers in Rust. And because of the modularity of the kernel, and the care taken to make Rust binary-compatible with C, this looks to be actually practical, as individual subsystems will be either entirely Rust or entirely C, particularly when new drivers are involved.
- Joel_Mckay 2y ago[flagged]
- tremon 2y agoPolyglot projects by their very nature inject unstable dependencies into the build tree What does this mean? This also make the core feature of bootstrapping Linux on new hardware more difficult. If by this you mean that Rust doesn't support all the architectures that gcc does: - that didn't stop people from making sure Linux could be compiled with LLVM as well - gccrs should make this issue moot anyway, as that will allow Rust code to be emitted for exactly the same architectures as gcc proper
- bronson 2y ago> This also make the core feature of bootstrapping Linux on new hardware more difficult. No, Rust is currently only for drivers that aren't on that hardware anyway. You can continue to build and use the kernel without Rust just fine. For now... Maybe one day that discussion will become relevant.
- Joel_Mckay 2y agoThe drama started because of the core memory API argument. That day is today my friend =3
- steveklabnik 2y agoYou’re simply incorrect, in a way that Linus himself very clearly stated. The drama started because Rust used an API written in C. It doesn’t contain any Rust at all. Nothing has changed in this regard.
- Joel_Mckay 2y agoIt was my understanding the request was to have the core maintainer take on the additional task of supporting the rust API on top of the existing wrapper. I could be wrong, but a branch or fork seems like the easiest solution. =3
- steveklabnik 2y agoYou misunderstood.
- dralley 2y agoYour understanding is completely wrong. There was no such request, and that concern was almost immediately addressed by spelling out very directly that no such expectation existed. https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/T/#mace05a0a97522193876bb38e6f64a6ca941a59d8 https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
- oskarkk 2y agoYes, and that API is needed for drivers written in Rust. So it's not like core parts of the kernel are being now written in Rust, it's still just specific Rust drivers.
- Joel_Mckay 2y ago"What does this mean?" In general, mixing languages has serious long-term consequences. Unless you have done refactoring of large legacy systems... you probably wouldn't understand fully. Perhaps ask why folks didn't create an isolated kernel branch for such a massive refactoring? "Rust doesn't support all the architectures that gcc does" Assuming a bootstrap compiler can even bring up Rust or the cargo monstrosity. People will just switch to other options, and maybe someone will get around to a Rusty Linux Fork if the working system needs entertaining drama. Best of luck =3
- steveklabnik 2y agoThe kernel doesn’t use Cargo, by the way.
- Joel_Mckay 2y agoIndeed, its actually worse because "x.py" has a lot more dependencies. lol =3
- steveklabnik 2y agoThe kernel doesn’t use or interact with x.py either. The Rust code uses build to drive rustc, just like the rest of the kernel.
- Joel_Mckay 2y agoI think you are operating under the assumption a fully compatible cross-compiler environment is already available in both languages. =3
- steveklabnik 2y agoDrivers are hardware specific, and so it's not a problem that Rust has support for a subset of the platforms that the kernel does. If you want to write a driver for a platform Rust doesn't support, just write it in C.
- braiamp 2y agoAnd yet, the powers that be, understand that, and have reasoned that the upside of preventing new code with bugs into the kernel is way too attractive to ignore.
- Joel_Mckay 2y ago[flagged]
- imtringued 2y agoLinus torvalds is the biggest idealist here.
- pjmlp 2y agoC already felt outdated in 1993, that is why since then I rather use C++ than C, when the choice boils down to these two languages. Exception being when there is really no way around C, like UNIX clones related development, or some kinds of embedded development. Even when using TypeScript, we sometimes have to occasionally get dirty with JavaScript. :)
- Joel_Mckay 2y ago"I rather use C++ than C" Depends what you are building, as some language specific features make specific tasks more difficult. Unfortunately, often we must deal with the infrastructure we are given. =3
- pjmlp 2y agoAgreed, that is why "Exception being when there is really no way around C,..." The first startup I worked on, back in the crazy 2000's, we were replicating AOLServer at our own way, and all the Tcl extension modules were written in C, because multiple reasons, including writing portable C across several UNIX variants was already complicated enough, e.g. the HP-UX aC we were using was still not C89 compliant, no need to add C++ into the picture.
- marcosdumay 2y ago> People could have spawned another kernel branch focused around Rust Linus already decided his one will be a mixed-languages fork. You are perfectly free to fork your own C-only kernel and maintain it.
- Joel_Mckay 2y agoThe hobby kernel I work on is only 68KiB in size, and won't work with most von Neumann machines. Probably a waste of time, but a fun odd architecture given the relative simplicity. =3