* Re: Rust library?
2025-11-20 22:10 Rust library? Simon Glass
@ 2025-11-21 4:13 ` David Gibson
2025-12-05 22:29 ` Rob Herring
1 sibling, 0 replies; 3+ messages in thread
From: David Gibson @ 2025-11-21 4:13 UTC (permalink / raw)
To: Simon Glass; +Cc: Devicetree Compiler, Rob Herring
[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]
On Thu, Nov 20, 2025 at 03:10:01PM -0700, Simon Glass wrote:
> Hi,
>
> Does anyone know of a good / official Rust library for libfdt?
>
> If not, this one[1] seems somewhat sane, although a bit limited. Would
> it make sense to try to create an 'official' version based on that? It
> would need quite a bit of work as it only supports reading.
>
> Any advice or thoughts are welcome!
I'd love to have a Rust library as part of the dtc/libfdt repository.
I've thought about doing it, but never had remotely enough time to
get anywhere.
There are a couple of extra complexities to consider.
# Bindings versus new library
Normally when presenting a library in several languages, I'd suggest
writing it in just one, and making a minimal binding wrapper for
others (like pylibfdt is a binding to libfdt at the moment).
In this case, though, while it certainly would be possible to write
Rust wrappers around the C library, I'm not sure it's a good idea. I
don't think the C library's interface would be particularly natural in
Rust. More significantly, it would be good to use Rust's features to
make the interface safer to use: e.g. I think it should be possible to
use the borrow checker to prevent a user from inadvertently re-using
an offset across a call to a read-write function (a subtle gotcha in
the libfdt interface). The mutable-xor-shared model is a good match
for safely manipulating an fdt.
Similarly, I don't think writing C bindings on top of a Rust library
would work well. Taking an interface that's natural and safe with the
borrow checker would likely be not just theoretically unsafe, but
wildly easy to misuse once accessed via C. Maybe I'm wrong about
that, though. But even then, being able to run anywhere - including
weird constrained systems - is an explicit design goal of libfdt, and
requiring a Rust compiler would be a big step away from that.
So, it seems likely that we'd need to maintain two separate libraries,
which isn't ideal. On the plus side, we should be able to cross-test
them.
# Memory allocation
libfdt is allocation free, by design. It's certainly possible to
write allocation-free Rust code, but I'd say it requires a bit more
discipline even than in C. We'd definitely want an allocation-free
#[no_std] library.
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread