From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MMwpw-0007bV-W0 for mharc-grub-devel@gnu.org; Sat, 04 Jul 2009 00:26:53 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMwpv-0007ar-Fb for grub-devel@gnu.org; Sat, 04 Jul 2009 00:26:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMwpr-0007ZU-Ss for grub-devel@gnu.org; Sat, 04 Jul 2009 00:26:51 -0400 Received: from [199.232.76.173] (port=38252 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMwpr-0007ZP-PV for grub-devel@gnu.org; Sat, 04 Jul 2009 00:26:47 -0400 Received: from c60.cesmail.net ([216.154.195.49]:46529) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1MMwpr-0008Dl-C8 for grub-devel@gnu.org; Sat, 04 Jul 2009 00:26:47 -0400 Received: from unknown (HELO smtprelay2.cesmail.net) ([192.168.1.112]) by c60.cesmail.net with ESMTP; 04 Jul 2009 00:26:45 -0400 Received: from [192.168.0.22] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by smtprelay2.cesmail.net (Postfix) with ESMTPSA id D389B34C6A for ; Sat, 4 Jul 2009 00:34:34 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: Content-Type: text/plain Date: Sat, 04 Jul 2009 00:26:43 -0400 Message-Id: <1246681603.2544.15.camel@mj> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: idea: library support for grub2 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 04:26:52 -0000 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. 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. -- Regards, Pavel Roskin