On Thu Jun 19, 2025 at 11:48 PM CEST, Viacheslav Dubeyko wrote:
> On Thu, 2025-06-19 at 22:22 +0200, Miguel Ojeda wrote:
>> On Thu, Jun 19, 2025 at 9:35 PM Benno Lossin <lossin@xxxxxxxxxx> wrote:
>> >
>> > There are some subsystems that go for a library approach: extract some
>> > self-contained piece of functionality and move it to Rust code and then
>> > call that from C. I personally don't really like this approach, as it
>> > makes it hard to separate the safety boundary, create proper
>> > abstractions & write idiomatic Rust code.
>>
>> Yeah, that approach works best when the interface surface is
>> small/simple enough relative to the functionality, e.g. the QR code
>> case we have in the kernel already.
>>
>> So there are some use cases of the approach (codecs have also been
>> discussed as another one). But going, in the extreme, "function by
>> function" replacing C with Rust and having two-way calls everywhere
>> isn't good, and it isn't the goal.
>>
>> Instead, we aim to write safe Rust APIs ("abstractions") and then
>> ideally having pure Rust modules that take advantage of those.
>> Sometimes you may want to keep certain pieces in C, but still use them
>> from the Rust module until you cover those too eventually.
>>
>
> Yeah, I completely agree. But I would like to implement the step-by-step
> approach. At first, introduce a Rust "library" that will absorb a "duplicated"
> functionality of HFS/HFS+. And C code of HFS/HFS+ will re-use the functionality
> of Rust "library". Then, elaborate "abstractions" (probably, HFS/HFS+ metadata
> primitives) and test it in Rust "library" by calling from C code. And, finally,
> completely switch to Rust implementation.
So the difficult part is the back and forth between Rust and C. You'll
have to write lots of glue code to make it work and that's why we don't
recommend it.
You can of course still build the driver step-by-step (and I'd recommend
doing that). For example the Nova driver is being built this way.
---
Cheers,
Benno
