From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@zip.com.au>,
linux-kernel@vger.kernel.org,
Werner Almesberger <wa@almesberger.net>,
"Erik A. Hendriks" <hendriks@lanl.gov>
Subject: Re: [RFC] x86 ELF bootable kernels/Linux booting Linux/LinuxBIOS
Date: 30 Jan 2002 22:15:40 -0700 [thread overview]
Message-ID: <m1r8o7ayo3.fsf@frodo.biederman.org> (raw)
In-Reply-To: <m1elk7d37d.fsf@frodo.biederman.org> <3C586355.A396525B@zip.com.au> <m1zo2vb5rt.fsf@frodo.biederman.org> <3C58B078.3070803@zytor.com> <m1vgdjb0x0.fsf@frodo.biederman.org> <3C58CAE0.4040102@zytor.com>
In-Reply-To: <3C58CAE0.4040102@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>
> > I am reluctant to go with a bootimg like interface because having a
> > standard format encourages people to standardize. Though a good
> > argument can persuade me. I don't loose any flexibility in comparison
> > to bootimg because composing files on the fly is not significantly
> > harder than composing a bootable image in ram. Please tell me if I haven't
> > clearly answered your concerns about
> > being locked into a single image.
> >
>
>
> I have to think about it. I'm not convinced that this particular flavour of
> standardization is a step in the right direction -- in fact, it is *guaranteed*
> to provide significant additional complexity for bootloaders, and bzImage
> support is still going to have to be provided for the forseeable
> future.
It is not my intention to deprecate bzImage at this time. But instead
to provide an alternative.
> Since
> you express that it will basically be necessary to stitch the ELF file together
> on the fly I don't see much point, quite frankly; it seems like extra complexity
> for no good reason.
This part is only for people using the kernel as a bootloader. My
apologies if I didn't make it clear.
Let me clarify a little with usage. I have three cases I am targeting.
1) LinuxBIOS.
I need a kernel format that doesn't unconditionally do 16bit BIOS
queries, as there is no 16bit code in LinuxBIOS. bzImage doesn't
work.
2) Portability.
For this I have with some simple bootstrap program that loads the
kernel. And then I have the kernel driving devices and acting a
super bootloader. Something like Grub but with the full power
linux can bring to bear on the issue. This is all I need to
standardize the user booting experience on multiple platforms.
3) Network Booting.
There is not much chance to change bootroms once they are flashed
so they like LinuxBIOS need a general purpose interface, so that can
handle whatever they need to boot.
On the dynamic stitching/initramfs side, the code should really be no
more complex than the current bzImage loading with ramdisks. And if
bootloaders want to keep it simple can drop any optional ELF features,
which should be much simpler than todays bzImage.
Now I will shut up and let you digest this.
Eric
next prev parent reply other threads:[~2002-01-31 5:19 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-30 19:54 [RFC] x86 ELF bootable kernels/Linux booting Linux/LinuxBIOS Eric W. Biederman
2002-01-30 21:19 ` Andrew Morton
2002-01-30 23:52 ` Keith Owens
2002-01-31 2:42 ` Eric W. Biederman
2002-01-31 2:48 ` H. Peter Anvin
2002-01-31 4:27 ` Eric W. Biederman
2002-01-31 4:41 ` H. Peter Anvin
2002-01-31 5:15 ` Eric W. Biederman [this message]
2002-01-31 5:59 ` H. Peter Anvin
[not found] ` <m1n0yvaucy.fsf@frodo.biederman.org>
2002-01-31 17:57 ` H. Peter Anvin
2002-01-31 22:34 ` Eric W. Biederman
2002-01-31 22:52 ` H. Peter Anvin
2002-02-01 7:52 ` Eric W. Biederman
2002-01-31 17:35 ` Erik A. Hendriks
2002-01-31 23:36 ` Eric W. Biederman
2002-02-01 0:03 ` H. Peter Anvin
2002-02-01 9:03 ` Eric W. Biederman
2002-02-01 9:25 ` H. Peter Anvin
2002-02-01 15:42 ` Eric W. Biederman
2002-02-01 18:26 ` H. Peter Anvin
2002-02-02 16:17 ` Eric W. Biederman
2002-02-02 21:06 ` H. Peter Anvin
2002-02-02 23:02 ` Eric W. Biederman
2002-02-03 1:56 ` H. Peter Anvin
2002-02-03 18:43 ` Eric W. Biederman
2002-02-03 19:39 ` H. Peter Anvin
2002-02-03 22:18 ` Rob Landley
2002-02-03 22:24 ` H. Peter Anvin
2002-02-03 22:59 ` Rob Landley
2002-02-03 23:01 ` H. Peter Anvin
2002-02-03 23:47 ` Rob Landley
2002-02-04 1:34 ` H. Peter Anvin
2002-02-04 9:53 ` Marco Colombo
2002-02-04 16:19 ` H. Peter Anvin
2002-02-04 19:55 ` Eric W. Biederman
2002-02-04 20:51 ` Alan Cox
2002-02-04 20:40 ` H. Peter Anvin
2002-02-03 19:48 ` H. Peter Anvin
2002-02-04 20:16 ` Eric W. Biederman
2002-02-04 4:29 ` Keith Owens
2002-02-04 20:01 ` Eric W. Biederman
2002-02-04 12:49 ` Werner Almesberger
2002-02-04 16:26 ` H. Peter Anvin
2002-02-04 19:45 ` Eric W. Biederman
2002-02-04 21:02 ` Werner Almesberger
2002-02-04 21:08 ` H. Peter Anvin
2002-02-05 7:45 ` Eric W. Biederman
2002-02-01 0:46 ` Keith Owens
2002-01-31 3:03 ` Keith Owens
2002-02-01 7:22 ` Greg KH
2002-01-30 21:32 ` H. Peter Anvin
2002-01-31 2:31 ` Eric W. Biederman
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=m1r8o7ayo3.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=akpm@zip.com.au \
--cc=hendriks@lanl.gov \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wa@almesberger.net \
/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