Re: [ANNOUNCE] iommu-2.6.git tree

From: Ingo Molnar
Date: Mon Oct 20 2008 - 04:52:58 EST

* David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at