Live data from Hacker News

Upcoming Rust language features for kernel development

lwn.net

101–110 of 240 posts

Re: Upcoming Rust language features for kernel development

#101

Earlier quoted context omitted.

Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)

And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?

> rustlang mutability is also a type system construct?

Yes

> I.e. it assumes that all other code is Rust for the purpose of those checks?

Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that

- x points to a properly aligned properly allocated i32 (not to null, not to the middle of un-unallocated page somewhere)

- The only way that memory will be accessed for the duration of the call to `foo` is via `x`. Which is to say that other parts of the system won't be writing to `x` or making assumptions about what value is stored in its memory until the function call returns (rust is, in principle, permitted to store some temporary value in `x`s memory even if the code never touches x beyond being passed it. So long as when `foo` returns the memory contains what it is supposed to). Note that this implies that a pointer to the same memory isn't also being passed to rust some other way (e.g. through a static which doesn't have a locked lock around it)

- foo will be called via the standard "C" calling convention (on x86_64 linux this for instance means that the stack pointer must be 2-byte aligned. Which is the type of constraint that is very easy to violate from assembly and next to impossible to violate from C code).

That it's up to the programmer to verify the invariants is why FFI code is considered "unsafe" in rust - programmer error can result in unsoundness. But if you, the programmer, are confident you have upheld the invariants you still get the guarantees about the broader system.

Rust is generally all about local reasoning. It doesn't actually care very much what the rest of the system is, so long as it called us following the agreed upon contract. It just has a much more explicit definition of what that contract is then C.

Re: Upcoming Rust language features for kernel development

#102
post #88

Earlier quoted context omitted.

> What does rust have to do with thread safety [...] ? Rust inherently models this idea. Read about Rust's "Send" and "Sync" marker traits. e.g. https://doc.rust-lang.org/std/marker/trait.Send.html > Is rust going to synchronize shared memory access for me? Much better than that. (safe) Rust is going to complain that you can't write the unsynchronized nonsense you were probably going to write, shortcutting the step w…

aren't they just annotations? proper use of mutexes and lock ordering aren't that hard, they just require a little bit of discipline and consistency. i can't remember the last time i faced a data race to be honest. i guess the real question is, how well does it all hold up when you have teamwork and everything isn't strictly adherent to one specific philosophy.

Proper use of lock ordering is reasonably difficult in a large, deeply connected codebase like a kernel.

Rust has real improvements here, like this example from the fuschia team of enforcing lock ordering at compile time [0]. This is technically possible in C++ as well (see Alon Wolf's metaprogramming), but it's truly dark magic to do so.

[0] https://lwn.net/Articles/995814/

Re: Upcoming Rust language features for kernel development

#103
post #36

Earlier quoted context omitted.

Indeed. Last I knew all the Rust UI libraries were declarative and/or immediate mode, both of which have their place but I’m not convinced that they’re suitable in all situations. Sometimes you need a boring “old style” imperative UI framework with deep toolbox of capable widgets (think AppKit, win32, etc), but that’s notably absent in the Rust world.

How far from "old style" is Slint?

From a quick glance, about as far as the other Rust toolkits. Looks declarative with with a relatively small number of more basic widgets (a lot of custom widget code is necessary), as opposed to e.g. AppKit which is imperative and comes with a great number of rich widgets that are ready to use out of the box.

Re: Upcoming Rust language features for kernel development

#104
post #76

Earlier quoted context omitted.

[flagged]

Also the guy that created "the world's most important piece of software", as you put it. Appealing to the authority on the exact thing you raised concern about is the single most important authority one can cite.

Eh?

Surely it's better to cite the authority's reasons as to why they think this way than just to cite the authority itself ...

It's not like there's a lack of times he's talked about rust. Just link his commentary similar to linking ashai linux.

Re: Upcoming Rust language features for kernel development

#105
Are there any researches/works/agents into use LLM to auto covert some/all C code to Rust?

Ask LLM to generate rust code from chat, usb, i2c, GPU drivers - build and test it automatically? Possible?

Or start with other "smaller" projects such as sqlite, apache, nginx, etc - possible?

Re: Upcoming Rust language features for kernel development

#106
post #71

Earlier quoted context omitted.

a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value

I meant the trait send sync things. I just thought it was obvious, since Rust is not the only language susceptible to data races.

> since Rust is not the only language susceptible to data races.

The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.

Re: Upcoming Rust language features for kernel development

#107

Earlier quoted context omitted.

The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.

I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.

I'm not sure I understand the point of your comment at all.

Rust does, successfully, guarantee the lack of data races. It also guarantees the lack of memory-unsafety resulting from race conditions in general (which to be fair largely just means "it guarantees a lack of data races", though it does also include things like "race conditions won't result in a use after free or an out of bounds memory access").

If by address it you mean "show how C/C++ does this"... they don't and this is well known.

If by address it you mean "prove that rust doesn't do what it says it does"... as that point you're inviting someone to teach you the details of how rust works down to the nitty gritty in an HN comment. You'd be much better off finding and reading the relevant materials on the internet than someones off hand attempt at recreating them on HN.

Re: Upcoming Rust language features for kernel development

#108
post #57
post #52

Earlier quoted context omitted.

This one? > Turns out threads also may share resources like out-of-process files, memory mapped regions, shared memory, databases, distributed transactions For multi-threaded parallelization, - out-of-process files - databases - distributed transactions aren't really relevant, and Rust directly helps with the other two aspects: - memory mapped regions - shared memory In practice, your "very specific" aspect is the mo…

Who gets to say what is relevant is the architect driving the project implementation. > aren't really relevant, and Rust directly helps with the other two aspects: Not at all, because Rust code has nothing to say about what other processes do to those resources, the only thing you can do is wrap accesses in a unsafe code block and hope for the best, that nothing was corrupted.

I think you're confusing concurrency with parallelism. I've been talking about parallelization since my first comment in this thread. There's some overlap, yes, but the aspects you listed have typically very little to do with parallelization, which is why I called them "[not] really relevant". And where they do matter to multi-threading (the shared memory part), Rust does help with correctness.

Re: Upcoming Rust language features for kernel development

#109
post #66
post #49

Earlier quoted context omitted.

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet. """ Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and al…

> Torvalds seems to disagree with you. i don't really care for mindless appeals to authority. make your own arguments and defend them or don't bother. this gpu driver looks pretty cool though. looks like there's much more to the rust compatibility layer in the asahi tree and it is pretty cool that they were able to ship so quickly. i'd be curious how kernel rust compares to user space rust with respect to bloat. (use…

> i don't really care for mindless appeals to authority. make your own arguments and defend them or don't bother.

You previously appealed to Linux being the largest worlds most important source tree and then you choose to eschew the opinion of that project's lead.

Re: Upcoming Rust language features for kernel development

#110
post #88

Earlier quoted context omitted.

> What does rust have to do with thread safety [...] ? Rust inherently models this idea. Read about Rust's "Send" and "Sync" marker traits. e.g. https://doc.rust-lang.org/std/marker/trait.Send.html > Is rust going to synchronize shared memory access for me? Much better than that. (safe) Rust is going to complain that you can't write the unsynchronized nonsense you were probably going to write, shortcutting the step w…

aren't they just annotations? proper use of mutexes and lock ordering aren't that hard, they just require a little bit of discipline and consistency. i can't remember the last time i faced a data race to be honest. i guess the real question is, how well does it all hold up when you have teamwork and everything isn't strictly adherent to one specific philosophy.

> aren't they just annotations? proper use of mutexes and lock ordering aren't that hard, they just require a little bit of discipline and consistency.

No, they are not. You also don't need mutex ordering as much since Mutexes in Rust are a container type. You can only get ahold of the inside value as a reference when calling the lock method.

Post reply on HN