You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can improve the vm-fdt abstractions after we publish an initial version of the crate so that we do not block the first release.
The current interface was built on purpose to be similar to the libfdt one, but we can optimize it (slightly) for Rust.
Things that can be improved are better abstractions for nodes. For example, we can have the property_* functions on the FdtWriterNode instead of FdtWriter so that we can disallow properties to be added in non valid locations (see #19).
The text was updated successfully, but these errors were encountered:
This sounds like a good idea to me - anything we can do to enforce valid DT output using API design is welcome.
I think it might be possible to use Rust's ownership/lifetime semantics to help with this as well; it would be good to ensure that a FdtWriterNode can only be passed to end_node on the FdtWriter that created it, for example. I tried to add a reference back to FdtWriter in FdtWriterNode when initially writing the Rust API, but I got stuck trying to get right lifetime annotations to make the borrow checker happy; maybe somebody with more Rust experience or more perseverance can help to figure this out.
We can improve the vm-fdt abstractions after we publish an initial version of the crate so that we do not block the first release.
The current interface was built on purpose to be similar to the libfdt one, but we can optimize it (slightly) for Rust.
Things that can be improved are better abstractions for nodes. For example, we can have the property_* functions on the
FdtWriterNode
instead ofFdtWriter
so that we can disallow properties to be added in non valid locations (see #19).The text was updated successfully, but these errors were encountered: