From: Sam Ravnborg <sam@ravnborg.org>
To: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 1/5] kbuild: default kernel image
Date: Tue, 15 Jun 2004 06:40:20 +0200 [thread overview]
Message-ID: <20040615044020.GC16664@mars.ravnborg.org> (raw)
In-Reply-To: <20040614220549.L14403@flint.arm.linux.org.uk>
On Mon, Jun 14, 2004 at 10:05:49PM +0100, Russell King wrote:
>
> I'm slightly scared of this. Historically, there's already pressure
> from boot loader people on ARM to include random file formats to suit
> their own boot loaders.
>
> In the first place, ARM had Image and zImage and that was it. It was
> well defined. Then people decided that gzipped Image would be nice
> and they'd merge the zlib code into their boot loader. I think there's
> even some people who use gzipped zImage...!
>
> Then ARMboot came along and we eventually ended up with uboot-style
> wrappings to support uboot / ARMboot, which require an external program
> to be installed on the host system called "mkimage" (which, incidentally
> is an incredibly bad choice of name.)
>
> People also came up with the idea of using the ELF file directly and
> having the boot loader parse the ELF file. I wouldn't put it past
> someone to want gzipped ELF as well.
>
> There's also srec to support serially downloaded images as well.
>
> So, in total, we have boot loaders which want:
>
> - Image
> - zImage
> - gzipped Image
> - gzipped zImage
> - uboot
> - ELF
> - srec
>
> Basically this is somewhere I don't want to go. My position is that
> if boot loaders want to have their own proprietary formats, they
> should do whatever manipulation to the kernel image is necessary as
> a post processing step themselves from one of the two standard kernel
> formats - Image or zImage.
>
> However, the problem of offering users all these options is that their
> first question will be "huh, which one of these 7 do I want?" rather
> than everyone knowing that they need the kernel build to produce either
> an Image or zImage and the boot loader documentation telling them what
> to do with it next.
The advantage is that you now have a good place to document all of
these formats - your Kconfig file.
And you select the default target for the user.
How did I know uboot required mkimage before - now it can be documented
in Kconfig.
So the situation above is actually a good example why it is whortwhile
to move the kernel image selection to the config stage.
If they all should be part of the kernel build is another discussion.
Sam
next prev parent reply other threads:[~2004-06-15 4:31 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-14 20:40 [PATCH 0/5] kbuild Sam Ravnborg
2004-06-14 20:44 ` [PATCH 1/5] kbuild: default kernel image Sam Ravnborg
2004-06-14 21:05 ` Russell King
2004-06-15 4:40 ` Sam Ravnborg [this message]
2004-06-15 8:38 ` Russell King
2004-06-15 8:59 ` Christoph Hellwig
2004-06-15 21:07 ` Sam Ravnborg
2004-06-15 21:17 ` Russell King
2004-06-16 15:34 ` Tom Rini
2004-06-15 15:38 ` Tom Rini
2004-06-15 15:53 ` Russell King
2004-06-14 20:45 ` [PATCH 2/5] kbuild: move rpm to scripts/package Sam Ravnborg
2004-06-14 20:46 ` [PATCH 3/5] kbuild: add deb-pkg target Sam Ravnborg
2004-06-14 20:58 ` Wichert Akkerman
2004-06-14 21:22 ` Sam Ravnborg
2004-06-14 20:46 ` [PATCH 4/5] kbuild: make clean improved Sam Ravnborg
2004-06-14 20:50 ` Russell King
2004-06-14 21:19 ` Sam Ravnborg
2004-06-14 21:38 ` Tom Rini
2004-06-15 4:36 ` Sam Ravnborg
2004-06-15 18:50 ` V13
2004-06-14 20:48 ` [PATCH 5/5] kbuild: external module build doc Sam Ravnborg
2004-06-15 12:13 ` Horst von Brand
2004-06-15 20:09 ` Sam Ravnborg
2004-06-15 19:21 ` Jari Ruusu
2004-06-15 19:55 ` Sam Ravnborg
2004-06-15 23:00 ` Martin Schlemmer
2004-06-16 17:32 ` Jari Ruusu
2004-06-14 20:59 ` [PATCH 0/5] kbuild Sam Ravnborg
2004-06-14 23:56 ` Jeff Garzik
2004-06-15 15:41 ` Tom Rini
2004-06-15 17:49 ` Sam Ravnborg
2004-06-15 17:54 ` Tom Rini
2004-06-15 19:01 ` Sam Ravnborg
2004-06-15 19:27 ` Tom Rini
2004-06-15 21:02 ` Sam Ravnborg
2004-06-15 21:24 ` Tom Rini
2004-06-15 18:09 ` Russell King
2004-06-15 19:14 ` Sam Ravnborg
2004-06-15 19:46 ` Russell King
2004-06-15 20:12 ` Sam Ravnborg
2004-06-15 20:55 ` Sam Ravnborg
2004-06-15 20:59 ` Tom Rini
2004-06-15 21:24 ` Sam Ravnborg
2004-06-15 21:06 ` Russell King
2004-06-16 19:49 ` Sam Ravnborg
2004-06-16 20:08 ` Tom Rini
2004-06-16 20:54 ` Sam Ravnborg
2004-06-16 20:49 ` Tom Rini
2004-06-17 6:56 ` Jan-Benedict Glaw
2004-06-18 20:58 ` Sam Ravnborg
[not found] <sam@ravnborg.org>
2004-09-05 20:12 ` kbuild: Simplify vmlinux generation Sam Ravnborg
2004-09-05 20:19 ` Sam Ravnborg
2004-09-06 18:41 ` Horst von Brand
2004-09-06 19:00 ` Sam Ravnborg
2004-09-06 19:12 ` Sam Ravnborg
2014-06-11 19:25 ` [PATCH v2] x86,vdso: Fix vdso_install Andy Lutomirski
2014-06-11 19:45 ` Sam Ravnborg
2014-06-12 13:19 ` Josh Boyer
2014-06-12 15:28 ` [PATCH v3] " Andy Lutomirski
2014-06-12 17:01 ` Josh Boyer
2014-06-13 17:24 ` H. Peter Anvin
2014-06-13 17:28 ` Andy Lutomirski
2014-06-13 18:19 ` [tip:x86/vdso] x86/vdso: " tip-bot for Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040615044020.GC16664@mars.ravnborg.org \
--to=sam@ravnborg.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox