Introduce a NodeId type - #50
Conversation
| let node_addr = (self.this as *const RawNode<<P as Parser<'a>>::Granularity>).addr(); | ||
| let strings_addr = self.strings.0.as_ptr().addr(); | ||
| NodeId(strings_addr - node_addr) | ||
| } |
There was a problem hiding this comment.
Alternatively the Node could gain an index field which is filled with the amount of nodes before the current node. This would make the Node type a bit larger though.
There was a problem hiding this comment.
I like the addition of a NodeId but using the pointer values feels a bit odd—though given that addresses are committed to being stable by this point, I suppose it doesn't really matter much what the addresses are. any scenarios that you could see this causing an issue? my mind is vaguely concerned about interactions with some future APIs but having a difficult time coming up with anything concrete given the data is supposed to be read-only at this stage.
There was a problem hiding this comment.
Yeah, if you ever add a mutation API, the current implementation would be problematic. In that case either the docs of .id() could be updated to indicate that edits invalidate all ids (presumably a kernel would only use it for overlays, which are applied before drivers start), or you could store NodeIds directly in the tree (assuming you expand the dtb to a heap allocated tree for easier edits)
|
I figured out an alternative for my purposes. I could still see it useful for others though. |
This can be used to check if two Node's are actually the same node. And it can be used as BTreeMap or HashMap key to map from a Node to OS data associated with this device like the active driver.
|
LGTM, if we need to mess with it in the future shouldn't be a big deal |
2 participants
This can be used to check if two Node's are actually the same node. And it can be used as BTreeMap or HashMap key to map from a Node to OS data associated with this device like the active driver.