Should we have this crate as no_std? about vm-fdt HOT 8 CLOSED

It would be great to have no_std support. We could make use of this in @hermit-os.

How can we help to move this forward? Can we open a PR, or would you rather do that yourself, @andreeaflorescu? :)

from vm-fdt.

It would be great to have no_std support. We could make use of this in @hermit-os.

How can we help to move this forward? Can we open a PR, or would you rather do that yourself, @andreeaflorescu? :)

Oh, I didn't get much time to work on that, so feel free to open a PR and I'll make time to review it. Here is my branch in case it helps with anything: https://github.com/andreeaflorescu/vm-fdt/commits/no_std

from vm-fdt.

Sounds great, I would support this as I might have a use for this in Rust Hypervisor Firmware.

from vm-fdt.

@danielverkamp what do you think? If this is needed sooner (before the error is stabilized), we can have it as an optional feature. I see that libc and serde also have a no_std option. The way that is implemented is by having std as the default feature. I think this could easily work for this crate as well.

Examples:

• https://github.com/serde-rs/serde/blob/master/serde/Cargo.toml#L35
• https://github.com/rust-lang/libc/blob/master/Cargo.toml#L24

from vm-fdt.

I agree making it no_std would be nice. I suppose since it still requires alloc, it may not be a good fit for really limited embedded environments, but no_std alone is a good improvement. I guess this would also justify a version bump.

The proposed change looks reasonable; the only minor concern I have is that each property_phandle() call becomes an O(n) operation (where n is the number of existing phandles), since it uses a linear search in a Vec rather than a HashSet lookup, but this is probably fine for any reasonably-sized devicetree. (Perhaps we could remove the duplicate phandle checking to avoid that, although I don't have a strong opinion about it.)

from vm-fdt.

I agree making it no_std would be nice. I suppose since it still requires alloc, it may not be a good fit for really limited embedded environments, but no_std alone is a good improvement. I guess this would also justify a version bump.

We can extend it once we have it as no_std to also have it as no_alloc I guess. I think we can have static allocation for the data blob, but this require some significant re-working of how it currently works, so I would leave it for the next iteration.

The proposed change looks reasonable; the only minor concern I have is that each property_phandle() call becomes an O(n) operation (where n is the number of existing phandles), since it uses a linear search in a Vec rather than a HashSet lookup, but this is probably fine for any reasonably-sized devicetree. (Perhaps we could remove the duplicate phandle checking to avoid that, although I don't have a strong opinion about it.)

Yes, in my branch I did a quick and dirty fix to get it to compile, I would improve that for the actual PR.

from vm-fdt.

I think having alloc is very common for many no_std users so I wouldn't worry about that too much for a first version.

from vm-fdt.

I opened #68.

from vm-fdt.