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

Rust for Filesystems

lwn.net

Post reply on HN
Print view View original

161–170 of 206 posts

Re: Rust for Filesystems

#161

Post by foldr »

nicce wrote: post #151
foldr wrote: post #143

Earlier quoted context omitted.

Generally speaking yes, but there could be a logic error somewhere in safe code that causes an unsafe block to do something it shouldn’t. For example, a safe function that is expected to return an integer less than n is called within an unsafe block to obtain an index, but the return value isn’t actually less than n. In that case the ‘bomb’ may be in the unsafe block, but the bug is in the safe code.

> yes, but there could be a logic error somewhere in safe code that causes an unsafe block to do something it shouldn’t. Sounds like bad design. You can typically limit the use for unsafe for so small area than you can verify the ranges of parameters which will cause memory problems. Check for invalid values and raise panic. Still ”memorysafe”, even if it panics.

Sure, it may be bad design. The point is that nothing in the Rust language itself guarantees that memory safety bugs will be localized to unsafe blocks. If your code has that property it’s because you wrote it in a disciplined way, not because Rust forced you to write it that way (though it may have given some moral support).

Let me emphasize that I am not criticizing Rust here. I am just pointing out an incontrovertible fact about how unsafe blocks in Rust work: memory safety bugs are not guaranteed to be localized to unsafe blocks.

Re: Rust for Filesystems

#162

Post by foldr »

Klonoar wrote: post #149
foldr wrote: post #143

Earlier quoted context omitted.

Generally speaking yes, but there could be a logic error somewhere in safe code that causes an unsafe block to do something it shouldn’t. For example, a safe function that is expected to return an integer less than n is called within an unsafe block to obtain an index, but the return value isn’t actually less than n. In that case the ‘bomb’ may be in the unsafe block, but the bug is in the safe code.

I cannot imagine writing a method to return a value less than n, and not verifying that constraint somewhere in the safe method.

It’s just a simple example to illustrate the point. Realistic bugs would probably involve more complex logic.

The prevalence of buffer overrun bugs in C code shows that it very definitely is possible for programmers to screw up when calculating indices. Rust removes a lot of the footguns that make that both easy to do and dangerous in C. But in unsafe Rust code, you’re still fundamentally vulnerable to any arithmetic bug in any function that you call as part of the computation of an index.

Re: Rust for Filesystems

#163

Post by josephcsible »

mnau wrote: post #5
gritzko wrote: post #2

From the minutes I conclude that Rust-in-the-kernel looks like an additional complexity tax. I mean, if you write an OS from scratch, you can use the full power of your language. Plastering it to the side of an already vast codebase creates additional issues, as we see here.

> additional complexity tax Yes, but that should be offsetted by easier driver development. See the blog about Rust GPU driver for asahii linux, done in one month. EDIT: Google "tales of the m1 gpu" (author has a very negative opinions about hacker news, read if you like by clicking the link https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ ) Is it universal? We'll see in coming years.

Warning: Don't click that link. Copy and paste the URL instead. That site serves only verbal abuse and harassment to people that it detects are HN users.

Re: Rust for Filesystems

#164

Post by lanstin »

yjftsjthsd-h wrote: post #153
mcronce wrote: post #147

Earlier quoted context omitted.

What? All you need to do is resubmit the request without a Referer header. For me, using Firefox, this meant clicking in the address bar, changing nothing, and hitting enter. That's hardly "no ability to do anything about it".

I mean people with no ability to alter HN moderation policy. Consider it like this: 1. I think, "oh, that looks relevant, let me open that link". 2. I get a screenful of objections to HN moderation. 3. I shrug and close the tab. Since I'm just a normal user who can't change HN moderation, the outcome is that HN doesn't change but I walk away with a worse opinion of the Asahi Linux folks.

Weird: HN is supposed to be technical but the people behind Asahi Linux have proven themselves to be technical wizards; meanwhile HN seems more interested in money and pseudo-libertarian politics than transformitive technical excellence. But such is our age.

Re: Rust for Filesystems

#165

Post by riku_iki »

vollbrecht wrote: post #8
gritzko wrote: post #2

From the minutes I conclude that Rust-in-the-kernel looks like an additional complexity tax. I mean, if you write an OS from scratch, you can use the full power of your language. Plastering it to the side of an already vast codebase creates additional issues, as we see here.

One can argue that any additional code is introducing complexity, not only writing Rust. Does that mean we should just stop innovating and go into an indefinite state of maintenance, since we are already so vast? A tax in one place may not be a net negative, if it's used like in the real world to offset other problems. And just saying it will not offset any problems because of a single discussion, that does not have…

> One can argue that any additional code is introducing complexity

additional code can replace more complex existing or future code, thus can reduce complexity

Re: Rust for Filesystems

#166

Post by varjag »

mcronce wrote: post #145
varjag wrote: post #134

Earlier quoted context omitted.

They quickly become unwieldy on non-trivial APIs, with hundreds of definitions across dozens of files and with macros to boot. Naturally people would still get the job done but it's beyond simple.

That's what bindgen is for, as was mentioned in the original comment you replied to.

How well does it handle preprocessor macros in APIs?

Re: Rust for Filesystems

#167

Post by kelnos »

gwbas1c wrote: post #78

Maybe they are asking the wrong questions? Does Rust need to change to make it easier to call C? I've done a bit of Rust, and (as a hobbyist,) it's still not clear (to me) how to interoperate with C. (I'm sure someone reading this has done it.) In contrast, in C++ and Objective C, all you need to do is include the right header and call the function. Swift lets you include Objective C files, and you can call C from th…

> Does Rust need to change to make it easier to call C?

No, because it's already dirt-simple to do. You just declare the C function as 'extern "C"', and then call it. (You will often need to use 'unsafe' and convert or cast references to raw pointers, but that's simple syntax as well.)

There are tools (bindgen being the most used) that can scan C header files and produce the declarations for you, so you don't have to manually copy/paste and type them yourself.

> Maybe Rust as a language needs to bend a little in this case, instead of expecting the kernel developers to bend to the language?

I think you maybe misunderstood the article? There's nothing wrong with the language here. The argument is around how Rust should be used. The Rust-for-Linux developers want to encode semantics into their API calls, using Rust's features and type system, to make these calls safer and less error-prone to use. The people on the C side are afraid that doing so will make it harder for them to evolve the behavior and semantics of their C APIs, because then the Rust APIs will need to be updated as well, and they don't want to sign up for that work.

An alternative that might be more palatable is to not make use of Rust features and the type system in order to encode semantics into the Rust API. That way, it will be easier for C developers, as updating Rust API when C API changes will be mechanical and simple to do. But then we might wonder what the point is of all this Rust work if the Rust-for-Linux developers can't use Rust some features to make better, safer APIs.

> I've done a bit of Rust, and (as a hobbyist,) it's still not clear (to me) how to interoperate with C.

Kinda weird that you currently have the top-voted comment when you admit you don't understand the language well enough to have an informed opinion on the topic at hand.

Re: Rust for Filesystems

#168

Post by kelnos »

varjag wrote: post #126
lambda wrote: post #119

Earlier quoted context omitted.

Calling C from Rust can be quite simple. You just declare the external function and call it. For example, straight out of the Rust book https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#usin... : extern "C" { fn abs(input: i32) -> i32; } fn main() { unsafe { println!("Absolute value of -3 according to C: {}", abs(-3)); } } Now, if you have a complex library and don't want to write all of the declarations by han…

That's not really "simple", it's on par with C FFI in about any other language (except C++), with same drawbacks.

How is that not simple? You just declare the function and then call it. I find it hard to imagine how it could be any more simple than that.

Re: Rust for Filesystems

#169

Post by merb »

John23832 wrote: post #96
colejohnson66 wrote: post #56

Earlier quoted context omitted.

Not really. C#'s Task/Task are based on background execution. Once something is awaited, control is returned to the caller. OTOH, Rust's Future is, by default, based on polling/stepping, a bit like IEnumerable in C#; If you never poll/await the Future , it never executes. Executor libraries like Tokio allow running futures in the background, but that's not built-in.

I don't want to "well actually" the "well actually", but I think you missed the word syntactically. > C#'s Task/Task are based on background execution. Once something is awaited, control is returned to the caller. Async/await in any language happens in the background. What happens during a Task.Yield() (C#)? The task is yielded to the another awaiting task in the work queue. Same as Rust. > OTOH, Rust's Future is, by…

> Task.Yield()

In c# you probably never call yield.

Re: Rust for Filesystems

#170

Post by [deleted] »

BiteCode_dev wrote: post #84

Given how those discussions usually go, and the scale of the change, I find that discussion extraordinarily civil. I disagree with the negative tone of this thread, I'm quite optimistic given how clearly the parties involved were able to communicate the pain points with zero BS.

[deleted]
Post reply on HN