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
I have a question about empty trees. In FRR we initialize a new tree by calling, dnode = NULL; lyd_validate_all(&dnode, NOSTATE); This is nice that it gets us a dnode (and more apparently) to use as a tree anchor.
I was replicating this behavior with the python libyang bindings, and it got me to wondering what exactly was being put in these dnodes. I only loaded a single module (frr-logging.yang) (and ietf-syslog-types for it's identities), and the root node it returns is a DNode named logging. What's interesting is that in the module itself the root is container logging {} so it seems like the DNode being returned is special in some way (as it's not a DContainer and the container is non-presence container at that).
Is this documented anywhere? I'd like to better understand what this non-container node for a container node is and what I can expect from it (API guarantee-wise).
BTW, I actually need an supported way to do the above, currently I have to use _libyang.ffi etc to invoke lyd_validate_all() directly as the only python binding for validate call is currently a method of DNode
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a question about empty trees. In FRR we initialize a new tree by calling,
dnode = NULL; lyd_validate_all(&dnode, NOSTATE);
This is nice that it gets us a dnode (and more apparently) to use as a tree anchor.I was replicating this behavior with the python libyang bindings, and it got me to wondering what exactly was being put in these dnodes. I only loaded a single module (
frr-logging.yang
) (and ietf-syslog-types for it's identities), and the root node it returns is aDNode
namedlogging
. What's interesting is that in the module itself the root iscontainer logging {}
so it seems like the DNode being returned is special in some way (as it's not aDContainer
and the container is non-presence container at that).Is this documented anywhere? I'd like to better understand what this non-container node for a container node is and what I can expect from it (API guarantee-wise).
BTW, I actually need an supported way to do the above, currently I have to use
_libyang.ffi
etc to invokelyd_validate_all()
directly as the only python binding for validate call is currently a method ofDNode
Beta Was this translation helpful? Give feedback.
All reactions