Skip to content

Conversation

@m4tx
Copy link
Collaborator

@m4tx m4tx commented Nov 24, 2025

No description provided.

@m4tx m4tx force-pushed the model branch 2 times, most recently from 9e8fc09 to 57db4ed Compare November 24, 2025 14:46
@m4tx m4tx requested a review from qwandor November 24, 2025 14:53
@m4tx m4tx force-pushed the model branch 2 times, most recently from e283557 to bb4e565 Compare December 9, 2025 11:05
Base automatically changed from fdt-memreserve to main December 9, 2025 11:47
pub mod error;
pub mod fdt;
pub mod memreserve;
#[cfg(feature = "write")]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks enabling the alloc feature without write has no meaningful effect, why not just have a single feature?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we might eventually have some functionality that will require the alloc crate, but won't be used for the intermediate DT representation (which requires its own set of additional libraries). For instance, in-place FDT modification might optionally require alloc crate to support extending the FDT size to relocate nodes when adding new data - but this is indeed too forward-looking and we can just re-introduce the feature flag then.

src/model/mod.rs Outdated
/// ```
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct DeviceTree {
pub(self) root: DeviceTreeNode,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't pub(self) the same as omitting pub entirely?

Copy link
Collaborator Author

@m4tx m4tx Dec 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, for some reason I thought that this makes the property visible in the child modules (which isn't even utilized in this PR, but at some point was in the next one), but indeed I was wrong. I'll just make this pub and remove the getter/setter methods (and add #[non_exhaustive] to the struct to avoid API breakages when we add new stuff here).

src/model/mod.rs Outdated
///
/// ```
/// # use dtoolkit::model::{DeviceTree, DeviceTreeNode};
/// let root = DeviceTreeNode::new("/");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if someone passes a node with a different name as the root? If there's no reason to do that, why not just construct the appropriate DeviceTreeNode within this new method?

Copy link
Collaborator Author

@m4tx m4tx Dec 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the device tree spec says:

The devicetree has a single root node of which all other device nodes are descendants. The full path to the root node is /.

I'll change this to create an appropriate root node here then. This isn't ideal, because the user can still do tree.root = DeviceTreeNode::new("foobar"), but I guess that's fine.

@m4tx m4tx requested a review from qwandor December 12, 2025 10:56
@m4tx m4tx merged commit 9d8fee9 into main Dec 12, 2025
25 checks passed
@m4tx m4tx deleted the model branch December 12, 2025 12:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants