[Fedora-packaging] OT: xen vs xen0 (was: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file)

[Axel Thimm]

On Thu, Aug 17, 2006 at 12:21:49PM +0300, Ville Skyttä wrote:
>  On Thu, 2006-08-17 at 09:12 +0200, Axel Thimm wrote:
>  > On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote:
>  > > >FE is em8300. Where is his "xen" flavour?
>  > > 
>  > > You'd have to ask scop. Maybe it didn't build, don't know.
>  > 
>  > If it builds for xen0 it builds for xen.
>  
>  I'm not aware of any problems building it, but nor am I knowledgeable
>  enough about Xen to be able to tell whether shipping this particular
>  module package for the FC5 "xen" variant makes sense in the first place
>  even if it compiles fine.  So I just followed what GFS and friends do
>  and didn't build for "xen".  Maybe that's a bug? 
If GFS didn't build for xen, but for xen0, it's a bug in GFS or the
associated buildsystem. Maybe exactly the design issues I'm referring
to of hardwiring the flavours in the specfile/src.rpm, or maybe
something else, in any case a bug. :)

>  Some info about the different xen variants from the POV of for which
> of
>  them in general it makes sense to ship hardware device drivers such as
>  this one would be nice.  WAG: xen0 and xen yes, xenU no?  And if the
>  module is not a hardware device driver but something else, then in
>  general ship+build for all xen*? 
Rules of thumb:
o Everything *should* build under xen and xen0, they are both domain0
  kernels (but see below)
o Not everything even makes sense under xenU (e.g. nvidia-graphics),
  this is the guest kernel.

If something does not work with xen or xen0 it's either a bug in these
flavours (forgetting to export something, or exporting an updated
symbol/signature of say 2.6.18 on 2.6.17, this has bitten me quite
some times like the premature _xmit_lock* changes) or a bug in the
upstream kernel module project.

But wrt xen vs xen0: iff it builds on one of them then it builds on
the other. That's 99.9% sure. Just for reference, here are the
differences between those two:

-CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
+# CONFIG_HIGHMEM4G is not set
+CONFIG_HIGHMEM64G=y
@@ -3078,2 +3079,2 @@
-CONFIG_XEN_BLKDEV_BACKEND=y
-CONFIG_XEN_NETDEV_BACKEND=y
+CONFIG_XEN_BLKDEV_BACKEND=m
+CONFIG_XEN_NETDEV_BACKEND=m
@@ -3103,0 +3105,8 @@
+# CONFIG_NOHIGHMEM is not set
+# CONFIG_HIGHMEM4G is not set
+CONFIG_HIGHMEM64G=y
+CONFIG_HIGHMEM=y
+CONFIG_XEN_BLKDEV_BACKEND=m
+CONFIG_XEN_NETDEV_BACKEND=m
+CONFIG_XEN_BLKDEV_FRONTEND=m
+CONFIG_XEN_NETDEV_FRONTEND=m

-- 
Axel.Thimm at ATrpms.net