Re: [ANNOUNCE] iommu-2.6.git tree

[Ingo Molnar <mingo@elte.hu>]

* David Woodhouse <dwmw2@infradead.org> wrote:

> On Sun, 2008-10-19 at 23:14 +0200, Joerg Roedel wrote:
> > This is a reason for a seperate Intel IOMMU tree which is pulled by
> > Linus. But I don't think that this is a reason to take over control of
> > all IOMMU development.
> 
> I have no intention of taking over control of anything, if I can 
> possibly avoid it. The _less_ patch-monkey work I have to do, the 
> happier I'll be. There's more to life than Jon's patch statistics.
> 
> I'm perfectly happy for Ingo to pull my tree into his, as I keep 
> saying. As long as it gets into linux-next, that's fine.
> 
> When I discussed it with Thomas a few weeks ago, he seemed to be 
> suggesting that creating a new tree was the best thing to do, but I'm 
> more than happy to adapt.

Creating a new Git tree is a good thing to do in any case - as i 
expressed it to you earlier as well, repeatedly. I told it you a month 
ago and later as well. Here's that portion of my mail to you from Sept 
22:

| > I'm also planning to create a separate git tree for iommu work, 
| > where we can all have direct access. It doesn't really live in the 
| > x86 tree.
|
| the separate git tree is sure useful for the Intel IOMMU bits.
|
| Note that this all affects the x86 tree very significantly so please 
| send pull requests to us like Joerg does it for the AMD-IOMMU bits and 
| then we'll integrate and send it upstream from there.

A number of non-x86 and x86 contributors to various tip/* topics do that 
already and it's a great help to be able to pull Git trees, as it scales 
the maintenance overhead.

We already do it for tip/sched/* topics and tip/tracing/* topics 
-neither of which has anything to do with the x86 trees, and all of 
these feed into linux-next independently of any x86 bits. We'd obviously 
pull from you and send it towards Linus. (Long term we want to 
eventually reach the kind of sub-maintainer setup that DaveM does so 
well with the networking tree.)

There's tip/core/iommu for generic / non-x86 bits - should any such bits 
show up. And out of caution, despite all IOMMU work being currently 
centered around x86, we've got a separate tip/auto-iommu-next as well, 
integrated into linux-next independently of the x86 tree.

What was not fine for you was to declare tip/auto-iommu-next the 'old' 
tree and to request a zapping of linux-next's auto-iommu-next 
integration, unilaterally.

If all IOMMU developers and Andrew/Linus want that to happen and want 
you to maintain it all then sure i have no objections - but based on the 
history of this code there will be ongoing integration trouble as 90% of 
the current IOMMU activities are centered around x86 and is actually 
done by x86 developers, for obvious reasons. linux-next needs another 
source of integration trouble like a sore tooth.

	Ingo