All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Cc: linux-kernel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] x86 boot enhancements, Clean up the 32bit entry points 6/11
Date: 18 Apr 2002 12:11:55 -0600	[thread overview]
Message-ID: <m1hem86fmc.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20020418165939.22502.qmail@web11801.mail.yahoo.com>

Etienne Lorrain <etienne_lorrain@yahoo.fr> writes:

>  Seems that previous message did not go through, rewrite.
> 
>  I am sorry I did not check enough your patch.
>  You are speaking of: arch/i386/boot/compressed/head.S

That is what you quoted, so I assumed that is what you were
talking about.

>  I am speaking of:    arch/i386/kernel/head.S
> 
>  Gujin skip completely arch/i386/boot/compressed/* and really
>  boots the file '$$tmppiggy.gz' line 44 of file:
> arch/i386/boot/compressed/Makefile
> 
>  So you can do whatever you want with the "first" 32 bits entry point,
>  I am just concerned by the "second" kernel 32 bits entry point, in
>  arch/i386/kernel/head.S
> 
>  I still have a problem to detect the size of your decompressor, and that
>  is my use of the "lss" instruction.
>  This "lss SYMBOL_NAME(stack_start),%esp" gives an access to the symbol
>  'stack_start', so it is quite easy to find back the GZIP signature
>  of the initial '$$tmppiggy.gz' in what I call my "compatibility" mode,
>  i.e. booting the legacy vmlinuz files - and skipping all of the real mode
>  code and the decompressor code.

Well it should be easier I put an explicit pointer to it.

>  This "lss" line has not always been at the same offset, but is around
>  since maybe even the 0.01 kernel, it is quite easy to find it from its
>  hexadecimal form. (function vmlinuz_header_treat() in vmlinuz.c of
>  Gujin).
> 
>  The loaded high/loaded low stuff is just to know if I have to remove
>  0x100000 or 0x1000 from this symbol to have the number of bytes
>  to skip on the file.
>  By the way, the bit in the kernel header is set by the bootloader to say
>  where it has loaded the kernel, not by the compiler/linker chain.

Nope.  LOADED_HIGH in loadflags is set at compile time.  It determines
where the bootloader must load the compressed part of the kernel.

>  So is it possible to write somewhere how much code to skip or the offset
>  of the kernel GZIP signature?

Already done.

>  Something like:
>   jmp next
>   lss SYMBOL_NAME(stack_start),%esp
> next:
>  Would make me really happy, but is dirty.
>  Changing the 'tmppiggy.lnk' in the Makefile can be done, but the value
>  (to know the length of the decompressor code) has to be _before_ the code
>  itself in the raw file.

Yep.

>  Else whatever signature at whatever fixed address with the code+rodata
>  size following would make me happy.

Check out the code.

Eric

  reply	other threads:[~2002-04-18 18:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-18 16:59 [PATCH] x86 boot enhancements, Clean up the 32bit entry points 6/11 Etienne Lorrain
2002-04-18 18:11 ` Eric W. Biederman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-18  9:44 Etienne Lorrain
2002-04-18 12:27 ` Eric W. Biederman
2002-04-17 16:56 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=m1hem86fmc.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=etienne_lorrain@yahoo.fr \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.