From: Werner Almesberger <wa@almesberger.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"Erik A. Hendriks" <hendriks@lanl.gov>,
Andrew Morton <akpm@zip.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] x86 ELF bootable kernels/Linux booting Linux/LinuxBIOS
Date: Mon, 4 Feb 2002 22:02:35 +0100 [thread overview]
Message-ID: <20020204220234.B5079@almesberger.net> (raw)
In-Reply-To: <3C58CAE0.4040102@zytor.com> <20020131103516.I26855@lanl.gov> <m1elk6t7no.fsf@frodo.biederman.org> <3C59DB56.2070004@zytor.com> <m1r8o5a80f.fsf@frodo.biederman.org> <3C5A5F25.3090101@zytor.com> <m1hep19pje.fsf@frodo.biederman.org> <3C5ADDD1.6000608@zytor.com> <20020204134927.A5079@almesberger.net> <m1sn8h6ngb.fsf@frodo.biederman.org>
In-Reply-To: <m1sn8h6ngb.fsf@frodo.biederman.org>; from ebiederm@xmission.com on Mon, Feb 04, 2002 at 12:45:08PM -0700
Eric W. Biederman wrote:
> I have come to agree with this sentiment.
Great !
> However I do have a small issue with the current bootimg api.
> Everything is done in page sized chunks. Which feels like it is
> exporting too much of the current implementation.
Well, it keeps things simple for the kernel, and bootimg(8) needs
to know the target architecture anyway. But there isn't really a
design reason why it would have to use pages, agreed.
> Except for the case of Loadlin where the old firmware is destroyed,
> and you cannot requery the firmware. You have a more robust solution
> if you let the new kernel query the firmware itself.
Yes, I was thinking of
- BIOS does IDE bus scan, boots boot loader kernel
- first kernel does IDE bus scan again, boots real kernel
- real kernel does IDE bus scan again
It should be possible to avoid at least the third IDE bus scan, at
least as an optimization.
> For the most part I agree, that the bootimg type interface will avoid
> bloat. At the same time, some of this information that we would like
> to pass is easier to get at in kernel space, oh well.
You can always look it up in /dev/mem, just like bootimg(1) did :-)
BTW, that's what I like about this approach: incremental development
is much easier this way, and you can hide all the ugly spots in the
library, if necessary.
> I will stop just a moment to say it is extremely nasty to read the ELF
> section header instead of the ELF program header for boot purposes.
> For an ELF static executable it is totally valid not to have a section
> header.
Touche ;-) I admit that I'm not much of an ELF expert. This was just
a surprisingly easy hack, so I was content with what I got.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Lausanne, CH wa@almesberger.net /
/_http://icawww.epfl.ch/almesberger/_____________________________________/
next prev parent reply other threads:[~2002-02-04 21:04 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
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 [this message]
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=20020204220234.B5079@almesberger.net \
--to=wa@almesberger.net \
--cc=akpm@zip.com.au \
--cc=ebiederm@xmission.com \
--cc=hendriks@lanl.gov \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.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