|
Description
|
While working on some layered topo code, I ran into a problem where
calling topo_fmri_getprop() was looking up properties in the wrong
node. My topology tree at the time looked like:
...
hc:///storage-enclosure=0/bay=0
...
hc:///bay=0
...
Attempting to look up anything in "hc:///bay=0" would incorrectly
return properties from "hc://storage-enclosure=0/bay=0". The
underlying problem is that TOPO_WALK_SIBLING doesn't actually do
a breadth-first search, despite the comments. step_sibling()
continues the search with TOPO_WALK_CHILD and any notion of
TOPO_WALK_SIBLING is lost. This ends up tripping up the folowing
code in hc_walker():
/*
* Special case for the root node. We need to walk by siblings
* until we find a matching node for cases where there may be multiple
* nodes just below the hc root.
*/
if (i == 0) {
if (strcmp(name, topo_node_name(node)) != 0 ||
inst != topo_node_instance(node)) {
return (TOPO_WALK_NEXT);
}
}
The problem is that we visit 'storage-enclosure=0' first, and
when we return TOPO_WALK_NEXT, we end up descending into the children
of that node without incrementing hcw_index, so when we then visit
'storage-enclosure=0/bay=0', we think we're still at the root level,
and the name/instance matches, and return the given node.
It seems like topo_walk_step() doesn't do a complete walk of the
tree, and it's up to the callback to initiate how to proceed through
the tree. If this is the case, it might just be a case of fixing
step_sibling() to do the correct thing. But I don't know enough about
how this code is supposed to work.
|