Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Randy.Dunlap]

| Date: Fri,  7 Feb 2003 21:36:21 +0000
| From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
| To: BK Commits List:  ;
| Subject: zImage now holds vmlinux, System.map and config in sections.
| 
| ChangeSet 1.914.1.34, 2003/02/07 15:36:21-06:00, tinglett@vnet.ibm.com
| 
| 	zImage now holds vmlinux, System.map and config in sections.


I'm very happy to see such a patch added to Linux (especially referring
to saving the .config file in the kernel image).  This is nice.

I've had such a patch for several months now but it's not quite as
simple as this one....so... I don't know linker scripts very well.
Can this be done for all architectures?
I'd like to see a solution that is arch-independent.

And I do prefer to see the config data saved with the kernel image file
(like this) and accessible even when the kernel isn't running, instead
of only being available in /proc/config.gz when that kernel is running.

Thanks,
~Randy




| diff -Nru a/arch/ppc64/boot/Makefile b/arch/ppc64/boot/Makefile
| --- a/arch/ppc64/boot/Makefile	Sat Feb 22 13:05:38 2003
| +++ b/arch/ppc64/boot/Makefile	Sat Feb 22 13:05:38 2003
| @@ -24,35 +24,45 @@
|  #CROSS32_COMPILE = /usr/local/ppc/bin/powerpc-linux-
|  
| +#-----------------------------------------------------------
| +# ELF sections within the zImage bootloader/wrapper
| +#-----------------------------------------------------------
| +required := vmlinux .config System.map
| +initrd   := initrd
| +
| +obj-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.o, $(section)))
| +src-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.c, $(section)))
| +gz-sec  = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.gz, $(section)))
| +
| +host-progs		:= piggy addnote addSystemMap addRamDisk
| +EXTRA_TARGETS 		+= zImage zImage.initrd imagesize.c \
| +			   $(patsubst $(obj)/%,%, $(call obj-sec, $(required) $(initrd))) \
| +			   $(patsubst $(obj)/%,%, $(call src-sec, $(required) $(initrd))) \
| +			   $(patsubst $(obj)/%,%, $(call gz-sec, $(required) $(initrd))) \
|  			   vmlinux.sm vmlinux.initrd vmlinux.sminitrd \
|  			   sysmap.o initrd.o
|  
| @@ -69,42 +79,48 @@
|  $(obj)/vmlinux.sminitrd: $(obj)/vmlinux.sm $(obj)/addRamDisk $(obj)/ramdisk.image.gz FORCE
|  	$(call if_changed,ramdisk)
|  
| +$(obj)/sysmap.o: System.map $(obj)/piggyback
| +	$(call if_changed,piggy)
| +
| +addsection = $(BOOTOBJCOPY) $(1) \
| +		--add-section=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $(1)))=$(patsubst %.o,%.gz, $(1)) \
| +		--set-section-flags=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $(1)))=$(OBJCOPYFLAGS)
| +
| +quiet_cmd_addnote = ADDNOTE $@ 
| +      cmd_addnote = $(BOOTLD) $(BOOTLFLAGS) -o $@ $(obj-boot) && $(obj)/addnote $@
|  
|  quiet_cmd_piggy = PIGGY   $@
|        cmd_piggy = $(obj)/piggyback $(@:.o=) < $< | $(BOOTAS) -o $@
|  
| -$(obj)/image.o: $(obj)/vmlinux.gz $(obj)/piggyback FORCE
| -	$(call if_changed,piggy)
| +$(call gz-sec, $(required)): $(obj)/kernel-%.gz: %
| +	$(call if_changed,gzip)
|  
| -$(obj)/sysmap.o: System.map $(obj)/piggyback FORCE
| -	$(call if_changed,piggy)
| +$(obj)/kernel-initrd.gz: $(obj)/ramdisk.image.gz
| +	cp -f $(obj)/ramdisk.image.gz $@
|  
| -$(obj)/initrd.o: $(obj)/ramdisk.image.gz $(obj)/piggyback FORCE
| -	$(call if_changed,piggy)
| +$(call src-sec, $(required) $(initrd)): $(obj)/kernel-%.c: $(obj)/kernel-%.gz
| +	touch $@
|  
| -quiet_cmd_addnote = ADDNOTE $@ 
| -      cmd_addnote = $(BOOTLD) $(LD_ARGS) -T $(obj)/zImage.lds -o $@ $(OBJS) $<\
| -		    && $(obj)/addnote $@
| +$(call obj-sec, $(required) $(initrd)): $(obj)/kernel-%.o: $(obj)/kernel-%.c
| +	$(call if_changed_dep,bootcc)
| +	$(call addsection, $@)
|  
| -$(obj)/zImage: $(obj)/no_initrd.o $(OBJS) $(obj)/addnote FORCE
| +$(obj)/zImage: obj-boot += $(call obj-sec, $(required))
| +$(obj)/zImage: $(call obj-sec, $(required)) $(obj-boot) $(obj)/addnote FORCE
|  	$(call if_changed,addnote)
|  
| -$(obj)/zImage.initrd: $(obj)/initrd.o $(OBJS) $(obj)/addnote FORCE
| +$(obj)/zImage.initrd: obj-boot += $(call obj-sec, $(required) $(initrd))
| +$(obj)/zImage.initrd: $(call obj-sec, $(required) $(initrd)) $(obj-boot) $(obj)/addnote FORCE
|  	$(call if_changed,addnote)
|  
| -$(obj)/vmlinux.bin: vmlinux FORCE
| -	$(call if_changed,objcopy)
| -
| -$(obj)/vmlinux.gz: $(obj)/vmlinux.bin FORCE
| -	$(call if_changed,gzip)
| -
|  $(obj)/imagesize.c: vmlinux
|  	@echo Generating $@
|  	ls -l vmlinux | \
|  	awk '{printf "/* generated -- do not edit! */\n" \
| -		"int uncompressed_size = %d;\n", $$5}' > $(obj)/imagesize.c
| +		"unsigned long vmlinux_filesize = %d;\n", $$5}' > $(obj)/imagesize.c
|  	$(CROSS_COMPILE)nm -n vmlinux | tail -1 | \
| -	awk '{printf "long vmlinux_end = 0x%s;\n", substr($$1,8)}' \
| +	awk '{printf "unsigned long vmlinux_memsize = 0x%s;\n", substr($$1,8)}' \
|  		>> $(obj)/imagesize.c
|  
| -clean-files :=  $(targets)
| +
| +clean-files := $(patsubst $(obj)/%,%, $(obj-boot))
| diff -Nru a/arch/ppc64/boot/README b/arch/ppc64/boot/README
| --- /dev/null	Wed Dec 31 16:00:00 1969
| +++ b/arch/ppc64/boot/README	Sat Feb 22 13:05:38 2003
| @@ -0,0 +1,11 @@
| +
| +To extract the kernel vmlinux, System.map, .config or initrd from the zImage binary:
| +
| +objcopy -j .kernel:vmlinux -O binary zImage vmlinux.gz
| +objcopy -j .kernel:System.map -O binary zImage System.map.gz
| +objcopy -j .kernel:.config -O binary zImage config.gz
| +objcopy -j .kernel:initrd -O binary zImage.initrd initrd.gz


| diff -Nru a/arch/ppc64/boot/zImage.lds b/arch/ppc64/boot/zImage.lds
| --- a/arch/ppc64/boot/zImage.lds	Sat Feb 22 13:05:38 2003
| +++ b/arch/ppc64/boot/zImage.lds	Sat Feb 22 13:05:38 2003
| @@ -58,6 +58,27 @@
|      *(.dynamic)
|      CONSTRUCTORS
|    }
| +
| +  . = ALIGN(4096);
| +  _vmlinux_start =  .;
| +  .kernel:vmlinux : { *(.kernel:vmlinux) }
| +  _vmlinux_end =  .;
| +
| +  . = ALIGN(4096);
| +  _dotconfig_start =  .;
| +  .kernel:.config : { *(.kernel:.config) }
| +  _dotconfig_end =  .;
| +
| +  . = ALIGN(4096);
| +  _sysmap_start =  .;
| +  .kernel:System.map : { *(.kernel:System.map) }
| +  _sysmap_end =  .;
| +
| +  . = ALIGN(4096);
| +  _initrd_start =  .;
| +  .kernel:initrd : { *(.kernel:initrd) }
| +  _initrd_end =  .;
| +
|    . = ALIGN(4096);
|    _edata  =  .;
|    PROVIDE (edata = .);
| -

RE: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Mikael Starvik]

>I don't know linker scripts very well.
>Can this be done for all architectures?
>I'd like to see a solution that is arch-independent.

In embedded systems it is probably not desirable to keep 
System.map and config in zImage (takes too much valuable space).

/Mikael

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Randy.Dunlap
Sent: Monday, February 24, 2003 8:58 PM
To: linux-kernel@vger.kernel.org
Cc: tinglett@vnet.ibm.com; torvalds@transmeta.com
Subject: Re: zImage now holds vmlinux, System.map and config in
sections. (fwd)


| Date: Fri,  7 Feb 2003 21:36:21 +0000
| From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
| To: BK Commits List:  ;
| Subject: zImage now holds vmlinux, System.map and config in sections.
| 
| ChangeSet 1.914.1.34, 2003/02/07 15:36:21-06:00, tinglett@vnet.ibm.com
| 
| 	zImage now holds vmlinux, System.map and config in sections.


I'm very happy to see such a patch added to Linux (especially referring
to saving the .config file in the kernel image).  This is nice.

I've had such a patch for several months now but it's not quite as
simple as this one....so... I don't know linker scripts very well.
Can this be done for all architectures?
I'd like to see a solution that is arch-independent.

And I do prefer to see the config data saved with the kernel image file
(like this) and accessible even when the kernel isn't running, instead
of only being available in /proc/config.gz when that kernel is running.

Thanks,
~Randy




| diff -Nru a/arch/ppc64/boot/Makefile b/arch/ppc64/boot/Makefile
| --- a/arch/ppc64/boot/Makefile	Sat Feb 22 13:05:38 2003
| +++ b/arch/ppc64/boot/Makefile	Sat Feb 22 13:05:38 2003
| @@ -24,35 +24,45 @@
|  #CROSS32_COMPILE = /usr/local/ppc/bin/powerpc-linux-
|  
| +#-----------------------------------------------------------
| +# ELF sections within the zImage bootloader/wrapper
| +#-----------------------------------------------------------
| +required := vmlinux .config System.map
| +initrd   := initrd
| +
| +obj-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.o, $(section)))
| +src-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.c, $(section)))
| +gz-sec  = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.gz, $(section)))
| +
| +host-progs		:= piggy addnote addSystemMap addRamDisk
| +EXTRA_TARGETS 		+= zImage zImage.initrd imagesize.c \
| +			   $(patsubst $(obj)/%,%, $(call obj-sec, $(required) $(initrd))) \
| +			   $(patsubst $(obj)/%,%, $(call src-sec, $(required) $(initrd))) \
| +			   $(patsubst $(obj)/%,%, $(call gz-sec, $(required) $(initrd))) \
|  			   vmlinux.sm vmlinux.initrd vmlinux.sminitrd \
|  			   sysmap.o initrd.o
|  
| @@ -69,42 +79,48 @@
|  $(obj)/vmlinux.sminitrd: $(obj)/vmlinux.sm $(obj)/addRamDisk $(obj)/ramdisk.image.gz FORCE
|  	$(call if_changed,ramdisk)
|  
| +$(obj)/sysmap.o: System.map $(obj)/piggyback
| +	$(call if_changed,piggy)
| +
| +addsection = $(BOOTOBJCOPY) $(1) \
| +		--add-section=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $(1)))=$(patsubst %.o,%.gz, $(1)) \
| +		--set-section-flags=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $(1)))=$(OBJCOPYFLAGS)
| +
| +quiet_cmd_addnote = ADDNOTE $@ 
| +      cmd_addnote = $(BOOTLD) $(BOOTLFLAGS) -o $@ $(obj-boot) && $(obj)/addnote $@
|  
|  quiet_cmd_piggy = PIGGY   $@
|        cmd_piggy = $(obj)/piggyback $(@:.o=) < $< | $(BOOTAS) -o $@
|  
| -$(obj)/image.o: $(obj)/vmlinux.gz $(obj)/piggyback FORCE
| -	$(call if_changed,piggy)
| +$(call gz-sec, $(required)): $(obj)/kernel-%.gz: %
| +	$(call if_changed,gzip)
|  
| -$(obj)/sysmap.o: System.map $(obj)/piggyback FORCE
| -	$(call if_changed,piggy)
| +$(obj)/kernel-initrd.gz: $(obj)/ramdisk.image.gz
| +	cp -f $(obj)/ramdisk.image.gz $@
|  
| -$(obj)/initrd.o: $(obj)/ramdisk.image.gz $(obj)/piggyback FORCE
| -	$(call if_changed,piggy)
| +$(call src-sec, $(required) $(initrd)): $(obj)/kernel-%.c: $(obj)/kernel-%.gz
| +	touch $@
|  
| -quiet_cmd_addnote = ADDNOTE $@ 
| -      cmd_addnote = $(BOOTLD) $(LD_ARGS) -T $(obj)/zImage.lds -o $@ $(OBJS) $<\
| -		    && $(obj)/addnote $@
| +$(call obj-sec, $(required) $(initrd)): $(obj)/kernel-%.o: $(obj)/kernel-%.c
| +	$(call if_changed_dep,bootcc)
| +	$(call addsection, $@)
|  
| -$(obj)/zImage: $(obj)/no_initrd.o $(OBJS) $(obj)/addnote FORCE
| +$(obj)/zImage: obj-boot += $(call obj-sec, $(required))
| +$(obj)/zImage: $(call obj-sec, $(required)) $(obj-boot) $(obj)/addnote FORCE
|  	$(call if_changed,addnote)
|  
| -$(obj)/zImage.initrd: $(obj)/initrd.o $(OBJS) $(obj)/addnote FORCE
| +$(obj)/zImage.initrd: obj-boot += $(call obj-sec, $(required) $(initrd))
| +$(obj)/zImage.initrd: $(call obj-sec, $(required) $(initrd)) $(obj-boot) $(obj)/addnote FORCE
|  	$(call if_changed,addnote)
|  
| -$(obj)/vmlinux.bin: vmlinux FORCE
| -	$(call if_changed,objcopy)
| -
| -$(obj)/vmlinux.gz: $(obj)/vmlinux.bin FORCE
| -	$(call if_changed,gzip)
| -
|  $(obj)/imagesize.c: vmlinux
|  	@echo Generating $@
|  	ls -l vmlinux | \
|  	awk '{printf "/* generated -- do not edit! */\n" \
| -		"int uncompressed_size = %d;\n", $$5}' > $(obj)/imagesize.c
| +		"unsigned long vmlinux_filesize = %d;\n", $$5}' > $(obj)/imagesize.c
|  	$(CROSS_COMPILE)nm -n vmlinux | tail -1 | \
| -	awk '{printf "long vmlinux_end = 0x%s;\n", substr($$1,8)}' \
| +	awk '{printf "unsigned long vmlinux_memsize = 0x%s;\n", substr($$1,8)}' \
|  		>> $(obj)/imagesize.c
|  
| -clean-files :=  $(targets)
| +
| +clean-files := $(patsubst $(obj)/%,%, $(obj-boot))
| diff -Nru a/arch/ppc64/boot/README b/arch/ppc64/boot/README
| --- /dev/null	Wed Dec 31 16:00:00 1969
| +++ b/arch/ppc64/boot/README	Sat Feb 22 13:05:38 2003
| @@ -0,0 +1,11 @@
| +
| +To extract the kernel vmlinux, System.map, .config or initrd from the zImage binary:
| +
| +objcopy -j .kernel:vmlinux -O binary zImage vmlinux.gz
| +objcopy -j .kernel:System.map -O binary zImage System.map.gz
| +objcopy -j .kernel:.config -O binary zImage config.gz
| +objcopy -j .kernel:initrd -O binary zImage.initrd initrd.gz


| diff -Nru a/arch/ppc64/boot/zImage.lds b/arch/ppc64/boot/zImage.lds
| --- a/arch/ppc64/boot/zImage.lds	Sat Feb 22 13:05:38 2003
| +++ b/arch/ppc64/boot/zImage.lds	Sat Feb 22 13:05:38 2003
| @@ -58,6 +58,27 @@
|      *(.dynamic)
|      CONSTRUCTORS
|    }
| +
| +  . = ALIGN(4096);
| +  _vmlinux_start =  .;
| +  .kernel:vmlinux : { *(.kernel:vmlinux) }
| +  _vmlinux_end =  .;
| +
| +  . = ALIGN(4096);
| +  _dotconfig_start =  .;
| +  .kernel:.config : { *(.kernel:.config) }
| +  _dotconfig_end =  .;
| +
| +  . = ALIGN(4096);
| +  _sysmap_start =  .;
| +  .kernel:System.map : { *(.kernel:System.map) }
| +  _sysmap_end =  .;
| +
| +  . = ALIGN(4096);
| +  _initrd_start =  .;
| +  .kernel:initrd : { *(.kernel:initrd) }
| +  _initrd_end =  .;
| +
|    . = ALIGN(4096);
|    _edata  =  .;
|    PROVIDE (edata = .);
| -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Russell King]

On Tue, Feb 25, 2003 at 07:28:46AM +0100, Mikael Starvik wrote:
> >I don't know linker scripts very well.
> >Can this be done for all architectures?
> >I'd like to see a solution that is arch-independent.
> 
> In embedded systems it is probably not desirable to keep 
> System.map and config in zImage (takes too much valuable space).

Agreed - zImage is already around 1MB on many ARM machines, and since
loading zImage over a serial port using xmodem takes long enough
already, this is one silly feature I'll definitely keep out of the
ARM tree.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Ville Herva]

On Tue, Feb 25, 2003 at 09:25:20AM +0000, you [Russell King] wrote:
> On Tue, Feb 25, 2003 at 07:28:46AM +0100, Mikael Starvik wrote:
> > >I don't know linker scripts very well.
> > >Can this be done for all architectures?
> > >I'd like to see a solution that is arch-independent.
> > 
> > In embedded systems it is probably not desirable to keep 
> > System.map and config in zImage (takes too much valuable space).
> 
> Agreed - zImage is already around 1MB on many ARM machines, and since
> loading zImage over a serial port using xmodem takes long enough
> already, this is one silly feature I'll definitely keep out of the
> ARM tree.

Why not make it a config option (like the other (two? three?) rejected
patches that implemented this did)?


-- v --

v@iki.fi

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Russell King]

On Tue, Feb 25, 2003 at 01:07:04PM +0200, Ville Herva wrote:
> On Tue, Feb 25, 2003 at 09:25:20AM +0000, you [Russell King] wrote:
> > Agreed - zImage is already around 1MB on many ARM machines, and since
> > loading zImage over a serial port using xmodem takes long enough
> > already, this is one silly feature I'll definitely keep out of the
> > ARM tree.
> 
> Why not make it a config option (like the other (two? three?) rejected
> patches that implemented this did)?

I, for one, do not see any point in trying to put more and more crap
into one file, when its perfectly easy to just use the "cp" command
to produce the same end result, namely a copy of zImage, System.map
and configuration, thusly:

cp arch/$ARCH/boot/zImage /boot/vmlinuz-$VERSION
cp .config /boot/config-$VERSION
cp System.map /boot/System.map-$VERSION

No hastles with configuration options.  No hastles with bloated zImage
files.  No hastles with adding extra stuff to makefiles to do special
mangling to zImage.

If people are worried about vmlinuz being out of step with config, once
you add the above to the installation target of the kernel makefile,
unless you do things manually, you won't get out of step.

If you're worried about config-* and System.map-* being out of step with
the kernel you're running, exactly the same applies to the "everything
in one file" version as well.

If you need to make a backup of it:

mkdir /boot/old
cp /boot/*-$VERSION /boot/old

Nice.  Simple.  No crap.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Ville Herva]

[This has been beaten to death multiple times over the years - I'm sorry to
repeat the same remarks again...]

On Tue, Feb 25, 2003 at 11:35:57AM +0000, you [Russell King] wrote:
> 
> I, for one, do not see any point in trying to put more and more crap
> into one file, when its perfectly easy to just use the "cp" command
> 
> <snip instructions>

I do appreciate that you find no use for this feature. You instructions will
work fine if one always compiles the kernel using the same discipline and
and stores them under /boot on the same computer.

Not everybody are always that careful. I know I'm not. I've copied tens of
kernels to floppy ("cp bzImage /dev/fd0" because it's so easy to do), and
lost track which one is which. I've copied kernels to other computers, and
lost track which is which. I've made mistakes copying kernels to /boot, and
lost track which is which.

I have been using Peter Breuer's proconfig patch and I have found it useful.
Just cat /proc/config, and there you have the config for the running kernel
- no matter if it was booted from a throw-away floppy, network or /boot.
It only adds couple of kB to the bzImage, and I am ready to pay that price.

If you are not - well it is a config option for that very reason. 


-- v --

v@iki.fi

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Remco Post]

On Tue, 25 Feb 2003 11:35:57 +0000
Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Feb 25, 2003 at 01:07:04PM +0200, Ville Herva wrote:
> > On Tue, Feb 25, 2003 at 09:25:20AM +0000, you [Russell King] wrote:
> > > Agreed - zImage is already around 1MB on many ARM machines, and since
> > > loading zImage over a serial port using xmodem takes long enough
> > > already, this is one silly feature I'll definitely keep out of the
> > > ARM tree.
> > 
> > Why not make it a config option (like the other (two? three?) rejected
> > patches that implemented this did)?
> 
> I, for one, do not see any point in trying to put more and more crap
> into one file, when its perfectly easy to just use the "cp" command
> to produce the same end result, namely a copy of zImage, System.map
> and configuration, thusly:
> 
> cp arch/$ARCH/boot/zImage /boot/vmlinuz-$VERSION
> cp .config /boot/config-$VERSION
> cp System.map /boot/System.map-$VERSION
> 

Hmm, and how would you implement that on a system (ppc/prep) that could very
easily netboot a kernel... no /boot needed? I for one build kernels on one
box that is more or less production and netboot another just to see it fail
horribly... having all stuff in one file could help....

-- 
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam    http://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer industry
didn't even foresee that the century was going to end." -- Douglas Adams

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Russell King]

On Tue, Feb 25, 2003 at 01:50:10PM +0100, Remco Post wrote:
> Hmm, and how would you implement that on a system (ppc/prep) that could very
> easily netboot a kernel... no /boot needed? I for one build kernels on one
> box that is more or less production and netboot another just to see it fail
> horribly... having all stuff in one file could help....

So you want to transfer the complete zImage, including the redundant
configuration and system.map to the target over the network, only to
have it thrown away?

Guess what?  I netboot ARM boxes as well.  I cope.  It's easy.  You
change /boot/ to be $TARGET (eg, /var/boot/kernels/), which is where
you put your netboot kernel image today.

If you have more than one kernel build, then put it in
TARGET=/var/boot/kernels/<machine-name>/

Or, in the case of a NFS root setup, you place all the files in the
boot directory of the NFS root image for the target system.  This way,
the target gets the correct System.map, again with no extra hastles.

I do all of the above (minus the .config.)  It works.  Nice.  Simple.
No hastle.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Jeremy Jackson]

>From a pure technical point of view, it seems just like bloat.  But from a
distribution, maintenance, etc point of view, it's a godsend.  It's a config
option, just like devfs and initrd, so just don't use it if you don't want
to.

One suggestion, make the config option have 2 choices to include it, one
which sets the ELF attribute to load it, the other which just puts it in the
file but doesn't load it.

Also, does it make sense to strip the kernel, reformat the symbols into
System.map, then put them back into the image?

Regards,

Jeremy

----- Original Message -----
From: "Ville Herva" <vherva@niksula.hut.fi>
To: "Mikael Starvik" <mikael.starvik@axis.com>; "'Randy.Dunlap'"
<rddunlap@osdl.org>; <linux-kernel@vger.kernel.org>;
<tinglett@vnet.ibm.com>; <torvalds@transmeta.com>
Sent: Tuesday, February 25, 2003 7:03 AM
Subject: Re: zImage now holds vmlinux, System.map and config in sections.
(fwd)


> I do appreciate that you find no use for this feature. You instructions
will
> work fine if one always compiles the kernel using the same discipline and
> and stores them under /boot on the same computer.
>
> Not everybody are always that careful. I know I'm not. I've copied tens of
> kernels to floppy ("cp bzImage /dev/fd0" because it's so easy to do), and
> lost track which one is which. I've copied kernels to other computers, and
> lost track which is which. I've made mistakes copying kernels to /boot,
and
> lost track which is which.
>
> I have been using Peter Breuer's proconfig patch and I have found it
useful.
> Just cat /proc/config, and there you have the config for the running
kernel
> - no matter if it was booted from a throw-away floppy, network or /boot.
> It only adds couple of kB to the bzImage, and I am ready to pay that
price.
>
> If you are not - well it is a config option for that very reason.

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Randy.Dunlap]

On Tue, 25 Feb 2003 09:25:20 +0000
Russell King <rmk@arm.linux.org.uk> wrote:

| On Tue, Feb 25, 2003 at 07:28:46AM +0100, Mikael Starvik wrote:
| > >I don't know linker scripts very well.
| > >Can this be done for all architectures?
| > >I'd like to see a solution that is arch-independent.
| > 
| > In embedded systems it is probably not desirable to keep 
| > System.map and config in zImage (takes too much valuable space).
| 
| Agreed - zImage is already around 1MB on many ARM machines, and since
| loading zImage over a serial port using xmodem takes long enough
| already, this is one silly feature I'll definitely keep out of the
| ARM tree.

Yes, I understand that.  I would want it to be a config option.

--
~Randy

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Randy.Dunlap]

On Tue, 25 Feb 2003 11:35:57 +0000
Russell King <rmk@arm.linux.org.uk> wrote:

| On Tue, Feb 25, 2003 at 01:07:04PM +0200, Ville Herva wrote:
| > On Tue, Feb 25, 2003 at 09:25:20AM +0000, you [Russell King] wrote:
| > > Agreed - zImage is already around 1MB on many ARM machines, and since
| > > loading zImage over a serial port using xmodem takes long enough
| > > already, this is one silly feature I'll definitely keep out of the
| > > ARM tree.
| > 
| > Why not make it a config option (like the other (two? three?) rejected
| > patches that implemented this did)?
| 
| I, for one, do not see any point in trying to put more and more crap
| into one file, when its perfectly easy to just use the "cp" command
| to produce the same end result, namely a copy of zImage, System.map
| and configuration, thusly:
| 
| cp arch/$ARCH/boot/zImage /boot/vmlinuz-$VERSION
| cp .config /boot/config-$VERSION
| cp System.map /boot/System.map-$VERSION

Yes, that almost matches my 'new.kernel' install script.

| No hastles with configuration options.  No hastles with bloated zImage
| files.  No hastles with adding extra stuff to makefiles to do special
| mangling to zImage.

Yes, you wouldn't have to use it.

| If people are worried about vmlinuz being out of step with config, once
| you add the above to the installation target of the kernel makefile,
| unless you do things manually, you won't get out of step.
| 
| If you're worried about config-* and System.map-* being out of step with
| the kernel you're running, exactly the same applies to the "everything
| in one file" version as well.
| 
| If you need to make a backup of it:
| 
| mkdir /boot/old
| cp /boot/*-$VERSION /boot/old
| 
| Nice.  Simple.  No crap.

I'm just guessing that it will be difficult to convince you otherwise,
but I think you are missing the point of this.  It's not for someone
who already has scripts to handle this or already uses 3+ commands
to handle it every time that they build a new kernel.  It's for
people who are less organized than you are -- gosh, maybe even
for Linux users.

--
~Randy

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Russell King]

On Tue, Feb 25, 2003 at 08:38:11AM -0800, Randy.Dunlap wrote:
> I'm just guessing that it will be difficult to convince you otherwise,
> but I think you are missing the point of this.  It's not for someone
> who already has scripts to handle this or already uses 3+ commands
> to handle it every time that they build a new kernel.  It's for
> people who are less organized than you are -- gosh, maybe even
> for Linux users.

Well, rather than creating yet another archive system, maybe we should
just tar the lot up and make all boot loaders aware of the tar format?
After all, everyone understands tar and .debs better than RPMs, don't
they?

8-)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Ville Herva]

On Tue, Feb 25, 2003 at 08:38:11AM -0800, you [Randy.Dunlap] wrote:
> 
> It's for people who are less organized than you are -- gosh, maybe even
> for Linux users.

It doesn't even have to be _you_ that didn't save the .config. Sometimes one
has to compile a kernel for a server someone else has been maintaining. You
may not know if and where the .config for the old kernel is. Or perhaps it's
a vendor kernel.

In such case it's pretty convenient to just cat /proc/config.


-- v --

v@iki.fi

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[H. Peter Anvin]

Followup to:  <20030225092520.A9257@flint.arm.linux.org.uk>
By author:    Russell King <rmk@arm.linux.org.uk>
In newsgroup: linux.dev.kernel
>
> On Tue, Feb 25, 2003 at 07:28:46AM +0100, Mikael Starvik wrote:
> > >I don't know linker scripts very well.
> > >Can this be done for all architectures?
> > >I'd like to see a solution that is arch-independent.
> > 
> > In embedded systems it is probably not desirable to keep 
> > System.map and config in zImage (takes too much valuable space).
> 
> Agreed - zImage is already around 1MB on many ARM machines, and since
> loading zImage over a serial port using xmodem takes long enough
> already, this is one silly feature I'll definitely keep out of the
> ARM tree.
> 

Isn't that what "strip" is for?

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Russell King]

On Tue, Feb 25, 2003 at 12:00:14PM -0800, H. Peter Anvin wrote:
> Followup to:  <20030225092520.A9257@flint.arm.linux.org.uk>
> By author:    Russell King <rmk@arm.linux.org.uk>
> In newsgroup: linux.dev.kernel
> >
> > On Tue, Feb 25, 2003 at 07:28:46AM +0100, Mikael Starvik wrote:
> > > >I don't know linker scripts very well.
> > > >Can this be done for all architectures?
> > > >I'd like to see a solution that is arch-independent.
> > > 
> > > In embedded systems it is probably not desirable to keep 
> > > System.map and config in zImage (takes too much valuable space).
> > 
> > Agreed - zImage is already around 1MB on many ARM machines, and since
> > loading zImage over a serial port using xmodem takes long enough
> > already, this is one silly feature I'll definitely keep out of the
> > ARM tree.
> > 
> 
> Isn't that what "strip" is for?

zImage on ARM is a binary blob without any formatting.  The first
instruction to be executed is at the start of the file.  Perfect
for loading directly into flash or RAM via whatever boot loader
or debugger you choose.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[H. Peter Anvin]

Russell King wrote:
>>
>>Isn't that what "strip" is for?
> 
> zImage on ARM is a binary blob without any formatting.  The first
> instruction to be executed is at the start of the file.  Perfect
> for loading directly into flash or RAM via whatever boot loader
> or debugger you choose.
> 

Well, then it doesn't have sections.  As far as I could see the original
post only applied to architectures for which zImage is an ELF binary.

Similarly, this will not exist on x86/x86-64 where the (b)zImage is
mostly a binary blob.

	-hpa

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Bryan Andersen]

>>I, for one, do not see any point in trying to put more and more crap
>>into one file, when its perfectly easy to just use the "cp" command

> Not everybody are always that careful. I know I'm not. I've copied tens of
> kernels to floppy ("cp bzImage /dev/fd0" because it's so easy to do), and
> lost track which one is which. I've copied kernels to other computers, and
> lost track which is which. I've made mistakes copying kernels to /boot, and
> lost track which is which.

These problems are why I now always use shell scripts to do the steps 
that always need to be done.  If I did the steps by hand I'd make a 
mistake atleast once in five times.  I use the standard "make 
modules_install install" to do the kernel install.  I use shell scripts 
to make the kernel and modules before the install and to build and 
install all the nVidia modules after.  This allows me to test a new 
kernel much faster and with much less effort while not forgetting steps 
along the way.  The shell scripts don't need to be all that fancy.  Most 
often the same commands I would type in at the command line.  The one 
that builds and installs the nVidia stuff is just a bunch of cds to 
directories then the make or make install with a "|| exit 2" for exiting 
on failres.  The lines are of the form:

   cd {directory} && make {optional arg} || exit {#}

Areas in {} are replaced with the appropriate values.  The "|| exit" 
code is important because bash will normally continue on when a command 
fails.

- Bryan

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Magnus Danielson]

From: Mikael Starvik <mikael.starvik@axis.com>
Subject: RE: zImage now holds vmlinux, System.map and config in sections. (fwd)
Date: Tue, 25 Feb 2003 07:28:46 +0100

> >I don't know linker scripts very well.
> >Can this be done for all architectures?
> >I'd like to see a solution that is arch-independent.
> 
> In embedded systems it is probably not desirable to keep 
> System.map and config in zImage (takes too much valuable space).

Exactly. Your trying to round up all the floobydust you can for the production
binaries. However, for others it may be a good patch. Ability to leave out is
what would make both camps happy.

Cheers,
Magnus

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Peter Bergner]

Jeremy Jackson wrote:
 > From a pure technical point of view, it seems just like bloat.  But from a
 > distribution, maintenance, etc point of view, it's a godsend.  It's a config
 > option, just like devfs and initrd, so just don't use it if you don't want
 > to.

It was precisely for those reasons I made the changes (Todd Inglett was nice
enough to push the changes for me, hence his name on the change set).  The PPC64
arch is a server platform, so the extra disk space caused by the bloat in the
zImage isn't a problem.  However, the benefits of having the attached sections
is a godsend when a customer calls you up with a kernel problem and all they
can give you (they may not be very adept with Linux) is the zImage and some
type of error message.


Russell King wrote:
 > So you want to transfer the complete zImage, including the redundant
 > configuration and system.map to the target over the network, only to
 > have it thrown away?

For our architecture, why not?  We're not short on disk space and we can
netboot, so no problems there.  Yeah, for ARM and other embedded arches,
it may not be what you want to do, but for PPC64, it's a good solution.



Peter

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Todd Inglett]

On Tue, 2003-02-25 at 11:52, Russell King wrote:

> Well, rather than creating yet another archive system, maybe we should
> just tar the lot up and make all boot loaders aware of the tar format?
> After all, everyone understands tar and .debs better than RPMs, don't
> they?

I'm not sure ELF should really be considered "yet another archive
system."  This is analogous with keeping debug in another ELF section
for user apps.  You can keep it, you can strip it, etc.  Other formats
would work, but as you say you'd have to modify the bootloaders to
accept them.

These sections don't have to be thrown away after boot either.  While
the sections should be marked as no-load, it may be useful to actually
load them and have the kernel explicitly toss them if it finds no use
for them.  Real uses would including exporting to /proc/config.gz (if
you like that kind of thing), or providing the System.map to kdb if kdb
is enabled.

Note that we also supply the initial ramdisk (which is loaded of course)
this way.  In theory you could remove the ramdisk and replace it by
using objcopy, but we still have some things to fix before that will
work.  This *is* useful for people who netboot (at least for ppc64
systems).

-todd

Re: zImage now holds vmlinux, System.map and config in sections. (fwd)

[Peter Bergner]

Todd Inglett wrote:
> These sections don't have to be thrown away after boot either.  While
> the sections should be marked as no-load, it may be useful to actually
> load them and have the kernel explicitly toss them if it finds no use
> for them.  Real uses would including exporting to /proc/config.gz (if
> you like that kind of thing), or providing the System.map to kdb if kdb
> is enabled.

To be precise, these sections _are_ part of a PT_LOAD segment in the
zImage bootloader.  The kernel/vmlinux is then passed info via birecs
on where those sections are in memory.  As you say, we can then decide
in the kernel whether we want to keep or toss them.

Peter