From: "Etienne Lorrain" <etienne_lorrain@yahoo.fr>
To: linux-kernel@vger.kernel.org
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] x86 boot enhancements, Clean up the 32bit entry points 6/11
Date: Thu, 18 Apr 2002 18:59:39 +0200 (CEST) [thread overview]
Message-ID: <20020418165939.22502.qmail@web11801.mail.yahoo.com> (raw)
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
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.
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.
So is it possible to write somewhere how much code to skip or the offset
of the kernel GZIP signature?
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.
Else whatever signature at whatever fixed address with the code+rodata
size following would make me happy.
Sorry again for the confusion,
Etienne.
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
next reply other threads:[~2002-04-18 16:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 16:59 Etienne Lorrain [this message]
2002-04-18 18:11 ` Eric W. Biederman
-- 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=20020418165939.22502.qmail@web11801.mail.yahoo.com \
--to=etienne_lorrain@yahoo.fr \
--cc=ebiederm@xmission.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
all inboxes | Powered by JetHome®