Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: g@ad.chargestorm.se,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v2 0/1] busybox: update to 1.19.3
Date: Tue, 29 Nov 2011 00:13:59 -0800	[thread overview]
Message-ID: <4ED49447.9070805@linux.intel.com> (raw)
In-Reply-To: <20111129070444.GA3653@ad.chargestorm.se>

On 11/28/2011 11:04 PM, Anders Darander wrote:
> * Saul Wold<sgw@linux.intel.com>  [111129 06:47]:
>> On 11/23/2011 12:59 AM, Anders Darander wrote:
>>> * Saul Wold<sgw@linux.intel.com>   [111122 21:36]:
>>>> On 11/22/2011 06:34 AM, Anders Darander wrote:
>>>>> This updates busybox to the latest stable, 1.19.3.
>
>>>>> Among other things, there should be rudimentary support in syslogd for
>>>>> systemd, by enabling CONFIG_FEATURE_SYSTEMD.
>
>>>> How much size does this add to busybox by having it enabled by default?
>
>>> Enabling FEATURE_SYSTEMD in busybox costs 192 bytes in my tests in
>>> qemux86.
>
>>>> Is it possible to conditional add a config fragment if systemd is
>>>> enabled ad the DISTRO/IMAGE_FEATURE level?
>
>>>> More info is required.
>
> Any more comment on this one? Otavio replied earlier that if it was a
> small cost, he would prefer to have it on by default. Otherwise, any
> suggestions for DISTRO/IMAGE_FEATURE?
>
Sorry for not being clear on this on, yes to the SYSTEMD change, it's 
small enough and something we are considering. As Phil points out in the 
follow-up to this, most are using custom defconfig's that we should just 
go ahead and enable this for future flexibility.

>>>>> Changes:
>>>>> v2: * Checked the new defconfig (removed settings implying CFLAGS and
>>>>>        ARCH). The new defconfig should be as close as possible to the old one,
>>>>>        with the exception of some new utils/options.
>>>> Can you clearly enumerate what new utils and options and what their size
>>>> impact on the busybox image is.
>
> I'll remove all features that you didn't OK (see below), unless we get
> some more replies/wishes in the next day. (Thus I plan to send a v3 this
> week, if times allow it).
>
> Just to clarify it once more, the choice of which new features to enable
> was done by trying to judge if they were reasonable, or seemed
> helpfull/usefull enough. I'm not normally running with the defconfig
> (apart from testing this patch), I'm using a heavily customized and
> often minimized defconfig.
>
>>> Apart from the FEATURE_SYSTEMD discussed above, these are the other new
>>> options that I kept the new busybox default on (i.e. these are enabled,
>>> while I turned of quite a few other options that automatically got
>>> enabled). All costs are evaluted using qemux86, and the busybox binary
>>> size is checked in the packages-split/busybox/bin directory.
>
>>> I don't mind disabling any of these feature in a v3, if
>>> desired/requested. Anyway, I'm running a completely custom config for my
>>> normal uses...
>
>>> FEATURE_RTMINMAX, support RTMIN[+n] RTMAX[-n] signals, claimed to cost
>>> ~250 bytes
>
>> I can see these being useful
>
>>> FEATURE_REVERSE_SEARCH claimed to cost ~0.5k
>
>> Why is this needed?
>
> Not needed, just nice to have. But I'll remove it in v3.
>
>>> FEATURE_AR_CREATE, enable ar to create files, ~2.5k
>
>>> FEATURE_SEAMLESS_XZ enable xz compression in tar, no measured cost.
>
>>> XZ and UNXZ, enable xz compression, 8k
>
>> This is the one and the ar create above that sticks out, are these
>> needed in the general case or just vfor your config?
>
> Shouldn't be needed. I just left it enabled as all other
> FEATURE_SEAMLESS's was enabled. I'll disable these two in v3.
>
>>> FGCONSOLE, print active console number, 128 bytes
>
>>> FEATURE_LOADFONT_PSF2, FEATURE_LOADFONT_RAW, cost 576 bytes
>
>> Seems resonable, but why did we not need this before, what changed?
>
> Not really sure what the change is (normally I'm only working on
> headless systems, thus no need for fonts). The two FEATURE_LOADFONT_*
> options were not available in the old defconfig. I'll leave these two in
> v3, as you thought the seemd reasonable.
>
For minimal, it's good to assume headless, then we should not need the 
LOADFONT. I thought it was needed for headless as well.

>>> FEATURE_VI_ASK_TERMINAL, last resort to find terminal size, 352 bytes
>
>> Not sure about this and the FGCONSOLE above.
>
> Sure, I'll remove these two.
>
>>> BLOCKDEV, perform some ioctls with block devices, cost 480 bytes
>
>> Again is this useful in the general case?
>
> Same as previously, an arbitrary choice. I'll remove it in v3.
>
>
Thanks for your efforts.

Sau!

>



  parent reply	other threads:[~2011-11-29  8:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-22 14:34 [PATCH v2 0/1] busybox: update to 1.19.3 Anders Darander
2011-11-22 14:34 ` [PATCH v2 1/1] " Anders Darander
2011-11-22 20:36 ` [PATCH v2 0/1] " Saul Wold
2011-11-22 20:47   ` Anders Darander
2011-11-23  8:59   ` Anders Darander
2011-11-29  5:47     ` Saul Wold
2011-11-29  7:04       ` Anders Darander
2011-11-29  7:54         ` Phil Blundell
2011-11-29  8:13         ` Saul Wold [this message]
2011-11-29  8:29           ` Anders Darander
2011-11-23 10:38   ` Otavio Salvador
2011-11-23 10:42     ` Anders Darander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED49447.9070805@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=g@ad.chargestorm.se \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox