>>> And with library,
>>> symlist.c is not needed as well, which saves another 3k.
>>
>> Perhaps I misunderstand something in your proposal. I don't see how
>> introducing a library would eliminate symlist.c.
>>
>> We'll need a list of symbols for modules to use, whether those symbols are
>> in th
On Sat, Jul 4, 2009 at 10:27 PM, Pavel Roskin wrote:
> Quoting Bean :
>
>> The biggest part is kern/misc.c, all are library function, many
>> function in startup can also be moved to library.
>
> It doesn't matter by itself. If the modules linked into the the kernel
> image use most functions in t
Quoting Bean :
The biggest part is kern/misc.c, all are library function, many
function in startup can also be moved to library.
It doesn't matter by itself. If the modules linked into the the
kernel image use most functions in that library, there will be little
of no saving.
And with
On Sat, Jul 4, 2009 at 12:26 PM, Pavel Roskin 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 fo
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 ob
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.
