busybox: Add a dependency on virtual/crypt

PATCH In review Peter Kjellerstedt 6 participants 8 messages Aug 20, 2018 – Aug 28, 2018

lore

Share & tools

lore

Peter Kjellerstedt

author

2018-08-20 02:46 UTC #0 lore raw

PATCH 1/1 busybox: Add a dependency on virtual/crypt

busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.

Signed-off-by Peter Kjellerstedt <[email protected]>

---
 meta/recipes-core/busybox/busybox.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

meta/recipes-core/busybox/busybox.inc +2 -1

index 8c6dbbaf9b..a8ba10d21c 100644
@@ -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"
 
 # bzip2 applet in busybox is based on lightly-modified bzip2 source
 # the GPL is version 2 only

Signature · 1 line

2.12.0

Richard Purdie

2018-08-20 09:45 UTC #1 lore raw

Quoted 17 lines · Peter Kjellerstedt

busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by Peter Kjellerstedt <[email protected]>
---
 meta/recipes-core/busybox/busybox.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes- renamed from meta/recipes-core/busybox/busybox.inc +0 -0
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
meta/recipes-core/busybox/busybox.inc +0 -0
@@ -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/"

meta/recipes-core/busybox/busybox.inc DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into · line 7

Quoted 3 lines

meta/recipes-core/busybox/busybox.inc +2 -1

-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?

Cheers,

Richard

Khem Raj

2018-08-20 19:45 UTC #2 lore raw

Quoted 19 lines · Richard Purdie

Quoted 17 lines · Peter Kjellerstedt
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by Peter Kjellerstedt <[email protected]>
---
 meta/recipes-core/busybox/busybox.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes- renamed from meta/recipes-core/busybox/busybox.inc +0 -0
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
meta/recipes-core/busybox/busybox.inc +0 -0
@@ -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/"

Quoted 7 lines

meta/recipes-core/busybox/busybox.inc DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into · line 7
Quoted 3 lines
meta/recipes-core/busybox/busybox.inc +2 -1
-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

Quoted 9 lines

Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Andre McCurdy

2018-08-20 20:22 UTC #3 lore raw

Quoted 29 lines · Khem Raj

Quoted 19 lines · Richard Purdie
Quoted 17 lines · Peter Kjellerstedt
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by Peter Kjellerstedt <[email protected]>
---
 meta/recipes-core/busybox/busybox.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes- renamed from meta/recipes-core/busybox/busybox.inc +0 -0
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
meta/recipes-core/busybox/busybox.inc +0 -0
@@ -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/"
Quoted 7 lines
meta/recipes-core/busybox/busybox.inc DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into · line 7
Quoted 3 lines
meta/recipes-core/busybox/busybox.inc +2 -1
-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?

Quoted 1 line

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.

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 Kjellerstedt

author

2018-08-20 21:03 UTC #4 lore raw

Quoted 51 lines

-----Original Message-----
From: Andre McCurdy <[email protected]>
Sent: den 20 augusti 2018 22:23
To: Khem Raj <[email protected]>
Cc: Richard Purdie <[email protected]>; Peter Kjellerstedt <[email protected]>; Patches and discussions about the oe-core layer <[email protected]>
Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt
Quoted 11 lines · Khem Raj
Quoted 9 lines · Richard Purdie
Quoted 7 lines · Peter Kjellerstedt
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by Peter Kjellerstedt <[email protected]>
---
 meta/recipes-core/busybox/busybox.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc DESCRIPTION = "BusyBox combines tiny versions of
Quoted 6 lines
meta/recipes- renamed from meta/recipes-core/busybox/busybox.inc +0 -0
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
meta/recipes-core/busybox/busybox.inc +0 -0
@@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
many
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc
Quoted 6 lines
common UNIX utilities into
HOMEPAGE = "http://www.busybox.net"
BUGTRACKER = "https://bugs.busybox.net/"
meta/recipes-core/busybox/busybox.inc +1 -1
-DEPENDS += "kern-tools-native"
+# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
defined
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
+DEPENDS += "kern-tools-native virtual/crypt"
I'm not a bug fan of adding dependencies which might not be needed.
How
Quoted 4 lines
Quoted 2 lines
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...

Quoted 3 lines

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.

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.

Quoted 16 lines

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.

Quoted 8 lines

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

Andre McCurdy

2018-08-20 21:28 UTC #5 lore raw

Quoted 51 lines · Peter Kjellerstedt

Quoted 51 lines
-----Original Message-----
From: Andre McCurdy <[email protected]>
Sent: den 20 augusti 2018 22:23
To: Khem Raj <[email protected]>
Cc: Richard Purdie <[email protected]>; Peter Kjellerstedt <[email protected]>; Patches and discussions about the oe-core layer <[email protected]>
Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt
Quoted 11 lines · Khem Raj
Quoted 9 lines · Richard Purdie
Quoted 7 lines · Peter Kjellerstedt
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by Peter Kjellerstedt <[email protected]>
---
 meta/recipes-core/busybox/busybox.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc DESCRIPTION = "BusyBox combines tiny versions of
Quoted 6 lines
meta/recipes- renamed from meta/recipes-core/busybox/busybox.inc +0 -0
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
meta/recipes-core/busybox/busybox.inc +0 -0
@@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
many
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc
Quoted 6 lines
common UNIX utilities into
HOMEPAGE = "http://www.busybox.net"
BUGTRACKER = "https://bugs.busybox.net/"
meta/recipes-core/busybox/busybox.inc +1 -1
-DEPENDS += "kern-tools-native"
+# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
defined
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
+DEPENDS += "kern-tools-native virtual/crypt"
I'm not a bug fan of adding dependencies which might not be needed.
How
Quoted 4 lines
Quoted 2 lines
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...

Quoted 7 lines

Quoted 3 lines
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)?

Quoted 32 lines

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.
Quoted 16 lines
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.
Quoted 8 lines
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

Andrej Valek

2018-08-27 06:42 UTC #6 lore raw

Did you find some final solution?
For me, we can make it enabled by default. Anyone could use custom defconfig in own layer.

Cheers,
Andrej

Quoted 101 lines · Andre McCurdy

Quoted 51 lines · Peter Kjellerstedt
Quoted 51 lines
-----Original Message-----
From: Andre McCurdy <[email protected]>
Sent: den 20 augusti 2018 22:23
To: Khem Raj <[email protected]>
Cc: Richard Purdie <[email protected]>; Peter Kjellerstedt <[email protected]>; Patches and discussions about the oe-core layer <[email protected]>
Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt
Quoted 11 lines · Khem Raj
Quoted 9 lines · Richard Purdie
Quoted 7 lines · Peter Kjellerstedt
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by Peter Kjellerstedt <[email protected]>
---
 meta/recipes-core/busybox/busybox.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc DESCRIPTION = "BusyBox combines tiny versions of
Quoted 6 lines
meta/recipes- renamed from meta/recipes-core/busybox/busybox.inc +0 -0
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
meta/recipes-core/busybox/busybox.inc +0 -0
@@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
many
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc
Quoted 6 lines
common UNIX utilities into
HOMEPAGE = "http://www.busybox.net"
BUGTRACKER = "https://bugs.busybox.net/"
meta/recipes-core/busybox/busybox.inc +1 -1
-DEPENDS += "kern-tools-native"
+# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
defined
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
+DEPENDS += "kern-tools-native virtual/crypt"
I'm not a bug fan of adding dependencies which might not be needed.
How
Quoted 4 lines
Quoted 2 lines
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...
Quoted 7 lines
Quoted 3 lines
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)?
Quoted 32 lines
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.
Quoted 16 lines
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.
Quoted 8 lines
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

Randy MacLeod

2018-08-28 20:13 UTC #7 lore raw

Quoted 1 line · Andrej Valek

Did you find some final solution?

Since no one has replied, it seems that the answer is to omit the virtual/crypt dependency.

Quoted 2 lines

For me, we can make it enabled by default. Anyone could use custom defconfig in own layer.

Right.

I would be nice get the package update done since 1.27.x is about a year old and M3 is yesterday/this week.
We can settle this potential dependency as a defect if someone finds such a bug.

../Randy

Quoted 106 lines

Cheers,
Andrej
Quoted 101 lines · Andre McCurdy
Quoted 51 lines · Peter Kjellerstedt
Quoted 51 lines
-----Original Message-----
From: Andre McCurdy <[email protected]>
Sent: den 20 augusti 2018 22:23
To: Khem Raj <[email protected]>
Cc: Richard Purdie <[email protected]>; Peter Kjellerstedt <[email protected]>; Patches and discussions about the oe-core layer <[email protected]>
Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt
Quoted 11 lines · Khem Raj
Quoted 9 lines · Richard Purdie
Quoted 7 lines · Peter Kjellerstedt
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by Peter Kjellerstedt <[email protected]>
---
  meta/recipes-core/busybox/busybox.inc | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc DESCRIPTION = "BusyBox combines tiny versions of
Quoted 6 lines
meta/recipes- renamed from meta/recipes-core/busybox/busybox.inc +0 -0
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
meta/recipes-core/busybox/busybox.inc +0 -0
@@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
many
Quoted 6 lines
Quoted 6 lines
meta/recipes-core/busybox/busybox.inc
Quoted 6 lines
common UNIX utilities into
HOMEPAGE = "http://www.busybox.net"
BUGTRACKER = "https://bugs.busybox.net/"
meta/recipes-core/busybox/busybox.inc +1 -1
-DEPENDS += "kern-tools-native"
+# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
defined
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
+DEPENDS += "kern-tools-native virtual/crypt"
I'm not a bug fan of adding dependencies which might not be needed.
How
Quoted 4 lines
Quoted 2 lines
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...
Quoted 7 lines
Quoted 3 lines
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)?
Quoted 32 lines
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.
Quoted 16 lines
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.
Quoted 8 lines
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

Signature · 2 lines

# Randy MacLeod
# Wind River Linux