H. Peter Anvin wrote:
Ingo Molnar wrote:
* Ian Campbell <[EMAIL PROTECTED]> wrote:
Hi Peter,
This patch switches the payload of a bzImage file to be in compressed
ELF format. There are several rough edges which need to be addressed
before it could go any further but I'd be interested to
Ingo Molnar wrote:
* Ian Campbell <[EMAIL PROTECTED]> wrote:
Hi Peter,
This patch switches the payload of a bzImage file to be in compressed
ELF format. There are several rough edges which need to be addressed
before it could go any further but I'd be interested to hear your
opinion of the
* Ian Campbell <[EMAIL PROTECTED]> wrote:
> Hi Peter,
>
> This patch switches the payload of a bzImage file to be in compressed
> ELF format. There are several rough edges which need to be addressed
> before it could go any further but I'd be interested to hear your
> opinion of the general
* Ian Campbell [EMAIL PROTECTED] wrote:
Hi Peter,
This patch switches the payload of a bzImage file to be in compressed
ELF format. There are several rough edges which need to be addressed
before it could go any further but I'd be interested to hear your
opinion of the general approach
H. Peter Anvin wrote:
Ingo Molnar wrote:
* Ian Campbell [EMAIL PROTECTED] wrote:
Hi Peter,
This patch switches the payload of a bzImage file to be in compressed
ELF format. There are several rough edges which need to be addressed
before it could go any further but I'd be interested to hear
Ingo Molnar wrote:
* Ian Campbell [EMAIL PROTECTED] wrote:
Hi Peter,
This patch switches the payload of a bzImage file to be in compressed
ELF format. There are several rough edges which need to be addressed
before it could go any further but I'd be interested to hear your
opinion of the
Ian Campbell wrote:
On Tue, 2008-01-29 at 13:50 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
I finessed the length issue slightly since it happens that the word
before the payload is the payload's length. I'm mulling a variety of
options:
* declare it compression scheme dependant. At
On Tue, 2008-01-29 at 13:50 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> >
> > I finessed the length issue slightly since it happens that the word
> > before the payload is the payload's length. I'm mulling a variety of
> > options:
> > * declare it compression scheme dependant. At
Ian Campbell wrote:
I finessed the length issue slightly since it happens that the word
before the payload is the payload's length. I'm mulling a variety of
options:
* declare it compression scheme dependant. At least for gzip it
knows when it has reached the end.
* codify
On Tue, 2008-01-29 at 10:34 -0800, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> > H. Peter Anvin wrote:
> >> It's also easy enough to either use objdump -h or nm to extract info
> >> from vmlinux; or for some of the simpler stuff, just parse the ELF
> >> directly (perhaps using libelf).
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
It's also easy enough to either use objdump -h or nm to extract info
from vmlinux; or for some of the simpler stuff, just parse the ELF
directly (perhaps using libelf).
There is also the -R option to ld, which imports symbols from one
H. Peter Anvin wrote:
It's also easy enough to either use objdump -h or nm to extract info
from vmlinux; or for some of the simpler stuff, just parse the ELF
directly (perhaps using libelf).
There is also the -R option to ld, which imports symbols from one
executable into another.
Yes, I
Jeremy Fitzhardinge wrote:
I solved that with some linker magic. One of the things I did was get
rid of tools/build and did everything in the linker. And I worked out a
trick where you can get the setup code to refer to vmlinux's symbols
without actually linking it in (no, wait, was that to
Ian Campbell wrote:
If you strip of setup_sects (+1?) from a bzImage, which I think is what
you are referring above, then you end up with essentially
arch/x86/boot/compressed/vmlinux (at address 0x10 from one of the
bzImage header fields) which can still be jumped to by a 32 bit
bootloader.
On Mon, 2008-01-28 at 14:54 -0800, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > I'm mainly interested in something along these lines to allow the Xen
> > bootloader to load a bzImage so that distros don't have to maintain two
> > kernel packages with the same basic bits in different file
On Mon, 2008-01-28 at 15:20 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> >
> > What would be the preferred way of allowing bootloaders/domain builders
> > to find the compressed payload? Tacking the offset from the end onto the
> > end as I have done for the moment seems pretty skanky...
Ian Campbell wrote:
If you strip of setup_sects (+1?) from a bzImage, which I think is what
you are referring above, then you end up with essentially
arch/x86/boot/compressed/vmlinux (at address 0x10 from one of the
bzImage header fields) which can still be jumped to by a 32 bit
bootloader.
Jeremy Fitzhardinge wrote:
I solved that with some linker magic. One of the things I did was get
rid of tools/build and did everything in the linker. And I worked out a
trick where you can get the setup code to refer to vmlinux's symbols
without actually linking it in (no, wait, was that to
On Tue, 2008-01-29 at 13:50 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
I finessed the length issue slightly since it happens that the word
before the payload is the payload's length. I'm mulling a variety of
options:
* declare it compression scheme dependant. At least for
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
It's also easy enough to either use objdump -h or nm to extract info
from vmlinux; or for some of the simpler stuff, just parse the ELF
directly (perhaps using libelf).
There is also the -R option to ld, which imports symbols from one
H. Peter Anvin wrote:
It's also easy enough to either use objdump -h or nm to extract info
from vmlinux; or for some of the simpler stuff, just parse the ELF
directly (perhaps using libelf).
There is also the -R option to ld, which imports symbols from one
executable into another.
Yes, I
Ian Campbell wrote:
On Tue, 2008-01-29 at 13:50 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
I finessed the length issue slightly since it happens that the word
before the payload is the payload's length. I'm mulling a variety of
options:
* declare it compression scheme dependant. At
Ian Campbell wrote:
What would be the preferred way of allowing bootloaders/domain builders
to find the compressed payload? Tacking the offset from the end onto the
end as I have done for the moment seems pretty skanky...
As Jeremy already mentioned, putting a pointer to the compressed ELF
Ian Campbell wrote:
I'm mainly interested in something along these lines to allow the Xen
bootloader to load a bzImage so that distros don't have to maintain two
kernel packages with the same basic bits in different file formats, I
think it would probably be of use to the kexec and/or lguest
Hi Peter,
This patch switches the payload of a bzImage file to be in compressed
ELF format. There are several rough edges which need to be addressed
before it could go any further but I'd be interested to hear your
opinion of the general approach before I spend time cleaning it up.
I'm mainly
Ian Campbell wrote:
What would be the preferred way of allowing bootloaders/domain builders
to find the compressed payload? Tacking the offset from the end onto the
end as I have done for the moment seems pretty skanky...
As Jeremy already mentioned, putting a pointer to the compressed ELF
Ian Campbell wrote:
I'm mainly interested in something along these lines to allow the Xen
bootloader to load a bzImage so that distros don't have to maintain two
kernel packages with the same basic bits in different file formats, I
think it would probably be of use to the kexec and/or lguest
Hi Peter,
This patch switches the payload of a bzImage file to be in compressed
ELF format. There are several rough edges which need to be addressed
before it could go any further but I'd be interested to hear your
opinion of the general approach before I spend time cleaning it up.
I'm mainly
28 matches
Mail list logo
