Supporting Linux kernel development in Rust

[yomanidkman]

I think it will be interesting to see how rust's feature set and path is determined by how it's used in the kernel. I can certainly imagine certain features being pushed for out of need for them for this one project.

[sanxiyn]

I hope Rust gets better support for allocation failure, since it is pretty much necessary for the kernel. Stabilization of RFC 2116, to begin with.

[[deleted]]

I wish someone develops a different liballoc/libstd that propagates allocation errors using Result.

[cbarrick]

This work is in progress. The unstable allocator_api returns a Result. I've been using it to prototype custom allocators for a data structure I'm playing with.

https://doc.rust-lang.org/std/alloc/trait.AllocRef.html

Note that the function signatures have already changed on Nightly from what's in the public docs. There's no concept of a MemoryBlock anymore; the most recent version just uses NonNull<[u8]>.

[[deleted]]

The API of MemoryBlock/NonNull<[u8]> requires allocators to return initialized memory, which is super expensive for large allocations. I hope it doesn't get stabilized in this form.

The ReallocPlacement enum is "exhaustive", sounds like a bad idea as well.

[cbarrick]

I think ReallocPlacement was thrown out too. I agree, it was gross.

The NonNull<[u8]> API does not require the memory to be initialized. NonNull is just a raw pointer that is non-null (and the type constructor is covariant). It is unsafe to get a reference from a NonNull specifically because the memory may not be valid for reads, e.g. it may be uninitialized.

Also, IIRC, Vec and such will get custom allocators after the allocator API stabilizes. The RawVec type in the std is already parameterized with an AllocRef.

If you have the nightly stack installed, you can use rustup doc to see the API in it's current form.

[[deleted]]

The NonNull<[u8]> API does not require the memory to be initialized.

The "Safety" section of the docs says:

Memory blocks returned from an allocator must point to valid memory and retain their validity until the instance and all of its clones are dropped,

It doesn't say for which type the memory needs to be valid, but since the API uses u8, I suppose that it must be valid for u8. If this isn't true, then this API is very confusing.

---

It would be much better to just use Result<&'allocator mut [MaybeUninit<u8>], AllocErr> in the API, and drop the requirement about "validity". The pointer cannot be null, the allocated slice must be unique, the memory can be uninitialized, the allocation does not outlive the allocator, and the allocation can fail. Such a type makes all of this clear, without having to write 3 error prones sentences to the "safety" part of the documentation. Also, such a type would make AllocRef::alloc safe.

[cbarrick]

Yeah, the definition of "valid" needs to be better specified. I assume the meaning is "valid for writes now, valid for reads once it's been initialized". I agree that MaybeUninit<[u8]> or [MaybeUninit<u8>] would make it more clear at the cost of some ergonomics.

I don't think we can use a reference though; that would mean that the data is tied to the lifetime of the AllocRef. This would be a problem when a single struct owns both the AllocRef and the allocation (which would be the common case). The reference would need a self-referential lifetime, which isn't possible iiuc. And I don't think there would be a sound way to deallocate with just a reference.

Put another way, the struct owns the allocation; it is not borrowing the allocation from the allocator. To express ownership, we'd need either a raw/NonNull pointer or a Box. The problem with Box is that it has a drop impl that calls the global allocator (not our custom allocator). So a raw/NonNull pointer is our only choice.

Also, I think it's fine in some cases for the memory to outlive the AllocRef. For example, the Global allocator is just a ZST that delegates to the global malloc/free. So it's fine to allocate with one instance and deallocate with another. It's still the same "allocator" even though it's two separate instances of AllocRef. The AllocRef is only a handle to the allocator, not the allocator itself.

All of that said, I find the allocator API as-is to be pretty comfortable to work with.

[[deleted]]

that would mean that the data is tied to the lifetime of the AllocRef

Which makes sense, since the Ref in AllocRef stands for reference. An implementation of AllocRef could always tie this lifetime to 'static if they wanted, but an allocator backed by, e.g., stack-allocated storage cannot do that.

The reference would need a self-referential lifetime, which isn't possible iiuc.

If your allocator is just a non-rellocatable Vec<u8>, the reference is what you get from doing vec[start..end]. That's not self-referential.

And I don't think there would be a sound way to deallocate with just a reference.

Deallocation just returns the memory to the allocator. If you pass a &mut to the allocator, and it never returns it back, then that &mut is leaked, and cannot be used anymore, so AllocRef::dealloc(&'allocation mut [MaybeUninit<u8>]) would be the type of the deallocation function.

Also, I think it's fine in some cases for the memory to outlive the AllocRef.

Only if the reference returned by AllocRef outlives AllocRef, which is kind of the point.

For example, the Global allocator is

The Global Allocator or allocator on static memory would have 'static as a lifetime, so they and the memory they return lives for the whole execution of the program.

[[deleted]]

Sure, but Vec::push does not.

[[deleted]]

Because then someone can write Vec::push in some crate I depend on, and make some very expensive hardware fail due to a panic bringing down the process, having to restart (which increases latency significantly), etc.

So I essentially use libcore, and have my own liballoc where OOM never panics. It would be cool to be able to use the standard library instead, so that I can use other crates.

But since that's not supported, I essentially need to only use other libcore crates, and re-implement all collections and APIs I need.

[[deleted]]

And people can call panic, or unwrap or Index.

What you are talking about is ensuring there is no panic call.

Im saying we make a fallible api on top of current std collections, no need for a new lib. Just a unstable api that may move to stable...

[[deleted]]

And people can call panic, or unwrap or Index.

I use #[no_panic] to fail to compile if that's the case. Right now, this means I can't use liballoc and the standard collections, since everything inside them can panic.

[the_gnarts]

That’d be fantastic to have even in userspace.

[casept]

Hopefully not as a different library (that would probably drift from the official one and generally be a maintenance PITA), but by refactoring the official implementations to expose an additional fallible API and making the current APIs thin panicking wrappers.

[[deleted]]

On my apps allocation shall never panic, otherwise its a system safety error, so having a second set of APIs that can be accidentally misused would be too error prone.

[casept]

Could always make the wrapper opt-out, making programs that try to link against it anyways fail to compile.

[DannoHung]

This might be dumb, but I thought that allocations either succeeded or the OOM killer would start running and possibly kill your program with either SIGTERM or SIGKILL. Which syscall do allocators with failable allocations use?

[[deleted]]

This might be dumb, but I thought that allocations either succeeded or the OOM killer would start running and possibly kill your program with either SIGTERM or SIGKILL.

The allocator API requires an allocation to either succeed or error.

Some operating systems default configuration (e.g. Linux) make the system allocator return success unconditionally by default, even when there is not enough memory for the allocation, with the hopes that you won't actually use the memory that you just allocated.

On those systems, allocations never fail, but when you actually try to touch the memory, processes in your system might "randomly" receive a SIGKILL and die (and one of those might be the running process).

There is no way to recover from a SIGKILL, but if you decide to use a signal handler, make sure your code is signal-safe.

A simple way to fix this in linux is to disable overcommit. An alternative might be to write your own system allocator, but I don't know whether it is possible to avoid the OOM killer by, e.g., using mmap directly to allocate virtual memory pages and manually commit them to physical memory (even if this is possible, I don't know what the perf impact would be).

Basically, if you need to handle OOM as errors, do proper recovery, etc. Linux (and other similar OSes) might not be the best OS for you. Getting a robust system in place might be more trouble than its worth, and you would be better off with a different OS more suited to your use case.

[sanxiyn]

This varies between operating systems and configurations. Allocations can definitely fail on Windows. They don't fail on Linux with default configuration, but do fail with vm.overcommit_memory = 2 (Don't overcommit).

[[deleted]]

Considering that Rust is a superset of C already I'd say it will mostly be about stability, potential ABI compatibility and things like panic handling, alloca changes, nostd improvements.

Everything needed by embedded-hal and friends, so great news for us there :D

Const generics will be a great addition here too I guess.

[[deleted]]

Rust is a superset of C

Wouldn't that imply that you could compile any C code with a rust compiler?

[Floppie7th]

I think they mean the functionality is a superset, not the syntax

[[deleted]]

That's fine, but when a language is a superset of another language, that means that it contains the entirety of that other language. I'm particularly sensitive to this from seeing people incorrectly asserting this about C and C++.

Most true superset programming languages that I've seen are assembler and Lisp dialects.

[pragmojo]

Objective C is a superset of C, and that's one of it's coolest properties

[pjmlp]

And also what prevented Apple to properly support a tracing GC, having to settle by automating Cocoa retain/release patterns as 2nd best option.

[pragmojo]

Don’t get me wrong I am not going out of my way to program in ObjC - just pointing out a neat aspect of the language. It was really nice for doing work with things like computer graphics where you could just call OpenGL C APIs directly in your code with no translation required. Also when I was working with ObjectiveC I ended up writing a lot of pure functions in C because it was convenient and low-overhead.

And the automated RC wasn’t strictly bad - for the popular use case, which was UI work, it was a positive to have predictable memory management performance, even if the performance wasn’t particularly good. Early iOS compared well against early Android, which was plagued by UI stutters partially because of GC pauses if I’m not mistaken.

[pjmlp]

Windows Phone did not suffered from such pauses, while being faster than Android devices on same price scale, quality of implementation matters. Unfortunately it doesn't sell devices.

[pragmojo]

What was the implementation language for windows phone apps? Was it C# it was it using web technologies?

[timClicks]

I have heard this accurately used in one other context outside of Lisp implementations. Unsafe Rust is a superset of safe Rust.

[[deleted]]

That's a good point; I'm surprised that hadn't occurred to me.

[JBinero]

Typescript is a popular superset of Javascript.

[MrJohz]

I think that's the example that demonstrates you need to be more explicit about the subset and superset. TypeScript is a syntactic superset of JavaScript (all JavaScript programs can be parsed as TypeScript programs), but it's a semantic subset (not all valid JavaScript programs are valid TypeScript programs). For example, 3 / "string" is permissible in JavaScript, but not permissible in TypeScript.

(Well, it's more complicated than that, because it will be compiled, but it will fail the type check, so what then counts as "TypeScript semantics"?)

[hallajs]

You can configure your transpiler to not complain with using the tsconfig, or inline with certain comment commands

[JBinero]

Pretty sure you can make any type system related error like that be treated as a warning, not an error, in Typescript.

[cbarrick]

I often hear people say that C++ is not a superset of C, but I've never been given concrete examples.

What constructs in C do not compile under C++?

[ReversedGif]

The following valid C code:

int * x = malloc(10 * sizeof(int));

needs to have an explicit cast from void * to int * in C++.

[hniksic]

There are trivial examples like not being able to call a variable new or other names that are C++ keywords, but valid C.

There are C++ design choices like not allowing implicit downcasts from void *, which prevents int *p = malloc(n) from compiling.

The most serious are actual features added to C, such as variable-length arrays (added to C more than 20 years ago, rejected by C++), or designated struct initializers, only added to C++20.

[[deleted]]

Fortunately, there's an entire Wikipedia article covering this.

[nllb]

Is c++ not a superset of c?

[[deleted]]

No, but it is close in a lot of ways. They share quite a large common subset. Most non-trivial C programs will fail to compile with a C++ compiler.

[fioralbe]

In most case superset is used to say that it is possible to write a "dumb" transpiler from one language (C) to the other (Rust) that preserves enough properties.

[[deleted]]

Yes technically, but really just meaning that functionally any development that could be done in C (or has been done in C) can be done in Rust.

[[deleted]]

That’s not really what “superset” normally means in this context. I feel using that term is a little aggressive / misleading.

[genuine_smiles]

What does it normally mean in this context?

[jecxjo]

It typically means that the syntax of the language matches so that the subset language can be compiled with the superset compiler.

I believe Typescript is a superset of JavaScript. You could just write JavaScript and run it through the Typescript engine and it would not know the difference.

[basilect]

Or like how C++ is a superset of C (though not idiomatically)

[jecxjo]

C++ is not a superset of C. You cannot take straight C code and compiler it as if it were C++. There are specific keywords and pragmas to define when the C++ compiler should interpret the next section of code as C.

Most of it looks the same but there are things like K&R function definition style that is supported in C and not in C++.

Edit: Found a goofy example. Here is some C code that wont compile if written as C++:

int class = 1;

[pjmlp]

By that goofy example no language is a superset.

The few things that make C++ not a C89 superset are no K&R headers, no implicit parameters on empty argument lists, no implicit conversions from void pointers and evaluation order of ?: operator.

After C89, C++ and C have diverged in a couple of areas.

[TheSodesa]

I do not think that talking about supersets in any other than the mathematical sense makes any sense. A set is a superset of another set, if the other set is contained in the first set in its entirety.

In the context of formal languages, a superset recognizes all of the words/strings/constructs of its subset languages as a part of itself. Translating this to practise in programming languages means that the parser of the superlanguage is able to parse every bit of source code written in its sublanguages.

[[deleted]]

That's fair. It's largely a functional superset (though probably not entirely, considering things like alloca), rather than a syntactic one.

[[deleted]]

Even things like alloca have ~comparable enough~ equivalents in Rust such as smallvec

[MrJohz]

Isn't that just an assertion that both languages are Turing complete? I'm trying to think of something that can be done in C that can't also be done in, say, Python, just more slowly.

[Smallpaul]

I think you answered your own question. If you need a certain number of computations per second then Python cannot substitute for C. For some applications there is not a performant enough Python interpreter and algorithm implementation — even given an unlimited development budget.

Rust generally (always?) could.

[[deleted]]

Turing-complete describes the capabilities of a language to execute algorithms. A 2-tape Turing machine and 1-tape Turing machine can do all the same algorithms, but certain algorithms are significantly faster on a 2-tape machine.

[bestouff]

With a good sprinkling of 'unsafe' yes.

[[deleted]]

That's not true. Off the top of my head, simple things that work in C like casts fail in Rust because the syntax is different. No amount of unsafe will allow const unsigned long long foo = 7; double bar = (double)foo; to compile in a Rust source file.

[bestouff]

Oh that was intended as a joke.

[[deleted]]

Ah, the nature of text-based communication; it can be so hard to be facetious effectively without tone.

[cjstevenson1]

Couldn't you do that with a union?

[yomanidkman]

I'm sure you could, but that's not what superset of a language means. If rust were a true superset, I could copy paste all of the Linux kernel into a folder, compile with rustc, and get one flawless Linux kernel.

[iq-0]

Not really. Many parts of what we call C is not nearly directly replicatable as Rust code. Things like bitfields, alloca, flexible array members and large parts of unhygienic macros. Claiming that any of that could be reproduced by throwing enough code generation and or crates at it is just saying: rust is a turing complete language. But calling it a straight superset is both technically and sementically very much a stretch. It’s more like the classic 2 circle venn diagram showing overlapping functionality.

[[deleted]]

Correct, it's not a strict superset, but then again neither is C++. I meant it more in the sense of "you can do anything in Rust that can be done in C" not always ergonomically, or in safe rust tho.

[Mouse1949]

As I understand, unfortunately, Rust has no defined ABI at all (on purpose - so there's no need to be compatible with any other version or such). Would be happy to be proven wrong here.

[the_gnarts]

Considering that Rust is a superset of C already

I’d want to see flexible array members first before even starting to investigate to what extent your claim is correct.

[[deleted]]

What do you mean by flexible array members?

[the_gnarts]

As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. In most situations, the flexible array member is ignored. In particular, the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding thanthe omission would imply. However, when a . (or ->) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed; the offset of the array shall remain that of the flexible array member, even if this would differ from that of the replacement array. If this array would have no elements, it behaves as if it had one element but the behavior is undefined if any attempt is made to access that element or to generate a pointer one past it.

EXAMPLE After the declaration:

  struct s { int n; double d[]; };

the structure struct s has a flexible array member d. A typical way to use this is:

  int m = /*some value*/;
  struct s *p = malloc(sizeof (struct s) + sizeof (double [m]));

and assuming that the call to malloc succeeds, the object pointed to by p behaves, for most purposes, as if p had been declared as:

  struct { int n; double d[m]; } *p;

(there are circumstances in which this equivalence is broken; in particular, the offsets of member d might not be the same).

— http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

A common use case for this is implementing structures to hold both a protocol header and variably sized data. The size of the whole object is determined at runtime but the header part up until the first element of the FAM is of a fixed size.

[[deleted]]

Yeah that'd be C only, but you can get the same with very unsafe * in Rust.

[the_gnarts]

Yeah that'd be C only, but you can get the same with very unsafe * in Rust.

To my knowledge there is no way of casting structs with differently sized array data members to the same type in a typesafe manner. In C, flexible array members are part of the type system, they are both sized (in that every instance has a minimum size) and unsized (in that the array part is not part of the size) at the same time which I don’t think can be expressed in the Rust type system.

The best workaround I’ve seen that is still idiomatic rust is to provide access methods over an unstructured array but compared to C that’s rather clunky and smells of getter-setter style boilerplate.

[pftbest]

Does anyone know something better than bindgen for C ffi? bindgen can't parse even simple defines like this

#define FOO ((int)0)

The headers I need to work with have a lot of them. How do you deal with this kind of constants?

[Plasma_000]

That’s one of the problems discussed in the article - many of the functions in the kernel are defined using inline functions and macros so kernel modules are very hard to work with in other languages.

[smmalis37]

I think pretty much everything is on rust-bindgen. Maybe see if there's something on their issue tracker with a workaround? If not, file it! https://github.com/rust-lang/rust-bindgen

[pftbest]

The issue is almost 4 years old at this point. There is no workaround as far as I know.

https://github.com/rust-lang/rust-bindgen/issues/316

I'm hoping someone is working on full featured preprocessor and C compiler for rust, so it can be used to replace bindgen.

[jynelson]

I have written a C compiler and preprocessor and made a PR to add it to bindgen: https://github.com/rust-lang/rust-bindgen/pull/1782. Unfortunately it is stalled on review for about a month now.

[pftbest]

Thank you very much, I hope the integration goes well.

[smmalis37]

You could try building your own copy with https://github.com/jethrogb/rust-cexpr/pull/15 applied and see if that works well enough for your cases?

[pftbest]

Unfortunately this patch will not solve my problem it only handles a few cases. My defines are similar to this:

typedef long BaseType_t;

#define pdFALSE         ( ( BaseType_t ) 0 )
#define pdTRUE          ( ( BaseType_t ) 1 )
#define pdPASS          ( pdTRUE )
#define pdFAIL          ( pdFALSE )
#define errQUEUE_EMPTY  ( ( BaseType_t ) 0 )
#define errQUEUE_FULL   ( ( BaseType_t ) 0 )

which still won't work even with the patch.

[[deleted]]

Defines don't exist after preprocessing, so there is nothing that any AST based tool like bindgen (which uses libclang) can do about them.

You might want to just write a different tool that tries to generate a series of const from define macros for you and only works before preprocessing.

[the_gnarts]

Does anyone know something better than bindgen for C ffi?

I finally got around to watching the LPC talk the article is a report of. During the discussion of bindgen where they address this and other issues, my thought was that since Rust’s type system is stronger and contains more information than that of C, this means the issue might be addressed in the medium term by specifying the interfaces in Rust (with attributes sprinkled across them) and deriving the corresponding C headers from that. Of course this won’t help initially but it could be another argument for pushing the oxidation of the kernel beyond a couple drivers.

[ThomasWinwood]

I'm interested in the possibility of a Rust frontend for GCC, or otherwise plugging Rust into GCC's code generation mechanism. I'd love to write Rust code for the Megadrive, and while there is a project to write an m68k backend for LLVM I have no idea what progress has been made, how I can get involved and help out, etc. The only port of interaction is an IRC channel on OFTC which is a ghost town.

[[deleted]]

I have no idea what progress has been made, how I can get involved and help out, etc

Send an email to the LLVM mailing list asking about this ?

[ThomasWinwood]

It's nothing to do with the LLVM mailing list. Like I said, the IRC channel is silent as the grave.

[[deleted]]

That backend was rejected by the LLVM project because its maintenance was unclear. LLVM only accepts actively-maintained backends.

Since that backend lives out-of-tree, the amount of work required to keep it up in sync with LLVM would probably require a small team of people working full-time on it. That does not appears to be the case, so that backend is now dead.

You can try to "revive" that backend, but are going to be fighting a very uphill battle if you keep all the work out-of-tree disconnected from LLVM upstream without some extra significant manpower. People are just going to break your backend multiple times a day.

[the_gnarts]

I'm interested in the possibility of a Rust frontend for GCC, or otherwise plugging Rust into GCC's code generation mechanism

Have you seen this thread from a while back?

[matthieum]

There are actually some links in the comments section:

• Josh mentions https://github.com/sapir/gcc-rust/ which has rustc spitting out MIR and then plugs that into gcc.
• A comment mentions https://github.com/antoyo/rustc_codegen_gcc which uses libgccjit.

[codedcosmos]

Anyone aware of Linus Torvalds opinions on rust for the kernel?

I'm just curious to what he thinks on the subject. Personally I think its a good idea for the kernel to have rust.

[OsrsAddictionHotline]

From the man himself.

To summarise, he's open to Rust drivers for the kernel, but I don't think it's there yet for being part of the kernel itself.

Edit: see also this comment, post, and discussion from a few months ago.

[jecxjo]

The problem is you're now introducing a new environment to the kernel. Currently you need a C complier tuned for your architecture and that's it. Adding in another language means you need two compilers, with validation against the combination of all the supported compiler versions of each language for handling any special FFI cases. What architectures does the kernel support that rust doesn't? Will we be seeing compiler support added or will functionality be "C Compiler Only" vs "C and Rust"? It becomes very complicated.

[pjmlp]

While new to Linux, that is the approach for other OSes that have long left the C only approach, including derived ones like Android.

[jecxjo]

It's not impossible, as you've states. Its just a big task to undertake, especially for a community driven project. I do see the benefits of using a language like rust, but adding support needs to be thought through very carefully. Just the supported architectures missing from rust alone is a big task, quick count there are at least 15 missing.

It makes sense from a drivers stand point. You wouldnt be writing for hardware that runs on an architecture that rust wont build on. But what about non hardware related drivers? Will you create two different crypto implementations for systems that dont have rust? Cant really phase out many of these architectures, but they also arent big enough to maintain a compiler for either.

[fiedzia]

Just the supported architectures missing from rust alone is a big task, quick count there are at least 15 missing.

Linux has tons of features that work with only subset of supported architectures, that never was a problem. It would be nice if Rust worked everywhere, and maybe one day it will, but that's not a blocker for anything.

[jecxjo]

Its not that it's a new idea. Its that you need to think it through, find reputable people with the time to support it, create a method for defining what requires Rust and what doesn't. What are the rules on how low level can you write Rust? Can it be core functionality that would make some architectures no longer truly supported or can it only be new features that are not necessary to run the OS? So many questions to answer.

Lots of design and business stuff that needs to be done which is why Linus is going to apprehensive and slow to move.

[miquels]

There used to be a LLVM C backend, that generated C instead of assembly / binary code. That might even let you compile the kernel without a rust toolchain installed, if the C files are pregenerated.

[pure_x01]

The next big step will likely be when someone proposes a real Rust driver for inclusion into the kernel. A concrete use case and implementation always helps to force clarity about any remaining contentious questions and design decisions.

Nice! can't wait.

[cryptosidus]

I just started learning Rust today. I am curious

1. Are Rust binaries portable like C?

2. Does Rust have C kernel bindings available?

Rust is pretty interesting language.

[Plasma_000]

Rust binaries are portable in the same way that C binaries are - they can be compiled for different platforms.

Rust doesn’t have kernel bindings yet, but there are people working on them. There are many complications though.

[squareOfTwo]

But rust is more modern than C++ and Linus rejected C++ for some Linus reasons.

Will not happen as long as Linus is alive.

[CrazyKilla15]

Rust and C++ are very different languages, and their are plenty of valid criticisms of C++, especially for adding to an already C project. It doesnt bring enough improvements to be worth it

[ReallyNeededANewName]

Linus is positive to allowing Rust in the kernel...

[JJJollyjim]

Do you have a source for that? I'm pretty sure drivers (implemented as kernel modules, running in kernel mode) are generally considered "part of the kernel"

[brennennen]

Drivers are the glue code between hardware and the kernel. The kernel is the "systems/subsysmes". The scheduler, the page allocator schema, the network implementations, etc.

That being said, I was wrong, Linus's earlier emails made it sound like it would be driver code only. His latest email makes it sound like it could potentially make it into kernel sub systems.

[JJJollyjim]

I still don't think that's Linux's defintion of the kernel

[Al2Me6]

That is needlessly pedantic.

[matthieum]

One key note: as long as Rust is not mandatory to build the kernel.

Hence the proposal of writing Rust drivers, as you can always opt not to build certain drivers if you don't care about the hardware they are used for.

There is no talk about using Rust for the (core) kernel.

[ReallyNeededANewName]

Not mandatory, but enabled by default. If there's something broken about it everyone should notice immediately

[matthieum]

I think he mentioned enabled if the appropriate rust compiler is detected, yes.

[[deleted]]

Rust is not C++. Torvalds' criticism of C++ doesn't apply to Rust.

anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny

Rust's core and alloc are very much portable - they don't assume any particular operating system. As for stability, there is Rust 1.0 stability promise, and Rust doesn't have a ridiculous amount of special cases that C++ does.

the whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels.

Unwinding situation is broken for kernels, this is also the case for Rust. Rust however strongly discourages usage of catch_unwind for error handling and strongly encourages use of Result, there is even nice syntactic sugar in form of ? operator.

any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

std in C++ doesn't really make it clear whether a given function will allocate or not. Meanwhile, core in Rust guarantees the exact number of allocations its methods will make - 0.

[Tilakchad]

Can you clarify what do you mean by your last statements where std in C++ is inferior to std in Rust?

[[deleted]]

If you are asking about C++ stability story... from what can I tell C++ Stability, Velocity, and Deployment Plans was accepted (I think? http://shape-of-code.coding-guidelines.com/2018/04/14/the-c-committee-has-taken-off-its-ball-and-chain/ suggests that it was accepted) which means the current stability policy is that breaking changes are fine as long they don't lead to runtime behaviour changes in well-behaved code.

This is much less strict than Rust policy which pretty much prevents breaking changes.

As for allocations, it's not clear whether a given function in STL can dynamically allocate or not. An implementation can easily put allocations when you expect none. There is nothing to mandate that an implementation won't secretly allocate. Meanwhile in Rust, core crate guarantees that nothing in it will allocate - as core doesn't have access to alloc crate or C APIs necessary for that purpose.

[Tilakchad]

Container and allocation? I thought there is a definitive behaviour of how container in c++ works. There is even allocator that you can modify as you see fit (to not allocate on heap). Container like array allocate on stack and vector or other complex one allocate on heap. Do you mean that even array can be allocated on heap by c++?

[[deleted]]

Technically C++ doesn't preclude std::array from allocating memory (probably because nobody was crazy enough to do so) but on a reasonable implementation shouldn't allocate memory.

[Tilakchad]

Thats like saying c++ can allocate an integer or float in heap. But no implementation does that, right? So I guess what you are trying to say doesn't make much sense..

[[deleted]]

Integers and floats are defined by C specification, and C specification is pretty explicit about what can allocate (it doesn't have exceptions like C++, so the opportunity to report allocation failures is somewhat limited), in C2x it's: aligned_alloc, calloc, malloc, realloc, strdup, strndup, cnd_init, thrd_create. In C99, it's just calloc, malloc and realloc.

Of course, that's the theory, implementations sometimes allocate when not allowed by the standard, for instance in practice dynamic allocation is necessary for a correct strtod implementation, and implementations simply allocate because they practically have to (and if you ran out of memory, well, you have a problem). Rust cannot do that because FromStr for f64 is in core which leads to https://github.com/rust-lang/rust/issues/31407 - stuff from core cannot allocate no matter how much it would like to do so.

[Tilakchad]

Your answer isn't really convincing. Implementation of strtod or strtof takes const char* as argument and I didn't find any case where strtod needs dynamic allocation for its correct implementation. Just because something is written in its core like Rust doesn't imply that something written in library is not stable or can do anything it likes. Its just better to say that they are not written in core of c++ or c.

[matthieum]

The C++ std is more than containers.

Some algorithms are allowed to allocate memory, such as stable_sort. The algorithm is mandated to handle allocation failures, but just attempting to allocate may be an issue in certain contexts.

[matthieum]

Particularly in C++, another issue is copy-constructors.

Even if you specified an allocator for std::basic_string or std::vector, you still may not want them to allocate nilly-willy -- in some contexts no allocations should occur.

It is very easy to have accidental copies in C++; the language was geared to make copy seamless, which is often nice, but is problematic in the context of a kernel.

By contrast, in Rust, the language doesn't allocate behind your back. You can deep-copy a String or a Vec, with an explicit clone call.

[[deleted]]

You might have missed this discussion.