LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Etienne Lorrain <>
Cc: "H. Peter Anvin" <>,,
Subject: Re: Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
Date: Tue, 06 Feb 2007 11:57:01 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Etienne Lorrain's message of "Tue, 6 Feb 2007 18:39:11 +0000 (GMT)")

Etienne Lorrain <> writes:

> Eric W. Biederman wrote:
>> Etienne Lorrain <> writes:
>> >  New features are more that this real-mode function can return an error
>> >  to the bootloader to tell something to the user, so the user can select
>> >  another kernel with the right processor, another video mode... with
>> >  clean error messages - not a crash dump because this assembly
>> >  instruction is not for that processor.
>> Having an error handling compatibility that is backwards compatible sounds
>> interesting.
>  Well, if the function called at offset 0 in the real-mode section return
>  non zero, that is probably an error - that is Gujin interface, but do not ask
>  me to change other bootloaders to handle that.
>  This function is called with few parameters, one is a string pointer
>  if the function do not want to print the problem report itself.
>  The function is called with an offset of zero in its own intel
>  segment.

So I think there are some backwards compatibility issues with your
real mode code interface.  Setting a new flag that says to return instead
of printing an error message and halting would be one way to handle

Is your real mode C code section relative such that it can be loaded
at different addresses and still work?

>> >   I am still saying that the bootloader knows the root filesystem to
>> >  be used by the kernel it loads, and that ELF is a clean format to
>> >  store different sections to be loaded into memory at predefined
>> >  addresses.
>> Yes.  Although when you think sections instead of segments I'm a little
>> worried.
>   Well, for my defense, if Gujin do not find the real mode code in the program
>  header it search for it in the section table, if the program header cannot be
>  modified for some reason. There may be some issues if that ELF file is
>  "stripped" but it seems to work on my side.

The program header is for executable loaders the section header is for
linkers and the section header is optional in PT_LOAD and PT_DYN
executables.  Use of the section header by a loader is a bug.

>> >  Also there isn't any more kernel size limit.
>> I think as HPA points out we have gotten past that a long time
>> ago with the bzImage format.
>   There was still a test not that long ago (in the code I am not executing) -
> but
>  I was wrong to bring this point forward.

There have been limitations but mostly with respect to page table size
and the like but they were not limitations a bootloader had to deal with.

>> With the right delicacy, and preserving backwards compatibility
>> with existing bootloaders I think we can achieve things.
>   Well, you can generate with the proposed patch and boot with SYSLINUX,
>  Grub and LILO, but trying to clean Linux real-mode code is where I begun.

I haven't looked yet.  But I believe this is something that we can do,
so long as cleaning and feature enhancement are not mixed in a bad way.

>> The big issue is that sometimes bootloaders are a little bit brittle.
>> Eric
>   I like to think mine is more stable - maybe I am a dreamer...
>   I do not compete on network booting neither.

Phrasing this another way.  What we can do with the interface is
determined our interface to existing bootloaders and what bootloaders
exist.  Basically it is the rule that we need to preserve backwards
compatibility and changes generally need to be evolutionary ones.


  reply	other threads:[~2007-02-06 18:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-06 18:39 Etienne Lorrain
2007-02-06 18:57 ` Eric W. Biederman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-07 14:55 Etienne Lorrain
2007-02-08  4:45 ` Vivek Goyal
2007-02-06 17:59 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 : 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).