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

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

[Ferruh Yigit]

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-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-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