Andi Kleen <[email protected]> writes:
>> > Actually the best way to reuse would be to first do 64bit uncompressor
>> > and linker directly, but short of that #includes would be fine too.
>>
>> > Would be better to just pull in lib/string.c
>>
>> Maybe. Size is fairly important
>
> Why is size important here?
For the same reason that we compress the kernel. ;)
This is the one chunk of code that we don't compress so every extra
byte makes our executable bigger. Now I think the code size is
actually in the 32k - 64k range so as long as it is a minor change
it doesn't really matter.
The big pain with using lib/string.c and
arch/x86_64/kernel/early_printk.c is that it is significant change
in how the code of misc.c is constructed. Which means some
serious reevaluation of all kinds of things need to be considered.
Making it a lot of work :)
One of the practical dangers is that we make it more likely
we can kill the boot by messing up the shared code.
I'm not certain what to think when even including normal
kernel headers causes problems. It certainly makes me leery
of including normal kernel code. But it might simplify some
of the problems too.
Whichever way I go scrutinizing that possibility carefully is
a lot of work.
Eric
-
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]
