Pure Rust implementation of littlefs

[enum-class]

Hi @geky, @sosthene-nitrokey @duanjr, and the littlefs community,

We’ve been following this discussion in here with great interest. To directly address the challenges of porting littlefs to idiomatic, safe, and maintainable Rust, we’ve developed an LLM-powered C-to-Rust transpiler that goes far beyond mechanical translation (e.g., C2Rust).

We’ve already run our end-to-end pipeline on the full littlefs codebase and are currently in active testing.

Early Metrics vs. C2Rust (on littlefs core):

Tool	RP decl	RP deref	RP arithmetic	Unsafe Line
Our tool	54	46	28	54
c2rust	378	1474	377	8903

RP = Raw Pointer

Key advantages of our tool output:

• Highly idiomatic: Uses Result, Option, iterators, Pin where appropriate
• Minimal unsafe: Only in well-encapsulated, reviewed modules (e.g., intrusive lists)

---

We’d love your feedback:

1. Are you open to reviewing a preview of the generated littlefs port?
   (We can share a public repo or draft PR with CI running C test equivalence.)

2. Initial thoughts on LLM-assisted transpilation for embedded code?
   (Especially given the safety/code-size tradeoffs discussed.)

3. Would a PR be welcome at this stage?
   Even as an experimental, parallel implementation (e.g., littlefs-rs), not to replace C, but to explore the design space.

We’re particularly excited to validate:

• Stack usage & code size on real MCUs
• Async API ergonomics

Looking forward to your thoughts, happy to hop on a call or share early artifacts.

Thanks again for the thoughtful discussion and for building such a solid foundation in littlefs!

Thanks
Saman

[geky]

Copying my comment from the other thread (#1112 (comment)):

@enum-class, I'm generally hesitant on the LLM front, especially when it comes to correctness-sensitive code, but I'll admit this is a really creative use case.

I would treat this the same as the rewrites proposed by @duanjr and @kokroo. The first step would be to publish the code in your own fork, to allow others to use/experiment with. Such as @sosthene-nitrokey has done with the littlefs2 crate.

Providing maintenance over an "official" Rust implementation is a different question that would be interesting to explore in the future. But it's not a high-priority. With littlefs3 on the horizon, fragmenting the codebase would be counterproductive.

User feedback is likely more interesting at this stage than maintainer feedback, if only because I have to get over the "oh hey, more work" impulse first.

---

Stack usage & code size on real MCUs

This is something I'm particularly interested in, and you don't necessarily need real hardware to explore. Most of the interesting numbers can be found at compile-time using GCC to cross-compile. Arm Thumb is currently the most popular architecture.

littlefs's Makefile and CI scripts may be a good starting point:

• make sizes
• gha install-thumb
• gha sizes

In theory these scripts work on any elf you can build, though I'm not sure if Cargo complicates things.

[geky]

To respond to specific questions:

1. Are you open to reviewing a preview of the generated littlefs port?
(We can share a public repo or draft PR with CI running C test equivalence.)

3. Would a PR be welcome at this stage?
Even as an experimental, parallel implementation (e.g., littlefs-rs), not to replace C, but to explore the design space.

My priority is on littlefs3. I'm interested in what we as a community can learn from such a port, but, to be blunt, contributing does not seem like the best use of the time I can allocate to the project.

2. Initial thoughts on LLM-assisted transpilation for embedded code?
(Especially given the safety/code-size tradeoffs discussed.)

Well if you want to know what I reaaaaaally think... You'd probably have to buy me a beer :P

I do worry you lose confidence whenever an LLM is involved. At least with traditional AST rewriting you have the guarantee that the semantics are preserved (including bugs!). With an LLM, my understanding is the only guarantee you have is that the code looks correct.

The other challenge, w.r.t. review and future maintenance, what do you think is more difficult: Learning how an LLM's codebase works? Or rewriting a codebase you understand in a different language?

• Async API ergonomics

As a C developer working on a C codebase, I don't think I have much to add. But it would be interesting to see what thoughts users have.