[dpdk-dev] [dpdk-web] [PATCH] add build system update as nice to have

Honnappa Nagarahalli Honnappa.Nagarahalli at arm.com
Sat Jan 18 01:10:01 CET 2020


<snip>
I think this is a good feature to have.

> 
> 2 thoughts on this, and adding dev list to discussion.
> 
> 1) This would only apply to make builds, I think. Any internal headers should
> not be passed to the "headers = " line in meson which tracks headers for
> installation only (all headers are found at build time in their original source
> locations, not by being copied to a central location, so internal-only headers
> need no action).
> 2) Not having some of these headers precludes the development of other
> out-of-tree drivers without the full DPDK source tree. This is probably not a
> major concern, but is there a use-case where we want to allow people to
> rebuild their own private drivers just using an installed DPDK instance? Based
> on that, I see three categories - regular public headers, headers for driver
> APIs (maybe for a dev package), and purely internal headers.
I cannot think of any advantage of developing out of tree drivers with an installed DPDK instance.
Do we need to do ABI for driver API headers? I hope not.

> 
> Regards,
> /Bruce
> 
> > -----Original Message-----
> > From: web <web-bounces at dpdk.org> On Behalf Of Ferruh Yigit
> > Sent: Friday, January 17, 2020 1:19 PM
> > To: web at dpdk.org
> > Cc: Thomas Monjalon <thomas at monjalon.net>; David Marchand
> > <david.marchand at redhat.com>
> > Subject: [dpdk-web] [PATCH] add build system update as nice to have
> >
> > Some headers in DPDK needs to be shared between various libraries,
> > these are treated as public header by build system and put into same
> > folder, other libraries can consume the header from this folder.
> > But this cause a side affect that internal headers exposed to the
> > application.
> >
> > A simple sample of this is 'rte_cryptodev_pmd.h', it is provided by
> > 'cryptodev' library and used by crypto PMDs, but this headers
> > shouldn't be used by applications.
> >
> > A solution can be using two different interim folders, one for public
> > headers and other for DPDK wide headers. DPDK components can look both
> > folders but only ones in the public header folder will be installed to
> > system folders.
> >
> > Cc: David Marchand <david.marchand at redhat.com>
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit at intel.com>
> > ---
> >  content/roadmap/_index.md | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/content/roadmap/_index.md b/content/roadmap/_index.md
> > index 6cb2e68..ea920bb 100644
> > --- a/content/roadmap/_index.md
> > +++ b/content/roadmap/_index.md
> > @@ -49,6 +49,7 @@ This list is obviously neither complete nor guaranteed.
> >  - default configuration from files
> >  - generic white/blacklisting
> >  - libedit integration
> > +- don't expose DPDK wide header to public, like rte_cryptodev_pmd.h
> >
> >  ### Cycle model {#cycle}
> >  ----
> > --
> > 2.24.1



More information about the dev mailing list