New Linux Kernel Patches Begin Plumbing Rust Support Into Bcachefs Driver

[bug77]

I'm quoting your post just to signal boost it. The lack of moderation is so bad that I sometimes wonder if it's intentional to get more ad impressions or something. I really hope not because I feel like more people would actively participate and even donate if the forum was cleaned up.

It's definitely intentional, it's one of the few revenue sources Michael has.
At the same time, it's not as bad as you think. It used to be much worse, to the point I took a couple if years off, only reading the articles and not touching the forums.

[bug77]

Oh no how dare I speak against the circlejerk of trolls. How can someone disagree? Impossible! Must be trolling...

Disagree with what, exactly? Some developers have decided to give Rust a try. What's there to disagree about?

[cb88]

Any computing platform that is fast enough for it to even make sense to use bcachefs already has rustc support anyway... basically ARM / Power / x86 / RISC-V what other architecture are you seriously going to run it on?

[Quackdoc]

Pretty exciting stuff, I know rust has been wanted for bcachefs for a long time now, and more rust in the kernel is something I will always be excited for.

[dlq84]

And the reason for this is? They removed a feature you wanted or?

Some people here are so invested in their Rust hate that it's their religion at this point.

[dekernel]

I am hoping that I simply am not fully understanding just how the merging of two languages into a driver will work because attempting this in the past several different times and different languages caused some serious uneligance (just made that word up) in the implementation for me. What started out as straight-forward ended up with enough glue code to cover edge cases that eventually caused regrets. My first foray was bringing together PL/M and C code many years ago and the last was C++ and Obj-C. I am hoping for their sake that the compilers play together much better than they did back then so I have my fingers crossed for them that they are smarter than myself...which really should not be an issue .

[Quackdoc]

I am hoping that I simply am not fully understanding just how the merging of two languages into a driver will work because attempting this in the past several different times and different languages caused some serious uneligance (just made that word up) in the implementation for me. What started out as straight-forward ended up with enough glue code to cover edge cases that eventually caused regrets. My first foray was bringing together PL/M and C code many years ago and the last was C++ and Obj-C. I am hoping for their sake that the compilers play together much better than they did back then so I have my fingers crossed for them that they are smarter than myself...which really should not be an issue .

rust and C actually play together pretty nicely, it's for sure not better then just a single lang, but the goal is to gradually port from C to rust over time from what I understand, C and Rust play together nicely enough for this

[Volker Schmidt]

I have to admit, I don't like it. If they would do a pure Rust implementation, fine. It is worth a try, and we could compare the results and let the better system win (and better here clearly includes saver and easier to maintain). But mixing the code between two languages, requires that future developers are excellent in both languages. To me that sound like a entry barrier, that will make debugging issues (and yes there will be some) a very nasty business.

[hyperchaotic]

I have to admit, I don't like it. If they would do a pure Rust implementation, fine. It is worth a try, and we could compare the results and let the better system win (and better here clearly includes saver and easier to maintain). But mixing the code between two languages, requires that future developers are excellent in both languages. To me that sound like a entry barrier, that will make debugging issues (and yes there will be some) a very nasty business.

This seems like guessing. The code is quite modular and it will be separate modules that already have a well defined interface between them that are rewritten, remember Rust uses C as a FFI already. In my experience this is not anymore difficult to debug than anything else, as long as I have good tracing in place. It's really not a big issue for a kernel or driver developer. The big barrier to getting more developers is learning to understand the BCacheFS design in general but rewriting small parts in Rust is a good way of getting to know BCacheFS, the idea might even attract some as we have seen on other projects.

[Brane215]

Edit: Seeing Kent's response, he is all in for rewriting things in Rust. As long the C implementation is removed. This makes it almost certain that large portions of bcachefs will be RIIRed with the C implemntations thrown away, causing a rustc dependency.

But it will weed out whole class of race conditions and voulnerabilities. Of the kind that pops up ever now and then even in kernel.
Which is kind of important for a FRIGGIN KERNEL FILESYSTEM DRIVER, don't you think ?