Strap in, get ready for more Rust drivers in Linux kernel

Rust is alive and well in the Linux kernel and is expected to translate into noticeable benefits shortly, though its integration with the largely C-oriented codebase still looks uneasy. In a hopeful coda to the recent maintainer drama that raised questions about the willingness of Linux maintainers to accommodate Rust code, …

[Richard 12]

Such awful interop

I'd really like to know why Rust chose such an objectively stupid syntax for binding to C.

It's deliberately impossible to include a C header directly. So a single source of truth is impossible!

It must be "manually created", thus creating a source of memory errors and an artificial barrier to the adoption of Rust.

Apparently, you can use an automated tool to rearrange the syntax - if true, that proves it's different purely for the sake of being different and provides nothing. Why not specify that the toolchain does that, and allow compile-time checks to exist?

There is a reason C++ uses "extern C". It allows the use of the actual C header, and thus memory errors can be spotted by the compiler. A C++ "wrapper" is optional, and provides actual semantics like lifetime management.

[Headley_Grange]

Re: Such awful interop

This is why I love the el Reg forum. I don't really understand this post other than "somebody could have made things easier/better (allegedly)" but I've added it to my RSS feed and look forward to a pleasant day reading some informative back and forth knowing that there won't be a load of name calling and other poor BTL behaviour. And I might even learn something.

[pikachu]

Re: Such awful interop

Like most reasons why Rust can't easily interop with C, it's because it would prevent the rust compiler from statically guaranteeing things. Just the #define keyword is already problematic because its untyped and that would put a hole in the Rust type-system.

There's many C-isms contained in header files that make it not possible to just be able to import them directly but tools like rust-bindgen exist to help.

[cyberdemon]

Re: Such awful interop

This argument reminds me a lot of the ravings of Lennart Poettering..

My way, though perhaps too convoluted for your tiny minds, is better by some metric of technical merit, therefore we shall do it my way, no matter how much pain, inconvenience and unintended consequences it causes for developers and users!

As you say, the rust-to-c bindings introduce lots of side channel problems, i.e. the potential for plain old-fashioned bugs, due to the increased complexity and lack of common API definition file, but we'll ignore all of that because memory safety is magical

Meanwhile the number of kernel developers who can mentally cope with the added complexity and heated arguments about it shrinks, and the project is weaker for it.

[pikachu]

Re: Such awful interop

Moving away from C/C++ is a big ask when they have been so central to the field of systems programming. This means that if there is gonna be a move away from them then it better be for a good reason. This is why Rust is getting all the buzz and not something like Zig, because Rust is willing to put its foot down where it is needed to make itself worth the trouble. I dunno what Lennart has to do with this, someone said "Why does X do Y when it is so terrible" then someone else interjects with "Because X would not work if it did not do Y". The only conclusion then is that Poettering is the sole purveyor of anything and all regarding "technical merit" which is a conclusion the typical register reader will probably find very pleasing and agreeable.

[big_D]

Re: Such awful interop

Moving away from horses and buggies is a big ask when they have been so central to the field of human transportation. This means that if there is gonna be a move towards internal combustion then it better be for a good reason.

[Gene Cash]

Re: Such awful interop

Yes... we had self-driving horses. Why did we give that up?

[sweh]

Re: Such awful interop

[clarkson]POWER![/clarkson]

[big_D]

Re: Such awful interop

My point exactly, I guess I should have used the /s at the end...

[bombastic bob]

Re: Such awful interop

I was gonna upvote you for the first line but a half a down 'cause of the rest.

Rust is NOT worth the extra pain (etc.) no matter HOW much foot-put-downing they do

It's like a bolt-on for your car engine that never addresses the REAL problem, like maybe needing a new set of spark plugs.

[Anonymous Coward]

Ok boomer

Boomer ok?

[martinusher]

Re: Such awful interop

The components cited in the article didn't sound very 'kernely' to me. Even a driver can be a combination of a low level driver proper plus higher level code that performs application and utility type functions.

Butt as I've remarked before, there's no point in trying to argue with someone who has a Messianic bent. Especially when you're old (and as one contributed remarked, the "horse and buggy" has to give way to the internal combustion engine for as every Angelino knows, if there's one thing better than a horse and buggy its a dozen lanes of choked up freeway traffic.....). But, just in case, I should ask those Rusty types if they actually know what a kernel is?

[bombastic bob]

Re: Such awful interop

This argument reminds me a lot of the ravings of Lennart Poettering..

My way, though perhaps too convoluted for your tiny minds, is better by some metric of technical merit, therefore we shall do it my way, no matter how much pain, inconvenience and unintended consequences it causes for developers and users!

snark appreciated!

[Anonymous Coward]

Perplexity disagrees with you

The quote "My way, though perhaps too convoluted for your tiny minds, is better by some metric of technical merit, therefore we shall do it my way, no matter how much pain, inconvenience and unintended consequences it causes for developers and users!" is widely attributed to Lennart Poettering in discussions about his approach to software development. However, there is no evidence in the provided search results or credible sources confirming that Poettering explicitly said this or something verbatim. Perplexity dot ai

[cyberdemon]

Perplexed

Clearly your AI failed to notice that this post was not a quote. (Note the absence of quotation marks...)

'Tis simply my impression of the man

[cyberdemon]

Re: Perplexed

Also what.. "Widely attributed to"???

Perplexity has clearly gone off its trolley if it thinks my one post this morning on the reg, making fun of Herr Poettering with a joke formed entirely in my own 'tiny mind' (and comparing him to a completely unrelated discussion no less), is "widely attributed" as something he actually said !

I think overuse of AI will someday be recognised in the same way as overuse of recreational drugs.. It might be fun for a while but it's really not good for you!

[Rich 2]

Re: Such awful interop

I don’t quite get this argument. #define is indeed untyped (because it’s a macro and the C predecessor/macro system doesn’t really have a concept of type.

However, given (for example)…

#define the_answer_to_everything (42)

…and then trying to use this to (say) initialise a string would be easily caught by the compiler (ANY compiler!). So while macros are the work of the devil, I don’t see why they can’t be dealt with sensibly and safely

By the way, I have nothing against Rust - I’ve never used it - I’m just not convinced by this particular argument

[Androgynous Cupboard]

Re: Such awful interop

#define something(a) ((void *)(((char *)a) + b))

I'm not a Rust guy. but the above (paraphrased from a grep from my /usr/include) looks like it's something a type-safe language might have issues with. No doubt there's nuance that hasn't made it through into this thread.

[Bent Metal]

Re: Such awful interop

Well, yes - but it's hard to see how that is a #define problem. The casts will be there in the source code either way; whether you directly write them or let the preprocessor substitute them in.

[Blazde]

Re: Such awful interop

The argument is that the only way to do this robustly is to bundle an existing C compiler with the Rust compiler, which is certainly doable and is what Zig does to 'natively' handle C headers, but it's enough effort to get that working seamlessly across different platforms (and the bindgen solution works well enough for now) that the desire is for a more 'proper' long-term approach than merely handling C headers. In particular a solution that includes interfacing with C++ (templates?), and one that interfaces in the other direction too, which probably needs coordination with C/C++ standards committees and various compilers. On top of that with various proposals to bolt memory safety on to C/C++ the Rust interop should eventually work well with that..

So C macros aren't the problem, but sort of the first worm that comes out of the can when you try to open it.

The relevant Rust goal proposal has regressed(/progressed) from 'Seamless C support' in 2024H2 to 'Evaluate approaches for seamless interop between C++ and Rust' in 2025H1. To give an idea where they're at: https://github.com/rust-lang/rust-project-goals/issues/253

[that one in the corner]

Re: Such awful interop

>> Just the #define keyword is already problematic because its untyped and that would put a hole in the Rust type-system.

Huh?

> The argument is that the only way to do this robustly is to bundle an existing C compiler with the Rust compiler

> So C macros aren't the problem, but sort of the first worm that comes out of the can when you try to open it.

No. C macros need not be a problem at all, if you don't want them to be.[1]

And you don't need to bundle a C compiler - you just need to "bundle" a copy of the C pre-processor. The cpp is a *lot* smaller than a full compiler and can easily be provided as a separate utility (in the Good Old Days your cpp was a separate executable to the compiler proper), or even within the Rust compiler itself. Although, of course, one could reasonably assume that if you are trying to feed C headers into Rust, in order to link with C code, you already *have* a full C compiler and can just invoke that cpp[2]

In the not too distant past I had to set my Makefiles to run a standalone cpp over all the C sources before handing them over to a particular compiler because *its* cpp (which was built into the compiler exe) was crap and fell over as soon as an expanded macro went over 255 characters, so running it over C headers before processing them with Rust, or any Rust-related tool, is a perfectly reasonable thing to do.

[1] which isn't to say that there aren't problems to be encountered in C headers, just that macros are a total red-herring.

[2] look for the command line options to cl (or lc); if nothing else it is useful to know how to just run the macro phase if you ever need to debug some of the weirder errors that can creep in to your C/C++ code.

[that one in the corner]

Re: Such awful interop

PS

Not that I'm actually suggesting that you *should* put cpp into Rust itself, just trying to point out that the argument presented about the macro language being typeless is a red-herring (and I forgot to mention that C/C++ gives you string typing and yet they are not bothered by the macro processor, because - that is a totally separate phase.

But if you have a utility for converting C headers into Rust, building cpp into that utility is - well, it is a necessity, the only way to actually make macro usage make sense.

[Blazde]

Re: Such awful interop

can easily be provided as a separate utility

Yea, this is what happens now (bindgen). But most people would like it to be more seamless and automatic if possible.

Interpreting a supposedly simple C header file can be dependent on both the compiler and the source files because they can #define things before the header is processed. You need a way to #define things in your Rust source. Ideally the right things automatically. Maybe you need to emulate autotools or something like that. Header files just don't neatly describe a self-contained cross-platform interface unfortunately, they need context. Anyone who's dealt with C libraries in a cross-platform situation knows how much of a massive pain in the ass this can all be even before you bring Rust into the equation. The simplest way of dealing with part of this is to use the C/C++ toolchains which already exist.

#defines being typeless isn't really the issue, it's that the types of your actual interface depend on the preprocessing.

[that one in the corner]

Re: Such awful interop

> But most people would like it to be more seamless and automatic if possible.

> they can #define things before the header is processed

Isn't that just a cae of copying the correct settings from the C portion of your Makefile/IDE settings across into the settings for your Rust portion? And after that it is just as automatic as you need as it is when building the C. The C/C++ toolchains aren't themselves magic - at best, they may provide a set of pre-defined macros (e.g. MYCOMPILER=1301 to identify the compiler family and version number). What these are can be found in the docs and/or by getting the compiler to dump them.

It is a bit irritating to dig out these definitions but it is a one-off - and only a very minor irritant compared to anything else when trying to get to grips with other differences in the actual languages.

> Anyone who's dealt with C libraries in a cross-platform situation knows how much of a massive pain in the ass this can all be even before you bring Rust into the equation.

I do a lot of cross-platform, and with multiple compilers on the platforms, builds - you just need a reasonably good build setup (I use Makefiles, with a half a dozen little utilities, so one build operation generates objects and executables for all the platforms in one go whilst I have a coffee). If you are at the stage where you are playing with combining Rust and C and you haven't bothered to find a half-decent build setup first[1] then you are just making a rod for your own back.[2]

[1] or, for some people, haven't bothered RTFMing about the IDE they are already using, mutter mutter!

[2] gawd, don't you hate a smug bastard!

[Blazde]

Re: Such awful interop

It is a bit irritating to dig out these definitions but it is a one-off

One-off per platform is not one-off. There are hundreds of target triplets, plus maybe bespoke configuration options for the specific code being interfaced. The desire is for that to work automatically (which it often does with bindgen currently if the C code is not too mad).

I don't know what to say other than take a look at the bindgen preprocessing issue list for a taste of the complexities: https://github.com/rust-lang/rust-bindgen/issues/2426

[bombastic bob]

Re: Such awful interop

various proposals to bolt memory safety on to C/C++

basically something to wrap around 'malloc' 'realloc' and 'free'. THIS is probably a better solution in the long run. I'd suggest start with a simple sub-allocator and go from there. I actuially started on one and stubbed it out with malloc/realloc/free but there's a framework for it at least. It would employ ref counts and report possible memory leaks and have some kind of optional pointer testing for debug code... 'ASSERT_POINTER_VALID' macro maybe, and calling 'free' equivalent would (in debug code) assign the pointer var to NULL to prevent use-after-free issues. Then when debugged you compile for release! also code coverage analysis with the compiler might be helpful, like 'unit test auto-generate' to be in a test build.

kernels often use linked lists of pre-allocated memory. The network stack is FULL of this kind of thing, with zero-copy buffers to speed things up. I do not know how "interoperable" Rust would be with THAT, but as networks get above 10Gbit you can NOT let the stack slow things down... just because, "Rust".

lots of things are possible WITHOUT "migrating lingos just because a bunch of youngin's are FEELing 'it's OUR turn now, get outa the way, grampa!!!'"

Arthur C. Clarke's "Superiority".

[Richard 12]

Re: Such awful interop

All things that C++ already has. Most of them since before Rust existed.

(I don't use modern C so don't know what's changed since C89)

[claimed]

Re: Such awful interop

Have you not read anything about how rust works? The type safety guarantees are done using logical inferences from some mostly simple rules which the compiler enforces, this makes the language a little more fiddely until you know why it’s doing things, but means everything compiles down to the same as efficient C code, with very little “stack getting in the way”. You’re thinking of Java, python etc, not Rust. The only example I can think of for stack overhead is smart pointers maintaining lists of who has a ref… so they can unwind the stack when no longer in use - you don’t have to use a smart pointer to do zero copy buffer stuff, just pass ownership of the buffer on, and you can certainly preallocate memory - so I don’t get the complaint.

The whole point of Rust is to be as close to safe as possible, with as little abstraction and runtime costs as possible. It’s specifically designed to prevent classes of bugs, by not breaking general rules, and if you want to optimize then you can. Also, if you want to write unsafe shit and put the ego on the line, go nuts. Literally no downside except learning a new thing, the trade off is amazing for what you get in return.

The borrow checker is the big one, but there are some other bits like not being able to alias a mutable reference (avoids multi threaded weirdness):

https://doc.rust-lang.org/nomicon/races.html

[Rich 2]

Re: Such awful interop

Re void* etc - You’re right. But what’s to stop the compiler making sense of that and throwing it out?

[JoeCool]

Re: Such awful interop

I would not accept that code in a C app.

I would not accept it in a C file

I would not accept it in a H file

I would instead recommend your a** be fired.

The point of using a common header format to share program definitions ("idl") has merit .

Abuse of the facility is not the use case for discarding the tool. Or maybe that is in fact the Rust approach to programming.

[Anonymous Coward]

Ok boomer

boomer,not ok?

[bombastic bob]

Re: Such awful interop

re-casting pointers makes certain kinds of structure handling ACTUALLY WORK. When you deal with devices you often have to deal with structures, sometimes variable length structures. Doing "type cast magic" is a simple and elegant way of extracting, let's say, a 4 byte integer from a variable length stream, for a low speed processor (let's say embedded controller running el cheapo arm core CPU at 100Mhz) that has to do a LOT of that kind of thing. A WiFi device or Access Point is a fine example. Done that sorta thing a LOT.

I wonder if it would even be POSSIBLE using Rust to do that...

Oh and those embedded devices often use Linux, so 100% relevant.

Thinking back in time, FORTRAN has something called EQUIVALENCE that can be mangled into something that works like a structure. I wonder how much mangling is done in Rust to make it do things that are BLISTERINGLY FAST and WELL SUITED to being done in C (but ugly and kludgy done in Rust).

[Blazde]

Re: Such awful interop

Doing "type cast magic" is a simple and elegant way of extracting, let's say, a 4 byte integer from a variable length stream

I wonder if it would even be POSSIBLE using Rust to do that...

fn next_four_bytes(stream: &[u8]) -> Option<[u8; 4]> {

stream.try_into().ok()

}

if let Some(be_four_bytes) = next_four_bytes(big_endian_stream) {

let four_byte_integer = u32::from_be_bytes(be_four_bytes);

// Do whatever with the integer

} else {

// End of stream

}

Safe, efficient. No magic required.

[JoeCool]

Re: Such awful interop

AND C++ provides type-safe casts that allows the compiler to enforce safety.

[Richard 12]

Re: Such awful interop

But it doesn't. At all!

The "Rust" edition of a C header contains absolutely nothing whatsoever that didn't already exist in the C header.

So you gain nothing, except the certainty of errors.

[tracker1]

Re: Such awful interop

A C header doesn't tell you who is responsible for allocation or deallocation.

[that one in the corner]

Re: Such awful interop

Well, a C header file is just[1] a series of type and function declarations.

Responsibility for allocation and deallocation (aka ownership) only makes sense for instances of a type. As is shown in the Rust docs for Defining and Instantiating Structs: the struct is just a declaration and the allocations are made within the example functions they show, and ownership of the instance passes from variable to variable via the assignment/move operation.

[1] ok, there is no actual, solid, definition of what a "header" file is - some people call any old file that happens to be the target of a #include cpp statement "a header file" even though you can, of course, put absolutely anything you feel like into included files - just so long as the final compilation unit is syntactically ok. For example, something like the SQLite "bundle" C file can be created by #include'ing all the dot-c files one after another into a single compilation unit (which has its pros and cons) *or* you can just compile each dot-c on its own and pull it together in the link phase. So here I'll stick to a well-behaved header, and ignore that Naughty People can put all sorts of crap in there as well, such as putting in a line "static int fred" and causing every compilation unit to suddenly have an instance of "int" called "fred".

[Richard 12]

Re: Such awful interop

And neither does Rust interop.

[O'Reg Inalsin]

Re: Such awful interop

It must be "manually created", thus creating a source of memory errors and an artificial barrier to the adoption of Rust ... Apparently, you can use an automated tool to rearrange the syntax Thanks for correcting yourself, and still leaving enough flame to warm the coldest hearts.

[Phil Lord]

Re: Such awful interop

When Rust was written syntactic interoperabilty with C wasn't an objective, and it doesn't have it. So the declaration of C function headers in Rust looks like Rust code not C.

However, it is a purely syntactic transformation. It has long since been automated with bindgen. And since it has now been automated, it is possible to do at build time, using a build script. Or, you can do it at compile time with a macro. You can do it manually if you want, but this only makes sense if, for example, you want to bind to only one or two C functions.

It is not different for the sake of it. It is different because it is easier to use the same syntax as Rust in the first instance and then automate it over time. Eventually, they might push bindgen directly into the compiler and have it as a keyword like with zig, but the advantages over what we have now are not that great.

[abend0c4]

look forward to a pleasant day reading some informative back and forth

One of the reasons I enjoy these forums is that I will often be prompted to go off and research something I didn't know much about, or to reflect on something I hadn't really thought about.

I'm not a Rust expert, but there is a tool, bindgen for Rust that automates the process of generating bindings for C code, though you may have to compile a list of the header files you want to feed to it. It seems reasonable to me that you'd use a separate tool for this purpose in Rust which has no notion of C syntax - whereas the C++ compiler already has most of what it needs.

Of course, if you're really worried about simplicity, you'd question the very existence of C header files - after all, it's not great to have to keep two separate files in sync with essentially the same information. But we seem to apply a different standard to things we're familiar with.

[Brewster's Angle Grinder]

STL

C++ reached the same conclusion. But decided to get rid of the source file and leave only the headers...

^{Separating the interface from the implementation is not unique to C/C++, and is generally good practice. C++ will check the two files match.}

[that one in the corner]

> though you may have to compile a list of the header files you want to feed to it

Which is why we have makefiles.

It doesn't matter that you need one, two or ten utilities to massage a header from one format to another, so long as those transforms are reliable, accurate and can be managed by your build system (which is under source control, like everything else).

Personally, I like having interface structure definitions in yet.another.text.format and using *that* to generate the C include files as well as the files for whatever the C is talking to - and at the same time, C/whatever functions to print the structures in human readable form, pretty diagrams for the documentation (by spitting out inputs for Mermaid or other diagram drawing tools) etc.

That way, *everybody* is equally pissed off at writing "those stupid weird definition files, why can't I just use (native language format)?". To which the reply is "You can, but *you* are then responsible for keeping everything else up to date and the machines *will* email every time one of them needs to be updated (aint Make calls to blat wonderful?)".

[Jaybus]

No header files?

How would dynamically linked libraries be used without header files? If only source files were used, then all builds would be static. I don't know if that could be considered a step forward.

[stiine]

Re: No header files?

Yes, but they would conceivably increase your compile time to weeks.

[Richard 12]

Re: No header files?

Static is the Rust way. It doesn't do dynamic linking, except via C interop.

[Brewster's Angle Grinder]

The great wheel of trends has turned again...

You've not been paying attention to modern trends: DLL hell is out; static is in vogue (with whole app optimisation). You'll need to wait a few years for that position to flip.

[abend0c4]

Re: No header files?

This is an excellent example of why I mentioned the chance to reflect on something I hadn't really thought about.

Even if you use header files, you can still choose between dynamic or static linking. C's header files arise partly from its origins as a one-pass compiler and partly as a way to share function signatures without having to share the implementation. Other languages can determine the signatures of exported functions from syntax in the source file and create the necessary glue automatically for other compilation units to link dynamically. And of course C header files bury in macros a great deal of historical cross-platform complexity that other languages have not yet accumulated - and are designed to avoid.

So, header files have come to solve a number of problems in C, but other design choices were available. However, it's hard to argue with the longevity of the choices that were made.

[Anonymous Coward]

> I'm not a Rust expert, but there is a tool, bindgen for Rust that automates the process of generating bindings for C code

Many people aren't. Luckily Rust isn't that unique and its flaws mirror that of many other languages. For example, most languages that aren't C based provide bindings generators. i.e SWIG and bindgen are the same things. They work up to around 75% but fail at non-opaque interfaces and complex C MACROs which... is actually a fair amount of C code in the wild! And then maintaining the code that gets churned out is another problem.

> you'd question the very existence of C header files - after all, it's not great to have to keep two separate files in sync with essentially the same information. But we seem to apply a different standard to things we're familiar with.

Headers solve the issue of needing to load everything into memory and linking it all atomically. This is why Rust struggles to build on weaker platforms such as i386 or future lightweight ASIC+AI chips. Also, correctly written headers should *not* be duplicating the same information as the .c and .cpp counterparts. Older versions of the C standard was more stict. It would error on "duplicate typedefs" for example.

Luckily in around 5 years, the Rust developers will bolt on a simple C frontend and many of these problems will be solved.

[dangerous race]

Beware geeks bearing gifts

I can't code my out of a paper bag and I've no idea if Rust in the Linux kernel is a good or bad thing. But, and it's a big but, when Microsoft have a hand in 'doing something for Linux' I hear Klaxons and red lights start flashing. MS has form when confronted by competition. Even if the MS coder, or whomever, working on a project doesn't realise it, there maybe an underlying objective to cause problems for the project. Cynical? Moi?

Is Rust used in that paragon of reliability and security Windows?

[A Non e-mouse]

Re: Beware geeks bearing gifts

Today's Microsoft isn't the same as the one from the Steve Balmer era.

I'm not trying to say it's all roses now with Redmond, but it's less hostile to the outside world.

[Rich 2]

Re: Beware geeks bearing gifts

“ …but it's less hostile to the outside world.”

Good point. MS have cut out the middle man and are directly hostile to their poor users now

[Blazde]

Re: Beware geeks bearing gifts

Is Rust used in that paragon of reliability and security Windows?

Little bits yes. If you have a Win11 machine go look for $Env:windir\system32\win32kbase_rs.sys

(I'm not sure whether this is the only bit that's made it into release or not - they're definitely working on other bits - but it's easy to see evidence of Rust in the kernel). They're targetting rewrites of very old messy code that's most likely to have critical bugs in.

[dangerous race]

Re: Beware geeks bearing gifts

"If you have a Win11 machine . . . " - splutter, I don't even like having Windows machines in the house! :-)

[Anonymous Coward]

> and is expected to translate into noticeable benefits shortly

Won't happen. Not in our lifetime.

Filling the Linux kernel with rotting bindings is not useful.

[Bartholomew]

past, now, future

In the not so distant past the Linux kernel was 99.9% C code (There is some assembly language for various architectures for various reasons), and most developers only needed to know C.

Now key people in the kernel validation and approval process need to know C and Rust.

At some stage in the, not so distant, future - at the current rate of assimilation by Rust developers the whole kernel will be refactored and be 99.9% Rust. And most kernel developers will only need to know Rust (until something better comes along, and this process is repeated).

In my mind, would it not have been faster and simpler for Rust developers to just create their own super memory safe OS from scratch in Rust (well 99.9% Rust, I'm sure that there would be some assembly required), that has a Rust based kernel, a Rust based bootloader and Rust based userspace applications. And because it was so much safer than Linux it would be the OS of choice by everyone who cared about security. Although even a 100% memory safe OS would do nothing to prevent human stupidly and basic social engineering (or memory security being bypassed from "custom" ME/PSP code).

[pikachu]

Re: past, now, future

It does exist, it's called redox and you can boot into it. Not yet ready for actual use though.

[G40]

Re: past, now, future

shame it (Redox( does not have enough cheerleaders.

[Anonymous Coward]

Re: past, now, future

Hopefully, Bartholomew will now become a Redox cheerleader.

[Rich 2]

Progress

With all this work being done with Rust in Linux, I’d be interested to see how many memory bugs they have found in the original C code that they have now eliminated through using Rust.

Bueller?

[Anonymous Coward]

Re: Progress

None. They are still writing bindings and have not replaced any C code.

[Someone Else]

Smallpox, eh?

It can be relegated to the past like smallpox, we just have to do the work."

I will (likely) comment elsewhere about the pure hubris of such a statement, but my point here is that measles (and polio) were once thought to have been "relegated to the past". And then we found RFK, Jr. and his merry band of anti-vaxxers (and no, I'm not talking about the DEC computer, either). So relegating something "to the past" is proving not to be as straightforward as one may have you believe.

_{And how may COBOL programmers are still out there, creating new programs with that antediluvian language?}

[Anonymous Coward]

Re: Smallpox, eh?

How much reasearch have you reviewed on Vaccines? Why are unvaccinated childern "unusually" healthy? Why are epidemic trends nearly always already falling at vaccine introduction? How much money is made from vaccines and all the problems that appear correlated with them? Why were the rich and powerful exempted from a certain one? Why if you travelled on a private jet was there no testing to enter countries and I can tell you from experience if you went to certain very exclusive eateries you did not need any precautions and neither did the staff. Please wake up, our governments and state institutions are not run by the fluffy, nice caring and altruistic people that they claim to be.

[Andrew Scott]

Re: Smallpox, eh?

Sure like my dad was "Unusually healthy" right up until he got polio! Jesus! Not look at those "unusually healthy" children in west Texas. Maybe you should use the "unusually healthy" children and adults in 1918-1919. My grandmother lived through that.

[Henry Wertz 1]

It's like very pedantic C

For those who haven't worked with Rust, I know the Rust fans will say this is an oversimplification, and it is, but it's like a very pedantic C. If your code doesn't follow best practices, it will throw compiler errors. Instead of catching memory errors at runtime (or not at all and you have some memory safety issues in your code, unsafe use of locks for concurrent variable access, switch or "if/then/else" statements where every possibility is not covered...) it's caught at compile time. It doesn't have an "#include" to include C headers because... it's not C. So some script generates Rust bindings instead.

I found *writing* new Rust code to be a PITA. But going through existing code, it parsed very much like C, and a C programmer should not have much trouble looking through Rust and seeing what it's doing, and indeed finding and fixing bugs if they know what the code is supposed to be doing.

I'm not a Rust fan or anything, but honestly including a few new drivers in the kernel in Rust is much ado about nothing. It's not increasing the burden on existing devs, it's not like they're throwing Fortran or Java or something in there where the programming model is radically different.

[Proton_badger]

Re: It's like very pedantic C

Yeah, it should be manageable. Changes to interfaces mean people need to be able to communicate and collaborate, which is already the case without Rust.

Aside: In Microsoft they now work with Rust in everything from the NT kernel, to Windows middleware libraries and for new stuff over in Azure. They did a survey and the general consensus was that Rust was considered annoying for the first few months but at some point it "clicked" and the devs began really enjoying it and writing code that compiled easily and they then spent much less time debugging because a whole class of issues were not there.

It's interesting because this is a real world large scale use case. Google had similar experiences, a survey given to 1000 of their Rust developers in 2023 showed that most felt confident within 1-2 months. Google also found, like you, that it was easy to review the code.

[Fruit and Nutcase]

Re: It's like very pedantic C

Having appropriate/as specialised IDE support can help the adoption. Would help if tools/plugins are developed (if not as already done) to support kernel and driver development in Rust.

And then have some sessions to show how they are used. Not videos, but have some real sessions and interact with them.

[Anonymous Coward]

To a coding novice with close to zero knwoledge of either C++ (Ok a tiny bit many years ago) or Rust, this sounds like 2 religions fighting. Surely, this comes down to a guessing game of what will be the prevalent language in the future, as both seem to have pros and cons. You don't want Linux to be the next mainframe with too few developers and maintainers. I'm sure Cobol adherents thought it would never be a problem getting skills. So maybe the energy would be better spent working out how to efficiently & safely integrate Rust use if there are a lot of supporters AND it looks like being a good and popular language in its own right.

[nijam]

> ... and is expected to translate into noticeable benefits shortly...

...and is hoped to translate into occasional benefits eventually...

FTFY

[Fido]

Somehow the disadvantages of having two distinct programming languages in a single code base has to be outweighed by one of them being Rust. Having to maintain separate bindings for each language and synchronise them by hand sounds more error prone to me than the danger C code in production for more than a decade possesses a hidden use after free, bounds error or null pointer dereferences. At the same time, I'd get very excited to see a nontrivial GPU, network or USB device driver written in Rust that avoids the unsafe keyword.

A year ago there was a US government directive to stop using C and switch to memory safe languages for essentially everything. While the directive looks as well thought out as the long since abandoned idea of using ADA for everything, it's possible adding Rust to the Linux kernel is based primarily on the need to demonstrate progress being made towards use of memory safe programming practices.

Such a benefit, though nontechnical in nature, could be enough to offset the interoperability and maintenance disadvantages of two languages in the same project.

The same considerations could be the main motivation behind both Microsoft's and Google's reported progress on the adoption of Rust.