lkml.org 
[lkml]   [2008]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ANNOUNCE] iommu-2.6.git tree
From
Date
On Sun, 2008-10-19 at 19:26 +0200, Ingo Molnar wrote:
> * David Woodhouse <dwmw2@infradead.org> wrote:
>
> > On Sun, 2008-10-19 at 14:47 +0200, Ingo Molnar wrote:
> > > * David Woodhouse <dwmw2@infradead.org> 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?
> > > > [...]
> > >
> > > That's weird, where did you get the impression from that i "dropped" the
> > > "old" IOMMU tree? It's alive and kicking, all the new IOMMU code that we
> > > queued up and tested in the last cycle for v2.6.28 have just gone
> > > upstream - about 80 commits.
> >
> > I cannot find the tree which allegedly already exists [...]
>
> it's tip/auto-iommu-next.

I have no idea what that means.

I tried 'locate auto-iommu-next' on master.kernel.org, but that doesn't
seem to find anything -- is it elsewhere?

Can you give a proper URL for a git tree, with a description explaining
its nature, and everything that one would normally expect from a git
tree?

> > [...] -- and unless I'm mistaken, a number of patches seem to have
> > fallen through the cracks in the last few weeks. Since I've been asked
> > to start looking after the Intel IOMMU parts, it seemed sensible to
> > make a git tree and round up those patches.
>
> hm, no patches have been lost that i'm aware of - the last ~10 days of
> inbox is not queued up yet because of the merge window - but those
> (except for urgent fixes) are v2.6.29 items anyway.

There were patches outstanding which depended on both the interrupt
remapping and the KVM work. And which add IA64 support for VT-d.

> > I thought you and Thomas were working together, and I spoke to Thomas
> > about it during the Kernel Summit. Unless I'm very much mistaken, he
> > agreed that it makes sense to have a separate, real, git tree for
> > cross-platform IOMMU-related work.
> >
> > If you want to pull that tree into yours, that's fine by me -- as long
> > as it gets into linux-next.
>
> okay, we can certainly do that. And if/when all future activities center
> around your tree, and there's no interaction with x86 platform bits, it
> will be natural for you to just not go over any middlemen.
>
> But i'd prefer to at least have some transitionary period - IOMMU
> changes are not easy topics and they caused subtle breakages a couple of
> times and it was quite handy that those breakages were generally seen by
> all x86 developers (and immediately fixed afterwards). 99% of the
> current iommu development activities are in the x86 space, so there's
> quite some alignment there.

Again, isn't this what linux-next is for? But if you want to pull it
into your own linux-next-but-only-for-x86 tree, then that's fine too; as
I said.

--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation



\
 
 \ /
  Last update: 2008-10-19 19:45    [W:0.076 / U:0.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site