>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: [email protected]
[mailto:[email protected]]On Behalf Of Randy.Dunlap
Sent: Monday, February 24, 2003 8:58 PM
To: [email protected]
Cc: [email protected]; [email protected]
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 <[email protected]>
| 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, [email protected]
|
| 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 = .);
| -
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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 --
[email protected]
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
[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 --
[email protected]
On Tue, 25 Feb 2003 11:35:57 +0000
Russell King <[email protected]> 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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Tue, 25 Feb 2003 09:25:20 +0000
Russell King <[email protected]> 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
On Tue, 25 Feb 2003 11:35:57 +0000
Russell King <[email protected]> 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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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 --
[email protected]
From: Mikael Starvik <[email protected]>
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
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
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