There's ongoing debate in the Linux community about the use of Rust in the Linux kernel (e.g. wrapping existing APIs safely for driver development). This heated up recently. Use of Rust puts requirements on the kernel developers to specify a Rust compiler version to use and ensure C code changes do not break Rust code and vice versa. This has triggered discussions in other communities.
The linked discussion is amongst FreeBSD developers about how to conceptualize FreeBSD itself (where compilers, kernel, userspace and ported application code lives) and where compilers like Rust fit into that vision in the future. Unlike Linux, which is just a kernel, FreeBSD is a kernel + userspace + compiler (equivalent to the GNU part of GNU/Linux + GCC or LLVM).
This is not true. C code is allowed to break Rust bindings. The Rust For Linux folks will then go fix it. The C side was repeatedly told this, but doesn’t seem to want to hear it.
Nobody has decided what the post-experiment policy will be. A second language is new grounds for the kernel. Ted is assuming in order to interfere with the experiment.
Doesn't this mean that the change will have to be blocked until the Rust side is also fixed? Rust folks are eager to do it now, and there's a lot of "hype" around having Rust but is it going to be the same in, say, 15 years?
Userspace Rust is awesome ( aside from being a bit big), but I don't know if Rust in the kernel is proven yet (Time will literally tell).
> but is it going to be the same in, say, 15 years?
You would think that by then either the Rust experiment has failed or the project has gained enough experienced developers such that maintaining such large refactors is feasible beyond heroics of the RfL folks. Either way it would be unlikely to be a problem then.
But in the meantime, how is the Linux project meant to evaluate what the maintenance burden is or wether the benefits outright the costs if the kernel maintainers doing the RfL work are being repeatedly stonewalled?
They said it, but it's a platitude - a lie. If this results in a broken kernel because the Rust part was not updated, the C change will be reverted to get a working kernel. This makes C maintainers de facto responsible for learning Rust to update the bindings.
That is simply not true. That is why Rust is an experiment currently: it is allowed to break. Compiling the Rust code at all requires an extra flag to be passed, so breaking Rust code never breaks normal builds.
They don't need to learn Rust. They could reach out and get help from someone that does. I'm sure the Rusteceans would be happy to if it got more support for C.
I'm not commenting on kernel dev specifically, just the general state of things.
> I’ve only ever seen hostility from the C folks
I've seen that, too, but it looks to me that the hostility in that direction was a reaction to the hostility Rust folks have.
It takes two to tango, of course, but also devs are people, too. While it's not ideal, it's also understandable that people react poorly to being treated poorly.
The context being discussed here is what happened recently in the kernel. If that outburst’s root cause was Rust folks being jerks to the C folks, that’s very different than what seemingly happened.
I think both communities are too large and disparate to make sweeping claims like this in a more general sense, but I agree that people should not treat each other poorly.
Everyone is free to watch the video and make up their own minds, invoking religion instead of engaging with the actual technical aspects is aggressive, yes.
(Also, I was employed to write documentation, not do marketing, at least be accurate if you're going to try and smear me.)
I'm not smearing you. I'm stating that you are extremely biased - which you are.
> invoking religion instead of engaging
Please, this is not the Mozilla mailing list. Don't bring the discussion to this kind of ground because you can't argue in good faith. You perfectly understood what I meant with zealots and it has nothing to do with religion here.
> You perfectly understood what I meant with zealots and it has nothing to do with religion here.
I am referring to the video that this discussion is about, and that I referred to in the first half of that sentence, and what was said in it, not your zealotry comments.
It's entierely possible we might be talking past each other because I haven't seen the worst of what was said regarding the Rust integration by its opponents and you were not aware of all the comments I personally found unconstructive from the other side.
I am cognisant that it doesn't paint a very good picture of the kernel community as a whole.
I don’t particularly care about this discussion and I’m overall fairly sympathetic to what Rust tries to achieve but some of the claims made on the Linux ML by Rust zealots don’t help them. Memory safety through life cycle tracking is not the be-all end-all perfect solution to issues that some proponents paint especially in the kernel context and constantly painting C developers are irresponsible is probably not the wisest choice as a convincing strategy.
I am simply stating the facts of the situation, if you think that means that the C folks are irresponsible, that’s on you.
I do not think the C folks are being irresponsible. I think some of the C people are being obstinate, and deliberately trying to interfere with the experiment Linus asked to be carried out. There are others who have been quite supportive!
No, you are not. You are presenting your interpretation of the facts implying it’s truth in a way which is entirely typical of how Rust outreach has always been done. As usual, it’s more about emotion that facts. If you bring the Ruby playbook to a kernel discussion, you are not going to be well received.
Anyway, let me bit this bullet regarding the irresponsible comment:
"But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more […] They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better."
That the Rust code is allowed to break, and that the Rust for Linux folks have agreed to fix it so that nobody who doesn't want to write Rust does not have to write Rust, is a fact.
I was merely stating that the Rust folks are going around stating that C developers who are not convinced that Rust is the way of the future are irresponsible. I never implied that the people were somehow forced to write Rust - even if it would be a logical conclusion of Rust becoming part of the kernel
at the end of the experiment considering the policy has always been that breakage is unacceptable.
I'm tempted to think that if you have to move the goal post so much maybe you are not the one being right in the conversation.
Note that I think that introducing Rust to the kernel with said policy might actually be a good thing. Rust has a lot of nice features (but so does Ada to be honest and I have yet to see anyone vehemently complain that Ada is not accepted in the kernel). I just extremely dislike the way the Rust community constantly oversell it and don't like seeing people like Ted Ts'o who have been huge contributors to the kernel being thrown mud at for perfectly understandable positions.
Historically a (Free-)BSD operating system is a single repository of source code that is self-hosting (kernel and userland including compilers). Commercial UNIX vendors loved to double dip by withholding the toolchain (that initially came with their AT&T tapes) and having customers pay extra for that part.
While BSDs included quite a lot of base system tools for the time e.g. a default DNS, SMTP, and HTTP server. OpenBSD contains their own forked X11 server and basic GUI tools, but FreeBSD reduced the base system over time. Most of the evicted code wasn't discarded, but mover into the FreeBSD ports tree. The ports tree is the collection of build instruction for software outside the FreeBSD source repository. These ports are compiled into binary packages for the FreeBSD package manager pkg (sometimes called pkgng). Just like the Klingons of TNG we prefer not to talk about the old pkg_ package manager that came before.
So FreeBSD is split into the base system installed during initial installation and kept up to date by freebsd-update or by compiling from source if you want to deeply customise your system or develop FreeBSD itself.
For almost a decade there have been efforts by a few FreeBSD developers and users to enable the use of the package manager for the FreeBSD operating system itself. The old release tools produced just a handful of tarballs while the package base tooling partitions the system into 400-500 small packages. Starting with FreeBSD 14.0 package base is officially supported even if it's not exposed in the menu driven installer (yet).
Now that it's feasible to have all software present on your FreeBSD system be installed by the package manager. In this configuration there is no friction installing or *not* installing base on if it's part of the FreeBSD source repository or a port in the ports tree.
Installing additional software from ports has always been possible, but omitting parts of the base system used to involve writing a make.conf, compiling the system yourself, and either installing and updating from the compiled sources or producing your own release images and running your own freebsd-update server. So while it has been possible to subset FreeBSD for decades few users cared enough about the on disk size of their FreeBSD installations to bother with this.
With the conclusion of package base it's now easy to trim down FreeBSD installations e.g. not install the debug symbols, compiler toolchain, test suite, a few other seldom used larger tools. The difference is massive in relative terms (e.g. ~100MiB vs. ~4GiB) and you can still install the packages while you to debug a problem.
Some FreeBSD port maintainers worry that their workload will increase. Either from users choosing to remove essential components from the operating system installation and incorrectly blaming the software impacted. Right now there is also no infrastructure in the FreeBSD ports tree for a port to specify which parts of the base system is required by a port as a runtime dependency recorded in the resulting package. Unless the package manager is extended to understand that base dependencies on base system packages are a special case such packages could also only be installed on system using packages to manage the base operating system installation.
Almost every FreeBSD installation in use will already have some packages installed: the package manager itself, a more modern shell (zsh, bash, etc.), developers will need git and users will install some set of services that as the reason they're even running the machine.
When it comes to LLVM: it's the system compiler toolchain. It's required to build FreeBSD, but not to run it (ignoring the C++ runtime library). Moving it from the base system into the ports tree would reduce FreeBSD (clean) build times a lot. At the same time the resulting operating system would no longer be self-hosting by some definitions of the term. The packages in a FreeBSD binary package repository are supposed to be compatible with all minor releases (that aren't end-of-life) within the same major release line (e.g. there is one repository for FreeBSD 14 and the packages contained in it must work on 14.0 and 14.1). The overlapping support windows of minor releases in the same major release line would otherwise effectively prevent upgrading the system compiler.
Finally lets look at the immediate consequences of accepting Rust code into FreeBSD itself instead. In my opinion this can best be estimated by looking a the fallout from commonly used libraries available through the ports tree starting to use Rust (e.g. librsvg). Building LLVM and clang is already bad enough, but a C and C++ compiler aren't negotiable for building any *BSD system. The rustc compiler is even slower to build then clang and unless the build system scales perfectly and you have enough spare cores and memory bandwidth to burn its build time comes mostly on top of the existing build time. As soon as essential parts of the operating system depend on anything written in Rust bootstrapping (or worse porting) its the Rust toolchain would also be a new burden on anyone wanting to bring up FreeBSD on a new architecture (e.g. RISC-V or CHERI). The FreeBSD base system would now also depend on a specific Rust version which will become a problem for the ports tree to bring a newer compiler to older releases to port new software to older, but still supported, releases.
TL;DR: Any benefit from evicting LLVM and clang out of the FreeBSD source repository would also apply to rustc. If done well this would mitigate most of the workflow problems by waiting for bloated compilers to build themselves. The merits of depending on an additional language and rewriting existing code in it aren't FreeBSD specific.
Putting all of a BSD in separate packages is going to make evolving the various parts together more difficult. See for instance the ease with which OpenBSD does ABI changes (I know FreeBSD doesn’t do that, just an illustration).
I'm using package base on FreeBSD 14.0 and 14.1. Upgrading the system worked as expected.
FreeBSD already has a documented official way to deal with ABI breakages. You're supposed to install the new kernel only, reboot, install rest of the new release (including updating /etc) and reboot again. Next upgrade the installed ports/packages. Afterward delete the old files (and libraries) and reboot again.
Upgrading/reinstalling all installed packages during the userland upgrade after the first reboot takes care of that on a package base installation whenever the ABI triple changes. If you're using ZFS boot environments they provide an even faster and safer way to upgrade without rebooting in between steps by creating a new boot environment from the currently active one, mounting it as a jail (or chroot env) and pointing the package manager at the mountpoint.
Neither OpenBSD nor FreeBSD are still commonly used without at least one binary package installed so the complexity of having a package manager that works isn't optional.
FreeBSD has always been able to self-host (build the itself from source) with just whats available in the FreeBSD src repository. To do this it needs a toolchain that includes among other things a linker, an assembler, and a C and C++ compiler. This used to be GCC, but GCC was replaced with clang which is a C and C++ frontend for LLVM. Just sticking to the last GCC 4.x release under GPLv2 forever wasn't an option and neither was importing a GPLv3 toolchain. Clang also brought some welcome advantages (it used to provide a lot more useful and human readable error messages, better code analysis tools to catch common bugs).
The reasons you have different versions of LLVM in the ports tree is that users either directly require a specific version or other ports require a specific LLVM version as a dependency (e.g. compilers for Rust, Haskell, Julia, etc.). There will never be a situation where every user and every port is happy at the same time with just one LLVM version, because LLVM isn't just the compiler frontends, but also the C++ libraries used to implement compilers and API changes with each release.
And even if the compilers available in the ports tree using LLVM as their code generation backend could be patched to build with the latest version, which would already be an unreasonable demand on their port maintainers. The new LLVM release may add new optimisations that are "legal" to a language lawyering compiler writer according to their understanding of the LLVM IR semantics, but still break existing code by exploiting undefined, under defined, or implementation specific behaviour.
The problem with moving the system compiler out of the ports goes deeper than just the self hosting aspect. The binary package repositories compiled from the ports tree must work for all still supported minor releases on that major release line (e.g. https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ works for both 14.0 and 14.1). Given that the supported lifetimes of minor releases in a major release line overlap and that compilers don't provide perfect binary compatibility this would lock in the compiler for the whole major release to whatever was packaged for the .0 release. Do you want to be restricted to C and C++ language version and instruction set support from 5 years ago by the end of a major release line? Stuck dealing with compiler bugs that have been fixed ages ago, but never backported?
I would like to see full support for external toolchains from ports before anyone dares to evict the compilers from the base system even if LLVM is a bloated enough to dominate the build time and install size.
I wonder if they could use tcc or similar and get a reasonable system. Hopefully someone familiar with BSD can expand on the quest for a suitably licensed compiler.
Yes clang used bootstrap in a similar time to its contemporary GCC version and compile code notably faster at the cost of emitting slightly less optimised code. Over the years LLVM became bloated. It's now by far the biggest and slowest to compile part of the FreeBSD base system, but there are only two useable open source C and C++ compilers and GCC isn't acceptable to the existing userbase because they changed their license to GPLv3. Also modern GCC isn't nearly as small as GCC 4.2 used to be.
reply