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.