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

111–120 of 240 posts

Re: Upcoming Rust language features for kernel development

#111

Post by cyphar »

heavyset_go wrote: post #14
oersted wrote: post #5

Earlier quoted context omitted.

As I understand it systems programming is the priority application area for Rust, and there are plenty of projects working on OSs, embedded or other bare-metal cases, as well as interoperability with complex C codebases. At first glance, these features look quite general to me and not particularly tied to the kernel, they are important utilities for doing this kind of programming in the real world.

What's the story with C interop now with these and related changes? I'm out of the loop.

Calling C code from Rust? Pretty nice.

Writing Rust code to be called from C (but within the same application)? Doable but somewhat painful.

Writing Rust code to act like a C shared library? Quite painful and some pretty important features are missing (proper symbol versioning support being the most obvious one). Theoretically doable if you're willing to compromise.

There's also some aspects of FFI-safety that are very subtle and easy to mess up:

  * #[repr(C)] enums still have the same requirements as Rust enums and so C callers can easily trigger UB, so you need to use something like open_enum. Thankfully cbindgen is too dumb to know that #[open_enum] is a proc macro and produces a non-enum type.
  * Before io_safety in Rust 1.63, dealing with file descriptors from C without accidentally closing them was horrific (though this was a wider problem in Rust). BorrowedFd is quite nice -- though Rustix will panic if you use negative fds and so you need to add validation and your own type in practice. However, #[repr(transparent)] is very nice for this.
  * Lots of reading about unsafe Rust is necessary when doing most non-trivial things with C FFI.
  * You need to make use of a lot of compiler internals, build scripts, and other magic to get the output you want.
  * Tools like cargo-c and cbindgen are nice and probably work great for 80% of projects, but the 20% really suffer from no useful tooling. I haven't tried to use rustc directly to work around some of the remaining issues, but I suspect it'd be even more painful.
I would say that the C interop with Rust is pretty good but it has lots of room for improvement and it feels like very few resources have been spent on it after they got the core stuff working.

Source: I've been writing a Rust library intended to be used primarily via C FFI and run into a lot of issues...

Re: Upcoming Rust language features for kernel development

#112

Post by mamcx »

pjmlp wrote: post #10
timschmidt wrote: post #8

Earlier quoted context omitted.

> for everything else on userspace compiled managed languages are a much better option As someone who's written a number of userspace applications in many languages as well as embedded firmwares running on bare metal, Rust is a rare gem that excels at both.

Only if those userspace applications are headless, Rust exceling at GUIs is a bit of a strech.

> Rust exceling at GUIs is a bit of a strech.

BTW, this happens to almost all languages. Which ACTUAL good GUIs toolkits exist? And which ACTUAL languages HAVE good integration or implementation of them?

A good GUI kit AND integration is a bigger task than do a Os or a RDBMS. (And neither are many good languages for RDBMS)

Re: Upcoming Rust language features for kernel development

#113

Post by anon-3988 » 

    fn project_reference(r: &MyStruct) -> &Field {
        &r.field
    }

    unsafe fn project_pointer(r: *mut MyStruct) -> *mut Field {
        unsafe { &raw mut (*r).field }
    }

    // The equivalent C code would look like this:
    struct field *project(struct my *r) {
        return &(r->field);
    }
I am a very heavy Rust user. I mostly program in safe Rust while occassionally dipping into unsafe Rust.

IDK, I think Rust should stick with what it is good at and not try to expand into domain that it is clearly not nicely designed for. That is, what if the best way to implement linked list in RUST is via an array of indices and NOT through RefCell or whatever it is? What if Rust will never ever have a sane way to implement linked list. What is so wrong with that? I think there should be a very clean divide between C and Rust. Rust stays in the happy Rust world and C stays on the happy C world.

I am not sure I am excited to see something like this

    unsafe fn project_pointer(r: *mut MyStruct) -> *mut Field {
        unsafe { &raw mut (*r).field }
    }

Re: Upcoming Rust language features for kernel development

#114

Post by tialaramex »

gpm wrote: post #101
remix2000 wrote: post #86

Earlier quoted context omitted.

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 m…

Also we can (in 2024 Edition) say we're vouching for an FFI function as safe to call, avoiding the need for a thin safe Rust wrapper which just passes through. We do still need the unsafe keyword to introduce the FFI function name, but by marking it safe all the actual callers don't care it wasn't written in Rust.

This is fairly narrow, often C functions for example aren't actually safe, for example they take a pointer and it must be valid, that's not inherently safe, or they have requirements about the relative values of parameters or the state of the wider system which can't be checked by the Rust, again unsafe. But there are cases where this affordance is a nice improvement.

Re: Upcoming Rust language features for kernel development

#115

Post by drdo »

anon-3988 wrote: post #113

fn project_reference(r: &MyStruct) -> &Field { &r.field } unsafe fn project_pointer(r: *mut MyStruct) -> *mut Field { unsafe { &raw mut (*r).field } } // The equivalent C code would look like this: struct field *project(struct my *r) { return &(r->field); } I am a very heavy Rust user. I mostly program in safe Rust while occassionally dipping into unsafe Rust. IDK, I think Rust should stick with what it is good at an…

It's not that hard to implement a linked list in Rust in exactly the same way as in C or C++, using raw pointers, and putting a safe API around it.

Re: Upcoming Rust language features for kernel development

#116

Post by lowbloodsugar »

anon-3988 wrote: post #113

fn project_reference(r: &MyStruct) -> &Field { &r.field } unsafe fn project_pointer(r: *mut MyStruct) -> *mut Field { unsafe { &raw mut (*r).field } } // The equivalent C code would look like this: struct field *project(struct my *r) { return &(r->field); } I am a very heavy Rust user. I mostly program in safe Rust while occassionally dipping into unsafe Rust. IDK, I think Rust should stick with what it is good at an…

The best way to implement a linked list is with unsafe in a collection type. You write that type once, check that it’s bullet proof, and then go onto the next thing. I’ve got a sorted map using doubly linked list and I don’t think twice about it. Using an array for a linked list means the compiler can’t tell if you are being unsafe. You still have all the same problems.

Re: Upcoming Rust language features for kernel development

#117

Post by gpm »

tonyplee wrote: post #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?

There's non-LLM research towards doing this which has a few success stories: https://github.com/immunant/c2rust

LLMs seem generally unsuited for the task, because they're fundamentally approximators that won't always get things right, and as a result will introduce subtle bugs. Perhaps if you paired them with some sort of formal methods... I'm not aware of anyone doing that. Tests aren't sufficient - lots of subtle bugs will not be caught by existing test suites.

Your idea of "smaller" projects is not... smaller enough. See the actual success stories for example: https://github.com/immunant/c2rust?tab=readme-ov-file#uses-o...

Re: Upcoming Rust language features for kernel development

#118

Post by dralley »

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

It is definitely a complex language though I would argue probably much less so, on the whole, than C++.

Re: Upcoming Rust language features for kernel development

#119

Post by meisel »

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

In my experience, C++ is a much more complicated language. The 8 ways to initialize something, the 5 types of values (xvalues etc.), inconsistent formatting conventions, inconsistent naming conventions, the rule of 5, exceptions, always remembering to check `this != other` when doing a move assignment operator, perfect forwarding, SFINAE, workarounds for not having a great equivalent to traits, etc. . Part of knowing the language is also knowing the conventions on top that are necessary in order to write it more safely and faster (if your move constructor is not noexcept it'll cause copies to occur when growing a vector of that object), and learning the many non-ideal competing ways that people do things, like error handling.

Re: Upcoming Rust language features for kernel development

#120

Post by lowbloodsugar »

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…?

Heh. This is such a C++ thing to say: “I want to do the right thing, but then my code is slow.” I know, I used to write video games in C++. So I feel your pain.

I can only tell you: open your mind. Is Rust just a fad? The latest cool new shiny, espoused only by amateurs who don’t have a real job? Or is it something radically different? Go dig into Rust. Compile it down to assembly and see what it generates. Get frustrated by the borrow checker rules until you have the epiphany. Write some unsafe code and learn what “unsafe” really means. Form your own opinion.

Post reply on HN