[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081019211449.GG21841@8bytes.org>
Date: Sun, 19 Oct 2008 23:14:49 +0200
From: Joerg Roedel <joro@...tes.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
fenghua.yu@...el.com, tony.luck@...el.com,
suresh.b.siddha@...el.com, sfr@...b.auug.org.au,
andreas.herrmann3@....com, joseph.cihula@...el.com,
akpm@...ux-foundation.org, jbarnes@...tuousgeek.org,
tglx@...utronix.de, torvalds@...ux-foundation.org, mingo@...e.hu
Subject: Re: [ANNOUNCE] iommu-2.6.git tree
On Sun, Oct 19, 2008 at 12:19:58PM +0100, David Woodhouse wrote:
> On Sun, 2008-10-19 at 13:12 +0200, Joerg Roedel wrote:
> > On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
> > > As previously threatened, I've created an iommu-2.6.git tree:
> > > git://git.infradead.org/iommu-2.6.git
> > > http://git.infradead.org/iommu-2.6.git
> >
> > Is there a specific reason why IOMMU stuff should go to Linus without
> > testing them in the x86 tree before? The DMA layer and IOMMU drivers are
> > an integral component of the architecture and patches for it are best
> > placed in the architecture tree instead of a seperate one, imho.
>
> This is the purpose that linux-next serves, not the x86 forest-of-doom.
>
> And I thought Ingo said his old iommu tree wasn't in there anyway? He
> said it was somewhere else, although I haven't actually managed to
> _find_ it.
Its quite easy to learn the workflow of the x86 maintainers with the
-tip tree. Just ask them, they are very responsive and friendly. I
personally like that workflow with lots of topic branches. It gives a
clear history of development.
> The Intel IOMMU appears on IA64 too, and doesn't want to be developed
> and tested off in an x86-specific corner by itself.
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.
> And I'm going to be looking at other generic things we can do to
> improve IOMMU-related performance, which will touch on other
> architectures too.
As IOMMU infrastructure is architecture-local in Linux (except the
very high level interface -> DMA-API) there is not much room for
optimization which will touch multiple architectures. If Intel IOMMU is
available on x86 and ia64 its definitly different for that driver. This
is another reason for a seperate Intel IOMMU tree.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists