Hello folks, I've just sent 3 patches addressing issues in LCP [0] [1] [2]. First one for marking APIs in progress. 2nd only for s/namespace/netns/g. 3rd fixes endian issues in different methods. One thing I can't understand - if the "autoendian" keyword is specified for API type - I should use macros end with _END, right? It worked for lcp_itf_pair_add_del_v2 and lcp_default_ns_get, but for some reason it doesn't work for lcp_itf_pair_details (though the type is also marked with "autoendian"). Any inputs here much appreciated.
Thanks guys [0] - https://gerrit.fd.io/r/c/vpp/+/36708 [1] - https://gerrit.fd.io/r/c/vpp/+/36709 [2] - https://gerrit.fd.io/r/c/vpp/+/36710 On Fri, 15 Jul 2022 at 17:41, Matthew Smith via lists.fd.io <mgsmith= netgate....@lists.fd.io> wrote: > Hi Andrew, > > Neale and I are the maintainers of linux-cp. I am ok with changing it in > place because the use of "namespace" is preventing Stanislav from even > being able to compile his code. > > When you say "mark the APIs as experimental" are you talking about putting > "state: experimental" in the FEATURE.yaml file or something else? If you're > talking about FEATURE.yaml, the file at src/plugins/linux-cp/FEATURE.yaml > already lists the state as experimental. Maybe the formatting of the file > is bad? > > Thanks, > -Matt > > > On Fri, Jul 15, 2022 at 4:14 AM Andrew Yourtchenko <ayour...@gmail.com> > wrote: > >> Hi Stanislav, >> >> The api is marked as “Production” so the behavior of checkstyle is there >> to protect the users (as for the duplication - it is a choice to do it once >> in VPP or in each and every downstream consumer). As for the pure code >> exercise - I just did it for the sake of a test, took a grand total of 15 >> minutes to add the new message versions. Hardly a massive deal. (We could >> probably improve tooling on the lifecycle management of these, though) >> >> That said - for this specific case - is the presence of the “namespace” >> member in a structure within the api a showstopper for you - that is, does >> it cause a compilation failure of some sort ? If so - one option is to >> mark the APIs as experimental and then change it in-place. It is up to >> component owners to decide the policy. >> >> --a >> >> On 15 Jul 2022, at 09:39, Stanislav Zaikin <zsta...@gmail.com> wrote: >> >> >> Hello folks, >> >> According to [0] it should be possible to add breaking changes to vpp api >> with incrementing the major version of the api. There's one issue in the >> LCP api - a C++ keyword "namespace" is used there and I want to change it >> to "netns" and increase a major version. But make checkstyle-api still >> fails. Any ideas? >> >> Of course, I can add new methods _v2 and deprecate the older ones. But >> it'd lead to code duplication and still I'd need to wait at least 2 >> releases. >> >> [0] https://wiki.fd.io/view/VPP/API_Versioning >> >> -- >> Best regards >> Stanislav Zaikin >> >> >> >> >> >> >> > > > -- Best regards Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21685): https://lists.fd.io/g/vpp-dev/message/21685 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
