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

151–160 of 206 posts

Re: Rust for Filesystems

#151

Post by nicce »

foldr wrote: post #143
weinzierl wrote: post #12

Earlier quoted context omitted.

Yes, they don't contain the blast, but they limit the places where a bomb can be, and that is their worth.

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.

Re: Rust for Filesystems

#152

Post by nicce »

pjc50 wrote: post #40
ysw0145 wrote: post #6

Having more options available in the Linux kernel is always beneficial. However, Rust may not be the solution for everything. While Rust does its best to ensure its programming model is safe, it is still a limited model. Memory issues? Use Rust! Concurrency problems? Switch to Rust! But you can't do everything that C does without using unsafe blocks. Rust can offer a fresh perspective to these problems, but it's not…

> But you can't do everything that C does without using unsafe blocks How much of this is actually 100% unambiguously necessary ? Is there a good reason why anything in the filesystem code at all needs to be unsafe? I suspect it's a very small subset needed in a few places.

Usually avoidance of copying or moving data is the primary reason. In filesystems, this is quite highlighted.

Re: Rust for Filesystems

#153

Post by yjftsjthsd-h »

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

Earlier quoted context omitted.

> I wouldn't call it a rant, but rather a polite request for HN policy to change. Which is made by blocking people with no ability to do anything about it.

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.

Re: Rust for Filesystems

#154

Post by nicce »

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.

> author has a very negative opinions about hacker news

I am not sure if author (Asahi Lina) has, but the project lead Hector Martin definitely has.

Re: Rust for Filesystems

#155

Post by nyssos »

jcranmer wrote: post #130
pessimizer wrote: post #74

Earlier quoted context omitted.

"Bullying" is a judgement. Intrinsic to the word is a judgement that what is being done is bad, and the person doing it would not describe it that way. And by that I don't mean that it's not bad to bully people (it's rather tautological), I mean that talk of bullying often begs the question, and is intentionally done in order to elide past the actual events that occurred. Lèse majesté laws against talking about the K…

What the referer-replacement page was talking is Kiwi Farms, which is doing the kind of stuff that even the US First Amendment's very expansive protections fails to protect. (The criminal liability here is "intentional inflection of emotional distress", although note that most lawsuits that allege that are groundless lawsuits that largely fail to make it pass the motion to dismiss for failure to state a claim stage a…

> The criminal liability here is "intentional inflection of emotional distress",

Intentional infliction of emotional distress is a tort, not criminal.

Re: Rust for Filesystems

#156

Post by Smaug123 »

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…

The point is that Rust can model invariants that C can't. You can call both ways, but if C is incapable of expressing what Rust can, that has important implications for the design of APIs which must be common to both.

Re: Rust for Filesystems

#157

Post by seanhunter »

pornel wrote: post #73

I don't get how can each file system have a custom lifecycle for inodes, but still use the same functions for inode lifecycle management, but apparently with different semantics? That sounds like the opposite of an abstraction layer, if the same function must be used in different ways depending on implementation details. If the lifecycle of inodes is filesystem-specific, it should be managed via filesystem-specific f…

If you haven't seen it before, you might find this useful https://www.kernel.org/doc/html/latest/filesystems/vfs.html

It's an overview of the VFS layer, which is how they do all the filesystem-specific stuff while maintaining a consistent interface from the kernel.

Re: Rust for Filesystems

#158

Post by adastra22 »

brodouevencode wrote: post #123

> about the disconnect between the names in the C API and the Rust API, which means that developers cannot look at the C code and know what the equivalent Rust call would be Ah, the struggle of legacy naming conventions. I've had success in keeping the same name but when I wanted an alternative name I would just wrap the old name with the new name. But yeah, naming things is hard.

One of the two major problems in computer science (the other two being concurrency and off-by-one errors).

Re: Rust for Filesystems

#159

Post by Phelinofist »

aniviacat wrote: post #63
eru wrote: post #14

Earlier quoted context omitted.

Alas, that link just gets you a rant about politics, if you click on it directly. Copy-and-pasting works.

I can't find a rant in the link. Was the link changed or did I overlook something?

Also didn't show for me with disabled JS

Re: Rust for Filesystems

#160

Post by structural »

BiteCode_dev wrote: post #125
nickparker wrote: post #118

Earlier quoted context omitted.

I found myself reading this more for the excellent notetaking than for the content. I suspect the discussion was about as charged, meandering, and nitpicky as we all expect a PL debate among deeply opinionated geeks to be, and Jake Edge (who wrote this summary) is exceptionally good at removing all that and writing down substance.

Certainly. We are talking about extremely competent people who worked on a critical piece of software for years and invested a lot of their lives in it, with all pain, effort, experience, and responsibilities that come with that. That this debate is inscribed is a process that is still ongoing, and in fact, progressing, is a testament to how healthy the situation is. I was expecting the whole Rust thing to be shut do…

I agree. And ideally, every time you raise the question and get the "no" response, you learn something about the system you're modifying or the reviewer learns something about your solution. Then you improve your solution, and come back.

Eventually consensus is built - either the solution becomes good enough, or both the developers and the reviewers agree that it's not going to work out and the line of development gets abandoned.

Large-scale change in production is hard, and messy, and involves a lot of imperfect humans that we hope are mostly well-intentioned.

Post reply on HN