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:	Mon, 20 Oct 2008 10:52:17 +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 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
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ