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

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

[Richardson, Bruce]

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.

Regards,
/Bruce

> -----Original Message-----
> From: web <web-bounces@dpdk.org> On Behalf Of Ferruh Yigit
> Sent: Friday, January 17, 2020 1:19 PM
> To: web@dpdk.org
> Cc: Thomas Monjalon <thomas@monjalon.net>; David Marchand
> <david.marchand@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@redhat.com>
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@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

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

[Honnappa Nagarahalli]

<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@dpdk.org> On Behalf Of Ferruh Yigit
> > Sent: Friday, January 17, 2020 1:19 PM
> > To: web@dpdk.org
> > Cc: Thomas Monjalon <thomas@monjalon.net>; David Marchand
> > <david.marchand@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@redhat.com>
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@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