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

31–40 of 206 posts

Re: Rust for Filesystems

#31

Post by renox »

aoieu wrote: post #25
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…

Perhaps a better approach would have been for Linus to design his own backwards-compatible and safer fork of the C language, and have the kernel gradually rewritten in that. He's already written - with a considerable amount of collaboration of course - the world's most popular kernel and the world's most popular source control system. I expect he'd be able to do the same for a new and improved systems language if he…

Note that the Linux kernel is already written with C 'extensions' not in pure C.

Re: Rust for Filesystems

#32

Post by riffraff »

formerly_proven wrote: post #24
atoav wrote: post #15

Earlier quoted context omitted.

But I'd rather have 50 lines of nuclear fissile code that needs to be correct than say the whole software. The danger of Rust it that you twist yourself into a bretzel in order to avoid unsafe, while you should have in fact made a exceptionally well tested and designed unsafe block that is surrounded by code that the compiler checks for you. I am still convinced that the naming choice for unsafe has some effects that…

dangerzone { ... }

I feel thinking of the song would make people more willing of going into the danger zone than otherwise.

Re: Rust for Filesystems

#33

Post by lelanthran »

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

> 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 can be encoded into Rust.

The responses from the kernel team members to the proposal seem reasoned and mature to me:

> In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work?

> As the C code evolves, which will happen more quickly than with the Rust code, at least initially, there will be a need to keep the two APIs in sync.

> The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs.

> Encoding a single lifecycle understanding into the API means that its functions will not work for some filesystems.

> Part of the problem, Ted Ts'o said, is that there is an effort to get "everyone to switch over to the religion" of Rust; that will not happen, he said, because there are 50+ different filesystems in Linux that will not be instantaneously converted.

> Bottomley said that as more of those semantics get encoded into the bindings, they will become more fragile from a synchronization standpoint

> But Ts'o pointedly said that not everyone will learn Rust; if he makes a change, he will fix all of the affected C code, but, "because I don't know Rust, I am not going to fix the Rust bindings, sorry".

Re: Rust for Filesystems

#34

Post by rcxdude »

aoieu wrote: post #4

[flagged]

It sounds more like it's mostly the standard kind of debate that happens over any significant API change in the kernel: you always get a variety of opinions on what the right way to do things. The additional complication is this by necessity is a parallel API and in a language which not everyone in the kernel knows, so there's some additional discussion about who's responsible for keeping thing in sync.

Re: Rust for Filesystems

#35

Post by pjc50 »

aoieu wrote: post #25
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…

Perhaps a better approach would have been for Linus to design his own backwards-compatible and safer fork of the C language, and have the kernel gradually rewritten in that. He's already written - with a considerable amount of collaboration of course - the world's most popular kernel and the world's most popular source control system. I expect he'd be able to do the same for a new and improved systems language if he…

> backwards-compatible and safer

Pick one.

The safety is achieved by eliminating constructs which cannot be proven to be safe. Additionally, Rust-style safety involves adding more information explicitly to the source which otherwise has to be kept in the programmer's head (or externally like sel4): object lifetimes, lock rules (see original article), etc.

At best you end up with "first wrap all your original code in 'unsafe' and then gradually move the safety boundary", but even that is very difficult.

Re: Rust for Filesystems

#36

Post by thrance »

aoieu wrote: post #28
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.

[flagged]

There are obvious differences between criticism and harassment. Let's not act like we don't know why the asahi linux team is getting death threats, and maybe try to improve the situation.

Re: Rust for Filesystems

#37

Post by erdii »

olivermuty wrote: post #20
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.

"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 want to stop someone from bullying someone else into their own suicide!

hastily jotted rant for the folks who'd like to complain about "politics" from creeping into every discussion everywhere:

It's really sad to see so many folks disconnecting and immediately dismissing whole groups of other folks as soon as they start complaining about an issue they have because of "politics". :(

I get that you don't want to get involved in shit flinging shows and that its tedious to figure out who's in the right and who's in the wrong. Especially because there are never clear answers. If you feel like this and then proceed to complain about 'politics' creeping everywhere, please beware of this:

Pretending to be apolitical doesn't work most of the time, as politics is basically another word for "acting (or deliberately not-acting) in some kind of public sphere" which you all do, and when the "policitics" have arrived at a topic, then they'll stay there at least in that specific case you are witnessing! You just are part of a hyperconnected and confusing world with a lot of conflict, wether you like it or not.

Pretending to be apolitical also serves the upholding of whatever status quo is currently in place because anything that has even a slight chance of changing anything is inherently a political topic.

Please don't turn your heads on "political" topics or, at least, don't complain about it in that way as it mostly enables unjust behaviour to continue. It doesn't even matter if it's the person who brought up the "political" stuff who is acting unjust or the folks they're complaining about). In both cases it's probably better to either avoid commenting at all or to convey your critical thoughts to that "political" conversation.

Re: Rust for Filesystems

#38

Post by pjc50 »

thesnide wrote: post #3
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.

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

Re: Rust for Filesystems

#39

Post by pjc50 »

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 refuse to believe that any single person would not want to stop someone from bullying someone else into their own suicide!

There are plenty of people who do want the freedom to say exactly what they choose, including a lengthy period of directed harassment, and shrug their shoulders if someone commits suicide over it. There's not much that can be done other than ban them from civilized spaces.

Re: Rust for Filesystems

#40

Post by pjc50 »

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.

Post reply on HN