*nod* This is part of why I did it. make-kpkg is just now getting some
kind of xen arch support from what I understand, and aparantly it does
since you are using it :). But it's specific to debian. I wanted to make
xenlinux-builder to be distro-agnostic at it's core and THEN use a few
distro specific tricks to assume compatibility. This way if an admin
needs to compile other OS kernels for xen, they use the same tool as you
said for xen kernels.:) Plus I dislike having to specify so many command
line options. I'd rather have a config file that the kernel builder
snakes the arch options etc from automagically. ;) But hey, each admin
has their own magical formula. *grin*
Where does make-kpkg stick the ekrnel and modules for unprived domains?
I'm assuming still in /boot and /lib/modules. I had a long discussion
with Adam over the location of the kernel and modules for "loaded"
kernels such as the ones used for starting domains via xm. We came to
the conclusion that it made more sense to use /usr/lib/kernels for UML
and xenlinux kernels (other than domain-0, which stays in /lib/modules
and /boot). This way you can simply nfs export the modules and kernel to
the unprived domains instead of having to load the darn package to every
domain that needs them.
Right now i'm playing with some ideas on how to best manage patchfiles.
I'm thinking of possibly using a configs/$(CONFIGFILE).patches control
file.
What kind of 3rd part patches have you been using with xen so far? How
have you managed to not hit the brokenness of running mkbuildtree
against the debianized kernel-source-x.x.x packages!? If I do that I
inevitably run into a mess with 2.4.27 and skbuff as well as IPSec
issues in both 2.4.27 and 2.6.8. 8-P
I also suspect a couple subtle issues when using the mkbuildtree on the
debian kernel-source-x.x.x packages. Haven't botherd to track em since
they went away once I started converting things prior to patching.
If you are using the debs I'm producing of xen, you may want to try
using the kernel-patch-xen package instead of mkbuildtree for your
kernels since it avoids the issues I mentioned above with sparse
patching the deb source. The patch set I create seems to apply with a
minimal fuzzing to a pristine kernel source as well as the debian kernel
source.
This is why I converted to a unified diff durign the debianizing of xen.
Specificly to FIX the areas where the xen sparse tree removes some
Debian patches to the kernel source. 8-P
Also, as a reminder to anyone else using the tb.c debian repo. Right now
the packages change pretty much daily. Once xen2.0 is official, the main
repo will become the stable packages. At that point I'll start a new
repo at /debian-xen-unstable for continuing bleeding edge packages. :)
Sorry for the spanish inquisition Nuutti. :)
Brian
On Sat, 2004-10-23 at 08:49, Nuutti Kotivuori wrote:
> Brian Wolfe wrote:
> > So if anyone is pulling from terrabox.com/debian, you will need to
> > override the package version to "downgrade" to the newer packages
> > (that seems liek a rather strange concept, but, eh, my bad on the
> > versioning. ;) )
>
> Yes, did that already, seemed to work fine now.
>
> > XenLinux-Builder is also cleaned up a bit more and now has a couple
> > new targets. See /usr/share/doc/xenlinux-builder/README for more
> > info on help, pristine, and other targets.
> >
> > Nuutti, if you did anythign special for your debianizing that beats
> > anythign i've done so far, I'd love to take a peek at your ideas. :)
> > Some fo this has been hurting my brain (patch conversion for
> > example).
>
> The idea of xenlinux-builder is kind of nice - and it is probably very
> useful for some people.
>
> I, however, do not wish to treat Xen builds in any way special from
> the way I build my normal host kernels - or from the way I build
> user-mode-linux kernels. That is, for me, the procedure is:
>
> - unpack kernel tarball to /usr/src/kernel-source-x.x.x
> - throw in patches (some debianized, some not)
> - run menuconfig (with appropriate arch if building um/xen kernels)
> - make-kpkg clean
> - make-kpkg kernel-image
>
> And for xen specifically, I use mkbuildtree from the xen directory
> first get the symlinks in for xen files to the kernel directory. A
> patch would be much nicer, since I use 'quilt' for patch management on
> the kernel tree. And the final line for me to build the xen kernel is:
>
> make-kpkg --arch=xen --subarch=xen0 --append-to-version=-shiro-1
> --revision=1 kernel-image
>
> So, no, I don't have any magic tricks to do these things - but I don't
> want to use a special builder for xen, um or anything else, if I don't
> build *all* my kernels with it.
>
> -- Naked
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home