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

--- "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.

> 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?
 I am not sure playing these games with addresses is cleaner than
not loading a section which is not in the program header.

> 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.



Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses

  reply	other threads:[~2007-02-12 10:42 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 [this message]
2007-02-12 12:29             ` Eric W. Biederman
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).