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

61–70 of 206 posts

Re: Rust for Filesystems

#61

Post by PhilipRoman »

pjc50 wrote: post #38
thesnide wrote: post #3

Earlier quoted context omitted.

While I agree there are benefits to rust, I tend to think all reason cannot fight hype. The tax will be seen as a necessity to embrace future and progress. I'm wondering why do not restrict ourselves to a safe subset instead of jumping into a huge bandwagon of unknown bugs and tradeoffs

There is no "safe subset" of C. MISRA is fairly close, but all sorts of things that you might need, like integer arithmetic, have potential UB in C. (The best current effort is https://sel4.systems/ , which is written in C but has a large proof of safety attached. The language design question is basically: should the proof be part of the language?)

I found frama-c to be pretty good, including all the integer quirks

Re: Rust for Filesystems

#62

Post by freeone3000 »

mjburgess wrote: post #42
tialaramex wrote: post #29

Earlier quoted context omitted.

> But you can't do everything that C does without using unsafe blocks For this particular work the huge benefit of Rust is its enthusiasm for encapsulating such safety problems in types. Which is indeed what this article is about. C and particularly the way C is used in the kernel makes it everybody's responsibility to have total knowledge of the tacit rules. That cannot scale. A room full of kernel developers didn't…

> That cannot scale. lol... you're talking about the linux kernel, written in C . The vast majority of software over many decades "bottoms out" in C whether in VMs, operating systems, device drivers, etc. The scale of the success of C is unparalleled.

But it doesn’t have to. We can choose any other language that compiles to native, including memory-safe ones.

Re: Rust for Filesystems

#63

Post by aniviacat »

eru wrote: post #14
mnau wrote: post #5

Earlier quoted context omitted.

> 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.

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?

Re: Rust for Filesystems

#64

Post by logicprog »

erdii wrote: post #37
olivermuty wrote: post #20

Earlier quoted context omitted.

"Rant about politics", haha. Or as other people like to call it: "A real concern described in an apt manner". I have observed these inflammatory sub-graphs of comments myself and have thought to myself that this must be a huge growing grounds for unmoderated and unwanted behaviour because it more or less becomes invisible once flagged enough.

In this specific case complaining about "politics" gets the sour by-taste of enabling (or at least not condoning) harrasment to the point of single folks taking their own lifes over it. Why?! Even if you're not sure what to think about the queer movement; even if you have already made up your mind about the queer movement and oppose their ideas or some of them; I refuse to believe that any single person would not wan…

I'm glad at least some other people on this horrible site feel this way.

Re: Rust for Filesystems

#65

Post by rascul »

lelanthran wrote: post #33
paavohtl wrote: post #17

Earlier quoted context omitted.

To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".

> To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects". Not in this case. It's the Rust evangelist who is the newcomer. FTA: > Almeida said that he is not trying to keep the C API static; his goal is to get the filesystem developers to explain the semantics of the API so that they c…

> Not in this case. It's the Rust evangelist who is the newcomer. FTA:

From a quick search, I've found that the person is somewhat active in kernel commits over the last four years (mostly but not all rust related from what I see) and is involved in some lkml stuff and some commits over a decade ago. Not sure if this makes him a newcomer or not, just wanted to provide a bit more context.

Re: Rust for Filesystems

#66

Post by drdo »

sanxiyn wrote: post #9
drdo wrote: post #7

Earlier quoted context omitted.

But unsafe blocks are available! And you should use them when you have to, but only when you have to. Using an unsafe block with a very limited blast radius doesn't negate all the guarantees you get in all the rest of your code.

Note that unsafe blocks don't have limited blast radius. Blast that can be caused by a single incorrect unsafe block is unlimited, at least in theory. (In practice there could be correlation of amount of incorrectness to effect, but same also could be said about C undefined behavior.) Unsafe blocks limit amount you need to get correct, but you need to get all of them correct. It is not a blast limiter.

That is of course correct.

The main value is that you only have to make sure that a small amount of code surrounding the unsafe block is safe, and hopefully you provide a safe API for the rest of the code to use.

Re: Rust for Filesystems

#67

Post by regularfry »

pjc50 wrote: post #54
regularfry wrote: post #48

Earlier quoted context omitted.

Given that undefined behaviour just means "undefined by the standard", do you get usefully closer to being able to identify a safe subset with the (MISRA/alternative, specific compiler, specific architecture) triple?

No, undefined behavior does not mean "not defined by the standard", it means those places where the standard says "undefined behavior". And then the long and complicated war over "the compiler may assume that UB does not happen and then optimize on that basis". You might be able to tighten it up in some specific cases, and those battles are being fought elsewhere, but there's stuff like lock lifetimes which you canno…

Sorry, yes - poor wording on my part.

Re: Rust for Filesystems

#68

Post by pjmlp »

The disconnect section of the article is a good example of exactly on how not to do the things, and how things can turn out sour if the existing community isn't taken for the ride.

Re: Rust for Filesystems

#69

Post by Firmwarrior »

paavohtl wrote: post #17
tucnak wrote: post #10

Earlier quoted context omitted.

They simply wish the actual kernel developers just surrendered & weren't in the way of new Rust code. Maybe if these guys wrote C for a living some 10 years or so, became maintainers in their own right, and THEN brought these ideas forward—they would have the chance. But you can't come to the other people's projects, and seriously expect them to just nod ahead to everything you have to say, surrender your concerns, a…

To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".

[flagged]

Re: Rust for Filesystems

#70

Post by jeroenhd »

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?

The author of the website details their issue with the way HN does moderation (which I can't say I disagree with, especially after HN intentionally disabled referrer headers for websites that take issue with HN). This only shows up if HN is in the referer URL.

I wouldn't call it a rant, but rather a polite request for HN policy to change.

Post reply on HN