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

111–120 of 206 posts

Re: Rust for Filesystems

#111

Post by sandywaffles »

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…

I understood it as they're working to abstract as much as is generally and widely possible in the VFS layer, but there will still be (many?) edge cases that don't fit and will need to be handled in FS-specific layers. Perhaps the inode lifecycle was just an initial starting point for discussion?

Re: Rust for Filesystems

#112

Post by [deleted] »

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…

[deleted]

Re: Rust for Filesystems

#113

Post by tracker1 »

dralley wrote: post #97
Firmwarrior wrote: post #69

Earlier quoted context omitted.

[flagged]

Rust is a thing in the real world. Both Windows and Android are shipping, today, with meaningful components written in Rust. Amazon S3 and Lambda are built on top of Rust. Apple is hiring Rust developers and they post about it on this platform [ https://news.ycombinator.com/item?id=40849188 ]. Dropbox and Discord backend services are written in Rust. Cloudflare uses Rust very extensively in their infrastructure, whic…

Thanks for eloquently responding to the GP comment... My own thoughts have been with Microsoft, Apple, Mozilla and Amazon actively backing Rust, it is definitely not something that will just go away.

Personally, I've only done surface level things (API middle tier dev) with a few different Rust frameworks (Axum, etc) and it's been relatively nice for the level of performance and low overhead compared to Node, C# and others. And what lower level code I've read has been particularly pleasant to come to understand.

While doing something like a global cache in Rust feels awkward as all hell, many other patterns just feel really nice to use. I like the semantics of the language itself. I do hope that certain enterprise patterns typical in Java and the C# communities don't come into play in Rust though.

Re: Rust for Filesystems

#115

Post by moomin »

tupshin wrote: post #85
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…

This is not a notable challenge in rust, nor relevant to the article. The article is about finding ways of using rust to actually implement kernel fs drivers/etc. Note that any rust code in the kernel is necessarily consuming C interfaces. Bindgen works quite well for the use case that you are thinking. https://github.com/rust-lang/rust-bindgen

Yeah, the Rust proponents are being significantly more ambitious. Not just the ability to code a file system in Rust, but do it in a way that catches a lot of the correctness issues relating to the complex (and changing) semantics of FS development.

Re: Rust for Filesystems

#116

Post by bigstrat2003 »

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. Rust can offer a fresh perspective to these problems, but it's not a complete solution.

It's true that you need to have unsafe code to do low level things. But it's a misconception that if you have to use unsafe then Rust isn't a good fit. The point of the safe/unsafe dichotomy in Rust is to clearly mark which bits of the code are unsafe, so that you can focus all your attention on auditing those small pieces and have confidence that everything else will work if you get those bits right.

Re: Rust for Filesystems

#117

Post by tracker1 »

tucnak wrote: post #92
abenga wrote: post #86

Earlier quoted context omitted.

Hmmm. Is this serious or facetious? Or could be either, depending on the response? There already is rust code in the Linux kernel (some drivers), afaik.

Linus strategy on Rust is genius, albeit immoral. — Don't engage the movement head-on, make concessions where it doesn't matter. — Nobody wants to write drivers? No problem, have THEM write the drivers where the impact is minimal. I believe, if Rust people really understood how they're being used exactly, they wouldn't bother with it, and would go on to write more impactful code. And yet, Linus had managed to execute…

I seriously doubt it's meant as an insult so much as to minimize near term impact in case there are (and likely will be) mistakes to the larger ecosystem. Creating clearer separations for where Rust can make more sense initially is important. Not just for Rust, but C/C++ and other future languages all around.

The file system is an area where Rust can make a lot of sense, similar for network drivers. Points of interaction with underlying hardware and external systems where well defined controls are all the more important and widely interacted with.

I would be surprised, if within a decade a lot of the use of OpenSSL isn't displaced with rustls across a lot of applications even if not written in Rust directly.

Re: Rust for Filesystems

#118

Post by nickparker »

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.

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.

Re: Rust for Filesystems

#119

Post by lambda »

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…

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 hand, you can use a tool like bindgen to automatically generate those extern declarations from a C header file: https://github.com/rust-lang/rust-bindgen

There's an argument to be made that something like bindgen could be included in Rust, not requiring a third party dependency and setting up build.rs to invoke it, but that's not really the issue at hand in this article.

The issue is not the low-level bindings, but higher level wrappers that are more idiomatic in Rust. There's no way you're going to be able to have a general tool that can automatically do that from arbitrary C code.

Re: Rust for Filesystems

#120

Post by CGamesPlay »

sandywaffles wrote: post #109

I wasn't clear and am not familiar enough with the Linux FS systems to know if this Rust API would be wrapping or re-implementing the C APIs? If it's re-implementing (or rather an additional API) it seems keeping the names the same as the C API would be problematic and lead to more confusion over time, even if initially it helped already-familiar-developers grok whats going on faster.

> Almeida put up a slide with the equivalent of iget_locked() in Rust, which was called get_or_create_inode().

Seems like the answer is that it's reimplementing and doesn't use the same names.

Post reply on HN