[patch-resend] take a bite out of xen-mkbuildtree-pre

[patch-resend] take a bite out of xen-mkbuildtree-pre

[Aron Griffis]

[-- Attachment #1.1: Type: text/plain, Size: 7263 bytes --]

This is an update of last week's patch to clean up some of
xen-mkbuildtree-pre and apply to current xen-unstable.  This builds
successfully on x86, x86_64, ia64-vp and ia64-non-vp.

This patch converges the ia64-specific and general versions of
xen/drivers/Makefile and xen/drivers/core/Makefile.  Use Kconfig
settings instead to control whether specific pieces are built.  These
config settings might disappear when the ia64 p2m/vp conversion is
complete, but for the moment it's a clean way of handling the two
personalities of xen-ia64.

Handle evtchn/evtchn_ia64 with ifeq ($(ARCH),ia64) since this will go
away with the next pull of xen-ia64-unstable into xen-unstable, and
I think this creates less work to undo when that occurs.

Signed-off-by: Aron Griffis <aron@hp.com>

diff -r d5f98d23427a linux-2.6-xen-sparse/arch/ia64/Kconfig
--- a/linux-2.6-xen-sparse/arch/ia64/Kconfig	Tue May 30 11:44:23 2006 +0100
+++ b/linux-2.6-xen-sparse/arch/ia64/Kconfig	Tue May 30 11:21:19 2006 -0400
@@ -73,7 +73,7 @@ config XEN_IA64_DOM0_VP
 
 config XEN_IA64_DOM0_NON_VP
 	bool
-	depends on !(XEN && XEN_IA64_DOM0_VP)
+	depends on XEN && !XEN_IA64_DOM0_VP
 	default y
 	help
 	  dom0 P=M model
@@ -496,15 +496,39 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+#
 # override default values of drivers/xen/Kconfig
-if !XEN_IA64_DOM0_VP
+#
+if XEN
+config XEN_UTIL
+	default n if XEN_IA64_DOM0_VP
+
 config HAVE_ARCH_ALLOC_SKB
-        bool
-        default n
+	default n if !XEN_IA64_DOM0_VP
 
 config HAVE_ARCH_DEV_ALLOC_SKB
-        bool
-        default n
+	default n if !XEN_IA64_DOM0_VP
+
+config XEN_BALLOON
+	default n if !XEN_IA64_DOM0_VP
+
+config XEN_SKBUFF
+	default n if !XEN_IA64_DOM0_VP
+
+config XEN_NETDEV_BACKEND
+	default n if !XEN_IA64_DOM0_VP
+
+config XEN_NETDEV_FRONTEND
+	default n if !XEN_IA64_DOM0_VP
+
+config XEN_CHAR
+	default n
+
+config XEN_REBOOT
+	default n
+
+config XEN_SMPBOOT
+	default n
 endif
 
 source "drivers/xen/Kconfig"
diff -r d5f98d23427a linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-pre
--- a/linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-pre	Tue May 30 11:44:23 2006 +0100
+++ b/linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-pre	Tue May 30 11:21:19 2006 -0400
@@ -9,12 +9,6 @@
 
 #eventually asm-xsi-offsets needs to be part of hypervisor.h/hypercall.h
 ln -sf ../../../../xen/include/asm-ia64/asm-xsi-offsets.h include/asm-ia64/xen/
-
-#ia64 drivers/xen isn't fully functional yet, workaround...
-#also ignore core/evtchn.c which uses a different irq mechanism than ia64
-#(warning: there be dragons here if these files diverge)
-ln -sf ../../arch/ia64/xen/drivers/Makefile drivers/xen/Makefile
-ln -sf ../../../arch/ia64/xen/drivers/coreMakefile drivers/xen/core/Makefile
 
 #not sure where these ia64-specific files will end up in the future
 ln -sf ../../../arch/ia64/xen/drivers/xenia64_init.c drivers/xen/core
diff -r d5f98d23427a linux-2.6-xen-sparse/drivers/xen/Kconfig
--- a/linux-2.6-xen-sparse/drivers/xen/Kconfig	Tue May 30 11:44:23 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/Kconfig	Tue May 30 11:21:19 2006 -0400
@@ -228,4 +228,30 @@ config NO_IDLE_HZ
 	bool
 	default y
 
+config XEN_UTIL
+	bool
+	default y
+
+config XEN_BALLOON
+	bool
+	default y
+
+config XEN_CHAR
+	bool
+	default y
+
+config XEN_SKBUFF
+	bool
+	default y
+	depends on NET
+
+config XEN_REBOOT
+	bool
+	default y
+
+config XEN_SMPBOOT
+	bool
+	default y
+	depends on SMP
+
 endif
diff -r d5f98d23427a linux-2.6-xen-sparse/drivers/xen/Makefile
--- a/linux-2.6-xen-sparse/drivers/xen/Makefile	Tue May 30 11:44:23 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/Makefile	Tue May 30 11:21:19 2006 -0400
@@ -1,14 +1,12 @@
-
-obj-y	+= util.o
-
 obj-y	+= core/
-obj-y	+= char/
 obj-y	+= console/
 obj-y	+= evtchn/
-obj-y	+= balloon/
 obj-y	+= privcmd/
 obj-y	+= xenbus/
 
+obj-$(CONFIG_XEN_UTIL)			+= util.o
+obj-$(CONFIG_XEN_BALLOON)		+= balloon/
+obj-$(CONFIG_XEN_CHAR)			+= char/
 obj-$(CONFIG_XEN_BLKDEV_BACKEND)	+= blkback/
 obj-$(CONFIG_XEN_NETDEV_BACKEND)	+= netback/
 obj-$(CONFIG_XEN_TPMDEV_BACKEND)	+= tpmback/
@@ -17,4 +15,3 @@ obj-$(CONFIG_XEN_BLKDEV_TAP)    	+= blkt
 obj-$(CONFIG_XEN_BLKDEV_TAP)    	+= blktap/
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= pciback/
 obj-$(CONFIG_XEN_PCIDEV_FRONTEND)	+= pcifront/
-
diff -r d5f98d23427a linux-2.6-xen-sparse/drivers/xen/core/Makefile
--- a/linux-2.6-xen-sparse/drivers/xen/core/Makefile	Tue May 30 11:44:23 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/core/Makefile	Tue May 30 11:21:19 2006 -0400
@@ -2,11 +2,21 @@
 # Makefile for the linux kernel.
 #
 
-obj-y   := evtchn.o reboot.o gnttab.o features.o
+obj-y   := gnttab.o features.o
 
-obj-$(CONFIG_PROC_FS)     += xen_proc.o
-obj-$(CONFIG_NET)         += skbuff.o
-obj-$(CONFIG_SMP)         += smpboot.o
-obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
-obj-$(CONFIG_SYSFS)       += hypervisor_sysfs.o
-obj-$(CONFIG_XEN_SYSFS)   += xen_sysfs.o
+obj-$(CONFIG_PROC_FS)	+= xen_proc.o
+obj-$(CONFIG_SYSFS)	+= hypervisor_sysfs.o
+obj-$(CONFIG_HOTPLUG_CPU)	+= cpu_hotplug.o
+obj-$(CONFIG_XEN_SYSFS)	+= xen_sysfs.o
+obj-$(CONFIG_IA64)	+= xenia64_init.o
+obj-$(CONFIG_XEN_SKBUFF)	+= skbuff.o
+obj-$(CONFIG_XEN_REBOOT)	+= reboot.o
+obj-$(CONFIG_XEN_SMPBOOT)	+= smpboot.o
+
+# This special handling should go away with the next pull of xen-ia64-unstable
+# into xen-unstable
+ifeq ($(ARCH),ia64)
+obj-y	+= evtchn_ia64.o
+else
+obj-y	+= evtchn.o
+endif
diff -r d5f98d23427a linux-2.6-xen-sparse/arch/ia64/xen/drivers/Makefile
--- a/linux-2.6-xen-sparse/arch/ia64/xen/drivers/Makefile	Tue May 30 11:44:23 2006 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,22 +0,0 @@
-
-ifneq ($(CONFIG_XEN_IA64_DOM0_VP),y)
-obj-y   += util.o
-endif
-
-obj-y	+= core/
-#obj-y	+= char/
-obj-y	+= console/
-obj-y	+= evtchn/
-obj-$(CONFIG_XEN_IA64_DOM0_VP)	+= balloon/
-obj-y	+= privcmd/
-obj-y	+= xenbus/
-
-obj-$(CONFIG_XEN_BLKDEV_BACKEND)	+= blkback/
-obj-$(CONFIG_XEN_NETDEV_BACKEND)	+= netback/
-obj-$(CONFIG_XEN_TPMDEV_BACKEND)	+= tpmback/
-obj-$(CONFIG_XEN_BLKDEV_FRONTEND)	+= blkfront/
-obj-$(CONFIG_XEN_NETDEV_FRONTEND)	+= netfront/
-obj-$(CONFIG_XEN_BLKDEV_TAP)		+= blktap/
-obj-$(CONFIG_XEN_TPMDEV_FRONTEND)	+= tpmfront/
-obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= pciback/
-obj-$(CONFIG_XEN_PCIDEV_FRONTEND)	+= pcifront/
diff -r d5f98d23427a linux-2.6-xen-sparse/arch/ia64/xen/drivers/coreMakefile
--- a/linux-2.6-xen-sparse/arch/ia64/xen/drivers/coreMakefile	Tue May 30 11:44:23 2006 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,20 +0,0 @@
-#
-# Makefile for the linux kernel.
-#
-
-obj-y   := gnttab.o features.o
-obj-$(CONFIG_PROC_FS) += xen_proc.o
-
-ifeq ($(ARCH),ia64)
-obj-y   += evtchn_ia64.o
-obj-y   += xenia64_init.o
-ifeq ($(CONFIG_XEN_IA64_DOM0_VP),y)
-obj-$(CONFIG_NET)     += skbuff.o
-endif
-else
-obj-y   += reboot.o evtchn.o fixup.o 
-obj-$(CONFIG_SMP)     += smp.o		# setup_profiling_timer def'd in ia64
-obj-$(CONFIG_NET)     += skbuff.o	# until networking is up on ia64
-endif
-obj-$(CONFIG_SYSFS)   += hypervisor_sysfs.o
-obj-$(CONFIG_XEN_SYSFS) += xen_sysfs.o

[-- Attachment #1.2: Type: application/pgp-signature, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [patch-resend] take a bite out of xen-mkbuildtree-pre

[Keir Fraser]

On 30 May 2006, at 22:56, Aron Griffis wrote:

> This is an update of last week's patch to clean up some of
> xen-mkbuildtree-pre and apply to current xen-unstable.  This builds
> successfully on x86, x86_64, ia64-vp and ia64-non-vp.
>
> This patch converges the ia64-specific and general versions of
> xen/drivers/Makefile and xen/drivers/core/Makefile.  Use Kconfig
> settings instead to control whether specific pieces are built.  These
> config settings might disappear when the ia64 p2m/vp conversion is
> complete, but for the moment it's a clean way of handling the two
> personalities of xen-ia64.

Lots of new config variables -- are they all really needed?
Can ia64 not use the Xenified /dev/mem (ia64 and x86 both seem to use 
direct_remap_pfn_range for various things now)?
Referring to xenia64_init.c from a generic Kconfig file is odd.
Can we pull the event-channel merge before taking this patch and avoid 
the kludge to pull in the ia64-specific evtchn code?

  -- Keir

Re: [patch-resend] take a bite out of xen-mkbuildtree-pre

[Aron Griffis]

Keir Fraser wrote:  [Wed May 31 2006, 02:49:48AM EDT]
> Lots of new config variables -- are they all really needed?

Not really lots... these are the new ones:

    XEN_UTIL

...doesn't work if XEN_IA64_DOM0_VP

    XEN_BALLOON
    XEN_CHAR
    XEN_SKBUFF
    XEN_REBOOT
    XEN_SMPBOOT

...don't work unless XEN_IA64_DOM0_VP

We could use bigger hammers by handling them all with 2 variables, but
IMHO that's just setting them up to be separated in the future when
the situation changes, a new architecture is ported, etc.

Do you think there's a better way?

> Can ia64 not use the Xenified /dev/mem (ia64 and x86 both seem to use 
> direct_remap_pfn_range for various things now)?

I'm a little confused how this relates to the patch...

> Referring to xenia64_init.c from a generic Kconfig file is odd.
> Can we pull the event-channel merge before taking this patch and avoid 
> the kludge to pull in the ia64-specific evtchn code?

I'd like that.  Alex, what do you think?

Aron

Re: [patch-resend] take a bite out of xen-mkbuildtree-pre

[Keir Fraser]

On 31 May 2006, at 15:43, Aron Griffis wrote:

>
>     XEN_BALLOON
>     XEN_CHAR
>     XEN_SKBUFF
>     XEN_REBOOT
>     XEN_SMPBOOT

Maybe rename XEN_CHAR to XEN_DEVMEM. I guiess the rest are okay.

  -- Keir

Re: [patch-resend] take a bite out of xen-mkbuildtree-pre

[Alex Williamson]

On Wed, 2006-05-31 at 10:43 -0400, Aron Griffis wrote:
> Keir Fraser wrote:  [Wed May 31 2006, 02:49:48AM EDT]
> > Referring to xenia64_init.c from a generic Kconfig file is odd.
> > Can we pull the event-channel merge before taking this patch and avoid 
> > the kludge to pull in the ia64-specific evtchn code?
> 
> I'd like that.  Alex, what do you think?

   Sure, let me get through today's patches, sync up, do some testing,
then I'll request a pull.  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.