[OE-core] [PATCH] busybox: Add a dependency on virtual/crypt

Andre McCurdy armccurdy at gmail.com
Mon Aug 20 21:28:24 UTC 2018


On Mon, Aug 20, 2018 at 2:03 PM, Peter Kjellerstedt
<peter.kjellerstedt at axis.com> wrote:
>> -----Original Message-----
>> From: Andre McCurdy <armccurdy at gmail.com>
>> Sent: den 20 augusti 2018 22:23
>> To: Khem Raj <raj.khem at gmail.com>
>> Cc: Richard Purdie <richard.purdie at linuxfoundation.org>; Peter
>> Kjellerstedt <peter.kjellerstedt at axis.com>; Patches and discussions
>> about the oe-core layer <openembedded-core at lists.openembedded.org>
>> Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on
>> virtual/crypt
>>
>> On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> > On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie
>> > <richard.purdie at linuxfoundation.org> wrote:
>> >>
>> >> On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
>> >> > busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
>> >> >
>> >> > Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
>> >> > ---
>> >> >  meta/recipes-core/busybox/busybox.inc | 3 ++-
>> >> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
>> >> > core/busybox/busybox.inc
>> >> > index 8c6dbbaf9b..a8ba10d21c 100644
>> >> > --- a/meta/recipes-core/busybox/busybox.inc
>> >> > +++ b/meta/recipes-core/busybox/busybox.inc
>> >> > @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
>> many
>> >> > common UNIX utilities into
>> >> >  HOMEPAGE = "http://www.busybox.net"
>> >> >  BUGTRACKER = "https://bugs.busybox.net/"
>> >> >
>> >> > -DEPENDS += "kern-tools-native"
>> >> > +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
>> defined
>> >> > +DEPENDS += "kern-tools-native virtual/crypt"
>> >>
>> >> I'm not a bug fan of adding dependencies which might not be needed.
>> How
>> >> common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
>> >> our default config?
>> >
>> > yes perhaps it should be packageconfig
>>
>> Busybox doesn't use PACKAGECONFIG. Conditional configuration is
>> handled by adding / removing cfg fragments and testing whether SRC_URI
>> contains "foo.cfg" (and also parsing the final .config within tasks
>> such as do_install). Unfortunately that approach doesn't work so well
>> for conditional build dependencies...
>>
>> Our Busybox defconfig does enable CONFIG_USE_BB_CRYPT (and there's no
>> cfg fragment to disable it) so the virtual/crypt dependency isn't
>> needed in our default builds.
>
> In our case we have our own defconfig. I am not responsible for it, it is
> maintained by our busybox maintainer, and he has apparently decided that
> we don't want CONFIG_USE_BB_CRYPT enabled.

Could you ask him about it? Maybe there's some advantage to it that isn't clear.

The general OE approach is to use system libraries when possible so
using external libcrypt does actually align to that.

Maybe we should use external libcrypt by default (with the option to
switch back to the built-in crypt functions via a cfg fragment)?

> I can of course add the dependency via a bbappend, but having to do that
> seems wrong given how the rest of busybox is configured (with defconfig
> and cfg fragments) and where enabling some options that don't happen to
> be enabled in the OE-Core default configuration will then break the build.
>
>> Disabling busybox's internal crypt functions doesn't seem like a very
>> common thing to want to do.
>>
>> config USE_BB_CRYPT
>>     bool "Use internal crypt functions"
>>     default y
>>     help
>>       Busybox has internal DES and MD5 crypt functions.
>>       They produce results which are identical to corresponding
>>       standard C library functions.
>>
>>       If you leave this disabled, busybox will use the system's
>>       crypt functions. Most C libraries use large (~70k)
>>       static buffers there, and also combine them with more general
>>       DES encryption/decryption.
>>
>>       For busybox, having large static buffers is undesirable,
>>       especially on NOMMU machines. Busybox also doesn't need
>>       DES encryption/decryption and can do with smaller code.
>>
>>       If you enable this option, it will add about 4.8k of code
>>       if you are building dynamically linked executable.
>>       In static build, it makes code _smaller_ by about 1.2k,
>>       and likely many kilobytes less of bss.
>
> //Peter
>



More information about the Openembedded-core mailing list