On Wed, Oct 04, 2006 at 01:27:49PM -0700, H. Peter Anvin wrote:
> Vivek Goyal wrote:
> >
> >Eric/Peter,
> >
> >How about just extending bzImage format to include some info in real mode
> >kernel header. Say protocol version 2.05. I think if we just include two
> >more fields, is kernel relocatable and equivalent of ELF memsz, then
> >probably
> >this information should be enough for kexec bzImage loader to load and run
> >a relocatable kernel from a different address.
> >
>
> What would be the exact semantics of the "equivalent of ELF memsz"? I
> have balked on that one in the past, because the proposed semantics were
> unsafe.
>
memsz will contain the memory required to load the kernel image. And
probably should also include the memory used by kernel in initial boot
up code which is unaccounted and unbounded.
> I suspect we need at least one more piece of data, which is the required
> alignment of a relocated kernel.
Now with the introduction of config option CONFIG_PHYSICAL_ALIGN, it
should be easy to get.
> Either which way, it seems clear that
> there is some re-engineering that needs to be done, and I think we need
> to better understand *why* the proposed patch failed.
>
> Can this failure be reproduced in a simulator?
I will try to reproduce in a simulator. May be qemu? Any suggestions?
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
