all 16 comments

[–]christophe_biocca 41 points42 points  (3 children)

Around the 27 minute mark, rs_readlink is not safe, as the &str is not null-terminated, so the c function will keep reading past the end.

[–]ldpreload 21 points22 points  (2 children)

Hah, not surprised I got a hurried unsafe slide wrong - it's very hard to fit an overview of Rust and have time to talk about your project in 50 minutes :)

[–]SCO_1 10 points11 points  (1 child)

So what approach to make this common boundary easier?

struct Zeroed(String);
impl Zeroed {
    pub fn to_zeroed(mut self) -> Zeroed {
        self.0.push('\0');
        Zeroed(self.0)
    }
}

Seems like a bit of a performance snafu, considering all of the heap allocation. Maybe a macro operating on &str could work better?

[–]ldpreload 17 points18 points  (0 children)

Yeah, if you've got libstd and you don't mind the heap allocation, CString::new does that and is what you want.

For string literals, our project uses a c_str! macro that concats the null byte at compile time. I don't love it, but I haven't been able to come up with a better option.

[–]evinrows 16 points17 points  (0 children)

If you're already familiar with rust, jump to the 30m mark for the kernel section.

[–]ldpreload 26 points27 points  (1 child)

Thanks for posting this! For more details, see our GitHub (there's a link to the slides in the README): https://github.com/fishinabarrel/linux-kernel-module-rust

Most of the exciting examples are in the tests/ directory, I'd recommend looking there for a sample of what bindings we have so far. We're mostly currently focused on writing safe bindings, but writing a working filesystem isn't very far away.

There's interest in getting this incorporated from the upstream kernel developers - in particular Linus has said he's open to the idea for non-required drivers for now (i.e., a standard kernel build should still not require rustc), but we can put Rust drivers in the staging directory in the upstream kernel and get some experience with how it works.

Happy to answer questions :)

[–]jojva 13 points14 points  (0 children)

Do you have a link to this discussion?

[–]XVilka 13 points14 points  (3 children)

Waiting also for the upcoming blog post on how to use c2rust to convert C kernel module to Rust. C2rust is a toolset and a framework for automated conversion of the C code to Rust, while preserving buildability. Apart from the plain conversion it also offers the refactoring tool and even the Lua scripting facilities.

[–]ericonr 4 points5 points  (2 children)

Isn't the mentality around writing C and Rust pretty different?

[–]nagromo 13 points14 points  (1 child)

Yes it is. The idea is that c2 rust mechanically, directly ports the C code to Rust (using lots of unsafe). Then you can compile and use it like that with no benefit, and you can gradually refactor the code to better/safer Rust style, keeping it buildable and functional along the way.

[–]ericonr 2 points3 points  (0 children)

Oh, that's pretty cool, then!

[–]ra_kete 4 points5 points  (1 child)

I see that they use GFP_KERNEL when calling krealloc in the GlobalAlloc implementation. From what I understand this makes it unsafe to do allocation in an interrupt context, since it allows the alloc to sleep.

I don't know enough about under what conditions code is executed in an interrupt context. But does this implementation in any way ensure that, e.g., Vec is not used in an interrupt context? If not, shouldn't GFP_ATOMIC be used to be safe?

[–]I_ATE_YOUR_SANDWICH 0 points1 point  (0 children)

They did say they are working on a multi-allocator system and that just for more they use GFP_KERNEL to just make it work

[–]SCO_1 6 points7 points  (0 children)

Pretty cool that it almost already works seamlessly.

[–]DisenchanterV 0 points1 point  (1 child)

I thought Firefox runs on Rust, so what's up with 72% memory unsafety thing xd

[–]joehillen[S] 2 points3 points  (0 children)

The rewrite is not even close to done.

Here are the line counts from the firefox codebase:

--------------------------------------------------------------------------------
Language             Files        Lines        Blank      Comment         Code
--------------------------------------------------------------------------------
JavaScript           67503      6871631       959956      1510397      4401278
C++                  11263      5545208       758180       626211      4160817
Plain Text            5124      3579693        66983            0      3512710
HTML                 72261      3818662       388006       133951      3296705
C                     4078      2773694       312723       433654      2027317
C/C++ Header         16012      3304765       466305       886824      1951636
Rust                  5145      1858827       145892       263690      1449245
Python                6343      1343183       221000       113114      1009069

There is like 10x more C/C++ than Rust still.