Patchwork Question about apply eglibc configurability to create minimal image

June 21, 2011, 7:35 a.m.

>> Hi Mark,
>>
>> According this list, expand with their run time depency(show in the attachment
>> minimal-image-runtime-dependies.png) , and the list is:
>>
>>      base-files \
>>      base-passwd \
>>      busybox \
>>      busybox-syslog \
>>      busybox-udhcpc \
>>      initscripts \
>>      makedevs \
>>      modutils-initscripts \
>>      sysvinit \
>>      sysvinit-pidof \
>>      sysvinit-inittab \
>>      tinylogin
>>
>>
>> When only enable eglibc libm, busybox, sysvinit and tinylogin can't be compiled.
>>
>> busybox depends on
>>
>>      * libc-crypt
>>      * libc-getlogin
>>      * libc-inet
>>      * libc-posix-regexp
>>
>> I wonder that maybe libc-crypt can NOT be disabled?  Other 3 options can be
>> disabled by closing some busybox feature and builtin commands.

Hi Mark,

> I would guess that there are options within busybox that are enabled that make
> use of each of these.  Do you get a failure in compilation, configuration, or?
> You will likely have to shrink busybox down to a shell and a few simple
> commands, instead of the normal config.

libm and libcrypt are added to LDLIBS unconditionally in Makefile.flags 
in busybox source code. I am trying to figure out why add them 
unconditionally. With these 2 options enabled and patch for busybox's 
defconf in attachment, I make the busybox compile succeed.

In the patch all the internet related features are disabled and some 
command such as awk, sed, grep(re support), mount( nfs feature), expr, 
logname, who, find, syslogd(remote log), rdate are removed or disabled .

>> sysvinit depends on
>>
>>      * libc-inet
>>      * libc-sunrpc
>>      * libc-crypt
>>
>> I don't how to resolve them, so as you said, remove it and use busybox init instead.
> Ya, busybox init should use fewer items.  If busybox init can't be used, then
> simply using the busybox shell as the init will likely work for a truly minimal
> system.

busybox init could be used, and mdev is also used to replace udev.

>> tinylogin depends on
>>
>>      * libc-crypt
>>      * libc-utmp
>>      * libc-getlogin
>>
>> I am trapped here, and could you give me some more help here, please?
> Ok, that makes sense.  Guess you need to remove tinylogin as well.  Since simply
> offering login services would require those three items.

tinylogin is removed.

>> The picture named eglibc-options-deps-for-minimal-image.png in attachment is the
>> packages depends on every eglibc option that required by other packages.
>>
>> There are some other dependencies cause problems.
>> linux-yocto requires elfutils python and perl.
> We need to figure out why linux-yocto requires these items.  (I suspect it's for
> perf or similar.  If thats the case, then this is likely a bug.  Perf should
> have to be built for each kernel, if the required capabilities don't exist.)

Yes, perf runtime depends on elfutils,  python and perl, and perf also 
need elfutils to provide libelf for its compilation.

I remove the perl and python in linux-tools.inc file, but keep the 
elfutils. After that remove elfutils' dependency gettext, and add
EXTRA_OEMAKE = "-C libelf"
to build libelf only(because other subdirectories requires libc-ftraverse).

>> elfutils requires gettext and gettext depends on:
>>
>>      * libc-locale-code
>>      * libc-spawn
>>      * libc-getlogin
> I think we have to assume that elfutils is not needed.  It's better to break
> that dependency instead of trying to fix it.
>
>> python requires ncurses and openssl.
>>
>>      * ncurses could be update bb file to choose support wchar or not.
>>      * openssl depends on:
>>            o libc-inet
>>            o libc-nsswitch
> I really wonder if there is something inside of openssl we can disable -- or if
> there is a switch to python that disables SSL support...  It might be worth
> investigating changing the python configuration.
>
>> perl depends on:
>>
>>      * libc-crypt
>>      * libc-fcvt
>>      * libc-inet
>>      * libc-utmp
> Similarly it might be worth investigating in perl if we can disable the users of
> these functions in a similar way.
>
>> How to remove these dependencies?  One way is to remove the "elfutils python
>> perl" from linux-yocto depencies, and the other is to disable related features
>> of these packages, and I wonder this is too hard to finish.
> I'd suggest, for now, simply to remove the elfutils, python and perl
> dependencies from the linux-yocto to continue.
>
> The goal of this exercise is simply to see how small of a eglibc system can be
> produced that will boot.  Then figure out how to scale up from there.  (I assume
> once we get beyond a few basic apps that we will need much of eglibc!)
>
> Based on your research above, I would suggest:
>
> * File a bug on the linux-yocto requiring elfutils, python and perl
>
> * Get rid of sysvinit and tinylogin.
>
> * Figure out if you can change the selections on busybox to still build
> something with a shell, but very little additional functionality with the
> minimal eglibc configuration.

With sysvinit and tinylogin removed and busybox configured by patch in 
the attachment, and keep 3 eglibc options (libc-libm libc-crypt 
libc-posix-regexp), the size of image rootfs after extraction is *2.9M* 
for ppc. busybox is 432K after extraction and maybe remove 
libc-posix-regexp will decrease the size of it. I'll try to do that.

libc-posix-regexp is required by perf.

> * Assuming that's possible... start adding in the additional functionality,
> crypt, inet, getlogin, utmp and get back to that standard busybox configuration
> and tinylogin.

After get "libc-sunrpc libc-utmp libc-inet libc-nsswitch libc-getlogin" 
back, after add tinylogin and standard busybox, I get the size after 
extraction is *3.5M*.

> This should give us a good size comparison between.  Non-internet connected,
> minimal system..  and something that could be connected to the internet.
>
> (Note, I don't think anyone will really build such a minimal system in the
> real-world.  However the size and configuration information could be useful for
> someone trying to squeeze this into a small system.  It might turn out that
> uClibc is still more practical for such systems.)

I wonder how can I record my current work that other people can take 
advantage of it? For now I modify task-core-boot directly, but it seems  
unacceptable because other image also include task-core-boot. Should I 
add a new task-core-boot-minimal only include

     base-files \
     base-passwd \
     busybox \
     initscripts \
     modutils-initscripts

and take the configure informations and the steps into a document file?

Because we will begin yocto pam works next week, I hope I can finish the job in this week.

Thanks for your great help!

Regards,
Kai

>
>
>
>
>>> First see if you can compile the above with a minimal eglibc configuration.  If
>>> not I can help you work through those issues..  If you can, you SHOULD see a
>>> fairly dramatic decrease in size.
>>>
>>> --Mark
>>>
>>>> Thanks a lot!
>>>>
>>>> I made a mistake that try eglibc configurability in a directory which
>>>> has build core-image-minimal, so the packages which depend on eglibc
>>>> didn't rebuild, and I didn't find the dependency before. I am sorry!
>>>>
>>>> Regards,
>>>> Kai

Submitter	Kang Kai
Date	June 21, 2011, 7:35 a.m.
Message ID	<4E0049AE.7050609@windriver.com>
Download	mbox \| patch
Permalink	/patch/6159/
State	New, archived
Headers	show Delivered-To: oepatches@gmail.com Received: from pop.gmail.com by melo.openembedded.org with POP3 (fetchmail-6.3.9-rc2) for <fetchmail@localhost> (single-drop); Tue, 21 Jun 2011 07:35:23 +0000 (UTC) Received: by 10.52.166.134 with SMTP id zg6cs45096vdb; Tue, 21 Jun 2011 00:34:57 -0700 (PDT) Received: by 10.14.10.165 with SMTP id 37mr2390925eev.1.1308641694082; Tue, 21 Jun 2011 00:34:54 -0700 (PDT) Return-Path: <openembedded-core-bounces@lists.openembedded.org> Received: from linuxtogo.org (linuxtogo.org [188.40.83.200]) by mx.google.com with ESMTPS id b2si14526226eeg.72.2011.06.21.00.34.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 00:34:53 -0700 (PDT) Received-SPF: neutral (google.com: 188.40.83.200 is neither permitted nor denied by best guess record for domain of openembedded-core-bounces@lists.openembedded.org) client-ip=188.40.83.200; Authentication-Results: mx.google.com; spf=neutral (google.com: 188.40.83.200 is neither permitted nor denied by best guess record for domain of openembedded-core-bounces@lists.openembedded.org) smtp.mail=openembedded-core-bounces@lists.openembedded.org Received: from localhost ([127.0.0.1]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from <openembedded-core-bounces@lists.openembedded.org>) id 1QYvXL-00009P-Px; Tue, 21 Jun 2011 09:38:15 +0200 Received: from mail.windriver.com ([147.11.1.11]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from <Kai.Kang@windriver.com>) id 1QYvXJ-00009I-6M for openembedded-core@lists.openembedded.org; Tue, 21 Jun 2011 09:38:13 +0200 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca [147.11.189.40]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id p5L7YcNt012848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jun 2011 00:34:38 -0700 (PDT) Received: from [128.224.162.154] (128.224.162.154) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.1.255.0; Tue, 21 Jun 2011 00:34:38 -0700 Message-ID: <4E0049AE.7050609@windriver.com> Date: Tue, 21 Jun 2011 15:35:10 +0800 From: Kang Kai <Kai.Kang@windriver.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Hatle <mark.hatle@windriver.com> References: <4DF0A70C.7080501@windriver.com> <4DF0E4A8.1000608@windriver.com> <4DFB26CE.7070807@windriver.com> <4DFB76E3.5090606@windriver.com> In-Reply-To: <4DFB76E3.5090606@windriver.com> Content-Type: multipart/mixed; boundary="------------020001090403000305020002" X-Originating-IP: [128.224.162.154] Cc: Robert, "poky@yoctoproject.org" <poky@yoctoproject.org>, Patches, about the oe-core layer <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core] Question about apply eglibc configurability to create minimal image X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org> List-Id: Patches and discussions about the oe-core layer <openembedded-core.lists.openembedded.org> List-Unsubscribe: <http://lists.linuxtogo.org/cgi-bin/mailman/options/openembedded-core>, <mailto:openembedded-core-request@lists.openembedded.org?subject=unsubscribe> List-Archive: <http://lists.linuxtogo.org/pipermail/openembedded-core> List-Post: <mailto:openembedded-core@lists.openembedded.org> List-Help: <mailto:openembedded-core-request@lists.openembedded.org?subject=help> List-Subscribe: <http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>, <mailto:openembedded-core-request@lists.openembedded.org?subject=subscribe> Sender: openembedded-core-bounces@lists.openembedded.org Errors-To: openembedded-core-bounces@lists.openembedded.org

Patchwork Question about apply eglibc configurability to create minimal image

Comments

Patch