Date:	Mon, 4 Apr 2011 10:55:55 +0100
From:	Ian Campbell <Ian.Campbell@...citrix.com>
To:	David Miller <davem@...emloft.net>
CC:	"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	"mirq-linux@...e.qmqm.pl" <mirq-linux@...e.qmqm.pl>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@...rix.com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"virtualization@...ts.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	AndreyPanin <pazke@...pac.ru>, linux-visws-devel@...ts.sf.net,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: [PATCH] xen: drop anti-dependency on X86_VISWS (Was: Re: [PATCH]
 xen: netfront: fix declaration order)

On Mon, 2011-04-04 at 01:24 +0100, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Sun, 03 Apr 2011 13:07:19 +0200
> 
> > [PATCH] xen: netfront: fix declaration order
> > 
> > Must declare xennet_fix_features() and xennet_set_features() before
> > using them.
> > 
> > Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
> > Cc: Michał Mirosław <mirq-linux@...e.qmqm.pl>
> 
> Ugh, it makes no sense that XEN won't make it into the x86_32
> allmodconfig build.  Those dependencies in arch/x86/xen/Kconfig
> are terrible.

You mean the "!X86_VISWS" I presume? It doesn't make sense to me either.
Or at least I'm not sure why this single X86_32_NON_STANDARD machine is
more special than the others to require an anti-dependency like this.

It seems to have originally appeared from f0f32fccbffa on
CONFIG_PARAVIRT due to a conflict around ARCH_SETUP() and subsequently
got pushed down to CONFIG_XEN. However ARCH_SETUP doesn't exist any more
and I think the subarch stuff has been much improved since then so there
should be no conflict any more.

I dropped the dependency and, with a bit of fiddling, was able to build
a kernel with both CONFIG_X86_VISWS and CONFIG_XEN which booted as a Xen
domU.

tglx, Andrey, to get VISWS to build I had to comment out some code in
arch/x86/platform/visws/visws_quirks.c which seems to have been missed
during some irq_chip update or something?

          CC      arch/x86/platform/visws/visws_quirks.o
        arch/x86/platform/visws/visws_quirks.c: In function 'startup_piix4_master_irq':
        arch/x86/platform/visws/visws_quirks.c:474: warning: no return statement in function returning non-void
        arch/x86/platform/visws/visws_quirks.c: At top level:
        arch/x86/platform/visws/visws_quirks.c:495: error: unknown field 'mask' specified in initializer
        arch/x86/platform/visws/visws_quirks.c:495: warning: initialization from incompatible pointer type
        arch/x86/platform/visws/visws_quirks.c: In function 'set_piix4_virtual_irq_type':
        arch/x86/platform/visws/visws_quirks.c:583: error: 'struct irq_chip' has no member named 'enable'
        arch/x86/platform/visws/visws_quirks.c:583: error: 'struct irq_chip' has no member named 'unmask'
        arch/x86/platform/visws/visws_quirks.c:584: error: 'struct irq_chip' has no member named 'disable'
        arch/x86/platform/visws/visws_quirks.c:584: error: 'struct irq_chip' has no member named 'mask'
        arch/x86/platform/visws/visws_quirks.c:585: error: 'struct irq_chip' has no member named 'unmask'
        arch/x86/platform/visws/visws_quirks.c:585: error: 'struct irq_chip' has no member named 'unmask'
        arch/x86/platform/visws/visws_quirks.c: In function 'visws_pre_intr_init':
        arch/x86/platform/visws/visws_quirks.c:602: error: expected expression before '>' token
        make[4]: *** [arch/x86/platform/visws/visws_quirks.o] Error 1

Ian

8<--------

>From db0ae26f479306ee8ebcfe2a08aa56a6dfe63987 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@...rix.com>
Date: Mon, 4 Apr 2011 10:27:47 +0100
Subject: [PATCH] xen: drop anti-dependency on X86_VISWS

This seems to have been added in f0f32fccbffa to avoid a conflict arising from
the long deceased ARCH_SETUP() macro and subsequently pushed down to the XEN
option.

As far as I can tell the conflict is no longer present and by dropping the
dependency I was able to build a kernel which has both CONFIG_XEN and
CONFIG_X86_VISWS enabled and boot it on Xen. I didn't try it on the VISWS
platform.

Signed-off-by: Ian Campbell <ian.campbell@...rix.com>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: konrad.wilk@...cle.com
Cc: xen-devel@...ts.xensource.com
Cc: Randy Dunlap <randy.dunlap@...cle.com>
Cc: Andrey Panin <pazke@...pac.ru>
Cc: linux-visws-devel@...ts.sf.net
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: x86@...nel.org
---
 arch/x86/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 1c7121b..65d7b13 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,7 +6,7 @@ config XEN
 	bool "Xen guest support"
 	select PARAVIRT
 	select PARAVIRT_CLOCK
-	depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
+	depends on X86_64 || (X86_32 && X86_PAE)
 	depends on X86_CMPXCHG && X86_TSC
 	help
 	  This is the Linux Xen port.  Enabling this will allow the
-- 
1.7.2.5




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists