The attached re-enables the pygrub build and fixes the build with older e2fsprogs (tested on RHEL4 with e2fsprogs-1.35 and rawhide with e2fsprogs-1.38) Signed-off-by: Jeremy Katz <katzj@redhat.com> Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> The attached re-enables the pygrub build and fixes the build > with older e2fsprogs (tested on RHEL4 with e2fsprogs-1.35 and > rawhide with > e2fsprogs-1.38)Excellent, it''ll be good to get pygrub working again. BTW: Have you guys got other patches to feed upstream? E.g. the stuff to make your xen-friendly glibc selection work? Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 8 Oct 2005, Ian Pratt wrote:> BTW: Have you guys got other patches to feed upstream? E.g. the stuff to > make your xen-friendly glibc selection work?This is what we use; ld-linux parses the vsyscall page ELF notes and uses the "nosegneg" glibc variant to ensure that things work fine. Signed-off-by: Rik van Riel <riel@redhat.com> Signed-off-by: Roland McGrath <roland@redhat.com> --- linux-2.6/arch/xen/i386/kernel/vsyscall-note.S +++ linux-2.6/arch/xen/i386/kernel/vsyscall-note.S @@ -0,0 +1,32 @@ +/* + * This supplies .note.* sections to go into the PT_NOTE inside the vDSO text. + * Here we can supply some information useful to userland. + * First we get the vanilla i386 note that supplies the kernel version info. + */ + +#include "../../../i386/kernel/vsyscall-note.S" + +/* + * Now we add a special note telling glibc''s dynamic linker a fake hardware + * flavor that it will use to choose the search path for libraries in the + * same way it uses real hardware capabilities like "mmx". + * We supply "nosegneg" as the fake capability, to indicate that we + * do not like negative offsets in instructions using segment overrides, + * since we implement those inefficiently. This makes it possible to + * install libraries optimized to avoid those access patterns in someplace + * like /lib/i686/tls/nosegneg. Note that an /etc/ld.so.conf.d/file + * corresponding to the bits here is needed to make ldconfig work right. + * It should contain: + * hwcap 0 nosegneg + * to match the mapping of bit to name that we give here. + */ +#define NOTE_KERNELCAP_BEGIN(ncaps, mask) \ + ASM_ELF_NOTE_BEGIN(".note.kernelcap", "a", "GNU", 2) \ + .long ncaps, mask +#define NOTE_KERNELCAP(bit, name) \ + .byte bit; .asciz name +#define NOTE_KERNELCAP_END ASM_ELF_NOTE_END + +NOTE_KERNELCAP_BEGIN(1, 1) +NOTE_KERNELCAP(1, "nosegneg") /* Change 1 back to 0 when glibc is fixed! */ +NOTE_KERNELCAP_END _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 8 Oct 2005, Ian Pratt wrote:> BTW: Have you guys got other patches to feed upstream?This is a hack for our kernel spec file. The Xen kernels are compiled as variants on i686 and x86_64, and the spec file is constructed in such a way that it has the same build targets for all the kernel variants within one architecture. This trivial patch adds a bzImage target. Signed-off-by: Rik van Riel <riel@redhat.com> --- linux-2.6/arch/xen/boot/Makefile.bzi 2004-11-17 22:07:46.000000000 -0500 +++ linux-2.6/arch/xen/boot/Makefile 2004-11-17 22:12:07.000000000 -0500 @@ -6,3 +6,6 @@ vmlinuz: vmlinux-stripped FORCE vmlinux-stripped: vmlinux FORCE $(call if_changed,objcopy) + +bzImage: vmlinuz + $(Q)$(LN) -sf ../../../vmlinuz $(srctree)/arch/xen/boot/bzImage unchanged: --- linux-2.6/arch/xen/Makefile.bzi 2004-11-17 22:07:34.000000000 -0500 +++ linux-2.6/arch/xen/Makefile 2004-11-17 22:07:40.000000000 -0500 @@ -45,6 +45,9 @@ all: vmlinuz vmlinuz: vmlinux $(Q)$(MAKE) $(build)=arch/xen/boot vmlinuz +bzImage: vmlinuz + $(Q)$(MAKE) $(build)=arch/xen/boot bzImage + XINSTALL_NAME ?= $(KERNELRELEASE) install: vmlinuz mkdir -p $(INSTALL_PATH)/boot _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Note that the glibc support was buggy until recently. It is not in mainstream glibc 2.3.x at all. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 7 Oct 2005, Roland McGrath wrote:> Note that the glibc support was buggy until recently.I did send the version with the workaround for the glibc bug. We can change the 1 (left of the comment) back to a 0 by the time we merge this code upstream. -- All Rights Reversed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/7/05, Rik van Riel <riel@redhat.com> wrote:> On Sat, 8 Oct 2005, Ian Pratt wrote: > > > BTW: Have you guys got other patches to feed upstream? > > This is a hack for our kernel spec file. The Xen kernels are > compiled as variants on i686 and x86_64, and the spec file is > constructed in such a way that it has the same build targets > for all the kernel variants within one architecture. > > This trivial patch adds a bzImage target.I think this is a very poor solution. Doesn''t the name bzImage imply that the image includes a bootsector? I don''t see how we will be able to justify adoption of this hack when we merge xen support into arch/i386... christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 13 Oct 2005, Christian Limpach wrote:> I think this is a very poor solution. Doesn''t the name bzImage imply > that the image includes a bootsector?On the contrary, the kernel that contained a boot image was zImage - the bzImage (or big zImage) was for kernels too big to boot that way.> I don''t see how we will be able to justify adoption of this hack when we > merge xen support into arch/i386...I don''t see how Xenolinux as a subarch of i386 could get away with NOT having the same build target as other i386 subarchs. -- All Rights Reversed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Oct 13, 2005 at 08:06:44PM -0400, Rik van Riel wrote:> On Thu, 13 Oct 2005, Christian Limpach wrote: > > I think this is a very poor solution. Doesn''t the name bzImage imply > > that the image includes a bootsector? > > On the contrary, the kernel that contained a boot image was > zImage - the bzImage (or big zImage) was for kernels too big > to boot that way.Hmm, you''re saying the bzImage file on a regular ARCH=i386 build doesn''t include a bootsector? Doesn''t include code to decompress itself? Seems to me that calling our vmlinuz bzImage is rather confusing...> > I don''t see how we will be able to justify adoption of this hack when we > > merge xen support into arch/i386... > > I don''t see how Xenolinux as a subarch of i386 could get away > with NOT having the same build target as other i386 subarchs.Because we are building something substantially different? christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 14 Oct 2005, Christian Limpach wrote:> Hmm, you''re saying the bzImage file on a regular ARCH=i386 build > doesn''t include a bootsector? Doesn''t include code to decompress > itself? > > Seems to me that calling our vmlinuz bzImage is rather confusing...It does contain the code to decompress itself, but not the boot sector that allowed you to dd the traditional zImage to floppy to create a bootable floppy.> > I don''t see how Xenolinux as a subarch of i386 could get away > > with NOT having the same build target as other i386 subarchs. > > Because we are building something substantially different?In distro packages, the Xen kernels are built as a variant on normal i686 kernels. The more the Xen kernels can be built and packaged the same way as normal x86 kernels, the easier it is for distributions to integrate Xen as a normal part of their build... -- All Rights Reversed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > > I don''t see how Xenolinux as a subarch of i386 could get > away with > > > NOT having the same build target as other i386 subarchs. > > > > Because we are building something substantially different? > > In distro packages, the Xen kernels are built as a variant on > normal i686 kernels. The more the Xen kernels can be built > and packaged the same way as normal x86 kernels, the easier > it is for distributions to integrate Xen as a normal part of > their build...I''m inclined to agree that user convenience of having a bzImage target outweighs the technical oddity. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel