[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: idea: library support for grub2
From: |
Bean |
Subject: |
Re: idea: library support for grub2 |
Date: |
Sat, 4 Jul 2009 15:04:33 +0800 |
On Sat, Jul 4, 2009 at 12:26 PM, Pavel Roskin<address@hidden> wrote:
> On Sat, 2009-07-04 at 09:48 +0800, Bean wrote:
>> Hi,
>>
>> Library is an archive file that contains unlinked object files. We can
>> use library function both statically or dynamically. In the former
>> case, we link the objects together to form an executable image, in the
>> later case, we load the object at runtime and resolve symbols, much
>> like the modules.
>>
>> With library, the size of kernel can be reduced dramatically. Now, the
>> kernel only contains platform specific function. To build a kernel
>> image, we link the kernel and other required module, then link any
>> unresolved function from the library, this way, only the function that
>> are actually used is in the kernel.
>
> What matters is the size of the linked and compressed kernel image
> (core.img) and not the bare kernel (kernel.img). Yes, we can have some
> savings, but I don't expect anything dramatic.
Hi,
The current size:
text data bss dec hex filename
4036 0 0 4036 fc4 kernel_img-kern_misc.o
3520 0 0 3520 dc0 kernel_img-kern_i386_pc_startup.o
3440 1504 0 4944 1350 kernel_img-symlist.o
3056 0 2064 5120 1400 kernel_img-kern_dl.o
2900 0 24544 27444 6b34 kernel_img-kern_disk.o
1384 64 40 1488 5d0 kernel_img-kern_fs.o
1204 4 64 1272 4f8 kernel_img-kern_env.o
1104 0 16 1120 460 kernel_img-kern_mm.o
1052 0 0 1052 41c kernel_img-kern_corecmd.o
964 320 0 1284 504 kernel_img-kern_parser.o
872 0 272 1144 478 kernel_img-kern_i386_pc_init.o
748 36 64 848 350 kernel_img-kern_term.o
572 0 16 588 24c kernel_img-kern_partition.o
556 0 0 556 22c kernel_img-kern_file.o
536 0 0 536 218 kernel_img-kern_device.o
524 0 0 524 20c kernel_img-kern_main.o
432 0 0 432 1b0 kernel_img-kern_i386_dl.o
384 0 0 384 180 kernel_img-kern_list.o
336 0 2640 2976 ba0 kernel_img-kern_err.o
288 4 0 292 124 kernel_img-term_i386_vga_common.o
276 20 256 552 228 kernel_img-kern_rescue_reader.o
264 20 0 284 11c kernel_img-kern_rescue_parser.o
208 0 32 240 f0 kernel_img-kern_i386_tsc.o
192 0 0 192 c0 kernel_img-kern_i386_pc_mmap.o
156 0 0 156 9c kernel_img-kern_handler.o
144 0 0 144 90 kernel_img-kern_command.o
96 16 0 112 70 kernel_img-kern_reader.o
92 96 0 188 bc kernel_img-term_i386_pc_console.o
56 0 0 56 38 kernel_img-kern_i386_pit.o
52 0 0 52 34 kernel_img-kern_generic_millisleep.o
32 0 0 32
20 kernel_img-kern_generic_rtc_get_time_ms.o
24 0 16 40 28 kernel_img-kern_time.o
The biggest part is kern/misc.c, all are library function, many
function in startup can also be moved to library. And with library,
symlist.c is not needed as well, which saves another 3k.
>
> We would only gain size reduction for the code that is in the kernel,
> but is not used by any module linked into the kernel image. I don't
> think there will be a lot of such code. Whatever modules we link, the
> image will need to output formatted strings, handle filesystems,
> partitions, disks.
>
>> As native library format of the building os could vary, we should use
>> a format that's specific to grub, perhaps something similar to cpio.
>
> The price will be a greatly increased complexity of the build system. I
> think it would be better to simplify it first.
Actually, I'm also thinking about unifying the object format. We can
write a program to convert from platform specific object file to an
unified elf format, this would simplify the build process for system
like osx, and the dynamic loader can be unified as well, which may
save some code.
--
Bean