Re: [dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-03-02 23:35, Thomas Monjalon:
> 2016-03-02 12:21, Thomas Monjalon:
> > 2016-03-02 11:47, Vincent JARDIN:
> > > Le 02/03/2016 09:27, Panu Matilainen a écrit :
> > > >>> I'd like to see these be merged.
> > > >>>
> > > >>> Jay
> > > >>
> > > >> The code is really not ready. I am okay with cooperative development
> > > >> but the current code needs to go into a staging type tree.
> > > >> No compatibility, no ABI guarantees, more of an RFC.
> > > >> Don't want vendors building products with it then screaming when it
> > > >> gets rebuilt/reworked/scrapped.
> > > >>
> > > >
> > > > Exactly.
> > > 
> > > +1 too
> > > 
> > > We need to build on this innovation while there is a path for kernel 
> > > mainstream. The logic of using a staging is a good one.
> > > 
> > > Thomas,
> > > 
> > > can we open a staging folder into the DPDK like it is done into the kernel?
> > 
> > It's possible to create a staging directory if everybody agree.
> > It is important to state in a README file or in the doc/ that
> > there will be no guarantee (no stable ABI, no validation and can be dropped)
> > and that it is a work in progress, a suggestion to discuss with the kernel
> > community.
> > 
> > The kernel modules must clearly target an upstream integration.
> 
> Actually the examples directory has been used as a staging for ethtool and
> lthread. We also have the crypto API which is still experimental.
> So I think we must decide among these 3 solutions:
> 	- no special directory, just mark and document an experimental state
> 	- put only kcp/kdp in the staging directory
> 	- put kcp/kdp in staging and move other experimental libs here

Any opinion? Are we targetting upstream work without any DPDK staging?

Please let's make clear the status of these patches.