On Tue, Jan 14, 2020 at 09:35:33AM +0100, David Marchand wrote: > Hey Eelco, > > On Mon, Jan 13, 2020 at 4:57 PM Eelco Chaudron <echau...@redhat.com> wrote: > [snip] > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c > > index 128963f..3f164c8 100644 > > --- a/lib/netdev-dpdk.c > > +++ b/lib/netdev-dpdk.c > > @@ -26,7 +26,10 @@ > > #include <sys/socket.h> > > #include <linux/if.h> > > > > +/* The below is needed as rte_meter.h gets included trough rte_bus_pci.h. > > */ > > +#define ALLOW_EXPERIMENTAL_API > > #include <rte_bus_pci.h> > > +#undef ALLOW_EXPERIMENTAL_API > > __rte_experimental is getting defined at the first inclusion of > rte_compat.h, so here rte_bus_pci.h is the first one. > __rte_experimental ends up being a big "all or nothing" switch, so we > don't need to #undef. > > Cc: Neil if he has a better idea/comments. > If I'm reading this properly, I think the request here is to have finer grained control over the use of experimental API's?
If so, What fine grained control are you looking for? Do you just want to not get the warning about a symbol being experimental only for the API exported in rte_bus_pci.h, but not others? If thats the case, I would make the argument that the right (or perhaps just the more prduent) thing to do would be to accept that you're getting warnings during the build, and that they are expected for those particular API calls. If you want to record that fact, I would do so at the call site, using whatever syntax covscan or other linters use to record the fact that you expect the warning there. Thats actual documentation, and saves you the odd ifdeffery above, and below Neil > > #include <rte_config.h> > > #include <rte_cycles.h> > > #include <rte_errno.h> > > @@ -35,7 +38,9 @@ > > #include <rte_flow.h> > > #include <rte_malloc.h> > > #include <rte_mbuf.h> > > +#define ALLOW_EXPERIMENTAL_API > > #include <rte_meter.h> > > +#undef ALLOW_EXPERIMENTAL_API > > #include <rte_pci.h> > > #include <rte_version.h> > > #include <rte_vhost.h> > > > -- > David Marchand > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
