Currently there are no semantic dependencies: - lisp_adjacency is used just by lisp
- counter types by vnet_interface_counters, But in the future it would be beneficial to have for example 'string' or 'ip-address' type. It would make Java/Python and perhaps other language binding easier to use. Few months ago we had a meeting to identify possible vpe.api improvements required by language bindings. One of them was to use custom types instead of byte arrays where possible: https://wiki.fd.io/view/VPP/API_Concepts#Type_issues Regards, Marek From: Dave Barach (dbarach) Sent: 31 października 2016 12:43 To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgrad...@cisco.com>; Luke, Chris <chris_l...@comcast.com>; vpp-dev@lists.fd.io Subject: RE: Clean-up tasks: 17.01 F0 -> RC0 The reorganization that I described has to do with reducing merge conflicts on .api files, and to placing API definitions and their message handlers near the feature code that they control. None of this has to do with semantic dependency of any kind. Except between foo_t and foo_reply_t - which would certainly end up in the same .api file = what kind of dependencies are there? Thanks... Dave From: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) Sent: Monday, October 31, 2016 5:53 AM To: Dave Barach (dbarach) <dbar...@cisco.com<mailto:dbar...@cisco.com>>; Luke, Chris <chris_l...@comcast.com<mailto:chris_l...@comcast.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: RE: Clean-up tasks: 17.01 F0 -> RC0 Hi, Great idea! It would make Java/Python APIs more manageable as well => we could group related APIs in packages/namespaces. But have you considered dependencies between the groups? It could be useful for example to be able to define a custom type that is used in two different groups. Regards, Marek From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Dave Barach (dbarach) Sent: 28 października 2016 00:02 To: Luke, Chris <chris_l...@comcast.com<mailto:chris_l...@comcast.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Clean-up tasks: 17.01 F0 -> RC0 It's an SMT [simple matter of typing] to create a number xxx.api files, related message handler implementation files, and to place them next to whatever the indicate API collection controls. The current setup is a historical artifact. Thanks... Dave From: Luke, Chris [mailto:chris_l...@comcast.com] Sent: Thursday, October 27, 2016 4:19 PM To: Dave Barach (dbarach) <dbar...@cisco.com<mailto:dbar...@cisco.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: RE: Clean-up tasks: 17.01 F0 -> RC0 Sounds good to me. The api files in particular strike me as unmanageably large right now. I've especially wondered if the API code for each "thing" can move physically closer the "thing" it provides an interface for. Chris. From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Dave Barach (dbarach) Sent: Thursday, October 27, 2016 4:07 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] Clean-up tasks: 17.01 F0 -> RC0 Folks, I'd like to suggest that we undertake several clean-up tasks once we reach the 17.01 F0 (API freeze) milestone: * Clean up Coverity warnings * Split .../vpp/vpp-infra/{vpe.api, api.c} into groups of related APIs, to reduce future merge collisions * Finish .../vnet coding standards cleanup * Add documentation Thoughts? Thanks... Dave
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
