Re: [PATCH] i386: always clear bss

[ebiederm@xmission.com (Eric W. Biederman)]

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Eric W. Biederman wrote:
>> Using 0x40 as a stack would be ok.
>>   
>
> OK.
>
>> There are issues with CONFIG_RELOCATABLE and V!=P that I'm not
>> comfortable with yet, because we can't tell the difference.
>
> But it doesn't matter in this case, does it?  It just needs to find the
> current address, whether it be virtual or physical, of the bss.  It
> doesn't assume any particular offset.

For the bss that sounds correct.

> When does the relocation happen?   Does the bzImage loader do it as part
> of decompression?  Or does the kernel do it to itself?  (Not that it
> makes any difference here.)

Currently right after compression just before we jump to startup_32.
But if the usage of vmlinux continues to increase we should really
move it to just after startup_32.  Which is where we run into problems
with supporting virtual addresses at our normal kernel entry point.

The relocation doesn't live just after startup_32 now because it is
hard to put there.

The practical challenge is that we need to compute the delta between
where we are at and where we were compiled for, and with possibility of
virtual address and physical address I don't know how we would compute
where we are at, in a way we could compare to our compile time physical
or virtual addresses.

Xen when it comes it at a completely isolated entry point is fine
because there is no pretence of code reuse, and we don't have to auto-detect
how we were started.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/