Vivek Goyal wrote:
>
> One would not know highest used address until ELF headers have been
> parsed. May be it is two step movement. First decompress ELF.gz and
> ELF parser can be at the end of decompressed data. Then it can parse
> the ELF headers and move itself out of the ELF header destinat
On Wed, Jun 06, 2007 at 05:42:35PM -0700, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> >
> > Certainly, but much harder to implement. The ELF parser needs to be
> > prepared to move itself around to get out of the way of the ELF file.
> > It's a fairly large change from how it works now.
Rob Landley wrote:
>
> Er, make that objcopy, not objdump.
>
> Sane, maybe not. Something people want to do (and under the mistaken
> assumption I know more about initramfs then they do, have asked me how), yes.
>
> It always boils down to "do you have a vmlinux image lying around? Doing
>
On Wednesday 06 June 2007 9:54 pm, H. Peter Anvin wrote:
> Rob Landley wrote:
> > On Wednesday 06 June 2007 7:41 pm, H. Peter Anvin wrote:
> >> This makes vmlinux (normally stripped) recoverable from the bzImage file
> >> and so anything that is currently booting vmlinux would be serviced by
> >> t
Rob Landley wrote:
> On Wednesday 06 June 2007 7:41 pm, H. Peter Anvin wrote:
>> This makes vmlinux (normally stripped) recoverable from the bzImage file
>> and so anything that is currently booting vmlinux would be serviced by
>> this scheme.
>
> Would this make it sane to strip the initramfs ima
On Wednesday 06 June 2007 7:41 pm, H. Peter Anvin wrote:
> This makes vmlinux (normally stripped) recoverable from the bzImage file
> and so anything that is currently booting vmlinux would be serviced by
> this scheme.
Would this make it sane to strip the initramfs image out of vmlinux with
objd
H. Peter Anvin wrote:
> It doesn't if we simply declare that a certain chunk of memory is
> available to it, for the case where it runs in the native configuration.
> Since it doesn't have to support *any* ELF file, just the kernel one,
> that's an option.
>
I suppose. But given that its alway
Jeremy Fitzhardinge wrote:
>
> Certainly, but much harder to implement. The ELF parser needs to be
> prepared to move itself around to get out of the way of the ELF file.
> It's a fairly large change from how it works now.
>
It doesn't if we simply declare that a certain chunk of memory is
ava
H. Peter Anvin wrote:
> I was thinking prescriptive, having the decompressor read the output
> stream and interpret it as ELF. I guess a descriptive approach could be
> made to work, too (I haven't really thought about that avenue of
> approach), but the prescriptive model seems more powerful, at
Jeremy Fitzhardinge wrote:
>
> I'm not sure I fully understand the mechanism you're proposing. You
> have the 16-bit setup code, the 32-bit decompressor, and an ELF.gz. Once
> the decompressor has extracted the actual ELF file, are you proposing
> that it properly parse the ELF file and follow it
H. Peter Anvin wrote:
> I still believe that we should provide, in effect, vmlinux as a
> (compressed) ELF file rather than provide the intermediate stage. It
> would reduce the complexity of testing (all information provided about a
> stage have to be both guaranteed to even make sense in the fut
Jeremy Fitzhardinge wrote:
> This patch makes the payload of the bzImage file an ELF file. In
> other words, the bzImage is structured as follows:
> - boot sector
> - 16bit setup code
> - ELF header
> - decompressor
> - compressed kernel
>
> A bootloader may find the start of the ELF file
12 matches
Mail list logo
