public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 21:27:07 -0700	[thread overview]
Message-ID: <m1vgdjb0x0.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>
In-Reply-To: <3C58B078.3070803@zytor.com>

"H. Peter Anvin" <hpa@zytor.com> writes:

> Neither is bzImage... you can use bzImage format for other things.  

Agreed.  Though the bzImage format does have a smaller set of programs
it can handle than an ELF image, and is a little harder to setup.
In particular many simple stand alone programs are ELF bootable by
accident. 

> My main
> worry about this is that it locks you into booting a single image (as opposed to
> 
> kernel+initramfs, the latter of which can be composed on the fly if desirable),
> which is a huge step backwards IMNSHO.

Compose on the fly requires some amount of knowledge of what you are
booting.  You cannot edit an arbitrary image, and know it will work.
The ELF file format does still help in that case though as it exports
which addresses are already taken. 

Beyond that ELF has a .note section and more usefully a PT_NOTE
program header that points at the .note section.  Using ELF notes I
can export information like where initrd_start and initrd_size are in
the ELF image, so they can be modified.   

ELF notes are composed of 3 pieces. name (string), descriptor (string)
and type. name is a label defining who defined the note (we can use
Linux).  type is a 32 bit binary integer, so there is plenty of room
for everything we need. descriptor we can use for the contents.  

Through this we can also export things like the command line.  I have
prototyped this with my mkelfImage utility and it doesn't look to hard
to handle.  And I use a checksum it adds to verify the images integrity
in LinuxBIOS.

Beyond that I can still build a bootable bzImage with my patched
kernel.  setup_arch() looks, sees that we have already queried the
BIOS and skips that step.  And the code used to query the BIOS is
exactly the same in both cases there is just has a different delivery
mechanism.

Beyond that having the ability to do the composition before booting is
important for the network booting case.  Making network bootloaders
simpler.  For network booting having ramdisks tends actually to be
more important then in regular booting because you can't count on
anything else being there on the machine.  So I have no intention of
not supporting initramfs.

My kexec system call directly supports ELF images simply because it
makes debugging easier.  It means I don't have to compute everything
on the fly.  I can go back and look to see what I did wrong or I can
try the same image on a known good bootloader.  

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.

Eric

  reply	other threads:[~2002-01-31  4:31 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 [this message]
2002-01-31  4:41         ` H. Peter Anvin
2002-01-31  5:15           ` Eric W. Biederman
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=m1vgdjb0x0.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