LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Etienne Lorrain <>
Cc:, "H. Peter Anvin" <>,
Subject: Re: Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
Date: Mon, 12 Feb 2007 05:29:31 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Etienne Lorrain's message of "Mon, 12 Feb 2007 11:42:21 +0100 (CET)")

Etienne Lorrain <> writes:

> --- "Eric W. Biederman" wrote:
>> So I really don't care if we move whole real mode section into a note
>> or if we just put a pointer to it into a note.  What is important is
>> that we use a note to find it.
>  Well, we can advertise by a note the section number or the section
> name which contains the real-mode code, but finding the section of
> type SHT_PROGBITS having SHF_EXECINSTR flags linked at zero is not
> that difficult to do: it is what Gujin does right now when it does
> not find the program header linked at zero.

What I was thinking is that in the not we place the physical address
and length that we load the real mode code at.  My assumption being
that we have marked the real mode code __init or the equivalent,
so we always load and just ignore it later on.

>> Which means that we could do something goofy in the linker script
>> like we do with the current vdso.  So we could give it a virtual
>> address of 0 and a physical address in the init code section.
>  Gujin loads at the physical address, i.e. kernel is loaded at
> 0x100000 and not 0xC0100000, is that wrong?

No.  For practical purposes we can say virtual addresses are for
the code and the kernel.  Physical addresses are for the loader.

>  I am not sure playing these games with addresses is cleaner than
> not loading a section which is not in the program header.

It is some cleaner.  I won't call it perfectly clean, but it is
better.  It keeps everything but argument generation generic,
and there is already precedent in things like the vdso.

Playing the games with the addresses does allow the existing debugging
tools to work without problem because the end users of the code all
examine the virtual not the physical address.

>> For me the objective is not so much reusing the existing tools
>> (although that is a plus) but more to be able to build a unified
>> binary that can be used for everything, and will give us the freedom
>> to do interesting things with the kernel in the future, and hopefully
>> something that is more or less usable by portable bootloaders.  Having
>> a different file format and different rules for different
>> architectures is a pain.
>  For me the objective is to have a reasonable bootloader,
> I will not have the time to port back and test with every other
> bootloader some transfert of code from Gujin to an ELF looking
> like bzImage file.

I agree I want a reasonable bootloader as well.

With ELF we get a single file format that works on multiple
architectures and for multiple OS-s, with well understood rules.  This
allows for a broader audience who can review and maintain the code.
In addition to the real possibility of multi-architecture or multi-os

What ELF cannot standardize is the how we pass the initial arguments.
ELF does standardize the initial parameters for unix executables but
the requirements of arguments to kernels, and the years of practice
are quite different.

ELF should make it much easier for people implementing simple
stand-alone executables for testing.  As you don't even need a linker
script or any fancy games if you don't take arguments.   Similarly
the switch from linux to multi-boot that almost standard is just
supporting a different argument passing format.


  reply	other threads:[~2007-02-12 12:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08 13:10 Etienne Lorrain
2007-02-09  5:59 ` Vivek Goyal
2007-02-09 13:04   ` Etienne Lorrain
2007-02-09 19:42     ` Eric W. Biederman
2007-02-11 13:23       ` RE : " Etienne Lorrain
2007-02-11 20:49         ` Eric W. Biederman
2007-02-12 10:42           ` Etienne Lorrain
2007-02-12 12:29             ` Eric W. Biederman [this message]
2007-02-12 13:58               ` Etienne Lorrain
2007-02-12 14:06               ` H. Peter Anvin
2007-02-12 19:47                 ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2007-02-08  9:48 Etienne Lorrain
2007-02-08 11:20 ` Eric W. Biederman
2007-02-08 11:37 ` Vivek Goyal
2007-02-08 12:10   ` Eric W. Biederman
2007-02-07 14:29 Etienne Lorrain
2007-02-07 17:12 ` H. Peter Anvin
2007-02-06 17:23 Etienne Lorrain
2007-02-06 17:34 ` H. Peter Anvin
2007-02-06 18:12 ` Eric W. Biederman
2007-02-06 13:23 Etienne Lorrain
2007-02-06 13:12 Etienne Lorrain
2007-02-07  6:44 ` Vivek Goyal
2007-02-06 12:49 Etienne Lorrain

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).