Zachary Amsden <zach at vmware.com> writes: > Jeremy Fitzhardinge wrote: >>> >>> Using an ELF field for the relocated kernel virtual base instead of (or, in >>> addition to) embedding it in the string table is the only thing I strongly >>> object to. >> >> Thinking about it, the best way to represent that stuff is probably in a >> PT_NOTE segment. That would give us flexibility without needing to pack >> everything into strings (while still allowing us to have strings where >> appropriate). Exactly. Plus all of the data is tagged so it is easy to see who the data is for. So you don't need a central standards body to define it. >> In general, I agree we should use standard ELF fields in standard ways if >> that's the right thing to do. Are you talking about using the phdr >> p_paddr/p_vaddr fields properly? > > Yes. Although Eric mentioned something about having the kernel relocation > available in the bzImage ELF header, and I think we need to make sure that the > use of the ELF fields is consistent between the two. It is my intention for the kernel to wind up as ET_DYN not ET_EXEC. So it's address can be shifted (to appropriately aligned addresses) at load time. No relocations will be available to the bootloader the kernel will handle all of that magic. The calling conventions will remain the current kernel calling conventions. I have not see anything that comes anywhere close to agreement on them. So sticking with the current defacto calling conventions of the entry point makes a lot of sense. For the moment. /sbin/kexec is the practical definition of how the ELF header fields get used. Eric
