I own a home router (TP-Link Archer C7) and I have been running OpenWRT for many years on it, having full control over it via SSH. A few years back, I had an idea for an daemon process/service to improve a certain thing in its functionality. I was delighted to find out that the MIPS chip that powers the thing was supported by Rust, and I coded a "script", cross-compiled it to a binary and SCP't that to the router. It ran beautifully. After that (and running Rust on a few other embedded systems, including an ARM Cortex-R chip) I became convinced that Rust is the next C for the embedded.
The OpenWRT SDK is quite polished and convenient to use, so I usually use that for custom OpenWRT binaries. But a few days ago I needed to run something custom on my old QNAP NAS (Marvell ARMv5TE based), and I decided to try cross-rs[1] for the first time.
It turned the usual multi-hour expedition of locating and configuring SDKs, toolchains, etc into 3 commands and 5 minutes of downloads and compilation. The resulting executable ran successfully at the first try. I was amazed.
I default to Go for code I want to run on old MIPS and ARMv5/v6 appliances because despite the "huge" binary sizes, cross-compiling is done by setting 2 environmental variables.
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?
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.
I think the article is wrong in that std::io::stdout would be panicking, or that "the panic is reachable somehow". It's just the optimizer doesn't see it doesn't panic.
But it only panicks if it is being used in a wrong way, which it isn't. The usage is contained within the implementation of std::io::stdout, so it's an implementation detail.
It's a shame that there are no better ways to eliminate panics in case they are impossible to trigger. The article shows some tricks, but I think the language is missing still some expressability around this, and the stdlib should also thrive harder to actually get rid of hard-to-optimize links to panic runtime in case of APIs that don't actually panic.
If the only problem was OnceLock, the simplest solution would be to replace it with a const initializer.
The main reason getting panic-free stdout is hard, is that the STDOUT initializers both call allocating constructors, and LineWriter doesn't have non-allocating constructors.
Thanks for the clarification on OnceLock::get_or_init. It's interesting to know that this is dynamically unreachable, but in a way that the compiler could not statically prove.
I 100% agree with your last paragraph. I would love if the language and stdlib made it easier to make panic-free binaries.
I've been living in Japan for more than 9 years. I think that the author is right in the sense that people in Japan seem to care more. Of course, the stress is on the word "seem". Some people truly care, but there is also the cultural expectation that you should care. I don't know if realising that counts as the "shine that will wear off", but it seems to not a bad default.
But because of the UNIX time stamp "re-synchronization" to the current calendar dates, you can't use UNIX time stamps to do those "delta seconds" calculations if you care about _actual_ amount of seconds since something happened.
reply