Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Rust language features for kernel development

lwn.net

Post reply on HN
Print view View original

61–70 of 240 posts

Re: Upcoming Rust language features for kernel development

#61

Post by tobz1000 »

remix2000 wrote: post #60
dmm wrote: 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…

Rustlang doesn't aim to address race conditions. Sounds to me like overly "cautious" inefficient code you can write in any language. Think using `std::shared_ptr` for everything in C++, perchance…?

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.

Re: Upcoming Rust language features for kernel development

#62

Post by corbet »

izacus wrote: post #55
koverstreet wrote: post #51

Earlier quoted context omitted.

"Experiment" is a misnomer. Rust has been around long enough and demonstrated more than enough real advantages in writing reliable code that we know it's what we want to be doing.

But WHERE is that code in the kernel? That, I think, it the OPs point. Where is that demonstration?

See, for example, the binder driver merged for 6.18. It's out there, and will land when it's ready.

Re: Upcoming Rust language features for kernel development

#63

Post by giancarlostoro »

dmm wrote: post #49
a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

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…

I was just going to say, I think its hard to argue against it since it is the only way to run the GPU on the M1 / M2 Macs.

Re: Upcoming Rust language features for kernel development

#64

Post by remix2000 »

tobz1000 wrote: post #61
remix2000 wrote: post #60

Earlier quoted context omitted.

Rustlang doesn't aim to address race conditions. Sounds to me like overly "cautious" inefficient code you can write in any language. Think using `std::shared_ptr` for everything in C++, perchance…?

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.

Re: Upcoming Rust language features for kernel development

#65

Post by William_BB »

dmm wrote: post #49
a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

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…

What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me?

Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

Re: Upcoming Rust language features for kernel development

#66

Post by a-dub »

dmm wrote: post #49
a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

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. (user rust is pretty bad in that regard, imo)

Re: Upcoming Rust language features for kernel development

#67

Post by pdimitar »

pjmlp wrote: post #48
adwn wrote: post #44

Earlier quoted context omitted.

> OS IPC exists for a reason Message-passing IPC is much, much slower and less efficient than shared-memory communication, and inter-process IPC (both message-passing and shared-memory) is much less convenient than intra-process multi-threading. Rust is the only mainstream language, managed or otherwise, which enables safe and efficient multi-threading.

Not at all, because as I explain on another sibiling answer, it is only safe if we cut down the use cases to a very specific one that helps to sell that narrative.

Eh, modern OS-es indeed have loads of problems still, of which non-transactional access to the filesystem is in my top three, but to put those problems on Rust is a bit uncharitable. It's not Rust's fault that zero kernel devs have the courage to finally start enforcing patterns that have proven themselves useful and safe for decades, in other areas outside of IT as well (i.e. in financial accounting).

Rust plucks the fruit it can reach and it mostly stays in its lane and it's trying to expand it here and there (like Rust in Linux and embedded). I too want one ultimate language and one ultimate kernel but I don't think you and I will live to see it. Maybe our grandchildren will not as well.

Re: Upcoming Rust language features for kernel development

#68

Post by codedokode »

ogoffart wrote: post #34
timschmidt wrote: post #30

Earlier quoted context omitted.

I looked at Slint a couple years ago when I was evaluating UI toolkits. Looks slick! The only thing that turned me off was needing an additional DSL to define UIs. Trying to learn fewer languages, more deeply, these days. Is it possible to use Slint without the DSL?

Slint does require using its DSL to define UIs, but I'd argue it's not really like learning a whole new language. It's not harder than learning the API surface of any other GUI framework. I actually wrote a blog post about this exact topic, since it's a common question: https://slint.dev/blog/domain-specific-language-vs-imperativ...

I don't think the DSL is any good. It looks weird (like a mix of CSS and classes), and it has a side effect of locking the user to a specific product.

In your article, you mention that an imperative code in Rust looks more complicated, but this can be fixed by adding an "object tree" syntax to Rust, that allows creating trees of objects and link them like this:

    VBox margin=10:
        Label text=label_text 
        Button label="OK" onclick=on_ok_clicked
This syntax could be used not only for UI, but for describing configuration, database tables and many other things. I think it would be better solution than a proprietary language.

Also I think it would be better if GUI could be drawn in the editor, it would allow to use lower paid developers without expensive computer science education for making UI.

Re: Upcoming Rust language features for kernel development

#69

Post by Aurornis »

William_BB wrote: post #65
dmm wrote: 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…

What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

> What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me?

Rust’s strict ownership model enforces more correct handling of data that is shared or sent across threads.

> Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

C++ is not used in the Linux kernel.

You can write safe code in C++ or C if everything is attended to carefully and no mistakes are made by you or future maintainers who modify code. The benefit of Rust is that the compiler enforces it at a language level so you don’t have to rely on everyone touching the code avoiding mistakes or the disallowed behavior.

Re: Upcoming Rust language features for kernel development

#70

Post by 15155 »

a-dub wrote: post #66
dmm wrote: 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.

This isn't an appeal to just any authority, but the authority that defines Linux and is its namesake.

Post reply on HN