Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

[Eric W. Biederman]

Jan Kratochvil <lace@xxxxxxxxxxxxxxxxx> writes:

> So you rather crash than running in that unmeasurably lower performance?

No simply I would rather not boot than run something I'm not certain will
work.  If we align things deliberately for better performance I don't
want to cope with that either.

> ...
>> I'm not terribly comfortable with the 8K alignment number as we only
>> tell the linker we need 4K alignment.
>
> Yes, it should be fixed there so that the stacks get allocated 8KB-aligned not
> depending on the kernel code position at all.  That means allocating the
> initial stack by code and not relying on its autoallocation by the linker.
> There would remain the 4KB alignment requirement due to the physical target
> address of the pagetable entries.

So thinking about this.  By processing relocations we end up with
no page table related relocation restrictions except that we must be
within the identity mapped page table area.  Not even the 4KB is
directly a page table related alignment restriction.

So the right answer is to review the arch/i386 kernel and make certain
we don't have any implicit alignment requirements, (and if we do
making them explicit so the linker will honor and report them).  At
which point all I need to do is to copy the required alignment from
vmlinux to the ELF header of the bzImage.

>> > ( I did not check your patches as they are locked in that useless GIT
> anyway. )

For code review sending patches is still the best way to do it.
Patches in email are easier to comment on, and require less work
for people to actually look at.  So since you have complained
I have sent out all of the patches.

My evil plan is to keep making interesting things available in GIT
until it is no longer considered useless :)

Eric

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