sonic-swss-common: port to libyang3 #973
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| @@ -86,17 +86,17 @@ struct TableInfoMultipleList : public TableInfoBase | |||
| class DefaultValueHelper | |||
| { | |||
| public: | |||
| static int BuildTableDefaultValueMapping(struct lys_node* table, TableDefaultValueMapping& tableDefaultValueMapping); | |||
| static int BuildTableDefaultValueMapping(const struct lysc_node* table, TableDefaultValueMapping& tableDefaultValueMapping); | |||
There was a problem hiding this comment.
is it possible to use typedef to avoid these changes?
There was a problem hiding this comment.
Its not clear to me what you are asking. Libyang1 and libyang3 are not API compatible, lys_node no longer exists. There were significant changes between libyang1 and libyang2, then again between libyang2 and libyang3. SONiC is way behind the curve here.
Are you asking for me to do something to try to make this compile against both libyang1 and libyang3 rather than just a straight port to a new version? If so, what would be the advantage and why would it be worth the effort? There are over a dozen linked PRs to upgrading to libyang3 at this point and all will need to be merged en masse
There was a problem hiding this comment.
I mean if it's possible to use typedef/macro to encapsulate the data type and function in swss-common, which may avoid such scattered modification, and not sure this gonna be changed again if later upgrade to another version. Thanks for your effort for these PRs.
There was a problem hiding this comment.
Being on the outside from libyang development, I can't really predict what changes they may make in the future that are not backwards compatible. But I do know that libyang1 -> libyang2 was supposedly a complete rewrite to differentiate uncompiled vs compiled schema trees hence lys_ was split into lysp_ and lysc_ data types. libyang2 -> libyang3 was a less substantial change. I don't think trying to abstract the changes here would help, it would probably make it harder down the road.
They do maintain transition manuals here:
https://netopeer.liberouter.org/doc/libyang/master/html/transition1_2.html
https://netopeer.liberouter.org/doc/libyang/master/html/transition2_3.html
It "feels" like their API is stabilizing, its just SONiC started with a really early version so there are lots of changes needed.
Port from libyang1 to libyang3. This depends on changes to sonic-buildimage. Signed-off-by: Brad House (@bradh352)
bradh352
force-pushed
the
bradh352/libyang3
branch
from
b08a922 to
42f329d
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Port from libyang1 to libyang3. This depends on changes to sonic-buildimage.
Main Tracking PR here: sonic-net/sonic-buildimage#21679
Signed-off-by: Brad House (@bradh352)