All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.