* x86: removing zImage support?
@ 2009-03-11 0:20 H. Peter Anvin
2009-03-11 1:15 ` Andi Kleen
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: H. Peter Anvin @ 2009-03-11 0:20 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: the arch/x86 maintainers
I'm thinking again about removing zImage support. An "allnoconfig"
kernel (with CONFIG_EMBEDDED=y to expose additional knobs, and
CONFIG_BINFMT_ELF=y so it can do anything at all) is currently 487K on
i386 -- very close to the upper limit of 512K for zImage.
Are there *any* residual users of this, or should I just push a patch to
remove it once and for all?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: x86: removing zImage support? 2009-03-11 0:20 x86: removing zImage support? H. Peter Anvin @ 2009-03-11 1:15 ` Andi Kleen 2009-03-11 1:47 ` H. Peter Anvin 2009-03-11 10:24 ` Ingo Molnar ` (2 subsequent siblings) 3 siblings, 1 reply; 14+ messages in thread From: Andi Kleen @ 2009-03-11 1:15 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Linux Kernel Mailing List, the arch/x86 maintainers "H. Peter Anvin" <hpa@zytor.com> writes: > I'm thinking again about removing zImage support. An "allnoconfig" > kernel (with CONFIG_EMBEDDED=y to expose additional knobs, and > CONFIG_BINFMT_ELF=y so it can do anything at all) is currently 487K on > i386 -- very close to the upper limit of 512K for zImage. An alternative would be to do a concentrated effort to get rid of text bloat again. I bet it could be stripped down to much below that again by just attacking some low hanging fruit. -Andi -- ak@linux.intel.com -- Speaking for myself only. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: x86: removing zImage support? 2009-03-11 1:15 ` Andi Kleen @ 2009-03-11 1:47 ` H. Peter Anvin 0 siblings, 0 replies; 14+ messages in thread From: H. Peter Anvin @ 2009-03-11 1:47 UTC (permalink / raw) To: Andi Kleen; +Cc: Linux Kernel Mailing List, the arch/x86 maintainers Andi Kleen wrote: > "H. Peter Anvin" <hpa@zytor.com> writes: > >> I'm thinking again about removing zImage support. An "allnoconfig" >> kernel (with CONFIG_EMBEDDED=y to expose additional knobs, and >> CONFIG_BINFMT_ELF=y so it can do anything at all) is currently 487K on >> i386 -- very close to the upper limit of 512K for zImage. > > An alternative would be to do a concentrated effort to get rid of text bloat > again. I bet it could be stripped down to much below that again by just > attacking some low hanging fruit. > That wasn't exactly the point. The whole point is whether or not we can reduce the complexity of the code by removing a mode which has few or no users. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: x86: removing zImage support? 2009-03-11 0:20 x86: removing zImage support? H. Peter Anvin 2009-03-11 1:15 ` Andi Kleen @ 2009-03-11 10:24 ` Ingo Molnar 2009-03-11 11:03 ` Thomas Gleixner 2009-03-11 14:14 ` Woody Suwalski 2009-03-11 18:06 ` [tip:x86/setup] x86: remove zImage support H. Peter Anvin 3 siblings, 1 reply; 14+ messages in thread From: Ingo Molnar @ 2009-03-11 10:24 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Linux Kernel Mailing List, the arch/x86 maintainers * H. Peter Anvin <hpa@zytor.com> wrote: > I'm thinking again about removing zImage support. An > "allnoconfig" kernel (with CONFIG_EMBEDDED=y to expose > additional knobs, and CONFIG_BINFMT_ELF=y so it can do > anything at all) is currently 487K on i386 -- very close to > the upper limit of 512K for zImage. > > Are there *any* residual users of this, or should I just push > a patch to remove it once and for all? Havent seen any zImage bugreport for years, so go for it. In the unlikely case of someone still relying on it and having a good use case we'll get a bugreport and can consider putting it back in. Ingo ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: x86: removing zImage support? 2009-03-11 10:24 ` Ingo Molnar @ 2009-03-11 11:03 ` Thomas Gleixner 0 siblings, 0 replies; 14+ messages in thread From: Thomas Gleixner @ 2009-03-11 11:03 UTC (permalink / raw) To: Ingo Molnar Cc: H. Peter Anvin, Linux Kernel Mailing List, the arch/x86 maintainers On Wed, 11 Mar 2009, Ingo Molnar wrote: > * H. Peter Anvin <hpa@zytor.com> wrote: > > > I'm thinking again about removing zImage support. An > > "allnoconfig" kernel (with CONFIG_EMBEDDED=y to expose > > additional knobs, and CONFIG_BINFMT_ELF=y so it can do > > anything at all) is currently 487K on i386 -- very close to > > the upper limit of 512K for zImage. > > > > Are there *any* residual users of this, or should I just push > > a patch to remove it once and for all? > > Havent seen any zImage bugreport for years, so go for it. In the > unlikely case of someone still relying on it and having a good > use case we'll get a bugreport and can consider putting it back > in. I haven't seen any zImage for years in the embedded space either. Go for it. Thanks, tglx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: x86: removing zImage support? 2009-03-11 0:20 x86: removing zImage support? H. Peter Anvin 2009-03-11 1:15 ` Andi Kleen 2009-03-11 10:24 ` Ingo Molnar @ 2009-03-11 14:14 ` Woody Suwalski 2009-03-11 17:03 ` H. Peter Anvin 2009-03-11 18:06 ` [tip:x86/setup] x86: remove zImage support H. Peter Anvin 3 siblings, 1 reply; 14+ messages in thread From: Woody Suwalski @ 2009-03-11 14:14 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Linux Kernel Mailing List, the arch/x86 maintainers H. Peter Anvin wrote: > I'm thinking again about removing zImage support. An "allnoconfig" > kernel (with CONFIG_EMBEDDED=y to expose additional knobs, and > CONFIG_BINFMT_ELF=y so it can do anything at all) is currently 487K on > i386 -- very close to the upper limit of 512K for zImage. > > Are there *any* residual users of this, or should I just push a patch to > remove it once and for all? > > -hpa > > If x86-only - OK. However zImage is the format used on ARM quite often... So any "kernel complexity removal" need to happen only on x86 side. Woody -- Woody Suwalski, Xandros, Ottawa, Canada, 1-613-842-3498 x414 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: x86: removing zImage support? 2009-03-11 14:14 ` Woody Suwalski @ 2009-03-11 17:03 ` H. Peter Anvin 2009-03-11 17:39 ` Ian Campbell 0 siblings, 1 reply; 14+ messages in thread From: H. Peter Anvin @ 2009-03-11 17:03 UTC (permalink / raw) To: Woody Suwalski; +Cc: Linux Kernel Mailing List, the arch/x86 maintainers Woody Suwalski wrote: >> > If x86-only - OK. > > However zImage is the format used on ARM quite often... So any "kernel > complexity removal" need to happen only on x86 side. > I have no idea about ARM zImage... the whole zImage vs bzImage is pretty x86-specific in the first place, so yes, I was referring to x86 specifically. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: x86: removing zImage support? 2009-03-11 17:03 ` H. Peter Anvin @ 2009-03-11 17:39 ` Ian Campbell 2009-03-11 18:02 ` H. Peter Anvin 0 siblings, 1 reply; 14+ messages in thread From: Ian Campbell @ 2009-03-11 17:39 UTC (permalink / raw) To: H. Peter Anvin Cc: Woody Suwalski, Linux Kernel Mailing List, the arch/x86 maintainers On Wed, 2009-03-11 at 10:03 -0700, H. Peter Anvin wrote: > Woody Suwalski wrote: > >> > > If x86-only - OK. > > > > However zImage is the format used on ARM quite often... So any "kernel > > complexity removal" need to happen only on x86 side. > > > > I have no idea about ARM zImage... the whole zImage vs bzImage is pretty > x86-specific in the first place, so yes, I was referring to x86 > specifically. Is there any point in just making bzImage==zImage for x86? I lost count of the number of times I've explained that bzImage has nothing to do with bzip... Ian. -- Ian Campbell Current Noise: Alice In Chains - Nutshell Live free or die. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: x86: removing zImage support? 2009-03-11 17:39 ` Ian Campbell @ 2009-03-11 18:02 ` H. Peter Anvin 0 siblings, 0 replies; 14+ messages in thread From: H. Peter Anvin @ 2009-03-11 18:02 UTC (permalink / raw) To: Ian Campbell Cc: Woody Suwalski, Linux Kernel Mailing List, the arch/x86 maintainers Ian Campbell wrote: > > Is there any point in just making bzImage==zImage for x86? > Not really. The *last* thing we want is to make people start using the name zImage, and then getting confused when an older kernel doesn't build. > I lost count of the number of times I've explained that bzImage has > nothing to do with bzip... Just to be extra confusing, in -tip there is code to compress it with bzip2 ;) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [tip:x86/setup] x86: remove zImage support 2009-03-11 0:20 x86: removing zImage support? H. Peter Anvin ` (2 preceding siblings ...) 2009-03-11 14:14 ` Woody Suwalski @ 2009-03-11 18:06 ` H. Peter Anvin 2009-03-12 17:45 ` Paul Bolle 3 siblings, 1 reply; 14+ messages in thread From: H. Peter Anvin @ 2009-03-11 18:06 UTC (permalink / raw) To: linux-tip-commits; +Cc: linux-kernel, hpa, mingo, tglx Commit-ID: 5e47c478b0b69bc9bc3ba544e4b1ca3268f98fef Gitweb: http://git.kernel.org/tip/5e47c478b0b69bc9bc3ba544e4b1ca3268f98fef Author: "H. Peter Anvin" <hpa@zytor.com> AuthorDate: Wed, 11 Mar 2009 10:55:33 -0700 Commit: H. Peter Anvin <hpa@zytor.com> CommitDate: Wed, 11 Mar 2009 11:00:00 -0700 x86: remove zImage support Impact: obsolete feature removal The zImage kernel format has been functionally unused for a very long time. It is just barely possible to build a modern kernel that still fits within the zImage size limit, but it is highly unlikely that anyone ever uses it. Furthermore, although it is still supported by most bootloaders, it has been at best poorly tested (or not tested at all); some bootloaders are even known to not support zImage at all and not having even noticed. Also remove some really obsolete constants that no longer have any meaning. LKML-Reference: <49B703D4.1000008@zytor.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/boot/Makefile | 23 +++++++-------------- arch/x86/boot/header.S | 29 ++++++++------------------- arch/x86/boot/pm.c | 44 ------------------------------------------- arch/x86/boot/tools/build.c | 9 +------- arch/x86/include/asm/boot.h | 4 --- 5 files changed, 18 insertions(+), 91 deletions(-) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index c70eff6..57a29fe 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -6,26 +6,23 @@ # for more details. # # Copyright (C) 1994 by Linus Torvalds +# Changed by many, many contributors over the years. # # ROOT_DEV specifies the default root-device when making the image. # This can be either FLOPPY, CURRENT, /dev/xxxx or empty, in which case # the default of FLOPPY is used by 'build'. -ROOT_DEV := CURRENT +ROOT_DEV := CURRENT # If you want to preset the SVGA mode, uncomment the next line and # set SVGA_MODE to whatever number you want. # Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode. # The number is the same as you would ordinarily press at bootup. -SVGA_MODE := -DSVGA_MODE=NORMAL_VGA +SVGA_MODE := -DSVGA_MODE=NORMAL_VGA -# If you want the RAM disk device, define this to be the size in blocks. - -#RAMDISK := -DRAMDISK=512 - -targets := vmlinux.bin setup.bin setup.elf zImage bzImage +targets := vmlinux.bin setup.bin setup.elf bzImage subdir- := compressed setup-y += a20.o cmdline.o copy.o cpu.o cpucheck.o edd.o @@ -71,17 +68,13 @@ KBUILD_CFLAGS := $(LINUXINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \ KBUILD_CFLAGS += $(call cc-option,-m32) KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -$(obj)/zImage: asflags-y := $(SVGA_MODE) $(RAMDISK) -$(obj)/bzImage: ccflags-y := -D__BIG_KERNEL__ -$(obj)/bzImage: asflags-y := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ -$(obj)/bzImage: BUILDFLAGS := -b +$(obj)/bzImage: asflags-y := $(SVGA_MODE) quiet_cmd_image = BUILD $@ -cmd_image = $(obj)/tools/build $(BUILDFLAGS) $(obj)/setup.bin \ - $(obj)/vmlinux.bin $(ROOT_DEV) > $@ +cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \ + $(ROOT_DEV) > $@ -$(obj)/zImage $(obj)/bzImage: $(obj)/setup.bin \ - $(obj)/vmlinux.bin $(obj)/tools/build FORCE +$(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE $(call if_changed,image) @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 7ccff48..5d84d1c 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -24,12 +24,8 @@ #include "boot.h" #include "offsets.h" -SETUPSECTS = 4 /* default nr of setup-sectors */ BOOTSEG = 0x07C0 /* original address of boot-sector */ -SYSSEG = DEF_SYSSEG /* system loaded at 0x10000 (65536) */ -SYSSIZE = DEF_SYSSIZE /* system size: # of 16-byte clicks */ - /* to be loaded */ -ROOT_DEV = 0 /* ROOT_DEV is now written by "build" */ +SYSSEG = 0x1000 /* historical load address >> 4 */ #ifndef SVGA_MODE #define SVGA_MODE ASK_VGA @@ -97,12 +93,12 @@ bugger_off_msg: .section ".header", "a" .globl hdr hdr: -setup_sects: .byte SETUPSECTS +setup_sects: .byte 0 /* Filled in by build.c */ root_flags: .word ROOT_RDONLY -syssize: .long SYSSIZE -ram_size: .word RAMDISK +syssize: .long 0 /* Filled in by build.c */ +ram_size: .word 0 /* Obsolete */ vid_mode: .word SVGA_MODE -root_dev: .word ROOT_DEV +root_dev: .word 0 /* Filled in by build.c */ boot_flag: .word 0xAA55 # offset 512, entry point @@ -123,14 +119,15 @@ _start: # or else old loadlin-1.5 will fail) .globl realmode_swtch realmode_swtch: .word 0, 0 # default_switch, SETUPSEG -start_sys_seg: .word SYSSEG +start_sys_seg: .word SYSSEG # obsolete and meaningless, but just + # in case something decided to "use" it .word kernel_version-512 # pointing to kernel version string # above section of header is compatible # with loadlin-1.5 (header v1.5). Don't # change it. -type_of_loader: .byte 0 # = 0, old one (LILO, Loadlin, - # Bootlin, SYSLX, bootsect...) +type_of_loader: .byte 0 # 0 means ancient bootloader, newer + # bootloaders know to change this. # See Documentation/i386/boot.txt for # assigned ids @@ -142,11 +139,7 @@ CAN_USE_HEAP = 0x80 # If set, the loader also has set # space behind setup.S can be used for # heap purposes. # Only the loader knows what is free -#ifndef __BIG_KERNEL__ - .byte 0 -#else .byte LOADED_HIGH -#endif setup_move_size: .word 0x8000 # size to move, when setup is not # loaded at 0x90000. We will move setup @@ -157,11 +150,7 @@ setup_move_size: .word 0x8000 # size to move, when setup is not code32_start: # here loaders can put a different # start address for 32-bit code. -#ifndef __BIG_KERNEL__ - .long 0x1000 # 0x1000 = default for zImage -#else .long 0x100000 # 0x100000 = default for big kernel -#endif ramdisk_image: .long 0 # address of loaded ramdisk image # Here the loader puts the 32-bit diff --git a/arch/x86/boot/pm.c b/arch/x86/boot/pm.c index 85a1cd8..8062f89 100644 --- a/arch/x86/boot/pm.c +++ b/arch/x86/boot/pm.c @@ -33,47 +33,6 @@ static void realmode_switch_hook(void) } /* - * A zImage kernel is loaded at 0x10000 but wants to run at 0x1000. - * A bzImage kernel is loaded and runs at 0x100000. - */ -static void move_kernel_around(void) -{ - /* Note: rely on the compile-time option here rather than - the LOADED_HIGH flag. The Qemu kernel loader unconditionally - sets the loadflags to zero. */ -#ifndef __BIG_KERNEL__ - u16 dst_seg, src_seg; - u32 syssize; - - dst_seg = 0x1000 >> 4; - src_seg = 0x10000 >> 4; - syssize = boot_params.hdr.syssize; /* Size in 16-byte paragraphs */ - - while (syssize) { - int paras = (syssize >= 0x1000) ? 0x1000 : syssize; - int dwords = paras << 2; - - asm volatile("pushw %%es ; " - "pushw %%ds ; " - "movw %1,%%es ; " - "movw %2,%%ds ; " - "xorw %%di,%%di ; " - "xorw %%si,%%si ; " - "rep;movsl ; " - "popw %%ds ; " - "popw %%es" - : "+c" (dwords) - : "r" (dst_seg), "r" (src_seg) - : "esi", "edi"); - - syssize -= paras; - dst_seg += paras; - src_seg += paras; - } -#endif -} - -/* * Disable all interrupts at the legacy PIC. */ static void mask_all_interrupts(void) @@ -147,9 +106,6 @@ void go_to_protected_mode(void) /* Hook before leaving real mode, also disables interrupts */ realmode_switch_hook(); - /* Move the kernel/setup to their final resting places */ - move_kernel_around(); - /* Enable the A20 gate */ if (enable_a20()) { puts("A20 gate not responding, unable to boot...\n"); diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c index 44dc192..ee3a4ea 100644 --- a/arch/x86/boot/tools/build.c +++ b/arch/x86/boot/tools/build.c @@ -130,7 +130,7 @@ static void die(const char * str, ...) static void usage(void) { - die("Usage: build [-b] setup system [rootdev] [> image]"); + die("Usage: build setup system [rootdev] [> image]"); } int main(int argc, char ** argv) @@ -145,11 +145,6 @@ int main(int argc, char ** argv) void *kernel; u32 crc = 0xffffffffUL; - if (argc > 2 && !strcmp(argv[1], "-b")) - { - is_big_kernel = 1; - argc--, argv++; - } if ((argc < 3) || (argc > 4)) usage(); if (argc > 3) { @@ -216,8 +211,6 @@ int main(int argc, char ** argv) die("Unable to mmap '%s': %m", argv[2]); /* Number of 16-byte paragraphs, including space for a 4-byte CRC */ sys_size = (sz + 15 + 4) / 16; - if (!is_big_kernel && sys_size > DEF_SYSSIZE) - die("System is too big. Try using bzImage or modules."); /* Patch the setup code with the appropriate size parameters */ buf[0x1f1] = setup_sectors-1; diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h index 6526cf0..6ba23dd 100644 --- a/arch/x86/include/asm/boot.h +++ b/arch/x86/include/asm/boot.h @@ -1,10 +1,6 @@ #ifndef _ASM_X86_BOOT_H #define _ASM_X86_BOOT_H -/* Don't touch these, unless you really know what you're doing. */ -#define DEF_SYSSEG 0x1000 -#define DEF_SYSSIZE 0x7F00 - /* Internal svga startup constants */ #define NORMAL_VGA 0xffff /* 80x25 mode */ #define EXTENDED_VGA 0xfffe /* 80x50 mode */ ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [tip:x86/setup] x86: remove zImage support 2009-03-11 18:06 ` [tip:x86/setup] x86: remove zImage support H. Peter Anvin @ 2009-03-12 17:45 ` Paul Bolle 2009-03-12 19:25 ` H. Peter Anvin ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Paul Bolle @ 2009-03-12 17:45 UTC (permalink / raw) To: hpa; +Cc: linux-tip-commits, mingo, linux-kernel, tglx On Wed, 2009-03-11 at 18:06 +0000, H. Peter Anvin wrote: > arch/x86/boot/Makefile | 23 +++++++-------------- > arch/x86/boot/header.S | 29 ++++++++------------------- > arch/x86/boot/pm.c | 44 ------------------------------------------- > arch/x86/boot/tools/build.c | 9 +------- > arch/x86/include/asm/boot.h | 4 --- > 5 files changed, 18 insertions(+), 91 deletions(-) Shouldn't the zImage target (and therefore the compressed, zlilo, and zdisk targets) also be dropped from arch/x86/Makefile? > diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile > index c70eff6..57a29fe 100644 > --- a/arch/x86/boot/Makefile > +++ b/arch/x86/boot/Makefile > @@ -6,26 +6,23 @@ > # for more details. > # > # Copyright (C) 1994 by Linus Torvalds > +# Changed by many, many contributors over the years. > # > > # ROOT_DEV specifies the default root-device when making the image. > # This can be either FLOPPY, CURRENT, /dev/xxxx or empty, in which case > # the default of FLOPPY is used by 'build'. > > -ROOT_DEV := CURRENT > +ROOT_DEV := CURRENT > > # If you want to preset the SVGA mode, uncomment the next line and > # set SVGA_MODE to whatever number you want. > # Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode. > # The number is the same as you would ordinarily press at bootup. > > -SVGA_MODE := -DSVGA_MODE=NORMAL_VGA > +SVGA_MODE := -DSVGA_MODE=NORMAL_VGA > > -# If you want the RAM disk device, define this to be the size in blocks. > - > -#RAMDISK := -DRAMDISK=512 > - > -targets := vmlinux.bin setup.bin setup.elf zImage bzImage > +targets := vmlinux.bin setup.bin setup.elf bzImage > subdir- := compressed > > setup-y += a20.o cmdline.o copy.o cpu.o cpucheck.o edd.o > @@ -71,17 +68,13 @@ KBUILD_CFLAGS := $(LINUXINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \ > KBUILD_CFLAGS += $(call cc-option,-m32) > KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > > -$(obj)/zImage: asflags-y := $(SVGA_MODE) $(RAMDISK) > -$(obj)/bzImage: ccflags-y := -D__BIG_KERNEL__ > -$(obj)/bzImage: asflags-y := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ > -$(obj)/bzImage: BUILDFLAGS := -b > +$(obj)/bzImage: asflags-y := $(SVGA_MODE) > > quiet_cmd_image = BUILD $@ > -cmd_image = $(obj)/tools/build $(BUILDFLAGS) $(obj)/setup.bin \ > - $(obj)/vmlinux.bin $(ROOT_DEV) > $@ > +cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \ > + $(ROOT_DEV) > $@ > > -$(obj)/zImage $(obj)/bzImage: $(obj)/setup.bin \ > - $(obj)/vmlinux.bin $(obj)/tools/build FORCE > +$(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE > $(call if_changed,image) > @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' Should the zlilo and zdisk targets be renamed to bzlilo and bzdisk in this file? > diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c > index 44dc192..ee3a4ea 100644 > --- a/arch/x86/boot/tools/build.c > +++ b/arch/x86/boot/tools/build.c > @@ -130,7 +130,7 @@ static void die(const char * str, ...) > > static void usage(void) > { > - die("Usage: build [-b] setup system [rootdev] [> image]"); > + die("Usage: build setup system [rootdev] [> image]"); > } > > int main(int argc, char ** argv) > @@ -145,11 +145,6 @@ int main(int argc, char ** argv) > void *kernel; > u32 crc = 0xffffffffUL; > > - if (argc > 2 && !strcmp(argv[1], "-b")) > - { > - is_big_kernel = 1; > - argc--, argv++; > - } > if ((argc < 3) || (argc > 4)) > usage(); > if (argc > 3) { > @@ -216,8 +211,6 @@ int main(int argc, char ** argv) > die("Unable to mmap '%s': %m", argv[2]); > /* Number of 16-byte paragraphs, including space for a 4-byte CRC */ > sys_size = (sz + 15 + 4) / 16; > - if (!is_big_kernel && sys_size > DEF_SYSSIZE) > - die("System is too big. Try using bzImage or modules."); > > /* Patch the setup code with the appropriate size parameters */ > buf[0x1f1] = setup_sectors-1; is_big_kernel now is unused. It can be dropped entirely, can't it? Paul Bolle ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tip:x86/setup] x86: remove zImage support 2009-03-12 17:45 ` Paul Bolle @ 2009-03-12 19:25 ` H. Peter Anvin 2009-03-12 19:28 ` H. Peter Anvin 2009-03-12 19:57 ` [tip:x86/setup] x86: remove additional vestiges of the zImage/bzImage split H. Peter Anvin 2 siblings, 0 replies; 14+ messages in thread From: H. Peter Anvin @ 2009-03-12 19:25 UTC (permalink / raw) To: Paul Bolle; +Cc: linux-tip-commits, mingo, linux-kernel, tglx Paul Bolle wrote: > On Wed, 2009-03-11 at 18:06 +0000, H. Peter Anvin wrote: >> arch/x86/boot/Makefile | 23 +++++++-------------- >> arch/x86/boot/header.S | 29 ++++++++------------------- >> arch/x86/boot/pm.c | 44 ------------------------------------------- >> arch/x86/boot/tools/build.c | 9 +------- >> arch/x86/include/asm/boot.h | 4 --- >> 5 files changed, 18 insertions(+), 91 deletions(-) > > Shouldn't the zImage target (and therefore the compressed, zlilo, and > zdisk targets) also be dropped from arch/x86/Makefile? > Yes. > Should the zlilo and zdisk targets be renamed to bzlilo and bzdisk in > this file? No. They've been called zlilo and zdisk despite being bzImages for a *long* time. > is_big_kernel now is unused. It can be dropped entirely, can't it? Yes, it was supposed to have been, but I apparently missed it. Thanks for the look-over. -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tip:x86/setup] x86: remove zImage support 2009-03-12 17:45 ` Paul Bolle 2009-03-12 19:25 ` H. Peter Anvin @ 2009-03-12 19:28 ` H. Peter Anvin 2009-03-12 19:57 ` [tip:x86/setup] x86: remove additional vestiges of the zImage/bzImage split H. Peter Anvin 2 siblings, 0 replies; 14+ messages in thread From: H. Peter Anvin @ 2009-03-12 19:28 UTC (permalink / raw) To: Paul Bolle; +Cc: linux-tip-commits, mingo, linux-kernel, tglx Paul Bolle wrote: > > Shouldn't the zImage target (and therefore the compressed, zlilo, and > zdisk targets) also be dropped from arch/x86/Makefile? > Forget what I asaid in the previous email; I had forgotten the ugly hacks in arch/x86/Makefile, which is even more reason to get rid of this crap ;) You were right, of course :) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [tip:x86/setup] x86: remove additional vestiges of the zImage/bzImage split 2009-03-12 17:45 ` Paul Bolle 2009-03-12 19:25 ` H. Peter Anvin 2009-03-12 19:28 ` H. Peter Anvin @ 2009-03-12 19:57 ` H. Peter Anvin 2 siblings, 0 replies; 14+ messages in thread From: H. Peter Anvin @ 2009-03-12 19:57 UTC (permalink / raw) To: linux-tip-commits; +Cc: linux-kernel, pebolle, hpa, mingo, tglx Commit-ID: f9c5107c2bcad91dd56d23888653d7bfa1a9696e Gitweb: http://git.kernel.org/tip/f9c5107c2bcad91dd56d23888653d7bfa1a9696e Author: H. Peter Anvin <hpa@zytor.com> AuthorDate: Thu, 12 Mar 2009 12:50:33 -0700 Commit: H. Peter Anvin <hpa@zytor.com> CommitDate: Thu, 12 Mar 2009 12:50:33 -0700 x86: remove additional vestiges of the zImage/bzImage split Impact: cleanup Remove targets that were used for zImage only, and Makefile infrastructure that was there to support the zImage/bzImage split. Reported-by: Paul Bolle <pebolle@tiscali.nl> LKML-Reference: <1236879901.24144.26.camel@test.thuisdomein> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/Makefile | 27 ++++++++------------------- arch/x86/boot/Makefile | 29 ++++++++++++++++------------- 2 files changed, 24 insertions(+), 32 deletions(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 1836191..43bd89c 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -153,34 +153,23 @@ endif boot := arch/x86/boot -PHONY += zImage bzImage compressed zlilo bzlilo \ - zdisk bzdisk fdimage fdimage144 fdimage288 isoimage install +BOOT_TARGETS = bzlilo bzdisk fdimage fdimage144 fdimage288 isoimage install + +PHONY += bzImage $(BOOT_TARGETS) # Default kernel to build all: bzImage # KBUILD_IMAGE specify target image being built - KBUILD_IMAGE := $(boot)/bzImage -zImage zlilo zdisk: KBUILD_IMAGE := $(boot)/zImage +KBUILD_IMAGE := $(boot)/bzImage -zImage bzImage: vmlinux +bzImage: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(KBUILD_IMAGE) $(Q)mkdir -p $(objtree)/arch/$(UTS_MACHINE)/boot $(Q)ln -fsn ../../x86/boot/bzImage $(objtree)/arch/$(UTS_MACHINE)/boot/$@ -compressed: zImage - -zlilo bzlilo: vmlinux - $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) zlilo - -zdisk bzdisk: vmlinux - $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) zdisk - -fdimage fdimage144 fdimage288 isoimage: vmlinux - $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) $@ - -install: - $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install +$(BOOT_TARGETS): vmlinux + $(Q)$(MAKE) $(build)=$(boot) $@ PHONY += vdso_install vdso_install: @@ -208,4 +197,4 @@ endef CLEAN_FILES += arch/x86/boot/fdimage \ arch/x86/boot/image.iso \ - arch/x86/boot/mtools.conf + arch/x86/boot/mtools.conf \ No newline at end of file diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index 57a29fe..2a3db75 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -109,9 +109,11 @@ $(obj)/setup.bin: $(obj)/setup.elf FORCE $(obj)/compressed/vmlinux: FORCE $(Q)$(MAKE) $(build)=$(obj)/compressed $@ -# Set this if you want to pass append arguments to the zdisk/fdimage/isoimage kernel +# Set this if you want to pass append arguments to the +# bzdisk/fdimage/isoimage kernel FDARGS = -# Set this if you want an initrd included with the zdisk/fdimage/isoimage kernel +# Set this if you want an initrd included with the +# bzdisk/fdimage/isoimage kernel FDINITRD = image_cmdline = default linux $(FDARGS) $(if $(FDINITRD),initrd=initrd.img,) @@ -120,7 +122,7 @@ $(obj)/mtools.conf: $(src)/mtools.conf.in sed -e 's|@OBJ@|$(obj)|g' < $< > $@ # This requires write access to /dev/fd0 -zdisk: $(BOOTIMAGE) $(obj)/mtools.conf +bzdisk: $(obj)/bzImage $(obj)/mtools.conf MTOOLSRC=$(obj)/mtools.conf mformat a: ; sync syslinux /dev/fd0 ; sync echo '$(image_cmdline)' | \ @@ -128,10 +130,10 @@ zdisk: $(BOOTIMAGE) $(obj)/mtools.conf if [ -f '$(FDINITRD)' ] ; then \ MTOOLSRC=$(obj)/mtools.conf mcopy '$(FDINITRD)' a:initrd.img ; \ fi - MTOOLSRC=$(obj)/mtools.conf mcopy $(BOOTIMAGE) a:linux ; sync + MTOOLSRC=$(obj)/mtools.conf mcopy $(obj)/bzImage a:linux ; sync # These require being root or having syslinux 2.02 or higher installed -fdimage fdimage144: $(BOOTIMAGE) $(obj)/mtools.conf +fdimage fdimage144: $(obj)/bzImage $(obj)/mtools.conf dd if=/dev/zero of=$(obj)/fdimage bs=1024 count=1440 MTOOLSRC=$(obj)/mtools.conf mformat v: ; sync syslinux $(obj)/fdimage ; sync @@ -140,9 +142,9 @@ fdimage fdimage144: $(BOOTIMAGE) $(obj)/mtools.conf if [ -f '$(FDINITRD)' ] ; then \ MTOOLSRC=$(obj)/mtools.conf mcopy '$(FDINITRD)' v:initrd.img ; \ fi - MTOOLSRC=$(obj)/mtools.conf mcopy $(BOOTIMAGE) v:linux ; sync + MTOOLSRC=$(obj)/mtools.conf mcopy $(obj)/bzImage v:linux ; sync -fdimage288: $(BOOTIMAGE) $(obj)/mtools.conf +fdimage288: $(obj)/bzImage $(obj)/mtools.conf dd if=/dev/zero of=$(obj)/fdimage bs=1024 count=2880 MTOOLSRC=$(obj)/mtools.conf mformat w: ; sync syslinux $(obj)/fdimage ; sync @@ -151,9 +153,9 @@ fdimage288: $(BOOTIMAGE) $(obj)/mtools.conf if [ -f '$(FDINITRD)' ] ; then \ MTOOLSRC=$(obj)/mtools.conf mcopy '$(FDINITRD)' w:initrd.img ; \ fi - MTOOLSRC=$(obj)/mtools.conf mcopy $(BOOTIMAGE) w:linux ; sync + MTOOLSRC=$(obj)/mtools.conf mcopy $(obj)/bzImage w:linux ; sync -isoimage: $(BOOTIMAGE) +isoimage: $(obj)/bzImage -rm -rf $(obj)/isoimage mkdir $(obj)/isoimage for i in lib lib64 share end ; do \ @@ -163,7 +165,7 @@ isoimage: $(BOOTIMAGE) fi ; \ if [ $$i = end ] ; then exit 1 ; fi ; \ done - cp $(BOOTIMAGE) $(obj)/isoimage/linux + cp $(obj)/bzImage $(obj)/isoimage/linux echo '$(image_cmdline)' > $(obj)/isoimage/isolinux.cfg if [ -f '$(FDINITRD)' ] ; then \ cp '$(FDINITRD)' $(obj)/isoimage/initrd.img ; \ @@ -174,12 +176,13 @@ isoimage: $(BOOTIMAGE) isohybrid $(obj)/image.iso 2>/dev/null || true rm -rf $(obj)/isoimage -zlilo: $(BOOTIMAGE) +bzlilo: $(obj)/bzImage if [ -f $(INSTALL_PATH)/vmlinuz ]; then mv $(INSTALL_PATH)/vmlinuz $(INSTALL_PATH)/vmlinuz.old; fi if [ -f $(INSTALL_PATH)/System.map ]; then mv $(INSTALL_PATH)/System.map $(INSTALL_PATH)/System.old; fi - cat $(BOOTIMAGE) > $(INSTALL_PATH)/vmlinuz + cat $(obj)/bzImage > $(INSTALL_PATH)/vmlinuz cp System.map $(INSTALL_PATH)/ if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi install: - sh $(srctree)/$(src)/install.sh $(KERNELRELEASE) $(BOOTIMAGE) System.map "$(INSTALL_PATH)" + sh $(srctree)/$(src)/install.sh $(KERNELRELEASE) $(obj)/bzImage \ + System.map "$(INSTALL_PATH)" ^ permalink raw reply related [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-03-12 20:00 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-11 0:20 x86: removing zImage support? H. Peter Anvin 2009-03-11 1:15 ` Andi Kleen 2009-03-11 1:47 ` H. Peter Anvin 2009-03-11 10:24 ` Ingo Molnar 2009-03-11 11:03 ` Thomas Gleixner 2009-03-11 14:14 ` Woody Suwalski 2009-03-11 17:03 ` H. Peter Anvin 2009-03-11 17:39 ` Ian Campbell 2009-03-11 18:02 ` H. Peter Anvin 2009-03-11 18:06 ` [tip:x86/setup] x86: remove zImage support H. Peter Anvin 2009-03-12 17:45 ` Paul Bolle 2009-03-12 19:25 ` H. Peter Anvin 2009-03-12 19:28 ` H. Peter Anvin 2009-03-12 19:57 ` [tip:x86/setup] x86: remove additional vestiges of the zImage/bzImage split H. Peter Anvin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.