[dpdk-dev] git trees organization

[Thomas Monjalon]

12/09/2017 10:32, Bruce Richardson:
> On Tue, Sep 12, 2017 at 12:03:30AM +0200, Thomas Monjalon wrote:
[...]
> > At the same time, we can think how to add more git sub-trees:
> 
> In principle, I'm in favour, but I think that the subtrees of the master
> tree should be at a fairly coarse granularity, and not be too many of
> them. The more subtrees, the more likely we are to have issues with
> patchsets needing to be split across trees, or having to take bits from
> multiple trees in order to test if everything is working.
> 
> > Should we create next-net-intel for Intel networking drivers?
> 
> Given the number and size of intel drivers, this seems reasonable to
> start as a second-level subtree.

OK, we need the name of a volunteer :)

> > Any volunteer?
> > 
> > Should we create next-bus for bus API and drivers?
> > Stephen Hemminger is working on a new bus.
> > Would you be interested by taking the responsibility of this git tree?
> 
> Is this something that is going to need ongoing work and maintenance, or
> just something that would be needed while the current rework of
> introducing bus types is being done? If the former, a tree makes sense,
> but not if it's the latter case.

We are going to have many bus drivers (pci, vdev, fslmc, vmbus).
If we look only at PCI, there are always some new patches to improve
or fix things. So I think it is reasonnable to imagine that we will
have some real activity with all bus drivers.

> > Should we create next-mem for malloc/mempool?
> > 
> Core libs tree, encompassing eal, mempool and 1 or 2 others? I don't
> think memory should have its own tree initially.
> 
> > Should we take ethdev patches into next-net?
> 
> Definitely! I think not doing so was a bit of a mistake when net tree
> was spun off.

Sure it was a mistake, but it was assumed because net drivers is already
a big work. I hope we can add it now while moving Intel drivers to
a second level sub-tree.

> > Other suggestions?
> 
> Similar to above, cryptodev should be in crypto tree, eventdev in event
> tree etc.

It is already the case. No change to do here :)

> Other than that, all I can say is "let's do it!". We have quite a
> backlog to get through for 17.11, so anything that moves things along
> faster is to be welcomed.

Yes!