linux-kernel - Re: [ANNOUNCE] iommu-2.6.git tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 19 Oct 2008 19:26:51 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Joerg Roedel <joro@...tes.org>, 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
Subject: Re: [ANNOUNCE] iommu-2.6.git tree


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

> On Sun, 2008-10-19 at 14:47 +0200, Ingo Molnar wrote:
> > * David Woodhouse <dwmw2@...radead.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. "Empty" right now because it just got merged 
upstream last week.

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

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

	Ingo
--
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/