Hacker News Reader

Comment by ahurmazda | Hacker News Reader

A very helpful summary from r/rust on the same topic [1]

>A few notes for people who haven't been tracking the Rust-in-kernel situation. Drivers especially have been targeted for a few reasons. First, drivers are isolated, with abstractions that don't require interaction with the rest of the system. Second, Linux is available on more systems than the Rust compiler has been ported to. Because drivers are inherently system-dependent, it is not an issue to introduce a dependency on rustc on compatible systems. Third, bugs tend to arise more in drivers than other parts of the codebase, so Rust can do the most good starting there.

[1] https://www.reddit.com/r/rust/comments/rb50yn/comment/hnmshs...

View on HN

> Because drivers are inherently system-dependent

I'm not sure I agree with this. As someone who does development for prehistoric PPC embedded systems, I get to take advantage of a lot of drivers that were never really intended for my platform, yet work just fine because they're based on standard busses like PCI and USB.

Consider some architecture supported by Linux, but not yet Rust. Now, consider that a vendor might create a driver for their fancy new PCIe network card in Rust with the logic being "well, this card was never intended to be used in anything other than an ARM or x86 system". There's a good chance that if that driver was written in C, it would have worked just fine (albeit not officially supported by the vendor) on that old non-Rust-supported architecture, but now that's not an option.

Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself.

I completely agree. We should not get ahead of ourselves just yet. It seriously should support most if not all of the architectures that Linux itself supports.

https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

vs.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... or https://en.wikipedia.org/wiki/List_of_Linux-supported_comput...

LLVM is the real bottleneck here. I've worked with a platform that would have been easy to build a custom rust for (even if it wasn't officially supported), but was held up by the lack of LLVM support.

Yep. But there are two different active projects for compiling Rust with a GCC backend at the moment (one as a completely new frontend written as part of the GCC codebase, one as a libgccjit backend for the existing Rustc), there's also a Cranelift backend for rustc that you could add new architecture support to, and LLVM does add new targets, it can just take a bit longer to get support into LLVM and they don't keep architectures that are lightly or unmaintained around as long as GCC does.

For instance, Tier 3 support for m68k-unknown-linux-gnu was recently stabilized in rustc as a result of m68k support landing in LLVM (https://github.com/rust-lang/rust/blob/master/RELEASES.md#co...), which has been one of the previous sticking points for Rust packaging on Linux distros, some of which still support m68k architectures.

Chances are that Rust would also work just fine even if the arch is not officially 'supported', as long as LLVM exists on that platform.

Also, this is not going to retroactively affect any drivers, only the ones (potentially) developed from now on. As time passes, Rust support is expected to increase.

> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself.

I don't think that's realistic.

If we buy the idea that Rust will allow kernel developers to write more robust, safer, more secure drivers, I think that should override a desire to allow things like driver portability to arches that hardware manufacturers never expected or intended. I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness).

Regardless, the Rust support here is still considered experimental. I would be surprised if any company adopted it for a Linux driver for at least a year or more. That's plenty of time for people to get esoteric platforms supported in LLVM/Rust if they want to. And it also gives more time for the Rust GCC backend to become more mature and usable, and I believe that will give Rust support for every arch that GCC supports (more or less), which should cover your objection.

(At any rate, LLVM+Rust does currently support PPC, so your specific argument here isn't relevant.)

> I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness).

So what happens to users that depend on these archs & drivers - get left behind on the last non-Rust kernel?

The same as any other project that decides it may drop support: either stick on an old version, or work to add support for the platforms you care about. Rust's lack of platform support isn't because it is impossible for Rust to gain support for those platforms, but because users of those platforms haven't added support yet. Obviously that is easier said than done, and I doubt that Linux would make a decision like this, but the options are pretty straightforward if they did.

Yes, why not? Must it absolutely be so that a 20 year old Macbook can run the latest kernel? One that isn't even released yet, it's just in the preliminary planning phase? It's not even like new software wouldn't run on it. Most software runs fine on 10 year old linux kernels. Also, by calling them 'users' you're anthropomorphising, who are these actual real human beings being "left behind"?

edit: ok so it sounds a bit mean if you interpret it as if I'm not considering UnkleJoe to be a real human being. What I mean is, I don't think UnkleJoe is trying to get new devices to talk to his prehistoric PPC embedded system just for fun. An organisation is maintaining these systems, and that organisation is mooching off of Linux's excellent backwards compatibility. What's the economical cost of supporting that organisation, versus the economical costs of not implementing ksmbd in Rust?

> Yes, why not?

Security updates for one. People are always complaining about insecure IoT devices/routers that get conscripted into botnets. Dropping kernel support entirely compounds to manufacturer firmware negligence - meaning end users can't update to the latest Lineage/DD-WRT/OpenWRT firmware, even if they want to.

> Most software runs fine on 10 year old linux kernels.

If you had to wrangle with world of custom Android ROMs or open source router firmware - even as a user and not a developer - you know that software does not work fine on old kernels. Trying to support both old and new kernels is a royal pain, especially if you have add shims to support old kernels that lack new features.

I thank $DIETY for Linus' pragmatic approach, I trust him to balance user support against developer zealotry. I wonder how long it'll take for Linux to go to shit after he retires. Kernel notes for v42.3: dropped support for Risc-V. Remaining supported archs are x64 and ARMv21-24

> Security updates for one.

I thought we were talking about new drivers being developed in Rust. Your IoT security upgrade probably doesn't include a hardware upgrade, so it will not require these new drivers.

Regardless, it is the responsibility of the device manufacturer to support their old devices. It is their problem, hold them accountable.

> I thought we were talking about new drivers being developed in Rust

The discussion moved to what happens to drivers that are not ported to Rust, and GP was arguing they should be abandoned/dropped - as opposed to requiring that all driver's be switched over to Rust first.

> It is their problem, hold them accountable

How can they be held accountable, pragmatically? Also, owning a CVE-riddled, insecure device is actually the user's problem. Open firmware can at least ameliorate the situation right now: where manufacturers cant be bothered to publish/upstream/update their drivers to the latest kernel API in the same language. Asking them to rewrite drivers in Rust and upstream is obviously a tall order - barring the passing of new legislation.

> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself.

Why is it that so many people feel like they need to make sweeping pronouncements on the exact compatibility guarantees that a project as large as the Linux kernel must maintain across its entire code base?

Different maintainers of different subsystems of the Linux kernel make their own decisions on compatibility and support effort. There are a few basic principles shared across the project as a whole, such as user-space ABI compat guarantees, lack of kernel-space ABI guarantees, module licensing requirements, etc.

Not every piece of hardware even exists in the form of a PCIe expansion card. Some drivers are for peripherals that are embedded into a specific line of systems-on-a-chip. If I'm writing a driver for some peripheral that only exists on an AWS Graviton chip, I don't see any reason why some HN commenter should dictate that that driver can't be written in Rust just because there isn't yet upstream LLVM support for DEC Alpha chips.

I feel like most of these takes are due to someone getting upset a couple of years ago because some core library in Gnome like librsvg added a dependency on a Rust compiler back when rustc didn't yet support m68k systems, and this got someone working on packaging upset due to conflicting distro packaging policies.

The world moves on, however. The Linux kernel drops support for old hardware all the time. It introduces features that might only work on certain hardware. Also, rustc has added support for more platforms, including moving some platforms like aarch64 to Tier 1 support, and adding support for m68k.

While maintaining backwards compatibility or wide portability of drivers is a good thing, so is the much easier ability to write maintainable and secure code that Rust brings, so the desire to simply block one good thing that works on the vast majority of machines running Linux in favor of some small niche use cases doesn't really seem like the soundest decision.

I strongly disagree with your viewpoint.

If you need to support plugging in new hardware to a very niche embedded architecture, you will still have many options. These range the gamut from writing a driver based on the reference driver for your environment, to requesting/funding the development of such C driver from the vendor, to funding support for your hardware architecture in Rust/LLVM. Yes, all of these cost time/money. Maintenance of software ports to various architectures is very much not zero-cost, and assuming it is will eventually bite you or your business hard.

As another thought experiment: let's say the development of drivers in Rust is less expensive (either in $$$ spent on engineer time, in $$$ lost to bugs and security issues, or any other valuation you choose. If you/your community of people who desire new hardware to be supported by your embedded architecture can not cover this difference in cost (to make it worthwhile for drivers to be written for you), nor can afford to develop and maintain support for your architecture in Rust (so that you can benefit from the development work done by the vendor), nor can afford to upgrade to a newer hardware platform (which solves the problem completely), then your business is already screwed and you just don't realize it yet.

That said, this is the responsible way to introduce Rust code to the kernel - if this had be done by limiting future releases of Linux to only those supported by Rust, I'd be out with my pitchfork too, because that's something that really needs to be planned very carefully. As long as stable kernel releases continue to exist that support the full set of architectures, everyone's existing code will keep working, receive security fixes, etc. This is fine.

Strongly agree here as a long time driver developer. I honestly don't see the point to rush rust into drivers in the kernel now, if anything, it makes the driver space even more complicated.

That can be achieved by linux dropping support for architectures not supported by rust :D

I'm joking of course, but the platform support list of rust is pretty good looking at [1].

I'm pretty sure people developing for arm5 aren't building the linux kernel on arm5.

[1] https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

Yes, x-compiling is certainly an option, particularly since developers typically have access to hardware easily capable of such (it's just a minor pain to set-up).

Linux has always favored support for currently (and in the foreseeable future) relevant architectures over widest possible spread.

I don't quite understand the desire to run recent software on museums piece hardware, but for those who must, there's NetBSD.

There are at least two efforts that support Rust with GCC (a rustc codegen backend that uses libgccjit for AOT compilation, and a GCC frontend that parses Rust).

https://lwn.net/Articles/871283/ https://github.com/Rust-GCC/gccrs https://github.com/antoyo/rustc_codegen_gcc

That is actually a good point, but on the other hand you have to start somewhere.

I hope vendors would be more supportive of third party drivers because that obviously makes their hardware more attractive, but that has not been the case the last years.

I also don't have an opinion on the rust foundation. Member setup doesn't convince me, hope it doesn't influence the language negatively.

> The GCC backend for the Rust compiler (through `libgccjit`, although used for ahead-of-time compilation) was merged into upstream Rust: https://github.com/rust-lang/rustc_codegen_gcc If the backend keeps progressing, we hope to soon be able to start experimenting with compiling the Rust side of the kernel with GCC!

This means that using it for the core parts may be feasible sooner rather than later, no? Developing those abstractions may not be a priority of course, but it might be allowable at least from a platform support perspective.

Even once Rust has first-class support for GCC as a backend, I suspect that supporting the long tail of more obscure platforms will be an ongoing process. And for exceptionally weird platforms (e.g. where a byte isn't 8 bits) Rust may never bother to contort itself enough to support those, although perhaps Linux also doesn't support such platforms?

> Even once Rust has first-class support for GCC as a backend, I suspect that supporting the long tail of more obscure platforms will be an ongoing process.

Linux's own support for the long tail of more obscure platforms is also an ongoing process. People aren't asking for Rust to do better than the Linux kernel in that regard, they're just asking for it to not immediately disqualify a range of platforms.

One could reasonably argue about the value of supporting those platforms, but the Linux kernel, reasonably, doesn't want to make that decision on the sole basis of the availability of Rust support.

> And for exceptionally weird platforms (e.g. where a byte isn't 8 bits) Rust may never bother to contort itself enough to support those, although perhaps Linux also doesn't support such platforms?

Linux doesn't support such platforms, and I don't think Rust ever will either.

> Linux doesn't support such platforms, and I don't think Rust ever will either.

Almost all software not written especially for such devices doesn't support non-8-platforms. Heck, POSIX mandates that char is 8 bits.

FWIW Linux does support s390 (n.b., not to be confused with s390x), which is a 31 bit arch. Rust does not support it (and I'd guess LLVM doesn't either). So Linux does support some "weird" arches still.

This is partially what caused the shitstorm when the python Cryptography library took a hard dependency on rust to compile:

https://github.com/pyca/cryptography/issues/5771

AFAIK, s390 also has 8-bit bytes. The "31 bits" is the pointer size; IIRC, it's actually 32 bits, but with one bit reserved for compatibility with its even older predecessors.

Linux has not had mainline support for s390 since Linux 4.1 (6 years ago). Only s390x is left.

You can still run 31-bit s390 usermode binaries on an s390x kernel, but that's a different beast.

>You can still run 31-bit s390 usermode binaries on an s390x kernel

Ah thanks, I didn't realize that was possible. I'm no where near rich and/or old enough to have ever encountered an s390 machine IRL :)

You can emulate it using Hercules. When searching I found plenty of guides showing how to set it up. I'm not linking to any in particular, because frankly I have never tried them so I don't know which one you should follow.

Linux does not support running on s390, it only supports running s390 binaries in userspace. So using Rust in the kernel would be fine.

> This means that using it for the core parts may be feasible sooner rather than later, no?

More like much later. There are several performance-critical patterns used in the Linux kernel that are difficult to express in unsafe Rust and impossible to express in safe Rust.

See https://paulmck.livejournal.com/62436.html and especially https://paulmck.livejournal.com/64209.html

I think promoting the use of Rust for driver code is an excellent compromise.

As an aside, I'd like to see Linux go further and move many of these drivers to user space. Now that we have io_uring, old performance-based arguments for keeping certain drivers in ring 0 hold less weight.

Just a guess, use of the gcc backend for rust will face hard opposition by the same people pushing for rust in the kernel specifically if it is chosen (as it should be) by the kernel as the default choice.

i don’t want rust in the kernel, because it will make my job as a small device manufacturer even more complicated. it is already super hard / time consuming to understand how to build custom drivers and tune the kernel for specific applications, so i don’t need or want another language involved in there. in the end, you still need to understand what you are doing, and rust is not going to change that.

the days that linux was only used as a secure server OS are long gone. it is used everywhere for all kinds of applications and by lots of small manufacturers who are using the pi or other platforms.

also, you cannot just develop a driver in isolation, you have to take the typical use cases in mind while you make choices how to handle things.

I'm pretty sure it will be totally optional to write drivers in Rust, rather than C.

I just really hope this thing will not be a bitch to cross-compile. I'm not interested in building llvm + rust in addition to my 5 or so gcc cross-compilers, especially looking at the cadence of rust releases.

So as long as it will be possible to use the system's llvm+rust to build for all 4 CPU archs (at once) I'm currently building my kernels for, I'll probably not be too cranky about rust in the kernel.

what if your driver or user space app is affected by a poorly architected driver which was written in rust? now you need to deal with that rust source code. a true nightmare.

Why would that be worse than if it was written in C? A rust codebase would be much easier to find the bugs in and refactor accordingly, than in C.

Plus it's not like most people are going to dive into driver code without experience in the driver itself. So it's a niche set of folks this would affect, the majority of whom would likely be writing the rust code anyway since they're likely the ones most familiar with the driver aspects.

People have said the same thing about every language. I'm positive people complained about using C over assembly (people still do for certain things).

I ask you to imagine a situation where a kernel is written in assembly, and they decide to start allowing C to be used for drivers. How would you view a change such as that?

There’s a huge difference. Rust syntax is a lot more complex than C, while this isn’t true for C v assembly.

The semantics of C and how to write code that is well defined is much more complex than assembly.

C is easy to read and follow though. Rust has far more syntax and as a language is way beyond the complexity of C.

Only if you know C but not Rust. I personally find Rust fairly easy to follow and C a complete nightmare (the details in C are ok, but it's really hard to see the forest for the trees).

I know C and can get by in Rust and I disagree that rust is easier to follow. C is a simple language, the complexity comes from large systems, while Rust is just not.

Well I know Rust and I can get by in C. Perhaps that makes a difference.

> C is a simple language, the complexity comes from large systems, while Rust is just not.

I mean I agree that C is simple if you're making a 50 line program that writes to stdout or something. But more often than not with C or Rust you are working with a large complex system. And I'd argue that when working with such a large system, Rust programs are less complex than C programs.

There is a huge difference between reading and writing C. C is very easy to read, but it's quite difficult to write (secure, portable, performant) C. Code is typically read a lot more than it is written. I haven't written a single line of code in torvalds/linux.git but read probably tens of thousands of lines of Linux kernel code over the years. I'd wager that for every kernel developer there are at least 10 people reading the code to figure out how something works, or how it broke.

C makes many questions when reading trivial to answer, questions like "how do I get here?", "where does it go?", "what is this type?" and "what does this code do?" are generally very easy to answer without expert-level C knowledge. From what I've seen, that's not true for rust.

I disagree. You can learn the semantics of C in a day, assembly requires a ton more memorization and a ton more code to write. C is more abstract that assembly but it is less complicated, on its face, than assembly or rust.

If you're familiar enough with programming to learn C in a day, you can learn assembly in a couple hours. It's really not that complicated. You can copy to/from memory addresses to local temp variable containers that are various sizes of bits (registers), you can do various math operations on those bits in those registers, you can compare those registers and test that comparison, and you can jump from the current point in the code to any other point by label or address (go-to). Sometimes operations will result in other registers you can check to see if something happened (overflow). The OS will provide some interrupts to do some base things as interrupts such as IO.

If you didn't know how to code in assembly already, you now know enough to do everything C can do with a simple reference sheet. All the extra boilerplate (such as program segments and where to store costants such as what the 'strings' program sees in a binary) you can read two to three pages to explain what you need for whatever OS you're on.

Assembly isn't hard, it's just tedious.

Cross compiling with Rust is actually not that bad.

LLVM is always inherently a "cross-compiler". In fact having to have "5 or so compilers" is just GCC being stupid.

Good. :)

Cross-compilation with Rust is fairly trivial; it's just a matter of "rustup target add some-host-triple".

GCC's cross-compilation story is indeed a nightmare. I expect if you have to use the GCC Rust backend (after it's ready) for arches rustc/LLVM don't support, you'll have that pain, but I expect it will just be a matter of adding an "--enable-language rust" to the GCC configure script run, similar to adding C++, ObjC, etc. to a GCC build. So the cross-compiler build will take longer, but won't involve extra steps or infrastructure.

Binutils/gcc cross-compiler can be built rather quickly, once you know the right configure flags for each. Then it's just make && make install. You can speed the buil considerably by building with -g0 and not doing a bootrstrap or building needless targets.

Then you have a cross-compiler in some --prefix that you can point the kernel build system to via some environment variables and you're done. It's a well known process.

It's basically built just like any other dependency and doesn't take much time.

Hardly a nightmare. If it would be possible to just add rust to the list of gcc languages, that would indeed be very easy.

Cross compilation is actually much easier with Rust than it is with gcc. Every Rust compiler is a cross-compiler for all architectures that Rust supports; all you need is the rest of the toolchain like linker and libraries. rustup handles installing the libraries, and as lld (the LLVM linker) adds support for more platforms it can also be used as a cross linker, rather than a linker per target as in the older toolchains.

I understand your concern and I would definitely feel the same if some language I wasn't familiar with was suddenly introduced in the kernel. But at the same time as a big Rust enthusiast I think it's really a good idea in the long run: C is going nowhere but it's really dated, design-wise. When you've tasted the sweet nectar of type inference, strong typing, union types and of course the safety of the borrow checker, returning to C feels like banging rocks together.

The main drawback of Rust here I think is the longer compile times (I dread to imagine how long a fully Rustified kernel would take to build) and a generally more complex, but also more expressive language.

More generally I trust the kernel maintainers not to succumb to the hype and overdo it. People who still exchange patchsets over mailing lists are probably unlikely to be blinded by shiny things.

the point is that you still need to know what you are doing. rust won’t change that. C is everywhere, and that is not going to change anytime soon. your time is better spent understanding more of the kernel instead of learning another tool set.

one of the biggest hurdles for me was the DTB declarative language. that was the most stupid idea ever to invent that and i lost 100s of hours trying to get my DTB files right for my hardware. so you can understand i don’t want more hipster shit to deal with.

You need to know less about what you're doing with Rust at any given time versus C, for the programmer.

Also at this point, Rust isn't "hipster shit". You're just not familiar with it, and that's fine. But it's in wide use now and proven to solve major classes of recurring issues.

i’ve looked at it briefly. i do not need or want it, and that is fine. what is important, is to keep the kernel tree simple and understandable. that means minimizing the number of tools and languages involved. which means not introducing rust.

> keep it simple and understandable

Yes. Rust helps with that because as a language it simplifies avoiding huge classes of vulnerabilities.

Rust simplifies it for the developers by moving part of the mental model of the developer into the compiler.

i don’t care about vulnerabilities. it is very annoying that everyone assumes that linux is only used for applications where security matters. plenty of devices using linux do not need to be secure and forcing rust onto the entire linux kernel community because of a vulnerability argument is stupid and will only make it harder for people to use linux in a project.

This is just absurd. It's like arguing against seatbelts as a default in cars because you might sit in your driveway most of the time.

Most Linux installations are cloud servers. So yes, Linux really needs to be secure.

i think that has changed over the past 20 years. linux is now everywhere and not just on servers in data centers. and this requirement is not a valid reason to force rust onto all device creators who choose linux.

Assuming anything new is bad because of a bad experience seems like a poor lesson to take.

Of course you need to know what you are doing still, but pretending humans don't make mistakes even when they know what they are doing is ignoring reality.

As a counterpoint security in e.g. Bluetooth has been an ongoing problem and even "mature" code like ext4 has recurring problems. Somehow I doubt the problem is that the people involved are not smart enough or trying hard enough. Maybe it's worth revisiting what tools we use.

there are many situations where security does not matter. so that is not a reason to force rust into the code base. not everyone is working on a device that needs to be secure.

> not everyone is working on a device that needs to be secure.

And those drivers can continue to be written in C. Rust is merely an option.

i need to be able to read and understand any driver’s source code without having to learn rust.

So the whole kernel should be beholden to you as the minimum viable target then? I hope you realize how self centered that outlook is.

The rubric for decision making in Linux kernel driver development is not "what HN user b20000 thinks they need", as far as I am aware.

this is not about me. it is about keeping the kernel tree reasonably accessible for small startups and device creators who do not have the funding of FAANGs and cannot afford to take on more complexity on top of something that is already very complex.

Anyone who values simplicity over security in the most used kernel in the world, has their priorities in the wrong place.

Have you tried reading or writing any Rust?

I have, and it was the most frustrating language I've ever tried. You sit there staring at the code wondering what's wrong with the variable you created until you Google it and find out it's a certain type that you never heard of. It's ridiculous.

I'm sure it gets better as you memorize the millions of different types, but what benefit do you get from all this pain?

I also think it's just a boy's club at this point. Big pipe dreams of rewriting all the C++ and C code is all we here about. It's not going to happen. The language is too f*k*g hard to learn so no one will. It's like trying to make everything in Haskell, c'mon, get real.

Someone had to say it...

How do you mean, "memorize the millions of different types" and "You sit there staring at the code wondering what's wrong with the variable you created until you Google it and find out it's a certain type that you never heard of"?

I don't think I've experienced this in any language, even ones with the most expressive type systems. More typing is better, as far as I have experienced, and as far as I have heard from people who take it up in their projects.

The compiler will tell you exactly what goes wrong if you pass the wrong type. If you mean that type inference was confusing, it's the same as `auto` in C++. Except the Rust compiler does an enormous amount of handholding with errors, often showing you exactly how to correct your code.

why is this voted down? can’t we have a conversation and hear some other opinions?

>> I also think it's just a boy's club at this point.

Probably mostly because of that.

Not that the other points are necessarily easy to follow since they're not well explained. If knowledge of why some type was hard to know or had to be googled (or for example noting what one of those types is) was presented, then people might have been able to respond to those points.

Instead it reads as "it's hard, I used it and it's hard, and I had to do some stuff I didn't like, and so my impression is it's just a bunch of people faffing off and it's too hard to take seriously", which isn't really useful for a discussion, and additionally is dismissive. Every one of the criticisms presented could be said about C without any change because no actual concrete details are provided.

It's not like Rust is perfect, there are many valid criticisms of it that have real examples and make useful points. Those comments probably deserve your defense more than this one.

> your time is better spent understanding more of the kernel instead of learning another tool set

No matter your skill level, that won't stop you from committing memory-safety mistakes that may lurk for years until they suddenly result in a catastrophic failure. Evidence for that is abundant.

What is DTB??

A file format to describe device trees, which describe the HW attached to the system. Mainly used on !x86 arches, as an alternative to ACPI-style autodiscovery:

https://en.wikipedia.org/wiki/Devicetree

I laughed out loud reading at his devicetree frustration, because while it's pretty gross to work with at times, at least it's not ACPI!

You always need to know what you're doing, but Rust lets you encode more of what you mean in the code and the compiler checks that you're not violating your own invariants. That's the killer feature for me. I feel like I'm working with the compiler, not against it.

Sometimes I feel like C's compiler is almost adversarial, going out of its way to find small mistakes in my code and have them blow in my face at runtime instead of notifying me. I understand why it works that way of course, but usually when my Rust code compiles, it works. I can't say as much for my C code, despite nearly 20 years of practice.

I do share some of your frustrations with the DTB thing, I'm not a fan of it either, although something like that was needed and I'm sure any alternative would have its haters.

From the perspective of people who don't know Rust, it's not a sweet nectar, but a suspicious murky liquid.

From the perspective of people who don't like aspects of Rust, it's a yucky goo.

This is _not_ like with C. Few people are enamored with C, but - the language itself is relatively simple (Duff's device notwithstanding...), so in my analogy it's like water. You may not adore it, but you can see through it, and you'll be ok with gulping it down to quench your thirst.

> From the perspective of people who don't like aspects of Rust, it's a yucky goo. > This is _not_ like with C

I beg to differ. This is exactly how I feel about C. C is the language that's confusing as hell to read for anything other than really simple use cases AND makes it super easy for me to shoot myself in the foot.

C is what you program is what you get. and i think that is pretty important.

C is what you program is what you might get.

Know thy standard and thy compiler optmizations, least you be surprised by the outcome.

This is true for any programming language. The problem is being aware of what you really wrote

No, you are wrong. C++ is one example. I've been using that language now for about 20 years and I still don't use all of its features. It is possible to write code in that language that you assume will work a certain way but then in practice it does a lot of things you didn't think you signed up for. Recently I started using STL more, after having stayed away from it for most of my career, and the performance of my application went out the window, and I had to override all memory allocation related functions to fully understand where the problem was coming from. It's easy to use the STL and make assumptions about performance, then find out later you get a lot of issues that come with it that you never signed up for. And that is why I don't want rust in the kernel. If a language does a lot of stuff for you, there will be a price to pay.

> It is possible to write code in that language that you assume will work a certain way but then in practice it does a lot of things you didn't think you signed up for

This is also possible for C. Most commonly around Undefined Behaviour. C only does what you expect it to do if you know the C spec inside out. Rust can have confusing behaviour too, but it is generally much better in this regard than C or C++.

You may find it easier to reason about C than Rust, but that's only because you know C better. I find it much easier to reason about Rust.

With modern compilers, there is no such thing as what you program is what you get.

As long as you stay away from compiler-dependent, platform-dependent, and/or undefined behaviour, you should be fine. Main problem is that a surprising ab´mount of "looks normal" code is actually UB.

You would be "fine", but the compiler will optimize away alot of your code, and will rearrange a lot of the rest. I wasn't even talking about platform-dependent or undefined behavior.

> Few people are enamored with C, but - the language itself is relatively simple

if you don't use pointers, yeah. but like you can't built anything useful without pointers.

if you do not understand pointers and cannot work with them, you probably should not be a software engineer.

I'm not sure that it's the concept of pointers that make C code harder to maintain than other languages. Lots of languages have pointers, including Rust.

It's a question of whether unguarded pointers (and a lack of language features that keep pointer math from devolving into an unreadable mess) are good to have in areas where pointer errors can result in critical bugs. We started discouraging goto statements not because developers didn't understand them, but because they did understand them, and they understood that the tools you use influence the type of code you write. And Rust doesn't even really get rid of pointers, it just adds rules around them.

We all accept some degree of abstraction/safety tradeoff, otherwise we'd program in lower-level languages than C that are even simpler and even easier to understand. C does introduce a lot of complexity over more primitive assembly languages. And Rust introduces a lot of complexity over C.

Different people pick different points where they think the tradeoffs are optimized. But we have a pretty large amount of data suggesting that even <quote>good</quote> programmers in industry make pointer errors in C. So it's pretty obviously not lack of understanding that's causing these issues, it's that unrestricted memory access and pointer math is inherently error-prone. Whether it's SO error-prone that's it's worth introducing a much more complicated, rigid language into the kernel is left as an exercise for the reader. There is a downside to introducing more complexity here, all abstractions have downsides.

But it's real dismissive to say that if everyone understood C pointers then their code wouldn't ever devolve into an unreadable mess. I just don't think that's an opinion that can be backed up by any real evidence, pretty much every org struggles to some extent with writing secure C code. And we have a lot of experience in the field of software engineering that should have taught us by now that sometimes unreadable code is the result of language affordances and patterns.

Also there are many different ways to undestand and use pointers; there are many many programmers that are really good at using pointers and are able to engineer essentially safe architechtures, but many of those very good programmers would come up with incompatible architectures around pointer usage.

My wild guess is that most "simple" pointer errors (use-after-free, double-free, unintentionally using unitialized memory, ...) happens at interfaces where there isn't perfect comunication about what component is responsible for keeping track of each task.

Yeah, I think about a very offhand comment that Carmack made once that ended up resonating with me a lot, even though I don't think it's universally across the entire board true:

> "Most bugs are a result of the execution state not being exactly what you think it is."

There is an aspect of language design that is about making it hard to be surprised by things. And I vaguely suspect that a lot of pointer errors fall into this category; people assume something is being freed, they assume that a subroutine is cleaning up after itself or that it's not manipulating something, or that it doesn't need to call some setup method before it's run. These are boundary errors between interfaces where allowing users to (inadvertently) mask what is happening can lead to logic that feels very convoluted and hard to follow, and can also lead to simple errors around just forgetting to do stuff.

I wouldn't call that Carmack quote a mantra, I'm not saying it explains all programming (or that all architectural restrictions are good), it's just a lens that I keep coming back to when I think about language design and architecture; there's a real tradeoff in removing flexibility, but there is also a huge amount of value in systems/patterns that make it very hard to bury relevant information. And if a language can auto-surface some of those problems, that can lead to cleaner code.

It depends what level you mean. Understanding and using pointers on basic way is simple. Understanding pointer provenance, aliasing rules, etc. are a completely different level and people not very familiar with the spec (so almost everyone) do not understand a lot about pointers. http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1434r0....

> The main drawback of Rust here I think is the longer compile times

The time scales with the compiled unit size. If you're compiling drivers/modules, they're going to be fairly small and not much slower than C.

I think type inference is much more important for people that used dynamically typed languages instead of C devs. You could argue that it is also much more important for Rust.

no offense but aren't security concerns just as pressing in the world small manufacturers, embedded etc.. given that those kinds of devices are nowadays part of pretty vital infrastructure?

the lack of memory safe languages is probably the nr. 1 contributor to critical bugs in software and regardless of what we're working on we ought to learn new languages if they help to improve software quality.

I don't believe that the change to rust (and I like rust a a lot) will lead to a measurably more secure kernel in the long term, although it will mean that maintaining the kernel will require knowledge of Rust in addition to C (and some flavors of assembly, occasionally). On top of that, the Rust that can be compiled into the kernel will be a subset, or its compilation will be tuned [idiomatic and safe allocation of memory within the stack, efficient Rust/C interoperability with dynamically allocated memory, in a Rust-safe way, etc.].

Let me explain why I think that:

In the short term, having more eyes looking at and re-implementing the scaffolding for drivers and the drivers themselves will certainly lead to a very positive outcome - many potential bugs (of which, most of them will not really be exploitable, but some will) will be uncovered which couldn't have been introduced with safe Rust. However, at some point, the coolness factor will drop, drivers will become fossilized, a larger developer base that has to maintain older Rust drivers might cut corners, use more unsafe features, misunderstand/misremember the nuances of this or that, and what was once exciting is now tedious. Maybe not, maybe Rust will slowly replace the whole kernel, however, at the current stage at which Linux is, I find it unlikely (but possible).

> a larger developer base that has to maintain older Rust drivers might cut corners, use more unsafe features, misunderstand/misremember the nuances of this or that, and what was once exciting is now tedious.

The great thing about Rust is that it makes it much harder to cut corners, and much more obvious when someone does (making it easier to pick up at review stage). Invariants can be built into APIs in a way that simply can't be done in C.

But the Rust safety guarantees aren't about eyeballs, they're about boring mechanical processes, the same difference as say, having your CI run unit tests and refuse to provide artefacts if the tests fail versus telling developers "Make sure you run the tests before shipping a release" which they will promptly forget to do.

The machine doesn't get bored. The fact Rust may not be "cool" any more doesn't alter the fact that your subsystem maintainer isn't going to accept your patch that doesn't compile because you tried to take the lock for foo, but then used locked variable bar - something C has no problem with but which in Rust of course does not compile.

That just sounds like "I don't want progress because it will mean I have to learn new things and I don't want more work for myself". Well... tough luck?

Regardless, if you want to keep using C to write your Linux drivers, the new Rust support does not change that.

If you're a device manufacturer trying to manage common code for a variety of hardware platforms with subtle differences in toolchains / kernels, dealing with all that complexity can be pretty tough. If Rust drivers start popping up in the kernel, you now need to start dealing with twice as many toolchains and twice as much complexity.

One of those toolchains is used to build the bootloader, kernel and majority of userspace software for the devices. The other toolchain is used to build an I2C temperature sensor driver that was rewritten in Rust so someone could put Rust driver experience on their resume.

Dismissing this and saying "suck it up, this is the price of progress" is fine. But it doesn't change the fact that this could be a giant PITA for people making devices and developing the BSPs for them while providing almost no value. I'm not trying to argue that appeasing this group is important enough to totally reject Rust from the kernel, but as a maintainer, making life difficult for a huge number of kernel users is probably something you'd like to avoid.

I think a lot of this will come down to how Rust patches are reviewed and accepted. If Amazon or Facebook want to upstream some new Rust driver they wrote for their own hardware, there's probably no negative impact to anyone by merging it. But I'd expect maintainers will be very hesitant to accept patches that touch existing drivers. I guess time will tell.

amazon or facebook can afford to pay lots of developers to deal with this. i cannot, and if they force their rust code onto the community, it will close the door for lots of smaller device manufacturers including myself. and that is the main issue. linux does not exist to entertain the interests of those with more money.

Reading up on the Rust spec and concepts is fairly trivial compared to letting a lot of devices and their drivers interface each other. I don't think Rust inclusion will change that however. Time will tell, but your response is rather childish.

have you designed any custom hardware running linux requiring custom drivers? if you do, then you will understand my concern.

Adding Rust doesn't make it harder to do any of this. When you build a custom driver, you could choose to develop it in C or in Rust. It gives you the choice, and many of us find it easier to build in Rust than in C; but even if you prefer C, you will still have that choice.

Most of "tuning the kernel for specific applications" consists of making changes to the kernel config or compiler settings. Rust won't change the kernel config system, and compiler settings for Rust are quite similar to those for C, as Rust uses LLVM as its backend, and LLVM is used by Clang which goes to a lot of effort to provide a mostly GCC compatible interface.

> in the end, you still need to understand what you are doing, and rust is not going to change that.

If think you understand what you are doing in C, you probably don't. C is a fantastically difficult language to write correct code in at scale; even the best developers make simple mistakes all the time.

I understand the frustration at seeing something else you might have to learn and deal with that might make things a bit trickier during a transition, but that's pretty much the nature of keeping up with any kind of ongoing development process. It's not like the Linux kernel sprang fully formed out of Linus's head on day one and it's just been a matter of adding drivers and making small incremental fixes. There are all kinds of changes that require you to change and adapt, like the removal of the Big Kernel Lock, or pretty much any internal API work, and yeah there can be work to keep up, but that doesn't mean you should hold back progress.

Seems like a brilliant fit for introducing Rust to Linux kernel.

> with abstractions that don't require interaction with the rest of the system

I have no idea what this is supposed to mean. Drivers obviously interact with each other and with the rest of the system via all kinds of in-kernel interfaces.

Drivers are also not inherently system dependent. Even the sample rust driver is for android binder, which is not a real HW device, but some kind of IPC mechanism. So that one is quite system independent.

The target architectures of the rust compiler are very limited compared to GCC.

So if you port some core functionality of the kernel to rust, that would make rust a hard dependency for the whole kernel.

You missed the point.

OTOH, it may cause companies to invest in creating a well maintained Rust frontend for gcc. People have already done much of the grunt work for this, so it seems like it's just a matter of manpower, and something that acceptance into the edges of the kernel might cause more investment in.

> I have no idea what this is supposed to mean. Drivers obviously interact with each other and with the rest of the system via all kinds of in-kernel interfaces.

But the total footprint of the interfaces that typical drivers use is fairly small. When a rusty shim is provided that provides access to those interfaces, you can write pure rust drivers.

Typical device drivers with limited interface footprint also barely do anything interesting.

For example look at typical audio codec drivers. They barely have any procedural code (and when they do it's just some form of register value mapping anyway), locking/concurency and almost all resource management is handled at the higher level and the driver is not exposed to it.

Another kind of a driver that features a very limited dependency on Linux interfaces is a SoC clock/reset driver. And clock drivers are even more boring in this aspect. Code vs data ratio is probably < 0.1 in many of those.

I guess some drivers that do more complicated stuff, and deal with concurrency issues or more complicated resource management may benefit, but they'll likely need to touch much larger API surface, too.

And I dunno, even the sample driver in the patchset has things like this:

        let mut data = kernel::new_device_data!(
            gpio::RegistrationWithIrqChip::new(),
            PL061Resources {
                // SAFETY: This device doesn't support DMA.
                base: unsafe { IoMem::try_new(res)? },
                parent_irq: irq,
            },
            // SAFETY: We call `spinlock_init` below.
            unsafe { SpinLock::new(PL061Data::default()) },
            "PL061::Registrations"
        )?;

        // SAFETY: General part of the data is pinned when `data` is.
        let gen = unsafe { data.as_mut().map_unchecked_mut(|d| &mut **d) };
        kernel::spinlock_init!(gen, "PL061::General");

        let data = Ref::<DeviceData>::from(data);

It's barely readable. I don't know what type `data` is, what `gen` is or how it's different from `data`. Variable names don't really help. `data.as_mut().map_unchecked_mut(|d| &mut *d)` also looks like some kind of WTF to the uninitiated, that is somehow retrieving some 'general part of data' whatever that is.

When I look at the kernel's spinlock type https://elixir.bootlin.com/linux/latest/source/include/linux... that doesn't really help me determine why whatever this `gen` [variable?] is needs to be passed to `spinlock_init`.

And what's with the two `let data`. Are they the same type or is the type now different and the first data variable now hidden? Because it looks like second `let data` gets somehow transformed from the first `data` into something else. So now we have two identically named `data` variables with different types in the same function?

Wasn't this supposed to be some simpler language to draw more people to the kernel development? At least with C each variable has a type that's quickly identifiable.

I guess after 15 minutes I see what this is trying to do. It passes some newly created spinlock object to `new_device_data` function and then calls `spinlock_init` on some part of the data returned from `new_device_data` that needs to be extracted from it via some really obtuse transformation, just to initialize the spinlock later instead of directly in `SpinLock::new` for some obscure reason, using two unsafe {} blocks in the process. But oh my god, if this kind of obfuscation is going to be the new standard for the kernel,... At least C is the devil I know. :)

Yeah, I hardly understand Rust code, and I did not start learning programming yesterday.

If you want to practice, check out https://github.com/immunant/ioq3/blob/transpiled/quake3-rs/q... or whatever.

That is not idiomatic code: it is an auto-translated code straight from C.

You are judging Rust by looking at what idiomatic C code looks like in Rust.

No no no, I know that it is not idiomatic code, it says in the URL: "transpiled". I am just telling him to practice using it. I was not judging Rust at all.

That said, idiomatic Rust is difficult for me to read/understand as well. I do not expect device drivers in Rust to be readable (by me), and if they have lots of unsafe blocks then we are back to square one I would say.

how would the idiomatic code for that example look like? (seriously)

Here is the refactored code: https://github.com/immunant/ioq3/blob/refactored/quake3-rs/q...

I wouldn't call that code idiomatic either: it is cleaned up from the automatic translation, but it still a far cry from what Rust written by hand would look like

  pub static mut g_color_table: [crate::src::qcommon::q_shared::vec4_t; 8] = [
      [0f32, 0f32, 0f32, 1f32],
      [1f32, 0f32, 0f32, 1f32],
      [0f32, 1f32, 0f32, 1f32],
      [1f32, 1f32, 0f32, 1f32],
      [0f32, 0f32, 1f32, 1f32],
      [0f32, 1f32, 1f32, 1f32],
      [1f32, 0f32, 1f32, 1f32],
      [1f32, 1f32, 1f32, 1f32],
  ];

would maybe look like

  pub static mut g_color_table: [[f32; 4]; 8] = [
      [0, 0, 0, 1],
      [1, 0, 0, 1],
      [0, 1, 0, 1],
      [1, 1, 0, 1],
      [0, 0, 1, 1],
      [0, 1, 1, 1],
      [1, 0, 1, 1],
      [1, 1, 1, 1],
  ];

but it still looks weird to me (a static mut would be uncommon in a design, and not having a new-type to represent these would also be uncommon).

If you are interested in looking what Rust written from the ground up in the same domain looks like, you can maybe look at Bevy[1].

The biggest source of "noise" in Rust is explicit type conversions, FP constructs and longer types (`.into()`/`.as_mut_ref()`/`.map()`/`Result<Option<T>, E>`).

[1]: https://github.com/bevyengine/bevy/blob/main/crates/bevy_ren...

  BufferInfo {
    buffer_usage: BufferUsage::VERTEX,
    ..Default::default()
  },

What is "..Default" here?

`Default` is a trait[1] that can be implemented on any type that can be conceived to have a default value. For example, Option has something like:

    impl<T> Default for Option<T> {
        fn default() -> Option<T> {
            None
        }
    }

If every field of a struct impl Default, then you can you can use the `#[derive(Default)]` annotation to auto-fill that impl for that struct, otherwise you have to write it by hand.

The .. is the spread operator, and it takes every field of the value on the right and applies it to every field of the struct constructor on the left. This only works for the same type (it's not only looking at the field names).

`Default::default()` is a qualified call on the trait equivalent to `<_ as Default>::default()`, where `_` is inferred from context to be `BufferInfo`.

What that code is doing is saying "build a default BufferInfo with field buffer_usage set to VERTEX".

The spread operator has a limitation you might have intuited from the description that it can't work for types where some field(s) should always be set but not others. To get around that you can use the builder pattern

    BufferInfo::with_buffer_usage(BufferUsage::VERTEX).build()

and there's a pre-RFC in flight to become an RFC to add support for

    struct Foo {
        field: i32 = 42,
    }
    
    let foo = Foo { .. };

[1]: https://doc.rust-lang.org/std/default/trait.Default.html

Normally in Rust, to initialize a struct, you must specify a value for every field of it, since null and uninitialized values aren't allowed. To make it a little more convenient, there's a trait called Default which can be implemented for your struct to provide an instance with every field set to a value that you think should be the default. And the .. syntax allows you to copy values for the rest of the fields of a struct from another struct instance. So calling that with Default::default() gets an instance with the default values and uses those values to fill all of the rest of the fields of the struct. Thus if you have a big struct where most values are the default most of the time, you can create instances of it with one or two fields set to something different like this without an extra few dozen lines of repetitive boilerplate for every other field of the struct.

So, what we're saying here is in effect, "and all the other fields should have their default value".

Specifically, when you initialise a structure like this, the .. is "struct update syntax" and is followed by an instance of that structure from which remaining fields will be copied. Default is a Rust trait (similar to an interface if you've never seen Rust traits before) and it has the method default() which gives you a default of whatever type.

Rust has type inference, if you don't specify a type, but there is only one possibility that could work, the type inference might (and in this case does) see that and you needn't bother laboriously writing down the type. This can only happen where there was no possible ambiguity. In this case, the only type you can use for struct update syntax is the structure type you're updating of course, BufferInfo, and so Default::default() must mean the default BufferInfo.

If you found the definition of BufferInfo it probably says #[derive(Default)] which means, using a macro just implement Default for this structure in the obvious way, although it might actually have an explicit Default written out instead.

Bear in mind this is the source code of a game/game engine. They are notorious for their use of hacks, specially to squeeze out performance.

In all fairness, the Linux kernel uses various techniques here and there for optimization, too.

Where do you see hacks being used in, say, the refactored code? If you meant generally, then sure, they do.

Oh, I thought that the comment about not looking as idiomatic code was referring to the kernel::new_device_... sample in a parent/parent HN comment. I was more interested in knowing what was so unidiomatic about that.

The posted code isn't terrible, but it is a bit denser and harder to read than I'd like. Some small changes (like importing the macros to avoid a full path) makes a bit easier to read

        // SAFETY: This device doesn't support DMA.
        let base = unsafe { IoMem::try_new(res)? };

        let mut data = new_device_data!(
            RegistrationWithIrqChip::new(),
            PL061Resources { base, parent_irq: irq },
            // SAFETY: We call `spinlock_init` below.
            unsafe { SpinLock::new(PL061Data::default()) },
            "PL061::Registrations"
        )?;

        // SAFETY: General part of the data is pinned when `data` is.
        let gen = unsafe { data.as_mut().map_unchecked_mut(|d| &mut **d) };
        spinlock_init!(gen, "PL061::General");

        let data: Ref<DeviceData> = data.into();

I imagine code like this would be the body of a small function that does all this unsafe preparations and gives back a Result<Ref<DeviceData>, Error> once it's done, which would change the end to be

        Ok(data.into())

Thanks, it actually looks better and more understandable.

> I don't know what type `data`

Most Rust is written with the implicit assumption that it will be read in an IDE that displays types, so explicit type annotations are usually kept to a minimum. Doesn't always translate well outside of the IDE, so I wouldn't be surprised if the consensus for kernel code shifts to more annotations.

> When I look at the kernel's spinlock type [...] that doesn't really help me determine why whatever this `gen` [variable?] is needs to be passed to `spinlock_init`

The rust version of the documentation makes an attempt at explaining it, though honestly it could be a lot clearer https://rust-for-linux.github.io/docs/kernel/sync/struct.Spi...

> And what's with the two `let data`.

That's pretty ideomatic in rust, probably borrowed from functional languages. The new definition hides the previous one, and the implication behind reusing the name is that it's fundamentally the same data, just with a different type, or different mutability (here it was converted from mutable DeviceData to an immutable Ref with the same DeviceData).

That clears some things. Thanks.

This is probably the biggest issue with Rust in the kernel; because it needs to deal with a lot of existing kernel interfaces and abstractions, you get code which is neither very idiomatic Rust, nor is terribly recognizable to someone who knows the kernel abstractions fairly well.

Now, some of that is just a matter of learning curve; once you have learned the Rust-in-Linux abstractions the above will probably be somewhat more readable.

Coming from someone who's more familiar with Rust, and less so with the kernel, here are a few notes.

* It might not be the best idea to post the example drivers with inferred types, for this familiarization reason. While there are a few types (such as those involving closures) that you can't write and can only use via type inference, or others that are too large to want to write out, these types should be fairly easy to write and it would improve readability during the familiarization process

* A lot of these things that you were having trouble with look like they are basically just dereferencing and accessing some data contained within the spinlock, and casting what is only guaranteed by the API to be an immutable (shared) reference into a mutable (unique) reference in an `unsafe` block. This is a place where trying to use simple Rust wrappers over core kernel structures which weren't designed for Rust makes things a bit more difficult to read, as you need to do a bit of an unidiomatic dance to tell the compiler "yes, the language and type don't gurantee uniqueness, but I promise this reference is unique and I won't misuse it."

* One of the small little humps to get over when learning Rust is to learn that "mut" actually means "unique", and unmarked (immutable) references means "potentially shared." But since you do need to sometimes write to objects that are potentially shared, it just means that you need to either guarantee yourself or use some kind of synchronization mechanism to ensure that at any given moment of time that data is only mutable in one place at a time.

So, I don't know the details of these APIs myself, but when I look at this here's what I see

* we're constructing some device data object protected by a spinlock

* we're providing some brief justification for why this particular usage is safe, since the API and compiler can't guarantee that it's safe

* we're extracting a mutable reference from it, for which we need to uphold the single exclusive access principle without assistance from the compiler

* we're wrapping that in a new reference to device data type which presumably provides a more idiomatic interface than what the raw primitives provide

I'm guessing that the following code which actually uses this Ref::<DeviceData> object will then be a bit more readable and require fewer uses of unsafe, as it looks like this code is what is providing that translation between some core kernel primitives which are not terribly idiomatic to use in Rust and a safer, more idiomatic wrapper.

> It might not be the best idea to post the example drivers with inferred types,

a `cargo fmt` option to add inferred types to the source code would have some advantages for that.

Most drivers don't interact with other drivers, only with kernel interfaces. A driver for a PCIe device has to interact with the PCI subsystem, but that subsystem isn't a driver in the traditional sense.

Consider this: Does your GPU need to talk to your mouse or your real-time clock? Or does your sound chipset need to talk to your HDD? The answer to both should be no. Even a file system driver does not need to know about the underlying storage driver, since it operates on a block device abstraction.

Of course, some kernel modules have dependencies on other kernel modules, but those dependencies generally don't cross subsystem boundaries.

(There are of course exceptions to the examples I listed, but the argument should apply to the majority of device drivers.)

I guess I have to deal with wrong drivers then, but many of the drivers I had pleasure working with cross many boundaries. For example look at rockchip type-c port stuff I've been looking into last month:

There's a phy driver for USB, phy driver for Type-C phy/mux, display port CDN driver, type-c TCPM controller driver, generic alternate mode DP driver, charger power supply driver, and more, and all these have to communicate together (and do so over extcon and type-c mux/role switch/orientation swtich interfaces)

USB 2.0 phy driver detects what kind of device is connected using BC1.2 specification (what kind of charger basically), TCPM driver does the same over USB-PD, they race together basically trying to identify how much current the device will be able to draw from the charger.

Because they are independent on HW and driver level, one of them takes it upon itself to get the information from the other, and decide what values will get more priority, and passes that over another interface to a charger driver, to make it configure the HW to not overload the power supply connected to the Type C port. This not a driver->subsystem but basically a driver<->driver interaction.

There's a ton more communication going on between these 7 or so drivers. TCPM figures out the peer device supports Alt-display port mode, so it will tell the type-c phy to reconfigure itself for 2 SS lanes and 2 alt-dp lanes modes to support parallel use of USB and display output. Displayport CDN driver orchestrates this, but there's a problem that link training is needed for this to work well, and that needs coordination between CDN-DP and Type-C PHY drivers, because there's no standard kernel interface for it.

So, yes I see a ton of inter-driver interaction. Many of it kinda ad-hoc, over some not perfectly well matching bus like interface like extcon or direct calls to other drivers, in addition to more common interfaces at the surface of various subsystems like clock, regulator, i2c, etc.

Maybe in x86 land this is saner, but in ARM SoC land, the drivers are often not that independent. Things need to happen across drivers in right order with right timing.

Not sure if that prevents these drivers to be implemented in rust, likely not, but the api surface is not small or simple, which was what I was trying to point out.

Likely these more tightly coupled drivers won't be the first target for Rust ports, but it's worth noting that Rust <-> C FFI is well supported and not as painful as you might expect.

"Does my GPU need to talk to my mouse"? That is definitely one of those "it depends on the system". On at least one DECStation model, sort of (depending on how you define "GPU"), the mouse interface is actually on the graphics card, and is read by the CPU talking to the graphics hardware.

When they're running the DEC-provided X11 server, the mouse pointer moving on screen is done entirely within the graphics subsystem, with no need to talk to the kernel. Which leads to the hilarity of wiggling the mouse actually not being a good diagnostic for "has the kernel hung itself", as the mouse pointer will wiggle (but clicking doing nothing, and usually not changing shape as you'd expect as it goes over fields where you'd expect that).

I'd be very curious if anyone knows what the Rust team's ambitions are for supporting the full set of Linux-supported platforms? Is this something they aspire toward? If so, how are they approaching it? Working with LLVM folks? Other backends (e.g., gcc)?

The rustc compiler uses LLVM, so whatever new architectures LLVM supports, rustc also gets. There are two projects going on right now - rustc_codegen_gcc which adds GCC as a rustc backend, and gcc-rs which adds a rust frontend to GCC. Both have seen considerable progress and support over the past year and are probably the most promising avenue to expanding the architectures that rust can compile to.

Not on the relevant team, but I can tell you what I've observed from the outside:

There's no specific goal to support every platform Linux supports. We have four tiers of support: 1-3, and then not supported in-tree. The project itself only moves things forward on a given platform if there are people championing that platform's support. If folks want to get Rust in more than just drivers and into the kernel proper, and platform support is an issue, then it's up to them to drive the platform support. For example, aarch64-unknown-linux-gnu only recently gained Tier 1 support, thanks to Arm themselves driving the effort.

For the details on what is supported today, and the process to expand that list: https://doc.rust-lang.org/stable/rustc/platform-support.html Here's an example of a contributor adding a new platform at tier 3: https://github.com/rust-lang/rust/pull/79608

Who wrote that? Why do you have confidence in it?

Reply on news.ycombinator.com