[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060817/21a46d3c/attachment.sig>