| 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
| ||
|
Message-ID: <alpine.LFD.2.00.1102081619410.31804@localhost6.localdomain6> Date: Tue, 8 Feb 2011 16:39:58 +0100 (CET) From: Thomas Gleixner <tglx@...utronix.de> To: Ian Campbell <Ian.Campbell@...citrix.com> cc: Jeremy Fitzhardinge <jeremy@...p.org>, LKML <linux-kernel@...r.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> Subject: Re: [patch 0/4] XEN: Interrupt cleanups On Tue, 8 Feb 2011, Ian Campbell wrote: > On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote: > > > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4 > > > (below), the entire series is: > > > Acked-by: Ian Campbell <ian.campbell@...rix.com> > > > > Cool. So what's the best way to proceed ? That code is not yet in > > linus tree, right ? > > Correct. > > > So I guess the best way is that I add the core changes to a rc-4 based > > branch and you can pull it in and apply the whole xen stuff to your > > own tree. > > My existing cleanup patches are in Konrad's tree (which is in linux-next > etc) so that probably makes most sense as a home for this series. So > unless Konrad has any objections I think it makes sense to pull your > core changes into that branch and then apply your Xen bits on top. > > Konrad's branch with my stuff is: > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/irq.rework > > Konrad, this thread starts at <20110205200108.921707839@...utronix.de> > == http://thread.gmane.org/gmane.linux.kernel/1096437 > > > I base my pending patches on top of that so it wont be any problem > > when merging the stuff together in next or linus later. > > I don't think there will be much trouble with overlap between these and > any Xen events.c changes for the next merge window but what you suggest > should remove the risk. Yes, and please talk to me next time before you hack around in the guts of the interrupt code. I noticed just because I was skimming -next, and that really conflicts with major cleanups I'm doing. If there is a shortcoming in the generic code, then let me know. Core change is in git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/for-xen Thanks, tglx -- 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