[PATCH] testsuite: fix last "which" change
In commit afa63b2dcdc9b9 I replaced `type -p' with `command -pv'. But actually it is wrong, the right substitution is `command -v'. We need to find our busybox which is in the first directory in $PATH, so `command -p' should not be used because it uses default PATH, not current value of PATH where our busybox binary resides. Signed-off-by: Michael Tokarev --- testsuite/which/which-uses-default-path |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testsuite/which/which-uses-default-path b/testsuite/which/which-uses-default-path index 349583d..92b6018 100644 --- a/testsuite/which/which-uses-default-path +++ b/testsuite/which/which-uses-default-path @@ -1,4 +1,4 @@ -BUSYBOX=$(command -pv busybox) +BUSYBOX=$(command -v busybox) SAVED_PATH=$PATH unset PATH $BUSYBOX which ls -- 1.7.10.4 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
1.22: zcat does not decompress data anymore [bisected]
Since this commit: commit 41655438c6b61d05ddf3619f31abc1fa3583e2be Author: Denys Vlasenko Date: Thu Feb 28 18:37:04 2013 +0100 zcat: fix "zcat FILE" trying to do detection twice busybox's zcat does not decompress files without .gz extension anymore: $ gzip < README > x $ ./busybox zcat x | wc -c -- before the above commit, it will uncompress the data fine, yelding the size of original README file (8763 bytes). But after this commit, it emits compressed data (effectively just copies content of the input file), of size 3985 bytes. I was about to submit this as a bugreport, but took a look at the current git tree, and noticed that apparently, this issue has already been fixed by the following two commits: commit 7c47b560a8fc97956dd8132bd7f1863d83c19866 (patch) libarchive: open_zipped() does not need to check extensions for e.g. gzip We only need to check for signature-less extensions, currently only .lzma. The rest can be happily autodetected. This fixes "zcat FILE_WITHOUT_GZ_EXT" case, among others. commit b664f740d90880560ce46b11f766625341342e80 (patch) busybox-b664f740d90880560ce46b11f766625341342e80.tar.bz2 libbb: open_zipped() should not fail on non-compressed files So it looks like the two commits are good candidates for 1.21. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.22: zcat does not decompress data anymore [bisected]
28.01.2014 12:48, Michael Tokarev пишет: > Since this commit: > > commit 41655438c6b61d05ddf3619f31abc1fa3583e2be > Author: Denys Vlasenko > Date: Thu Feb 28 18:37:04 2013 +0100 > > zcat: fix "zcat FILE" trying to do detection twice > > busybox's zcat does not decompress files without .gz > extension anymore: > > $ gzip < README > x > $ ./busybox zcat x | wc -c > > -- before the above commit, it will uncompress the data fine, > yelding the size of original README file (8763 bytes). But > after this commit, it emits compressed data (effectively just > copies content of the input file), of size 3985 bytes. > > > I was about to submit this as a bugreport, but took a look at > the current git tree, and noticed that apparently, this issue > has already been fixed by the following two commits: > > commit7c47b560a8fc97956dd8132bd7f1863d83c19866 (patch) > libarchive: open_zipped() does not need to check extensions for e.g. gzip > We only need to check for signature-less extensions, currently only .lzma. > The rest can be happily autodetected. This fixes "zcat FILE_WITHOUT_GZ_EXT" > case, among others. > > commitb664f740d90880560ce46b11f766625341342e80 (patch) > busybox-b664f740d90880560ce46b11f766625341342e80.tar.bz2 > libbb: open_zipped() should not fail on non-compressed files > > > So it looks like the two commits are good candidates for 1.21. Note that with the above two patches, busybox zcat will happily accept uncompressed input and will behave like plain cat, while original zcat refuses to work on uncompressed data: $ zcat README gzip: README: not in gzip format $ ./busybox zcat README | wc -l 204 For some, it might look like a bug. I've seen scripts verifying if the data is compressed by running zcat >/dev/null - arguable those are also broken, but heck... Note that for (uncompressed) data read from stdin, busybox actually fails correctly, but does not produce any error message: $ ./busybox zcat < README $ echo $? 1 Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH trivial] do not fail build if SIGPWR is not defined
Apparently, some *BSD variants (and maybe some other OSes) does not define SIGPWR signal. So since commit 760fc6debcba8c, busybox fails to build on such platforms. Fix this. Signed-off-By: Michael Tokarev diff --git a/init/init.c b/init/init.c index d29328c..992a21e 100644 --- a/init/init.c +++ b/init/init.c @@ -1135,7 +1137,9 @@ int init_main(int argc UNUSED_PARAM, char **argv) struct sigaction sa; bb_signals(0 +#ifdef SIGPWR + (1 << SIGPWR) /* halt */ +#endif + (1 << SIGUSR1) /* halt */ + (1 << SIGTERM) /* reboot */ + (1 << SIGUSR2) /* poweroff */ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH trivial] do not fail build if SIGPWR is not defined
29.01.2014 12:51, Harald Becker пишет: > Hi Michael ! > >> Apparently, some *BSD variants (and maybe some other OSes) does >> not define SIGPWR signal. So since commit 760fc6debcba8c, >> busybox fails to build on such platforms. Fix this. > >> +#ifdef SIGPWR >> + (1 << SIGPWR) /* halt */ >> +#endif >> + (1 << SIGUSR1) /* halt */ > > Does this change the signal send to do system halt? If so, this I'm not sure I follow what you're asking. This is a bitmask of signals which needs to be catched by init. It is not a set of signals _sent_ by init, it is a set of signals _intercepted_ by init. This can't actually change anything (except of re-enabling building this code on platforms which don't have SIGPWR), because if the signal isn't defined, it doesn't exist and can't be used anyway. > may break several scripts which require a specific usage of > signals. Which scripts send signals to init? Which process is actually _able_ to send any signal to init on linux? Really I'm not sure I understand what you're talking about. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: mdev and post 3.6 kernels
09.02.2014 05:28, Michael J. Hammel wrote: > I've been using 3.2.27 from the RPi repos with mdev and usbfs. This > worked fine to load drivers for wifi and webcams. I'm trying to move to > RPi's "3.10.y" branch. I've found that usbfs is deprecated and now I'm > not sure how to find the usb devices and load the drivers. mdev doesn't > seem to report them. I have it log every event at boot time and the usb > devices don't show up. > > Does anyone know if there are kernel config options that need to be > enabled in 3.6+ (when usbfs was deprecated) for mdev to be notified of > usb devices at boot time? Or maybe suggestions on what mdev should be > looking at to find them? I could dig into mdev but I'm not sure where > it should be looking for the devices. lsusb shows them. How about actually loading usb _controller_ drivers before trying to look up devices on usb bus? Such as ehci_pci? (this has nothing to do with usbfs btw). Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] iproute: support onelink route option and print route flags
Signed-off-by: Michael Tokarev
---
networking/libiproute/iproute.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/networking/libiproute/iproute.c b/networking/libiproute/iproute.c
index ec4d8ba..273f6fe 100644
--- a/networking/libiproute/iproute.c
+++ b/networking/libiproute/iproute.c
@@ -298,6 +298,19 @@ static int FAST_FUNC print_route(const struct sockaddr_nl
*who UNUSED_PARAM,
if (tb[RTA_PRIORITY]) {
printf(" metric %d ", *(uint32_t*)RTA_DATA(tb[RTA_PRIORITY]));
}
+ if (r->rtm_flags & RTNH_F_DEAD) {
+ printf("dead ");
+ }
+ if (r->rtm_flags & RTNH_F_ONLINK) {
+ printf("onlink ");
+ }
+ if (r->rtm_flags & RTNH_F_PERVASIVE) {
+ printf("pervasive ");
+ }
+ if (r->rtm_flags & RTM_F_NOTIFY) {
+ printf("notify ");
+ }
+
if (r->rtm_family == AF_INET6) {
struct rta_cacheinfo *ci = NULL;
if (tb[RTA_CACHEINFO]) {
@@ -330,7 +343,7 @@ static int iproute_modify(int cmd, unsigned flags, char
**argv)
{
static const char keywords[] ALIGN1 =
"src\0""via\0""mtu\0""lock\0""protocol\0"IF_FEATURE_IP_RULE("table\0")
- "dev\0""oif\0""to\0""metric\0";
+ "dev\0""oif\0""to\0""metric\0onlink";
enum {
ARG_src,
ARG_via,
@@ -341,6 +354,7 @@ IF_FEATURE_IP_RULE(ARG_table,)
ARG_oif,
ARG_to,
ARG_metric,
+ ARG_onlink,
};
enum {
gw_ok = 1 << 0,
@@ -431,6 +445,8 @@ IF_FEATURE_IP_RULE(ARG_table,)
NEXT_ARG();
metric = get_u32(*argv, "metric");
addattr32(&req.n, sizeof(req), RTA_PRIORITY, metric);
+ } else if (arg == ARG_onlink) {
+ req.r.rtm_flags |= RTNH_F_ONLINK;
} else {
int type;
inet_prefix dst;
--
1.7.10.4
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] iproute: support onelink route option and print route flags
Signed-off-by: Michael Tokarev
---
networking/libiproute/iproute.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/networking/libiproute/iproute.c b/networking/libiproute/iproute.c
index ec4d8ba..273f6fe 100644
--- a/networking/libiproute/iproute.c
+++ b/networking/libiproute/iproute.c
@@ -298,6 +298,19 @@ static int FAST_FUNC print_route(const struct sockaddr_nl
*who UNUSED_PARAM,
if (tb[RTA_PRIORITY]) {
printf(" metric %d ", *(uint32_t*)RTA_DATA(tb[RTA_PRIORITY]));
}
+ if (r->rtm_flags & RTNH_F_DEAD) {
+ printf("dead ");
+ }
+ if (r->rtm_flags & RTNH_F_ONLINK) {
+ printf("onlink ");
+ }
+ if (r->rtm_flags & RTNH_F_PERVASIVE) {
+ printf("pervasive ");
+ }
+ if (r->rtm_flags & RTM_F_NOTIFY) {
+ printf("notify ");
+ }
+
if (r->rtm_family == AF_INET6) {
struct rta_cacheinfo *ci = NULL;
if (tb[RTA_CACHEINFO]) {
@@ -330,7 +343,7 @@ static int iproute_modify(int cmd, unsigned flags, char
**argv)
{
static const char keywords[] ALIGN1 =
"src\0""via\0""mtu\0""lock\0""protocol\0"IF_FEATURE_IP_RULE("table\0")
- "dev\0""oif\0""to\0""metric\0";
+ "dev\0""oif\0""to\0""metric\0onlink";
enum {
ARG_src,
ARG_via,
@@ -341,6 +354,7 @@ IF_FEATURE_IP_RULE(ARG_table,)
ARG_oif,
ARG_to,
ARG_metric,
+ ARG_onlink,
};
enum {
gw_ok = 1 << 0,
@@ -431,6 +445,8 @@ IF_FEATURE_IP_RULE(ARG_table,)
NEXT_ARG();
metric = get_u32(*argv, "metric");
addattr32(&req.n, sizeof(req), RTA_PRIORITY, metric);
+ } else if (arg == ARG_onlink) {
+ req.r.rtm_flags |= RTNH_F_ONLINK;
} else {
int type;
inet_prefix dst;
--
1.7.10.4
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Fwd: [PATCH] iproute: support onelink route option and print route flags
Hello. I submitted the attached patch to the list 2 times, but
it never made into the list for some reason. Last time was
today, here's a line from my maillog:
Jul 28 06:05:45 isrv postfix/smtp[24869]: 4586B45736: to=,
\
relay=smtp1.osuosl.org[140.211.166.138]:25, delay=3.5, delays=0.09/0/2.5/0.85,
\
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 669BE8C12E)
(The timestamp is in UTC).
Resending again now using my regular MUA, just in case, and adding a Cc to
postmaster@...
Thanks,
/mjt
--- Begin Message ---
Signed-off-by: Michael Tokarev
---
networking/libiproute/iproute.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/networking/libiproute/iproute.c b/networking/libiproute/iproute.c
index ec4d8ba..273f6fe 100644
--- a/networking/libiproute/iproute.c
+++ b/networking/libiproute/iproute.c
@@ -298,6 +298,19 @@ static int FAST_FUNC print_route(const struct sockaddr_nl
*who UNUSED_PARAM,
if (tb[RTA_PRIORITY]) {
printf(" metric %d ", *(uint32_t*)RTA_DATA(tb[RTA_PRIORITY]));
}
+ if (r->rtm_flags & RTNH_F_DEAD) {
+ printf("dead ");
+ }
+ if (r->rtm_flags & RTNH_F_ONLINK) {
+ printf("onlink ");
+ }
+ if (r->rtm_flags & RTNH_F_PERVASIVE) {
+ printf("pervasive ");
+ }
+ if (r->rtm_flags & RTM_F_NOTIFY) {
+ printf("notify ");
+ }
+
if (r->rtm_family == AF_INET6) {
struct rta_cacheinfo *ci = NULL;
if (tb[RTA_CACHEINFO]) {
@@ -330,7 +343,7 @@ static int iproute_modify(int cmd, unsigned flags, char
**argv)
{
static const char keywords[] ALIGN1 =
"src\0""via\0""mtu\0""lock\0""protocol\0"IF_FEATURE_IP_RULE("table\0")
- "dev\0""oif\0""to\0""metric\0";
+ "dev\0""oif\0""to\0""metric\0onlink";
enum {
ARG_src,
ARG_via,
@@ -341,6 +354,7 @@ IF_FEATURE_IP_RULE(ARG_table,)
ARG_oif,
ARG_to,
ARG_metric,
+ ARG_onlink,
};
enum {
gw_ok = 1 << 0,
@@ -431,6 +445,8 @@ IF_FEATURE_IP_RULE(ARG_table,)
NEXT_ARG();
metric = get_u32(*argv, "metric");
addattr32(&req.n, sizeof(req), RTA_PRIORITY, metric);
+ } else if (arg == ARG_onlink) {
+ req.r.rtm_flags |= RTNH_F_ONLINK;
} else {
int type;
inet_prefix dst;
--
1.7.10.4
--- End Message ---
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: [PATCH] iproute: support onelink route option and print route flags
28.07.2014 10:23, Michael Tokarev wrote: > Hello. I submitted the attached patch to the list 2 times, but > it never made into the list for some reason. Last time was > today, here's a line from my maillog: > > Jul 28 06:05:45 isrv postfix/smtp[24869]: 4586B45736: > to=, \ > relay=smtp1.osuosl.org[140.211.166.138]:25, delay=3.5, > delays=0.09/0/2.5/0.85, \ > dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 669BE8C12E) > > (The timestamp is in UTC). > > Resending again now using my regular MUA, just in case, and adding a Cc to > postmaster@... So mail sent from my MUA worked, -- the question is, why busybox.net dislikes mail sent by `git send-email', which is sent by the same MTA from the same server. Also, postmas...@busybox.net bounces: whitealder.osuosl.org: : mail for busybox.net loops back to myself Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: [PATCH] iproute: support onelink route option and print route flags
28.07.2014 10:46, Baruch Siach wrote: [] > I received your original post today. It's also on the gmane.org archive at > http://article.gmane.org/gmane.linux.busybox/39641. Oh. I think I know what's going on. The mailing list does not send email to the author if he's already listed in a Cc list. This email should not be sent back to me if that's true. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: [PATCH] iproute: support onelink route option and print route flags
A friendly ping, https://www.mail-archive.com/busybox@busybox.net/msg19972.html . It's been several months already, apparently forgotten. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] ip addr: support change and replace commands
Signed-off-by: Michael Tokarev
---
networking/ip.c | 2 +-
networking/libiproute/ipaddress.c | 20
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/networking/ip.c b/networking/ip.c
index 98fe621..d35345c 100644
--- a/networking/ip.c
+++ b/networking/ip.c
@@ -33,7 +33,7 @@
//usage: "{ {add|del} IFADDR dev STRING | {show|flush}\n"
//usage: " [dev STRING] [to PREFIX] }"
//usage:#define ipaddr_full_usage "\n\n"
-//usage: "ipaddr {add|delete} IFADDR dev STRING\n"
+//usage: "ipaddr {add|change|replace|delete} IFADDR dev STRING\n"
//usage: "ipaddr {show|flush} [dev STRING] [scope SCOPE-ID]\n"
//usage: " [to PREFIX] [label PATTERN]\n"
//usage: " IFADDR := PREFIX | ADDR peer PREFIX\n"
diff --git a/networking/libiproute/ipaddress.c
b/networking/libiproute/ipaddress.c
index 4072d06..85f3356 100644
--- a/networking/libiproute/ipaddress.c
+++ b/networking/libiproute/ipaddress.c
@@ -598,7 +598,7 @@ static int default_scope(inet_prefix *lcl)
}
/* Return value becomes exitcode. It's okay to not return at all */
-static int ipaddr_modify(int cmd, char **argv)
+static int ipaddr_modify(int cmd, int flags, char **argv)
{
static const char option[] ALIGN1 =
"peer\0""remote\0""broadcast\0""brd\0"
@@ -622,7 +622,7 @@ static int ipaddr_modify(int cmd, char **argv)
memset(&req, 0, sizeof(req));
req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifaddrmsg));
- req.n.nlmsg_flags = NLM_F_REQUEST;
+ req.n.nlmsg_flags = NLM_F_REQUEST | flags;
req.n.nlmsg_type = cmd;
req.ifa.ifa_family = preferred_family;
@@ -749,16 +749,20 @@ static int ipaddr_modify(int cmd, char **argv)
int FAST_FUNC do_ipaddr(char **argv)
{
static const char commands[] ALIGN1 =
- "add\0""delete\0""list\0""show\0""lst\0""flush\0";
+ /* 01 2 3 4 5 6 7
8 */
+
"add\0""change\0""chg\0""replace\0""delete\0""list\0""show\0""lst\0""flush\0";
int cmd = 2;
if (*argv) {
cmd = index_in_substrings(commands, *argv);
if (cmd < 0)
invarg(*argv, applet_name);
argv++;
- if (cmd <= 1)
- return ipaddr_modify((cmd == 0) ? RTM_NEWADDR :
RTM_DELADDR, argv);
- }
- /* 2 == list, 3 == show, 4 == lst */
- return ipaddr_list_or_flush(argv, cmd == 5);
+ if (cmd <= 4)
+ return ipaddr_modify(cmd == 4 ? RTM_DELADDR :
RTM_NEWADDR,
+ cmd == 0 ?
NLM_F_CREATE|NLM_F_EXCL :
+ cmd == 1 || cmd == 2 ?
NLM_F_REPLACE :
+ cmd == 3 ?
NLM_F_CREATE|NLM_F_REPLACE :
+ 0, argv);
+ }
+ return ipaddr_list_or_flush(argv, cmd == 8);
}
--
2.1.4
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ip addr: support change and replace commands
Ping?
20.05.2015 16:27, Michael Tokarev wrote:
> Signed-off-by: Michael Tokarev
> ---
> networking/ip.c | 2 +-
> networking/libiproute/ipaddress.c | 20
> 2 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/networking/ip.c b/networking/ip.c
> index 98fe621..d35345c 100644
> --- a/networking/ip.c
> +++ b/networking/ip.c
> @@ -33,7 +33,7 @@
> //usage: "{ {add|del} IFADDR dev STRING | {show|flush}\n"
> //usage: " [dev STRING] [to PREFIX] }"
> //usage:#define ipaddr_full_usage "\n\n"
> -//usage: "ipaddr {add|delete} IFADDR dev STRING\n"
> +//usage: "ipaddr {add|change|replace|delete} IFADDR dev STRING\n"
> //usage: "ipaddr {show|flush} [dev STRING] [scope SCOPE-ID]\n"
> //usage: " [to PREFIX] [label PATTERN]\n"
> //usage: " IFADDR := PREFIX | ADDR peer PREFIX\n"
> diff --git a/networking/libiproute/ipaddress.c
> b/networking/libiproute/ipaddress.c
> index 4072d06..85f3356 100644
> --- a/networking/libiproute/ipaddress.c
> +++ b/networking/libiproute/ipaddress.c
> @@ -598,7 +598,7 @@ static int default_scope(inet_prefix *lcl)
> }
>
> /* Return value becomes exitcode. It's okay to not return at all */
> -static int ipaddr_modify(int cmd, char **argv)
> +static int ipaddr_modify(int cmd, int flags, char **argv)
> {
> static const char option[] ALIGN1 =
> "peer\0""remote\0""broadcast\0""brd\0"
> @@ -622,7 +622,7 @@ static int ipaddr_modify(int cmd, char **argv)
> memset(&req, 0, sizeof(req));
>
> req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifaddrmsg));
> - req.n.nlmsg_flags = NLM_F_REQUEST;
> + req.n.nlmsg_flags = NLM_F_REQUEST | flags;
> req.n.nlmsg_type = cmd;
> req.ifa.ifa_family = preferred_family;
>
> @@ -749,16 +749,20 @@ static int ipaddr_modify(int cmd, char **argv)
> int FAST_FUNC do_ipaddr(char **argv)
> {
> static const char commands[] ALIGN1 =
> - "add\0""delete\0""list\0""show\0""lst\0""flush\0";
> + /* 01 2 3 4 5 6 7
> 8 */
> +
> "add\0""change\0""chg\0""replace\0""delete\0""list\0""show\0""lst\0""flush\0";
> int cmd = 2;
> if (*argv) {
> cmd = index_in_substrings(commands, *argv);
> if (cmd < 0)
> invarg(*argv, applet_name);
> argv++;
> - if (cmd <= 1)
> - return ipaddr_modify((cmd == 0) ? RTM_NEWADDR :
> RTM_DELADDR, argv);
> - }
> - /* 2 == list, 3 == show, 4 == lst */
> - return ipaddr_list_or_flush(argv, cmd == 5);
> + if (cmd <= 4)
> + return ipaddr_modify(cmd == 4 ? RTM_DELADDR :
> RTM_NEWADDR,
> + cmd == 0 ?
> NLM_F_CREATE|NLM_F_EXCL :
> + cmd == 1 || cmd == 2 ?
> NLM_F_REPLACE :
> + cmd == 3 ?
> NLM_F_CREATE|NLM_F_REPLACE :
> + 0, argv);
> + }
> + return ipaddr_list_or_flush(argv, cmd == 8);
> }
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ip addr: support change and replace commands
23.06.2015 18:44, Bernhard Reutner-Fischer wrote:
> On June 23, 2015 3:27:54 PM GMT+02:00, Michael Tokarev
> wrote:
>> Ping?
>>
>> 20.05.2015 16:27, Michael Tokarev wrote:
>>> Signed-off-by: Michael Tokarev
>>> ---
>>> networking/ip.c | 2 +-
>>> networking/libiproute/ipaddress.c | 20
>>> 2 files changed, 13 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/networking/ip.c b/networking/ip.c
>>> index 98fe621..d35345c 100644
>>> --- a/networking/ip.c
>>> +++ b/networking/ip.c
>>> @@ -33,7 +33,7 @@
>>> //usage: "{ {add|del} IFADDR dev STRING | {show|flush}\n"
>>> //usage: " [dev STRING] [to PREFIX] }"
>>> //usage:#define ipaddr_full_usage "\n\n"
>>> -//usage: "ipaddr {add|delete} IFADDR dev STRING\n"
>>> +//usage: "ipaddr {add|change|replace|delete} IFADDR dev STRING\n"
>>> //usage: "ipaddr {show|flush} [dev STRING] [scope SCOPE-ID]\n"
>>> //usage: " [to PREFIX] [label PATTERN]\n"
>>> //usage: " IFADDR := PREFIX | ADDR peer PREFIX\n"
>>> diff --git a/networking/libiproute/ipaddress.c
>> b/networking/libiproute/ipaddress.c
>>> index 4072d06..85f3356 100644
>>> --- a/networking/libiproute/ipaddress.c
>>> +++ b/networking/libiproute/ipaddress.c
>>> @@ -598,7 +598,7 @@ static int default_scope(inet_prefix *lcl)
>>> }
>>>
>>> /* Return value becomes exitcode. It's okay to not return at all */
>>> -static int ipaddr_modify(int cmd, char **argv)
>>> +static int ipaddr_modify(int cmd, int flags, char **argv)
>>> {
>>> static const char option[] ALIGN1 =
>>> "peer\0""remote\0""broadcast\0""brd\0"
>>> @@ -622,7 +622,7 @@ static int ipaddr_modify(int cmd, char **argv)
>>> memset(&req, 0, sizeof(req));
>>>
>>> req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifaddrmsg));
>>> - req.n.nlmsg_flags = NLM_F_REQUEST;
>>> + req.n.nlmsg_flags = NLM_F_REQUEST | flags;
>>> req.n.nlmsg_type = cmd;
>>> req.ifa.ifa_family = preferred_family;
>>>
>>> @@ -749,16 +749,20 @@ static int ipaddr_modify(int cmd, char **argv)
>>> int FAST_FUNC do_ipaddr(char **argv)
>>> {
>>> static const char commands[] ALIGN1 =
>>> - "add\0""delete\0""list\0""show\0""lst\0""flush\0";
>>> + /* 01 2 3 4 5 6 7
>>>
>> 8 */
>>>
>> +
>> "add\0""change\0""chg\0""replace\0""delete\0""list\0""show\0""lst\0""flush\0";
>>> int cmd = 2;
>>> if (*argv) {
>>> cmd = index_in_substrings(commands, *argv);
>>> if (cmd < 0)
>>> invarg(*argv, applet_name);
>>> argv++;
>>> - if (cmd <= 1)
>>> - return ipaddr_modify((cmd == 0) ? RTM_NEWADDR :
>>> RTM_DELADDR, argv);
>>> - }
>>> - /* 2 == list, 3 == show, 4 == lst */
>>> - return ipaddr_list_or_flush(argv, cmd == 5);
>>> + if (cmd <= 4)
>>> + return ipaddr_modify(cmd == 4 ? RTM_DELADDR :
>>> RTM_NEWADDR,
>
> wrong comma?
Nope, not wrong comma. The first argument is the command, and the second:
>>> + cmd == 0 ?
>>> NLM_F_CREATE|NLM_F_EXCL :
>>> + cmd == 1 || cmd == 2 ?
>>> NLM_F_REPLACE :
>>> + cmd == 3 ?
>>> NLM_F_CREATE|NLM_F_REPLACE :
>>> + 0, argv);
is the flags for the command.
>>> + }
>>> + return ipaddr_list_or_flush(argv, cmd == 8);
>
> bloat-o-meter output, please.
$ make bloatcheck
function old new delta
.rodata 67076771 +64
do_ipaddr 90 139 +49
static.commands 32 51 +19
ipaddr_modify 10841085 +1
--
(add/remove: 0/0 grow/shrink: 4/0 up/down: 133/0) Total: 133 bytes
textdata bss dec hex filename
4714313058360 56808dde8 busybox_old
4725513058360 56920de58 busybox_unstripped
Thanks,
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] tar: Fix build error when CONFIG_UNCOMPRESS is not selected
[Rehashing a thread from 3 years ago] 28.01.2013 11:48, Denys Vlasenko wrote: > On Monday 28 January 2013 00:17, Abdoulaye Walsimou GAYE wrote: > diff --git a/archival/libarchive/Kbuild.src > b/archival/libarchive/Kbuild.src > index 58457fc..87e1ab9 100644 > --- a/archival/libarchive/Kbuild.src > +++ b/archival/libarchive/Kbuild.src > -lib-$(CONFIG_TAR) += get_header_tar.o > +lib-$(CONFIG_TAR) += get_header_tar.o > decompress_uncompress.o >> >> /home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/busybox-1.20.2/archival/tar.c:1065: >> undefined reference to `unpack_Z_stream' >> /home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/busybox-1.20.2/archival/tar.c:1065: >> undefined reference to `unpack_Z_stream' >> /home/walsimou/embtoolkit.git/tools-mipsel-linux-mips32/bin/mipsisa32el-unknown-linux-uclibc-ld: >> busybox_unstripped: hidden symbol `unpack_Z_stream' isn't defined >> /home/walsimou/embtoolkit.git/tools-mipsel-linux-mips32/bin/mipsisa32el-unknown-linux-uclibc-ld: >> final link failed: Bad value >> mipsisa32el-unknown-linux-uclibc-clang: error: linker command failed with >> exit code 1 (use -v to see invocation) > > > I was able to build busybox-1.20.2 with this .config > without errors. > > Looks like your compiler did not optimize this out: > > if (opt & OPT_COMPRESS) > USE_FOR_MMU(xformer = unpack_Z_stream;) > USE_FOR_NOMMU(xformer_prog = "uncompress";) > > > even though OPT_COMPRESS is a constant zero. The same prob exists with clang, apparently, Here's a bugreport filed against debian package of busybox: http://bugs.debian.org/789499 . The proposed fix is to apply the above patch only if building with clang :) Basically, I'm not sure relying on dead code elimination like this is a good idea. I mean, the code is eliminated, there's no if() statement in the generated code, so it is okay, but it looks like clang still records symbols referenced in the eliminated code. Sometimes it is actually a good idea to keep ref symbols, eg when you build an executable which can load modules, so that modules will use symbols in that executable. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] tar: Fix build error when CONFIG_UNCOMPRESS is not selected
01.07.2015 19:55, Denys Vlasenko wrote: > Rob Landley has an opposite view: preprocessor #if's are evil. > > I agree with him that they do tend to obfuscate. So what's the solution to this? Blame compilers and force them to act like GCC does? Thanks, /mjt > On Sun, Jun 28, 2015 at 9:44 AM, Michael Tokarev wrote: >> [Rehashing a thread from 3 years ago] >> >> 28.01.2013 11:48, Denys Vlasenko wrote: >>> On Monday 28 January 2013 00:17, Abdoulaye Walsimou GAYE wrote: >> >>>>>>> diff --git a/archival/libarchive/Kbuild.src >>>>>>> b/archival/libarchive/Kbuild.src >>>>>>> index 58457fc..87e1ab9 100644 >>>>>>> --- a/archival/libarchive/Kbuild.src >>>>>>> +++ b/archival/libarchive/Kbuild.src >>>>>>> -lib-$(CONFIG_TAR) += get_header_tar.o >>>>>>> +lib-$(CONFIG_TAR) += get_header_tar.o >>>>>>> decompress_uncompress.o >>>> >>>> /home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/busybox-1.20.2/archival/tar.c:1065: >>>> undefined reference to `unpack_Z_stream' >>>> /home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/busybox-1.20.2/archival/tar.c:1065: >>>> undefined reference to `unpack_Z_stream' >>>> /home/walsimou/embtoolkit.git/tools-mipsel-linux-mips32/bin/mipsisa32el-unknown-linux-uclibc-ld: >>>> busybox_unstripped: hidden symbol `unpack_Z_stream' isn't defined >>>> /home/walsimou/embtoolkit.git/tools-mipsel-linux-mips32/bin/mipsisa32el-unknown-linux-uclibc-ld: >>>> final link failed: Bad value >>>> mipsisa32el-unknown-linux-uclibc-clang: error: linker command failed with >>>> exit code 1 (use -v to see invocation) >>> >>> >>> I was able to build busybox-1.20.2 with this .config >>> without errors. >>> >>> Looks like your compiler did not optimize this out: >>> >>> if (opt & OPT_COMPRESS) >>> USE_FOR_MMU(xformer = unpack_Z_stream;) >>> USE_FOR_NOMMU(xformer_prog = "uncompress";) >>> >>> >>> even though OPT_COMPRESS is a constant zero. >> >> The same prob exists with clang, apparently, Here's a bugreport >> filed against debian package of busybox: http://bugs.debian.org/789499 . >> The proposed fix is to apply the above patch only if building >> with clang :) >> >> Basically, I'm not sure relying on dead code elimination like this is >> a good idea. I mean, the code is eliminated, there's no if() statement >> in the generated code, so it is okay, but it looks like clang still >> records symbols referenced in the eliminated code. Sometimes it >> is actually a good idea to keep ref symbols, eg when you build an >> executable which can load modules, so that modules will use symbols >> in that executable. >> >> Thanks, >> >> /mjt >> ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] su: support numeric UIDs with a -n flag
10.05.2022 16:30, Ben Fuller wrote: Signed-off-by: Ben Fuller --- Hi, I want to be able to use UIDs rather than usernames in order to handle cases where some POSIX tools truncate usernames at 8 characters. This patch adds a `-n` flag to su, which causes it to interpret the given USER as a numeric UID rather than a username. Do you really want su there? Maybe setpriv will better suit your needs? Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] su: support numeric UIDs with a -n flag
10.05.2022 16:53, Michael Tokarev wrote: .. Do you really want su there? Maybe setpriv will better suit your needs? Grrr, and setpriv in busybox does not support user/group settings at all... ;) Why I asked: it is uncommon for su to accept numeric UIDs, - be it busybox or anything else. Also, su interface is quite strange in the arguments handling. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] use libresolv on non-linux too
nslookup uses symbols from libresolv, no matter it is on linux or not. This also eliminates hackish way to detect linux. --- Makefile.flags | 2 -- 1 file changed, 2 deletions(-) diff --git a/Makefile.flags b/Makefile.flags index 84cb00a75..be0a3c4bb 100644 --- a/Makefile.flags +++ b/Makefile.flags @@ -184,10 +184,8 @@ LDLIBS += $(if $(SELINUX_LIBS),$(SELINUX_LIBS:-l%=%),$(SELINUX_PC_MODULES:lib%=% endif ifeq ($(CONFIG_FEATURE_NSLOOKUP_BIG),y) -ifneq (,$(findstring linux,$(shell $(CC) $(CFLAGS) -dumpmachine))) LDLIBS += resolv endif -endif ifeq ($(CONFIG_EFENCE),y) LDLIBS += efence -- 2.30.2 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets
This effectively reverts the following two commits:
commit e3b1a1fd28558f7a1b3c0ec33313bedb675be8a1
Author: Denys Vlasenko
Date: Sat Feb 26 22:24:08 2011 +0100
Replace "depends on PLATFORM_LINUX" with "select PLATFORM_LINUX"
and
commit 5c69ad0ecdc18cf51b312c7c82848f4438fe1c8d
Author: Ron Yorston
Date: Tue Aug 4 08:24:19 2020 +0100
build system: drop PLATFORM_LINUX
but does, hopefully, the right thing.
Original complain was that the allnoconfig turns off PLATFORM_LINUX
on which all linux-specific applets depends. Instead of setting this
config option right for linux and non-linux (initially it was just a
regular kconfig symbol, not set depending on the platform), it were
turned into something which made little sense (in the first commit),
and later dropped completely.
So introduce a dynamic kconfig symbol PLATFORM_LINUX with the value
actually depending on the target platform, so that it is not affected
by all{yes|no|whatever}config. This way, it is possible to depend on
it for linux-specific applets without breaking *config anymore.
It is done by creating a small kconfig fragment, .platform.in, to
define just PLATFORM_LINUX symbol. It is created in Makefile if
${CPP} has __linux__ #defined. And include it in the top-level Config.in.
Regenerate default config files with the new symbol.
And mark all the applets which were marked as "select PLATFORM_LINUX"
before the "build system: drop PLATFORM_LINUX" commit, as
"depends on PLATFORM_LINUX".
Also mark 2 other applets, tc and dhcprelay, as linux-only too.
This way, it is finally possible to build busybox on other platforms
without really huge efforts to maintain list of "incompatible" applets
externally, and does not put any pressure on the main development, -
the only thing needed is to keep the existing "depends on PLATFORM_LINUX"
lines.
Signed-off-by: Michael Tokarev
---
Config.in | 4
Makefile| 9 -
configs/TEST_nommu_defconfig| 1 +
configs/TEST_noprintf_defconfig | 1 +
configs/TEST_rh9_defconfig | 1 +
configs/android2_defconfig | 1 +
configs/android_502_defconfig | 1 +
configs/android_defconfig | 1 +
configs/android_ndk_defconfig | 1 +
configs/cygwin_defconfig| 1 +
configs/freebsd_defconfig | 1 +
console-tools/chvt.c| 1 +
console-tools/deallocvt.c | 1 +
console-tools/dumpkmap.c| 1 +
console-tools/fgconsole.c | 1 +
console-tools/kbd_mode.c| 1 +
console-tools/loadfont.c| 2 ++
console-tools/loadkmap.c| 1 +
console-tools/openvt.c | 1 +
console-tools/setconsole.c | 1 +
console-tools/setkeycodes.c | 1 +
console-tools/setlogcons.c | 1 +
console-tools/showkey.c | 1 +
coreutils/date.c| 1 +
coreutils/stat.c| 1 +
e2fsprogs/lsattr.c | 1 +
klibc-utils/run-init.c | 1 +
libbb/Config.src| 2 ++
miscutils/adjtimex.c| 1 +
miscutils/beep.c| 1 +
miscutils/conspy.c | 1 +
miscutils/devfsd.c | 2 ++
miscutils/fbsplash.c| 1 +
miscutils/hdparm.c | 1 +
miscutils/i2c_tools.c | 5 +
miscutils/lsscsi.c | 1 +
miscutils/nandwrite.c | 2 ++
miscutils/partprobe.c | 1 +
miscutils/raidautorun.c | 1 +
miscutils/readahead.c | 1 +
miscutils/rfkill.c | 1 +
miscutils/rx.c | 1 +
miscutils/setserial.c | 1 +
miscutils/ubi_tools.c | 6 ++
miscutils/ubirename.c | 1 +
miscutils/watchdog.c| 1 +
modutils/depmod.c | 1 +
modutils/insmod.c | 1 +
modutils/lsmod.c| 1 +
modutils/modinfo.c | 1 +
modutils/modprobe.c | 1 +
modutils/rmmod.c| 1 +
networking/arp.c| 1 +
networking/arping.c | 1 +
networking/brctl.c | 1 +
networking/ether-wake.c | 1 +
networking/ifconfig.c | 1 +
networking/ifenslave.c | 1 +
networking/ifplugd.c| 1 +
networking/ip.c | 7 +++
networking/nameif.c | 1 +
networking/netstat.c| 1 +
networking/ntpd.c | 1 +
networking/ping.c | 1 +
networking/route.c | 1 +
networking/slattach.c | 1 +
networking/tc.c | 1 +
networking/traceroute.c | 1 +
networking/tunctl.c | 1 +
networking/udhcp/Config.src | 3 +++
networking/vconfig.c| 1 +
networking/zcip.c | 1 +
procps/free.c | 1 +
procps/ps.c | 1 +
procps/uptime.c | 1 +
sysklogd/klogd.c| 1 +
sysklogd/syslogd.c
[PATCH] Fix non-Linux builds
From: Samuel Thibault
Some features are Linux-only.
Also, libresolv is used on all GNU platforms, notably GNU/Hurd and
GNU/kfreeBSD.
---
coreutils/dd.c | 20 ++--
networking/traceroute.c | 2 ++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/coreutils/dd.c b/coreutils/dd.c
index 06c1b7b9c..3e034eb1e 100644
--- a/coreutils/dd.c
+++ b/coreutils/dd.c
@@ -200,6 +200,7 @@ static void dd_output_status(int UNUSED_PARAM cur_signal)
}
#if ENABLE_FEATURE_DD_IBS_OBS
+# ifdef O_DIRECT
static int clear_O_DIRECT(int fd)
{
if (errno == EINVAL) {
@@ -211,6 +212,7 @@ static int clear_O_DIRECT(int fd)
}
return 0;
}
+# endif
#endif
static ssize_t dd_read(void *ibuf, size_t ibs)
@@ -225,8 +227,10 @@ static ssize_t dd_read(void *ibuf, size_t ibs)
#endif
n = safe_read(ifd, ibuf, ibs);
#if ENABLE_FEATURE_DD_IBS_OBS
+# ifdef O_DIRECT
if (n < 0 && (G.flags & FLAG_IDIRECT) && clear_O_DIRECT(ifd))
goto read_again;
+# endif
#endif
return n;
}
@@ -239,8 +243,10 @@ static bool write_and_stats(const void *buf, size_t len,
size_t obs,
IF_FEATURE_DD_IBS_OBS(write_again:)
n = full_write(ofd, buf, len);
#if ENABLE_FEATURE_DD_IBS_OBS
+# ifdef O_DIRECT
if (n < 0 && (G.flags & FLAG_ODIRECT) && clear_O_DIRECT(ofd))
goto write_again;
+# endif
#endif
#if ENABLE_FEATURE_DD_THIRD_STATUS_LINE
@@ -501,8 +507,13 @@ int dd_main(int argc UNUSED_PARAM, char **argv)
if (infile) {
int iflag = O_RDONLY;
#if ENABLE_FEATURE_DD_IBS_OBS
- if (G.flags & FLAG_IDIRECT)
+ if (G.flags & FLAG_IDIRECT) {
+# ifdef O_DIRECT
iflag |= O_DIRECT;
+# else
+ bb_error_msg_and_die("O_DIRECT not supported on this
platform");
+# endif
+ }
#endif
xmove_fd(xopen(infile, iflag), ifd);
} else {
@@ -516,8 +527,13 @@ int dd_main(int argc UNUSED_PARAM, char **argv)
if (G.flags & FLAG_APPEND)
oflag |= O_APPEND;
#if ENABLE_FEATURE_DD_IBS_OBS
- if (G.flags & FLAG_ODIRECT)
+ if (G.flags & FLAG_ODIRECT) {
+# ifdef O_DIRECT
oflag |= O_DIRECT;
+# else
+ bb_error_msg_and_die("O_DIRECT not supported on this
platform");
+# endif
+ }
#endif
xmove_fd(xopen(outfile, oflag), ofd);
diff --git a/networking/traceroute.c b/networking/traceroute.c
index fb9315db5..760ed6d64 100644
--- a/networking/traceroute.c
+++ b/networking/traceroute.c
@@ -964,8 +964,10 @@ traceroute_init(int op, char **argv)
if (af == AF_INET) {
xmove_fd(xsocket(AF_INET, SOCK_RAW, IPPROTO_ICMP), rcvsock);
#if ENABLE_FEATURE_TRACEROUTE_VERBOSE
+# ifdef IP_PKTINFO
/* want recvmsg to report target local address (for -v) */
setsockopt_1(rcvsock, IPPROTO_IP, IP_PKTINFO);
+# endif
#endif
}
#if ENABLE_TRACEROUTE6
--
2.30.2
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets
Just a bit of context I failed to add.
I'm aware of the previous issues there,
http://lists.busybox.net/pipermail/busybox/2011-February/074954.html
was the reason it was changed from "depends on linux" to "select linux".
It was a wrong thing to do, instead, PLATFORM_LINUX should have been
made a non-user-selectable symbol whith automatic value depending on
the actual platform in question.
This is an attempt to do just that.
Thanks,
/mjt
04.11.2022 19:49, Michael Tokarev wrote:
This effectively reverts the following two commits:
commit e3b1a1fd28558f7a1b3c0ec33313bedb675be8a1
Author: Denys Vlasenko
Date: Sat Feb 26 22:24:08 2011 +0100
Replace "depends on PLATFORM_LINUX" with "select PLATFORM_LINUX"
and
commit 5c69ad0ecdc18cf51b312c7c82848f4438fe1c8d
Author: Ron Yorston
Date: Tue Aug 4 08:24:19 2020 +0100
build system: drop PLATFORM_LINUX
but does, hopefully, the right thing.
Original complain was that the allnoconfig turns off PLATFORM_LINUX
on which all linux-specific applets depends. Instead of setting this
config option right for linux and non-linux (initially it was just a
regular kconfig symbol, not set depending on the platform), it were
turned into something which made little sense (in the first commit),
and later dropped completely.
So introduce a dynamic kconfig symbol PLATFORM_LINUX with the value
actually depending on the target platform, so that it is not affected
by all{yes|no|whatever}config. This way, it is possible to depend on
it for linux-specific applets without breaking *config anymore.
It is done by creating a small kconfig fragment, .platform.in, to
define just PLATFORM_LINUX symbol. It is created in Makefile if
${CPP} has __linux__ #defined. And include it in the top-level Config.in.
Regenerate default config files with the new symbol.
And mark all the applets which were marked as "select PLATFORM_LINUX"
before the "build system: drop PLATFORM_LINUX" commit, as
"depends on PLATFORM_LINUX".
Also mark 2 other applets, tc and dhcprelay, as linux-only too.
This way, it is finally possible to build busybox on other platforms
without really huge efforts to maintain list of "incompatible" applets
externally, and does not put any pressure on the main development, -
the only thing needed is to keep the existing "depends on PLATFORM_LINUX"
lines.
Signed-off-by: Michael Tokarev
---
...
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix non-Linux builds
04.11.2022 19:49, Michael Tokarev wrote: From: Samuel Thibault Some features are Linux-only. And this is what's left from the patch by Samuel sent in October - only the actual source changes. Maybe some bits could be done in a more compact way, with less ifdeffery. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets
07.11.2022 08:25, Kang-Che Sung wrote:
On Sat, Nov 5, 2022 at 12:55 AM Michael Tokarev wrote:
diff --git a/Makefile b/Makefile
+.platform.in:
+ $(Q)printf '#ifndef __linux__\nplatform_is_not_linux\n#endif' \
+ | $(CPP) - | grep -s platform_is_not_linux \
+ && linux=n || linux=y; \
+ printf "config PLATFORM_LINUX\n\tbool\n\tdefault $$linux\n" > $@
What is the reason for preferring #ifndef check rather than #ifdef?
I mean, that would make PLATFORM_LINUX defaults to y if the compiler fails,
and I would expect n in that case.
That's exactly the goal, - to make linux the default, that's the reason
I changed from ifdef linux to ifndef. The idea is to bring as few burden
to the main authors as possible, - if this doesn't work, their favorite
platform wont be affected. See the email I referred to in other message -
http://lists.busybox.net/pipermail/busybox/2011-February/074954.html -
from 11 years ago, - this is when "depends on LINUX" were (mistakenly)
changed to "select LINUX" in the first place, making it effectively
impossible to build busybox on non-linux.
And I'm curious. Does Busybox's kconfig system supports macros as described in
<https://www.kernel.org/doc/html/latest/kbuild/kconfig-macro-language.html> ?
If the system supports macros, we can put this in the Kconfig file and simplify
a lot of things:
config PLATFORM_LINUX
bool
default $(shell, { printf '#ifndef __linux__\n#error \n#endif\n' \
| $(CPP) - -o /dev/null; } >/dev/null 2>&1 && echo y || echo n)
No, - busybox's kconfig is much simpler than that, as far as I can see,
it is a fork off a much earlier kconfig language.
Thanks,
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] build system: fix linking on Red Hat systems
31.12.2022 11:48, Ron Yorston wrote: Commit 77216c368 (Fix non-Linux builds) made linking with libresolv conditional on the output of 'gcc -dumpmachine' containing 'gnu'. This broke builds on Red Hat systems (Fedora, RHEL) and derivatives (CentOS, Rocky). Such systems report a machine type of the form 'x86_64-redhat-linux'. Check for 'linux' as well as 'gnu'. This is - in my opinion - both wrong test to begin with, and a wrong fix. -lresolv is needed when nslookup applet is enabled, because it uses res_XXX functions, - this is regardless of the system, I think. I submitted a patch about this a few months ago. If anything, this can be made a test whenever we actually have and need -lresolv by doing a small compile test. Also, conditionals around linux are also wrong in my opinion, it should check (maybe with dumpmachine, - I used cpp check for __linux__ define instead) if it is being compiled for linux, and disable a bunch of linux-only applets as it has been before 2015 iirc. I also submitted a fix for this a few months back. /mjt Signed-off-by: Ron Yorston --- Makefile.flags | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.flags b/Makefile.flags index 50137a78e..e484ab6c7 100644 --- a/Makefile.flags +++ b/Makefile.flags @@ -186,6 +186,8 @@ endif ifeq ($(CONFIG_FEATURE_NSLOOKUP_BIG),y) ifneq (,$(findstring gnu,$(shell $(CC) $(CFLAGS) -dumpmachine))) LDLIBS += resolv +else ifneq (,$(findstring linux,$(shell $(CC) $(CFLAGS) -dumpmachine))) +LDLIBS += resolv endif endif ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] build system: fix linking on Red Hat systems
31.12.2022 14:23, David Laight wrote: [] You don't need to check whether libresolv is needed just whether it exists. We only need to worry about all this only if nslookup applet is in use (this is already the case in the Makefile), - this is what I mean, if we don't have nslookup we don't have to check for -lresolv. Checking for -lresolv existance is done by trying to link with -lresolv because it can be in different system-specific place which is known by the linker but not by the Makefile. The linker won't (usually) add the NEEDED entry unless the library actually defines some undefined symbols. It is only true when --when-needed is in effect. Historically, for many decades, it werent. I think ubuntu turned it on some years back (maybe when switching from ld to gold), but that's details. FWIW. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets
A friendly ping? This patch still applies and works okay with current 1.36 version. Thanks, /mjt 04.11.2022 19:49, Michael Tokarev wrote: This effectively reverts the following two commits: commit e3b1a1fd28558f7a1b3c0ec33313bedb675be8a1 Author: Denys Vlasenko Date: Sat Feb 26 22:24:08 2011 +0100 Replace "depends on PLATFORM_LINUX" with "select PLATFORM_LINUX" and commit 5c69ad0ecdc18cf51b312c7c82848f4438fe1c8d Author: Ron Yorston Date: Tue Aug 4 08:24:19 2020 +0100 build system: drop PLATFORM_LINUX but does, hopefully, the right thing. … ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets
21.01.2023 19:49, Clément Péron пишет: Hi Michael, On Sat, 21 Jan 2023 at 16:38, Michael Tokarev wrote: A friendly ping? This patch still applies and works okay with current 1.36 version. diff --git a/miscutils/lsscsi.c b/miscutils/lsscsi.c index 8f7eda761..a9d8c3772 100644 --- a/miscutils/lsscsi.c +++ b/miscutils/lsscsi.c @@ -9,6 +9,7 @@ //config:config LSSCSI //config: bool "lsscsi (2.5 kb)" //config: default y +//config: #depends on PLATFORM_LINUX Why is there a '#' here? Should we not drop it? same for lspci.c /lsusb.c These has been there before this PLATFORM_LINUX has been dropped. It is basically a revert of the previous patch (rebased to current version). To me, it looks like it weren't clear if these applets are linux-specific or not, so I decided to keep it this way now, - we'll know it once others will start using this stuff on other platforms. Think of it as a documentation, - when you grep for PLATFORM_LINUX you'll see them. It's trivial to drop these though. Maybe add a small comment in the Makefile about the .platform.in: That might be a good idea indeed. But having in mind the age of this context and the previous attempts to change it, I'd love to have some feedback for the approach itself, before adding cosmetics. I don't like this .platform.in file, - linux-kernel kconfig now has some variables support so things like that does not require temp files, but busybox's kconfig is older, so this hack is the only way to do that which I found. Maybe I'm wrong here. Either way, this change allowed us to build and use busybox on hurd and kfreebsd, finally.. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets
Friendly ping #2.
Is something like this not welcomed at all, or is okay generally but
done in a wrong way, or maybe something else entirely?
The change is relatively large and the code is bit-rotting slowly..
Thanks,
/mjt
04.11.2022 19:49, Michael Tokarev wrote:
This effectively reverts the following two commits:
commit e3b1a1fd28558f7a1b3c0ec33313bedb675be8a1
Author: Denys Vlasenko
Date: Sat Feb 26 22:24:08 2011 +0100
Replace "depends on PLATFORM_LINUX" with "select PLATFORM_LINUX"
and
commit 5c69ad0ecdc18cf51b312c7c82848f4438fe1c8d
Author: Ron Yorston
Date: Tue Aug 4 08:24:19 2020 +0100
build system: drop PLATFORM_LINUX
but does, hopefully, the right thing.
Original complain was that the allnoconfig turns off PLATFORM_LINUX
on which all linux-specific applets depends. Instead of setting this
config option right for linux and non-linux (initially it was just a
regular kconfig symbol, not set depending on the platform), it were
turned into something which made little sense (in the first commit),
and later dropped completely.
So introduce a dynamic kconfig symbol PLATFORM_LINUX with the value
actually depending on the target platform, so that it is not affected
by all{yes|no|whatever}config. This way, it is possible to depend on
it for linux-specific applets without breaking *config anymore.
It is done by creating a small kconfig fragment, .platform.in, to
define just PLATFORM_LINUX symbol. It is created in Makefile if
${CPP} has __linux__ #defined. And include it in the top-level Config.in.
Regenerate default config files with the new symbol.
And mark all the applets which were marked as "select PLATFORM_LINUX"
before the "build system: drop PLATFORM_LINUX" commit, as
"depends on PLATFORM_LINUX".
Also mark 2 other applets, tc and dhcprelay, as linux-only too.
This way, it is finally possible to build busybox on other platforms
without really huge efforts to maintain list of "incompatible" applets
externally, and does not put any pressure on the main development, -
the only thing needed is to keep the existing "depends on PLATFORM_LINUX"
lines.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2] seedrng: fix getrandom() detection for non-glibc libc
26.04.2023 15:09, Raphaël Mélotte пишет:
glibc <= 2.24 does not provide getrandom(). A check for it has been
added in 200a9669fbf6f06894e42439fc11a1a6073a and fixed in
cb57abb46f06f4ede8d9ccbdaac67377fdf416cf.
However, building with a libc other than glibc can lead to the same
problem as not every other libc has getrandom() either:
- uClibc provides it from v1.0.2 onwards, but requires to define
_GNU_SOURCE (all versions - we already define it by default), and
stddef to be included first (when using uClibc < 1.0.35 - we already
include it through libbb.h).
- musl libc has getrandom(), but only from version 1.1.20 onwards. As
musl does not provide __MUSL__ or version information, it's not
possible to check for it like we did for glibc.
All of this makes it difficult (or impossible in case of musl) to
check what we need to do to have getrandom() based on each libc
versions.
On top of that, getrandom() is also not available on older kernels. As
an example, when using a 3.10 kernel with uClibc 1.0.26, getrandom()
is declared so compiling works, but it fails at link time because
getrandom() is not defined.
To make it easier, take a similar approach to what was done for the
crypt library: try to build a sample program to see if we have
getrandom().
Based on the new Makefile variable, we now either use the
libc-provided getrandom() when it's available, or use our own
implementation when it's not (like it was the case already for glibc <
2.25).
This should fix compiling with many libc/kernel combinations.
Signed-off-by: Raphaël Mélotte
---
Changes v1 -> v2:
- move _GNU_SOURCE to bb_libtest.c
- remove GRND_NONBLOCK
Note that I was not able to test every single combination, but I could
confirm it builds successfully for:
uClibc 10.0.24, linux headers 3.10 (libc getrandom NOT used)
uClibc 1.0.36, linux headers 4.9 (libc getrandom used)
musl 1.1.16, linux headers 4.12 (libc getrandom NOT used)
musl 1.2.1, linux headers (libc getrandom used)
glibc 2.25, linux headers 4.10 (libc getrandom used)
Makefile.flags | 7 +++
miscutils/seedrng.c | 8
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Makefile.flags b/Makefile.flags
index 1cec5ba20..ff593748f 100644
--- a/Makefile.flags
+++ b/Makefile.flags
@@ -161,6 +161,13 @@ ifeq ($(RT_AVAILABLE),y)
LDLIBS += rt
endif
+# Not all libc versions have getrandom, so check for it.
+HAVE_GETRANDOM := $(shell printf '#include \n#include \n#define _GNU_SOURCE\nint
main(void){char buf[256];\ngetrandom(buf,sizeof(buf),0);}' >bb_libtest.c; $(CC) $(CFLAGS) $(CFLAGS_busybox) -o
/dev/null bb_libtest.c >/dev/null 2>&1 && echo "y"; rm bb_libtest.c)
What defining _GNU_SOURCE is supposed to do here?
It's a very interesting place to #define it.
It's like doing LFS this way:
#include
#define _FILE_OFFSET_BITS 64
// use 64bit off_t here
It just doesn't work. In both cases, those definitions are checked
within the header files to enable/disable certain functionality.
Such #define does absolutely nothing after #includes.
If anything, you can use -D_GNU_SOURCE=1 on the command line.
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] syslogd: fork after init on a regular system, not before
Current syslogd performs all init after daemonizing, meanwhile
main process exits successfully. This means any errors during init
will not be even shown up because at this time the process has its
stderr redirected to /dev/null already.
On a MMU system, delay daemonizing to after init.
On non-MMU system, keep current code.
Signed-off-by: Michael Tokarev
---
This is a generic problem with many busybox daemons, I think its
root is within the no-MMU system support (where we can't fork).
I think this should be solved in a more generic way too, but this
is just an example of how this can be fixed in principle. The
prob with syslogd is real, any error and it doesn't start but
does not show error messages and reports success, - this is hardly
acceptable behavour.
sysklogd/syslogd.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/sysklogd/syslogd.c b/sysklogd/syslogd.c
index 6ddfd771a..2f9a727cd 100644
--- a/sysklogd/syslogd.c
+++ b/sysklogd/syslogd.c
@@ -1025,7 +1025,6 @@ static void do_syslogd(void)
signal(SIGALRM, do_mark);
alarm(G.markInterval);
#endif
- xmove_fd(create_socket(), STDIN_FILENO);
if (option_mask32 & OPT_circularlog)
ipcsyslog_init();
@@ -1033,6 +1032,16 @@ static void do_syslogd(void)
if (option_mask32 & OPT_kmsg)
kmsg_init();
+ {
+ int fd = create_socket();
+#if BB_MMU
+ if (!(option_mask32 & OPT_nofork)) {
+ bb_daemonize(DAEMON_CHDIR_ROOT);
+ }
+#endif
+ xmove_fd(fd, STDIN_FILENO);
+ }
+
timestamp_and_log_internal("syslogd started: BusyBox v" BB_VER);
write_pidfile_std_path_and_ext("syslogd");
@@ -1179,9 +1188,11 @@ int syslogd_main(int argc UNUSED_PARAM, char **argv)
G.hostname = safe_gethostname();
*strchrnul(G.hostname, '.') = '\0';
+#if !BB_MMU
if (!(opts & OPT_nofork)) {
bb_daemonize_or_rexec(DAEMON_CHDIR_ROOT, argv);
}
+#endif
do_syslogd();
/* return EXIT_SUCCESS; */
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] syslogd: fork after init on a regular system, not before
13.06.2023 17:30, Denys Vlasenko wrote: I think we can delay daemonizing in both cases. Please try current git. Yes, your version is better, it is definitely cleaner, especially after the preparational patch. But does it work for non-MMU case? Or will it just open /dev/log twice and everything will be ok? I'm not sure how important the non-MMU case is these days, to begin with. The prob there is that you open stuff in parent and check for errors, that's okay. But now you repeat the same open again in a new process after exec, and you can only _hope_ things will work the same way one more time, because you just did that a moment before. This is still a bit dirty at least, I think. But "generally" will work. Either way, this version definitely works ok on a regular system with MMU. The same problem exists in klogd as well. Thank you! /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] syslogd: fork after init on a regular system, not before
14.06.2023 23:30, Michael Tokarev пишет:
13.06.2023 17:30, Denys Vlasenko wrote:
I think we can delay daemonizing in both cases.
Please try current git.
Yes, your version is better, it is definitely cleaner, especially
after the preparational patch.
But does it work for non-MMU case?
Or will it just open /dev/log twice and everything will be ok?
Actually it doesn't work on regular system too, the fd#0 is redirected
from /dev/null somewhere down the line and enters a tight loop:
44138 readlink("/dev/log", "/run/systemd/journal/dev-log", 80) = 28
44138 readlink("/run/systemd/journal/dev-log", 0x5611c6c26ee0, 80) = -1 EINVAL
(Invalid argument)
44138 unlink("/run/systemd/journal/dev-log") = 0
44138 socket(AF_UNIX, SOCK_DGRAM, 0)= 3
44138 bind(3, {sa_family=AF_UNIX, sun_path="/run/systemd/journal/dev-log"},
110) = 0
44138 chmod("/dev/log", 0666) = 0
44138 dup2(3, 0)= 0
44138 close(3) = 0
44138 chdir("/")= 0
44138 openat(AT_FDCWD, "/dev/null", O_RDWR) = 3
44138 clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fb6bc72fa10) = 44139
44138 exit_group(0) = ?
44138 +++ exited with 0 +++
44139 set_robust_list(0x7fb6bc72fa20, 24) = 0
44139 setsid() = 44139
44139 dup2(3, 0)= 0
44139 dup2(3, 1)= 1
44139 dup2(3, 2)= 2
44139 close(3) = 0
It is done in bb_daemonize_or_rexec(). Which, it seems,
can be optimized too, to avoid duplicate dup(0,1,2) case.
This is why I used extra variable 'int fd = .. xmove_fd(fd)'.
(btw, should it chmod the result of readlink, not /dev/log? - probably doesn't
matter).
Thanks,
/mjt
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] syslogd: fork after init on a regular system, not before
14.06.2023 23:52, Michael Tokarev wrote:
Actually it doesn't work on regular system too, the fd#0 is redirected
from /dev/null somewhere down the line and enters a tight loop
Attached is the fix. Not touching daemonize_or_reexec().
Signed-off-by: Michael Tokarev
--- busybox.orig/sysklogd/syslogd.c
+++ busybox/sysklogd/syslogd.c
@@ -1009,6 +1009,7 @@ static int try_to_resolve_remote(remoteH
static int NOINLINE syslogd_init(char **argv)
{
int opts;
+ int fd;
char OPTION_DECL;
#if ENABLE_FEATURE_REMOTE_LOG
llist_t *remoteAddrList = NULL;
@@ -1056,7 +1057,7 @@ static int NOINLINE syslogd_init(char **
G.hostname = safe_gethostname();
*strchrnul(G.hostname, '.') = '\0';
- xmove_fd(create_socket(), STDIN_FILENO);
+ fd = create_socket();
if (opts & OPT_circularlog)
ipcsyslog_init();
@@ -1068,6 +1069,8 @@ static int NOINLINE syslogd_init(char **
bb_daemonize_or_rexec(DAEMON_CHDIR_ROOT, argv);
}
+ xmove_fd(fd, STDIN_FILENO);
+
/* Set up signal handlers (so that they interrupt read()) */
signal_no_SA_RESTART_empty_mask(SIGTERM, record_signo);
signal_no_SA_RESTART_empty_mask(SIGINT, record_signo);
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] syslogd: fork after init on a regular system, not before
14.06.2023 23:58, Michael Tokarev wrote: 14.06.2023 23:52, Michael Tokarev wrote: Actually it doesn't work on regular system too, the fd#0 is redirected from /dev/null somewhere down the line and enters a tight loop Attached is the fix. Not touching daemonize_or_reexec(). Signed-off-by: Michael Tokarev Ping? syslogd is completely broken in master now. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] udhcpd: Per-client boot_file
25.06.2023 02:23, Adam Goldman wrote: This patch adds the ability to specify a different boot_file for each client. This is useful if clients have different CPU architectures or if some clients are legacy BIOS and some are EFI. It adds a config file option of the form "for xx:xx:xx:xx:xx:xx boot_file foo" which sets the boot_file to "foo" for the client with the MAC address xx:xx:xx:xx:xx:xx. If no such line exists, the global boot_file will be used. The syntax of the option is intended so that in the future, per-client options other than boot_file could be added. I don't think this scales. Instead of per-client, it needs to be per group of clients based on some criteria (such as CPU architecture). See for example how dnsmasq does this (and maybe it is better suited for your usage). /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: syslogd problem
20.09.2023 18:16, Jeff Pohlmeyer wrote: It seems that local logging with syslogd is no longer working for me. I think commit 02378ce20c6d2df062357b6d60fc440609d203be (syslogd: decrease stack usage, ~50 bytes) has broken something. It's been broken for quite some time http://lists.busybox.net/pipermail/busybox/2023-June/090363.html /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] syslogd: fork after init on a regular system, not before
03.10.2023 20:16, Denys Vlasenko: Pushed to git, thank you. Thank you for that. There's one more issue in there with remote logging, see this message for the patch: http://lists.busybox.net/pipermail/busybox/2023-September/090499.html /mjt On Sun, Jun 18, 2023 at 9:24 AM Michael Tokarev wrote: 14.06.2023 23:58, Michael Tokarev wrote: 14.06.2023 23:52, Michael Tokarev wrote: Actually it doesn't work on regular system too, the fd#0 is redirected from /dev/null somewhere down the line and enters a tight loop Attached is the fix. Not touching daemonize_or_reexec(). Signed-off-by: Michael Tokarev Ping? syslogd is completely broken in master now. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets
Another ping 1.5 hours later? Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: syslogd problem
21.09.2023 15:10, Jeff Pohlmeyer : On Wed, Sep 20, 2023 at 11:54 AM Michael Tokarev wrote: It's been broken for quite some time Thanks, I didn't know about that one. These are actually two different problems, your "read() not blocking" fix, and my "OPT_locallog not in opts" fix. After applying both fixes I was finally able to get syslogd working from my init script. Sure hope these can make it into master soon! Ping? This fix hasn'f found its way to busybos, it seems.. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Spelling: recevied, delimeter
--- a/coreutils/cut.c +++ b/coreutils/cut.c @@ -33,8 +33,8 @@ //usage: "\n -b LIST Output only bytes from LIST" //usage: "\n -c LIST Output only characters from LIST" //usage: "\n -d SEP Field delimiter for input (default -f TAB, -F run of whitespace)" -//usage: "\n -O SEP Field delimeter for output (default = -d for -f, one space for -F)" -//usage: "\n -D Don't sort/collate sections or match -fF lines without delimeter" +//usage: "\n -O SEP Field delimiter for output (default = -d for -f, one space for -F)" +//usage: "\n -D Don't sort/collate sections or match -fF lines without delimiter" //usage: "\n -f LIST Print only these fields (-d is single char)" //usage: IF_FEATURE_CUT_REGEX( //usage: "\n -F LIST Print only these fields (-d is regex)" ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v1] seedrng.c: fix clock_gettime support for older kernels and glibc combinations
19.01.2024 16:30, Thomas Devoogdt : CLOCK_BOOTTIME has been added in Linux >= 2.6.39, so fallback to CLOCK_MONOTONIC on older kernels. Also, ensure proper compilation with older glibc versions. Why do you care about such old kernels? To me, it would be better to clean up such old fallbacks, remove support for, say, kernels <3.x or <4.x (like, for example, modutils compatibility can be removed entirely), instead of adding new fallbacks.. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: networking: compilation error on ubuntu 24
13.07.2024 17:50, Denys Vlasenko wrote: Your headers are not new enough for tc applet. Disable CONFIG_TC, or install newer headers. It isn't "new enough", it is "too new". This part has been removed from 6.9 kernel. FWIW. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
interesting segfault when running awk as pid==1
Hello.
I've an "interesting" case here, when busybox (in debian)
segfaults when run in initramfs as pid == 1, when invoking
awk applet (PREFER_APPLETS is set to yes). I can't trigger
it with pid != 1, and since pid=1 is special in linux,
I can't really debug it too.
To complicate things further, it looks like reverting a
trivial debian-only patch fixes this issue, but I suspect
it fixes only the symptom, not the actual cause of the
problem.
The debian-specific patch in question is this (one-liner):
shell/ash.c:
- { VSTRFIXED|VTEXTFIXED , bb_PATH_root_path, changepath },
+ { VSTRFIXED|VTEXTFIXED|VEXPORT, bb_PATH_root_path, changepath },
so it merely exports PATH variable, and should not affect
the behavour in question, but I'm not sure anymore about
this. It looks rather innocent.
Anyway. The problem is that, from within initramfs, from
/init script which gets executed as pid==1, run by busybox's
sh with PREFER_APPLETS=y, any attempt to execute "awk"
results in a segfault. Only this way -- "awk", not "/bin/awk"
or "busybox awk". No arguments are necessary.
When I put the call into a separate .sh file and exec it,
it will succeed. If I'll source this .sh file from within
/init, it will segfault.
The corresponding debian bugreport is http://bugs.debian.org/679377
I weren't able to trigger the issue using other NOFORK
applets, only awk so far shows this problem.
I understand the problem happens only with debian-specific
patch (which I wanted to get rid of anyway), but it might
be some more deep issue. And I'm asking for some help with
debugging this, since I don't have enough knowlege about
the busybox internals. Does it even make any sense at all?
Thanks!
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: interesting segfault when running awk as pid==1
On 06.07.2012 04:10, ra...@gmx.de wrote: > Hi Michael ! > >> I've an "interesting" case here, when busybox (in debian) >> segfaults when run in initramfs as pid == 1, when invoking >> awk applet (PREFER_APPLETS is set to yes). I can't trigger >> it with pid != 1, and since pid=1 is special in linux, >> I can't really debug it too. > > I hit this problem some years ago. May be same reason. Try running awk > via env command and setup some environment variables. pid 1 is special > as environment on invocation may be empty (or something missing, most > likely SHELL or PATH). As I stated in my initial email, when running awk from a subshell it works. I know PID=1 is special, and for one, it can't be straced or debugged. PATH isn't empty since busybox ash sets it to some value, but PATH at least _should_ be irrelevant, since awk is NOEXEC applet. And finally, it isn't a solution to run it from a subshell, since running awk from within /init in initramfs is a valid usage case. Thanks for trying, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: interesting segfault when running awk as pid==1
On 06.07.2012 15:03, Laurent Bercot wrote:
>> As I stated in my initial email, when running awk from a subshell
>> it works. I know PID=1 is special, and for one, it can't be straced
>> or debugged.
>
> Actually, on some Linux versions (I'm not certain which ones though,
> but it should work on modern kernels), process 1 *can* be straced:
> somehow get a shell running and do "strace -p 1". If you're not afraid
> of dirty hacks, you could even run that from your /init, if everything
> is properly mounted:
> ( strace -p 1 /dev/null 2>/tmp/strace-file ) &
> or even replace /tmp/strace-file with /dev/tty for a live performance.
I tried this right away, but failed: strace does not show anything
at all in that case, even if the process 1 actually does something.
No, I'm not afraid at all, since it is trivial to experiment in
a virtual machine.
And I don't think strace will do anything interesting here: I
looked at what happens when busybox ash spawns awk in a regular
case, there, it just forks (with a pipe open) and does one or
two read/writes -- it is ofcourse not enough information to
understand what's going on. It may help a bit ofcourse, if
I'll add a few debug printfs here and there.
Ideally it'd be nice to get a coredump, but for some reason
the process being fork'ed in this context isn't dumpable.
>> And finally, it isn't a solution to run it from a subshell,
>> since running awk from within /init in initramfs is a valid usage
>> case.
>
> But are you really running awk as process 1 ?
> I doubt your /init script is *executing* awk. If it was, then after
> performing its work, awk would die, and your kernel would panic.
> I suspect that instead, your /init script looks like
>
> #!/bin/sh
> ...
> awk something
> ...
> exec chroot foobar /sbin/init
>
> in which case you are *not* running awk as process 1: your shell is
> forking first, then executing awk as a child. The question then becomes,
> why is there a problem when awk is run directly as process 1's child.
Well. My $subject is inaccurate. I meant to say when awk is
spawned from pid=1 as NOEXEC applet. The code like
rootfs=`awk '$2=="/"{print $1}`
or anything of this theme. This works:
rootfs=`/bin/awk '$2=="/"{print $1}`
rootfs=`busybox awk '$2=="/"{print $1}`
and this
rootfs=`awk '$2=="/"{print $1}`
segfaults, just like a bare 'awk' call:
awk
(in normal case it produces an error message
about invalid usage).
Thank you!
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: interesting segfault when running awk as pid==1
On 07.07.2012 23:33, Denys Vlasenko wrote:
[]
>>> The debian-specific patch in question is this (one-liner):
>>>
>>> shell/ash.c:
>>> - { VSTRFIXED|VTEXTFIXED , bb_PATH_root_path, changepath },
>>> + { VSTRFIXED|VTEXTFIXED|VEXPORT, bb_PATH_root_path, changepath },
>>>
>>> so it merely exports PATH variable, and should not affect
>>> the behavour in question, but I'm not sure anymore about
>>> this. It looks rather innocent.
>>
>> Apparently, it makes it so that ash exports $PATH.
>> If $PATH was in the set of inherited variables,
>> then it is reused, and this apparently works.
>> But in init, $PATH may be _not_ inherited.
>> So ash sets its own $PATH (I just tested it):
>>
>> PATH=/sbin:/usr/sbin:/bin:/usr/bin
>>
>> Basically, these two scenarios are not exactly the same.
>>
>> Try reproducing segfault by running ahs with empty environment:
>>
>> env - /path/to/busybox ash
>>
>> Does it segfault if you run awk from it?
>
> Reproduced.
>
> if (environ) for (envp = environ; *envp; envp++) {
> /* environ is writable, thus we don't strdup it needlessly */
> char *s = *envp;
> char *s1 = strchr(s, '=');
> if (s1) {
> *s1 = '\0';
>
> It happens in the above line.
>
> Caused by: ash.c:
>
> static void
> tryexec(IF_FEATURE_SH_STANDALONE(int applet_no,) char *cmd, char
> **argv, char **envp)
> {
> #if ENABLE_FEATURE_SH_STANDALONE
> if (applet_no >= 0) {
> if (APPLET_IS_NOEXEC(applet_no)) {
> clearenv();
> while (*envp)
> putenv(*envp++);
> ^^
> run_applet_no_and_exit(applet_no, argv);
> }
> /* re-exec ourselves with the new arguments */
> execve(bb_busybox_exec_path, argv, envp);
> /* If they called chroot or otherwise made the binary no
> longer
> * executable, fall through */
> }
> #endif
>
> Basically, we putenv() a string which is constant,
> and when we try to modify it, we segfault.
Thank you Denys, thank you very much for figuring it out.
I was about to add printfs here and there, planned to do
that today evening.
> I think Debian's patch does something which is not supported.
Funny you mention it. The thing is: with the patch,
there's just ONE variable marked as VEXPORT, and no
variable is marked as such without the patch.
So I'm not surprized it doesn't work.
Looking at the other places, everywhere where VEXPORT
flag is used, the variable in question is dynamically
allocated. So setting this flag for initial value is
indeed not supported -- maybe it is a good idea to
document this fact in the code.
Now, for the root issue -- exporting $PATH from [a]sh --
I inherited this patch together with busybox debian
package, and am now trying to understand where it
comes from and for what. I'll drop it from the next
Debian release (wheezy+1), since neither bash nor
dash exports $PATH by default. But for now, I'll
have to change the way stdpath is set up, to allow
VEXPORT to work correctly.
Thank you very much for finding the root of the issue!
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] include/libbb.h: declare messages with ALIGN1
On 16.07.2012 12:56, Aurelien Jarno wrote: > Some messages strings are defined with ALIGN1 in libbb/messages.c > to make sure strings are not aligned and thus to save some bytes. The > corresponding declaration in include/libbb.h should also use ALIGN1, > otherwise the compiler may assume they are aligned and generate wrong > code to access them. This is the case on at least s390x. > > Signed-off-by: Aurelien Jarno > --- > include/libbb.h | 36 ++-- > 1 file changed, 18 insertions(+), 18 deletions(-) > > diff --git a/include/libbb.h b/include/libbb.h > index 322a28c..f22e58e 100644 > --- a/include/libbb.h > +++ b/include/libbb.h > @@ -1612,8 +1612,8 @@ unsigned get_cpu_count(void) FAST_FUNC; > char *percent_decode_in_place(char *str, int strict) FAST_FUNC; > > > -extern const char bb_uuenc_tbl_base64[]; > -extern const char bb_uuenc_tbl_std[]; > +extern const char bb_uuenc_tbl_base64[] ALIGN1; > +extern const char bb_uuenc_tbl_std[] ALIGN1; I wonder whenever changing all these from arrays to pointers is a good idea? Compiler should not assume any alignments about pointer to char, unlike an array, I think. I mean, -extern const char bb_uuenc_tbl_base64[]; +extern const char *bb_uuenc_tbl_base64; Besides, this, and a few others (bb_hexdigits_upcase), might be better without alignment. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
udhcpd: write leases on exit?
Why udhcpd does not write leases file upon
receipt of termination signal? Here's the
code in question (networking/udhcp/udhcpd.c):
switch (udhcp_sp_read(&rfds)) {
case SIGUSR1:
bb_info_msg("Received SIGUSR1");
write_leases();
/* why not just reset the timeout, eh */
timeout_end = monotonic_sec() + server_config.auto_time;
continue;
case SIGTERM:
bb_info_msg("Received SIGTERM");
goto ret0;
case 0: /* no signal: read a packet */
break;
default: /* signal or error (probably EINTR): back to select */
continue;
}
I think there should be a call to write_leases()
right after "Received SIGTERM" message, just like
it is done in SIGUSR1 case?
Ofcourse this makes little sense when UDHCPD_WRITE_LEASES_EARLY
feature is set, but when it does not, there might be quite
several "uncomitted" leases (7200 seconds (by default) is
quite alot).
Thanks,
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
declare more strings with ALIGN1
As with messages in libbb/messages.c and their declarations
in include/libbb.h, there are a few other places where
ALIGN1 (force no alignment) is used in definition but not
in declaration, which leads to miscompiles. Fix these
too.
--- a/include/busybox.h
+++ b/include/busybox.h
@@ -13,10 +13,10 @@ PUSH_AND_SET_FUNCTION_VISIBILITY_TO_HIDD
/* Defined in appletlib.c (by including generated applet_tables.h) */
/* Keep in sync with applets/applet_tables.c! */
-extern const char applet_names[];
+extern const char applet_names[] ALIGN1;
extern int (*const applet_main[])(int argc, char **argv);
extern const uint16_t applet_nameofs[];
-extern const uint8_t applet_install_loc[];
+extern const uint8_t applet_install_loc[] ALIGN1;
#if ENABLE_FEATURE_SUID || ENABLE_FEATURE_PREFER_APPLETS
# define APPLET_NAME(i) (applet_names + (applet_nameofs[i] & 0x0fff))
--- a/networking/udhcp/common.h
+++ b/networking/udhcp/common.h
@@ -187,8 +187,8 @@ struct option_set {
};
extern const struct dhcp_optflag dhcp_optflags[];
-extern const char dhcp_option_strings[];
-extern const uint8_t dhcp_option_lengths[];
+extern const char dhcp_option_strings[] ALIGN1;
+extern const uint8_t dhcp_option_lengths[] ALIGN1;
unsigned FAST_FUNC udhcp_option_idx(const char *name);
--- a/shell/shell_common.h
+++ b/shell/shell_common.h
@@ -21,7 +21,7 @@
PUSH_AND_SET_FUNCTION_VISIBILITY_TO_HIDDEN
-extern const char defifsvar[]; /* "IFS= \t\n" */
+extern const char defifsvar[] ALIGN1; /* "IFS= \t\n" */
#define defifs (defifsvar + 4)
int FAST_FUNC is_well_formed_var_name(const char *s, char terminator);
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: declare more strings with ALIGN1
On 19.07.2012 13:59, Sedat Dilek wrote: > Can you label your patches, please? > Like this: > > "busybox.h: declare more strings with ALIGN1" The patch touches 3 files. Should I list them all? Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: declare more strings with ALIGN1
On 24.07.2012 17:57, Denys Vlasenko wrote: > On Thu, Jul 19, 2012 at 11:56 AM, Michael Tokarev wrote: >> As with messages in libbb/messages.c and their declarations >> in include/libbb.h, there are a few other places where >> ALIGN1 (force no alignment) is used in definition but not >> in declaration, which leads to miscompiles. Fix these >> too. > > Applied, thanks! There are a few other cases like this. For example, ALIGN2 is also used in definitions but not declarations. I'm not sure it all is worth fixing - to my taste this whole construct is just too fragile, and having in mind gcc does not tell us the difference (it must, IMHO), it makes even more fragile. In debian we fixed it by #defining ALIGN* to be empty on s390(x). /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 2/3] remove unused variable opts
31.07.2012 17:15, manuel.f.zerp...@ww.stud.uni-erlangen.de wrote: > From: Manuel Zerpies > > The variable "unsigned opts" is not used. Saves an unnecessary call to > getopt32(). > > Signed-off-by: Manuel Zerpies > --- > miscutils/flashcp.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/miscutils/flashcp.c b/miscutils/flashcp.c > index 790f9c0..47d1189 100644 > --- a/miscutils/flashcp.c > +++ b/miscutils/flashcp.c > @@ -50,7 +50,6 @@ int flashcp_main(int argc UNUSED_PARAM, char **argv) > int fd_f, fd_d; /* input file and mtd device file descriptors */ > int i; > uoff_t erase_count; > - unsigned opts; > struct mtd_info_user mtd; > struct erase_info_user e; > struct stat statb; > @@ -59,7 +58,6 @@ int flashcp_main(int argc UNUSED_PARAM, char **argv) > RESERVE_CONFIG_UBUFFER(buf2, BUFSIZE); > > opt_complementary = "=2"; /* exactly 2 non-option args: file, dev */ > - opts = getopt32(argv, "v"); Before the change, the command accepted but ignored -v option, (maybe) handled --help, rejected (with error message) all other options, and required exactly 2 non-option arguments. All this is now gone. I'm not sure at all this is right change. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 1/3] fix literal error warning
31.07.2012 17:15, manuel.f.zerp...@ww.stud.uni-erlangen.de wrote:
> From: Manuel Zerpies
>
> compiling with gcc >= 4.4.3 the warning "format not a string literal
> and no format arguments" is thrown. This patch fixes that.
>
[]
> index 0b1c4aa..a67e8b4 100644
> --- a/applets/usage_pod.c
> +++ b/applets/usage_pod.c
> @@ -71,7 +71,7 @@ int main(void)
> } else {
> printf(", ");
> }
> - printf(usage_array[i].aname);
> + printf("%s", usage_array[i].aname);
This can be replaced with fputs().
> col += len2;
> }
> printf("\n\n");
(and this too).
> diff --git a/archival/libarchive/data_extract_to_command.c
> b/archival/libarchive/data_extract_to_command.c
> index a2ce33b..354e958 100644
> --- a/archival/libarchive/data_extract_to_command.c
> +++ b/archival/libarchive/data_extract_to_command.c
> @@ -38,7 +38,7 @@ static const char *const tar_var[] = {
> static void xputenv(char *str)
> {
> if (putenv(str))
> - bb_error_msg_and_die(bb_msg_memory_exhausted);
> + bb_error_msg_and_die("%s", bb_msg_memory_exhausted);
And this, and many other similar warnings, are just silly.
Yes, gcc can't verify the format string, but it is declared
as constant for a reason. These changes (all around bb_msg_*)
are just adding code without fixing anything. In my opinion,
gcc should be fixed instead, to at least treat const char[]
fmt string as non-dangerous.
> diff --git a/libbb/dump.c b/libbb/dump.c
> index 7e43564..91efe41 100644
> --- a/libbb/dump.c
> +++ b/libbb/dump.c
> @@ -613,7 +613,7 @@ static void display(priv_dumper_t* dumper)
> printf(pr->fmt, (char
> *) bp);
> break;
> case F_TEXT:
> - printf(pr->fmt);
> + printf("%s", pr->fmt);
If you "fixed" this, how about fixing the one right above it too (shown),
and all the rest? There's no reason to fix only one of them, and other
cases can't be fixed easily.
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: declare more strings with ALIGN1
06.08.2012 15:50, Denys Vlasenko wrote: > > So, can you please tell me what "!defined(arch)" statements you used > to exclude s390[x]? It is just __s390__, which covers both: http://anonscm.debian.org/gitweb/?p=d-i/busybox.git;a=blob;f=debian/patches/dont-force-no-alignment-for-s390.patch;h=35202a786b97bca689e241a6674443821ef2776e Thanks! /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
On 11.08.2012 14:03, Harald Becker wrote: > Hi Walter ! > >> perhaps you can create a busybox with awk only ? > > That wont't help. If Busybox awk is called direct or via symlink it > works correct. The problem arrise with the standalone/preferred applet > feature. Which I really want to work, as Busybox sit on a System with > most GNU utilities installed. I can't add symlinks to Busybox for every > applet as this would overwrite the installed utilities. Despite those > installed utilities I like to use Busybox for shell scripts. Those > scripts shall use the Busybox applets, not the installed GNU utilities. PATH=/busybox:$PATH ./busybox.shell.script where /busybox contains (sym)links for all busybox applets. Just a data point, not anything to add about the bug in question. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in mountpoint applet?
14.08.2012 16:33, Harald Becker wrote: > Hi all, > > looks like there is a bug in Busybox mountpoint: > > $ mkdir m r > $ mount -obind m r > $ touch m/a touch m/b > $ ls m/ > a b > $ ls r/ > a b > $ mountpoint r > r is a mountpoint > $ busybox mountpoint > r is not a mountpoint !!! > > Looks that Busybox mountpoint ignore via bind mounted directories and > illegally report them as not being a mounted point. Did not dig into > source, just detected that bug. If you can detect such a mountpoint somehow, without resorting to parsing /proc/mounts, please let the world know. Usual trick to detect a mountpoint is to stat(2) the directory in question and the parent directory of it, and compare st_rdev fields of the two (see man 2 stat). If they differ, it is a mountpoint, if they're the same, it is not. When you bind-mount one directory into another in the same system, both will have the same st_rdev. So there's no known way to detect such mountpoints, and parsing /proc/mounts is at least slow and unreliable. Note: you can also bind-mount a single _file_, not a directory. This has the same issue. This is a kernel interface problem, and is known since the day bind mounts were introduced in 2.4 kernel. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in mountpoint applet?
On 14.08.2012 22:54, Harald Becker wrote: [] > My request is, to have Busybox mountpoint give at least same result as > upstream ... not more, but not less! > ... so just see how GNU mountpoint does the check (can't do it > currently here on my absolutely overloaded notebook, hacking on this > to get away from this situation). Which GNU mountpoint utility (aka "upstream") you're talking about? On my (debian) system, /bin/mountpoint comes from sysvinit package, it is written by Miquel van Smoorenburg, and it has exactly the same problem with bind mounts. I'm interested to know which "GNU" mountpoint utility you're talking about. As for "reliability", /proc/self/mounts (or /proc/self/mountinfo which is exactly of the same nature in this context) may have complex structure describing complex structure of mounts on the sytem, when you can have nested cross-mounts - so the utility will have to build whole tree (or graph) of mounts to understand this structure. Also, again due to this same bind mounts, or (sym)links, or due to mount --move or something else, the path given to `mountpoint' utility might be not the same path recorded in /proc/mounts (or mountinfo - again, does not matter), it might be some alternative path leading to the same directory. So our great mountpoint utility will need to very carefully canonicalize the given argument first, before looking it up in mounts (or mountinfo), and there is no single way to canonicalize a given path generally. So parsing mounts (or mountinfo) is inherently unreliable, even after somehow overcoming the problem with special characters in pathnames. We should have some much more reliable interface here, and kernel does not provide it. So any utility which tries to detect such bind mounts is broken in one or another way. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in mountpoint applet?
On 15.08.2012 10:12, Michael Tokarev wrote: > > $ mkdir /tmp/test > $ cd /tmp/test > $ mkdir -p a/b > $ mount -t tmpfs tmpfsb a/b > # here, a/b is a mountpont obvously. Now, we mount another dir over > everything: > $ mount -t tmpfs tmpfsa a > $ mkdir a/b > # here, a/b is a plain directory in upper tmpfsa which covers tmpfsb, > # it is NOT a mountpoint. Yet, > $ util-linux-mountpoint a/b > a/b is a mountpoint > > But the traditional mountpoint utility (from sysvinit) correctly > says it is a mountpoint. correctly says it is NOT a mountpoint, ofcourse. Sorry typo. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in mountpoint applet?
On 15.08.2012 05:58, Harald Becker wrote: [] > The util linux version has the device node compare as a fallback > method. So why not have a global config option to enable the usage > of /mnt/self/mountinfo ... for those who neglect to use such kind of > interfaces. As I mentioned already, this method is still unreliable. util-linux mountpoint utility tries hard to find the thing, but it fails. For example: $ mkdir /tmp/test $ cd /tmp/test $ mkdir -p a/b $ mount -t tmpfs tmpfsb a/b # here, a/b is a mountpont obvously. Now, we mount another dir over everything: $ mount -t tmpfs tmpfsa a $ mkdir a/b # here, a/b is a plain directory in upper tmpfsa which covers tmpfsb, # it is NOT a mountpoint. Yet, $ util-linux-mountpoint a/b a/b is a mountpoint But the traditional mountpoint utility (from sysvinit) correctly says it is a mountpoint. Note: there's no bind-mount tricks. It is just unreliable to parse /proc/mounts (or mountinfo) -- exactly the thing I referred to initially. It is not about funky names, it is only about a bit more complex mount structure. It's too easy to trick it to believe in different things. And once you add some mount --move or bind- mounts into the mix, things becomes even more interesting. It is a) unreliable (and hence buggy as I just demonstrated), b) has a lot of code (busybox is about small size), relies on /proc to be mounted (traditional mountpoint applet does not, and it is perfectly okay for a chroot or another kind of system to work without /proc). It is not a solution. > Do we really need to have lengthy discussions about ugly things and > unreliable interfaces when the question is something completely > different? IMO no, so please let us concentrate about the main questions > (report bind mount points and being compatible to util-linux). Thx. My first reply to you was: "if you find a way to detect a mount point WITHOUT RESORTING TO PARSING /PROC/MOUNTS, please tell us and save the world." Until such a method is found, there's no point discussing various buggy hacks. Sorry. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
busybox@busybox.net
On 03.09.2012 20:40, Rich Felker wrote: > On Mon, Sep 03, 2012 at 12:58:37PM +0200, Denys Vlasenko wrote: >> On Sun, Sep 2, 2012 at 11:21 PM, Rich Felker wrote: >>> It seems busybox ash is misinterpreting "&>" as having some special >>> meaning rather than being a "&" token followed by a ">" token. I've >>> filed a bug report: >>> >>> https://bugs.busybox.net/show_bug.cgi?id=5498 >> >> Set CONFIG_ASH_BASH_COMPAT to "no" and it will stop doing that. > > Indeed I tested and this fixes the problem. But all the other reasons > to turn CONFIG_ASH_BASH_COMPAT off just seem to be minimizing binary > size; I couldn't find any other extensions that conflict the > interpreting of standards-conforming shell programs. As far as I can see, this token -- "&>" -- has never been standard. If you mean background and redirection, you must separate the two with whitespace. In that case it will be both standards-conforming AND easier to read. Without some space in between, it is a grey area at best. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [vamos-dev] [PATCH 1/3] fix literal error warning
On 10.09.2012 19:31, Manuel Zerpies wrote:
> Hey guys,
>
> what about this patch? Is there anyone who can have a look at it?
>
[]
>> -bb_perror_msg(filename);
>> +bb_perror_msg("%s", filename);
Please stop fixing a non-issue. This GCC warning is wrong.
This has been discussed several times, and exactly the same
patch has been proposed several times too.
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [vamos-dev] [PATCH 1/3] fix literal error warning
On 10.09.2012 20:36, Michael Conrad wrote:
> On 9/10/2012 11:46 AM, Michael Tokarev wrote:
[]
>>>> -bb_perror_msg(filename);
>>>> +bb_perror_msg("%s", filename);
>> Please stop fixing a non-issue. This GCC warning is wrong.
>> This has been discussed several times, and exactly the same
>> patch has been proposed several times too.
>
> Actually, that half of his patch *is* legitimate. It's a bug.
>
Oh. Yeah. there's one place which were identified in one of
the previous patches which tried to address this problem.
Please excuse me for not looking close enough and for making
premature and harsh comments. I was very angry this morning
due to unrelated issues, I shouldn't reply to emails in that
bad mood.
I stand corrected. And indeed, this patch looks right.
Thank you!
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 19/19] scripts/kconfig/mconf: fix build error on Mac OS X
On 25.09.2012 16:06, Florian Fainelli wrote: > From: Felix Fietkau > > SIGWINCH is not defined for this platform, provide a definition of it if > needed. > > Signed-off-by: Felix Fietkau > --- > scripts/kconfig/mconf.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c > index 1b0b6ab..84d7662 100644 > --- a/scripts/kconfig/mconf.c > +++ b/scripts/kconfig/mconf.c > @@ -27,6 +27,10 @@ > #include > #include > > +#ifndef SIGWINCH > +#define SIGWINCH 28 > +#endif Isn't it better to #ifdef the relevant code instead of defining something which will never be used or may even clash with some other signal? /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 04/19] trylink: fix linking when /bin/sh is not bash
On 25.09.2012 16:06, Florian Fainelli wrote: > From: Nicolas Thill > > See https://dev.openwrt.org/ticket/1115 for background on this issue. > > Signed-off-by: Nicolas Thill > --- > scripts/trylink |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/trylink b/scripts/trylink > index a8b0b2e..ddada7a 100755 > --- a/scripts/trylink > +++ b/scripts/trylink > @@ -1,4 +1,4 @@ > -#!/bin/sh > +#!/usr/bin/env bash I think it's better to fix the script itself than to require bash. Just IMHO anyway. BTW, on my dash (0.5.7) it appears to work fine. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: memory usage increases with redirection on loop
On 10.10.2012 12:56, walter harms wrote: > Am 09.10.2012 23:08, schrieb Jon Tollefson: >> I have an ash script that I have stripped down to its simplest form >> below that still exhibits the behavior. While the script is running >> under busybox I look at 'top' output in another window and see the RES >> column for busybox slowly increasing. The testing I have been doing is >> under Linux. >> >> If I remove the redirection after the 'done' then it doesn't show this >> memory increase. Or if I move it to the front of the while such as "cat >> /dev/null | while true" then it also doesn't show the memory usage >> increasing. Still it seems the case below shouldn't be increasing >> memory usage either. >> >> Jon >> >> >> while true >> do >> while true >> do >> break; >> done> done >> > > hi Jon, > to reproduce that we need a .config and a version number for busybox. This happens on a current 1.20.2 version, I just reproduced it locally. There's apparently no memory leaks, but valgrind is helpful still: ==20170== 4,883,404 bytes in 9,613 blocks are still reachable in loss record 15 of 15 ==20170==at 0x48CF308: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20170==by 0x804EE8B: xmalloc (xfuncs_printf.c:47) ==20170==by 0x806EC96: stalloc (ash.c:1417) ==20170==by 0x806ED00: stzalloc (ash.c:1434) ==20170==by 0x8071A22: expandarg (ash.c:7271) ==20170==by 0x8071ADE: expredir (ash.c:8666) ==20170==by 0x8073455: evaltree (ash.c:8401) ==20170==by 0x80744D2: evalloop (ash.c:8534) ==20170==by 0x8073546: evaltree (ash.c:8454) ==20170==by 0x8074916: cmdloop (ash.c:12185) ==20170==by 0x80761ED: ash_main (ash.c:13224) ==20170==by 0x804E143: run_applet_no_and_exit (appletlib.c:755) This is after a few seconds of execution. With more execution time, this number of blocks increases rapidly, and so is the process memory size. Without redirection this piece is not growing. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] udhcpc: allow trailing dot in names
Commit 7280d2017d8075267a12e469983e38277dcf0374 (fix for #3979, which is CVE-2011-0997) added sanitization of some strings returned from DHCP server. And one of the things it now disallows is a trailing dot, for, for example, domain names like "host.example.com." -- this is now treated as invalid. However, apparently, some installations use this sort of names, and especially, other implementations (ISC DHCP client for example) allows such trailing dots too. It is arguable corner case - for example, it is unknown how much 3rd party software parses /etc/resolv.conf - where the domain name ends at - and how many software does not expect trailing dot to be there, and will segfault or do other bad things if it is present. But being consistent appears to be a good idea too, or else udhcpc will be blamed for being buggy in situations where other popular software works. Also, the comment around this function especially says there is no reason to perform very strict checking, and especially mentions trailing dot. And I really don't know how serious this issue is in practice -- ie, how many places has this trailing dot configured in their setup, and how do this on purpose instead of by mistake. Signed-off-by: Michael Tokarev --- networking/udhcp/dhcpc.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/networking/udhcp/dhcpc.c b/networking/udhcp/dhcpc.c index f72217c..01a9bf8 100644 --- a/networking/udhcp/dhcpc.c +++ b/networking/udhcp/dhcpc.c @@ -187,6 +187,8 @@ static int good_hostname(const char *name) return 0; if (!name[0]) return 1; + if (name[0] == '.' && !name[1]) /* trailing dot */ + return 1; //Do we want this? //return ((name - start) < 1025); /* NS_MAXDNAME */ name++; -- 1.7.10.4 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: XZ embedded bug unpacking linux-3.8.tar.xz
26.02.2013 03:21, John Spencer wrote:
> [ quoting the full mail of lasse since it didnt make its way into the bb
> maillist yet ]
Additionally there has been a discussion and attempts to cook up a
patch in Debian, see http://bugs.debian.org/686502 , which I submitted
as a bug to busybox bugzilla -- https://bugs.busybox.net/show_bug.cgi?id=5804 .
Cc'ing the Debian bugreport. I like the below patch better :)
/mjt
> On 02/25/2013 12:05 PM, Lasse Collin wrote:
>> On 2013-02-25 Denys Vlasenko wrote:
>>> On Sunday 24 February 2013 22:37, John Spencer wrote:
> http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.8.tar.xz
>
> using busybox 1.20.2 and xz 5.0.3 or xz 5.0.4:
>
> $ tar xf linux-3.8.tar.xz
>
> i get: "short read" and exit status 1.
> however the data seems to be there (at least partial).
the culprit is the file linux-3.8/drivers/media/tuners/mt2063.c
after doing xzcat linux-3.8.tar.xz> linux-3.8.tar , that file is
truncated after 4096*2+512 bytes.
xzcat is from busybox (not from xz, as i assumed earlier)
the .tar file is truncated at this point as well, it is only 200
MB, but with xzcat from xz package, it is> 500 MB.
>>>
>>> Apparently XZ embedded has a bug :(
>>> Not only our in-tree one, but the latest git of it is buggy too:
>>>
>>> $ git clone http://git.tukaani.org/xz-embedded.git
>>> $ cd xz-embedded/userspace
>>> $ make
>>> $ ./xzminidec>> ./xzminidec: Unsupported check; not verifying file integrity
>>> <..working for some time...>
>>> 201330688
>>>
>>> (xzminidec doesn't crash: exit code is zero).
>>>
>>> The peculiar thing is that 201330688 is exactly 0x0c001000.
>>
>> linux-3.8.tar.xz from kernel.org has three concatenated .xz streams.
>> You can see this with e.g. "xz -l" or "xz -lvv". At least pxz creates
>> such .xz files. Such files are valid and fine.
>>
>> xzminidec is a limited example program. It doesn't support concatenated
>> streams. This is mentioned in the comment in the beginning of
>> xzminidec.c. One may argue if it is a bug or a feature, but at least
>> the limitation has been documented.
>>
>> Busybox' xzcat lacks support for concatenated .xz streams. For
>> comparison, Busybox' zcat and bzcat do support concatenated streams.
>>
>> $ echo foo | gzip> test.gz
>> $ echo bar | gzip>> test.gz
>> $ busybox zcat test.gz
>> foo
>> bar
>>
>> $ echo foo | xz> test.xz
>> $ echo bar | xz>> test.xz
>> $ busybox xzcat test.xz
>> foo
>>
>> liblzma in XZ Utils has a flag to decode concatenated streams to make
>> it a bit easier to handle such files. I would prefer to not include
>> such a flag in XZ Embedded, since I think in most embedded situations
>> (boot loaders, kernels etc.) such a flag is useless. Busybox is an
>> exception to this.
>>
>> Below is a patch to add support for concatenated .xz streams. It also
>> handles possible padding (sequence of zero-bytes) between the streams.
>> It probably has room for improvement, but it should be a useful starting
>> point.
>>
>> diff --git a/archival/libarchive/decompress_unxz.c
>> b/archival/libarchive/decompress_unxz.c
>> index 79b48a1..5ebbd28 100644
>> --- a/archival/libarchive/decompress_unxz.c
>> +++ b/archival/libarchive/decompress_unxz.c
>> @@ -86,8 +86,40 @@ unpack_xz_stream(transformer_aux_data_t *aux, int src_fd,
>> int dst_fd)
>> IF_DESKTOP(total += iobuf.out_pos;)
>> iobuf.out_pos = 0;
>> }
>> -if (r == XZ_STREAM_END) {
>> -break;
>> +while (r == XZ_STREAM_END) {
>> +/* Handle concatenated .xz Streams including possible
>> + * Stream Padding.
>> + */
>> +if (iobuf.in_pos == iobuf.in_size) {
>> +int rd = safe_read(src_fd, membuf, BUFSIZ);
>> +if (rd< 0) {
>> +bb_error_msg(bb_msg_read_error);
>> +total = -1;
>> +goto out;
>> +}
>> +if (rd == 0)
>> +goto out;
>> +
>> +iobuf.in_size = rd;
>> +iobuf.in_pos = 0;
>> +}
>> +
>> +/* Stream Padding must always be a multiple of four
>> + * bytes to preserve four-byte alignment. To keep the
>> + * code slightly smaller, we aren't as strict here as
>> + * the .xz spec requires. We just skip all zero-bytes
>> + * without checking the alignment and thus can accept
>> + * files that aren't valid, e.g. the XZ Utils test
>> + * files bad-0pad-empty.xz and bad-0catpad-empty.xz.
>> + */
>> +while (iobuf.in_pos< iobuf.in_size) {
>> +if (membuf[iobuf.in_pos] != 0) {
>> +xz_dec_reset(state);
>> +r = XZ_OK;
>> +break;
>> +}
>> +++iobuf.in_pos;
>>
Re: XZ embedded bug unpacking linux-3.8.tar.xz
28.02.2013 04:22, Antonio Diaz Diaz wrote: [] > The history in a nutshell: "In 2008, Antonio Diaz released lzip, which uses a > proper container format with checksums and magic numbers instead of the raw > LZMA data stream, providing a complete Unix-style solution for using LZMA. > Nevertheless, LZMA Utils was extended to have similar features and then > renamed to XZ Utils"[3]. Oh. I remember that 2008 year (or a bit before) when kernel folks discussed which format to use for kernel.org archives and leaned towards lzma, and I pointed out that it does not have any checksums. I guess it was a starting point for xz and lzip. For some reason I haven't heard of lzip at all until now. I remember when xz come out, I looked at it and noticed its complexity and lack of stable format, exactly as you describe, but that didn't rang any bells for me and eventually it become a widely known and accepted format. So, I become curious how lzip behaves. And I immediately gave it a very quick try. CPU: AMD AthlonII X2 260, 3.2GHz (2 cores) file: 1Gb (1073741824 bytes), an image of a small linux virtual machine. .lz: 273684804, real 11m53.112s, user 20m30.563s .xz: 266670056, real 11m8.190s, user 10m45.835s This is the default compression level. WOW. So, 2-thread plzip is about TWO TIMES solwer than single-thread xz when compressing, making parallel plzip on 2 cores to be as fast as xz. lz produces slightly larger result. Are you sure the stream and compression algorithm are the same? :) Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] grep: Don't bail out on first mismatch if '-w' option is set
15.05.2013 01:01, Bartosz Golaszewski wrote: > This fixes bug 4520: 'grep -w fails when pattern is a strict substring > of a word'. If '-w' option is set - grep will retry to match against > the rest of the string after it finds a match not enclosed by delimiting > symbols. It's been fixed by commit 2f5b5beb28a3ffe9d12a19b79c453c640cee2f29 Author: Denys Vlasenko Date: Sun Jan 20 16:57:19 2013 +0100 grep: fix grep -Fw not respecting the -w option. Closes 5792 Apparently 4520 should have been fixed too at that time. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
running testsuite with PREFER_APPLETS=y and EXEC_PATH=
Hello. When running testsuite, we're trying to execute applets by their names, like "grep", "cp", "sh" and so on. When CONFIG_BUSYBOX_PREFER_APPLETS set to "y", busybox tries to exec itself. But this, in turn, depends on CONFIG_BUSYBOX_EXEC_PATH pointing to the right executable. On linux this is /proc/self/exe, but this obviously requires mounted /proc. On other systems, this does not work. On Debian we used "/bin/busybox" as BUSYBOX_EXEC_PATH, to work around not mounted /proc (since busybox is used as shell for initramfs), and for other systems without /proc/self support. But this way, as long as our just-built busybox is not placed to /bin/busybox, we can't test it, we're testing system /bin/busybox (provided it actually exists), or system utilities (found in $PATH). So now I'm basically lost. I can re-set EXEC_PATH back to the default "/proc/self/exe", this will re-enable testsuite on linux correctly. It will still fail on other systems (*bsd, solaris etc). Any suggestion on this? Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: running testsuite with PREFER_APPLETS=y and EXEC_PATH=
Please excuse me for incomplete subject line. It was supposed to be .. and EXEC_PATH=/bin/busybox, not empty as it is now. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
testsuite and "bashisms"
Another question/issue with the testsuite.
'
The testsuite uses ${var/search/replace} construct
heavily. It is implemented in bash and in busybox
ash, but not, for example, in dash, and it is not
in POSIX either.
So when the system /bin/sh does not implement this
construct, los of tests fails like this:
$ ./pidof.tests
PASS: pidof (exit with error)
PASS: pidof (exit with success)
PASS: pidof this
pidof.tests: 59: pidof.tests: Bad substitution
(this is actually in testing.sh:59, not pidof.tests:59).
The line in question is:
optional()
{
SKIP=
while test "$1"; do
if test x"${OPTIONFLAGS/*:$1:*/y}" != x"y"; then
which uses this very construct.
I can modify runtest script to explicitly run the
tests using busybox's ash (by prepending `busybox sh' to
the command line). But this will lead to failing this
very `pidof' test:
$ busybox sh pidof.tests
PASS: pidof (exit with error)
PASS: pidof (exit with success)
FAIL: pidof this
because it will be unable to "this" process by its
name (pidof.tests), since it will be named `busybox'
instead.
Also, when explicitly using busybox ash, we assume
that the configuration actually includes ash, which
is not always the case.
Is there any interest in fixing these usages of
this problematic variable substitution, or applying
a workaround?
Thanks,
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: testsuite and "bashisms"
10.11.2013 19:25, Michael Tokarev wrpte:
Another question/issue with the testsuite.
'
The testsuite uses ${var/search/replace} construct
heavily. It is implemented in bash and in busybox
ash, but not, for example, in dash, and it is not
in POSIX either.
So when the system /bin/sh does not implement this
construct, los of tests fails like this:
Actually there are just 2 places which are trivial to fix,
and the following patch does just that.
Signed-off-by: Michael Tokarev
Thanks,
/mjt
From: Michael Tokarev
Subject: fix bashisms in testsuite/testing.sh and testsuite/hostid/hostid-works
These places use ${var/search/replace} construct which is non-standard.
Replace it with equivalent constructs.
Signed-off-by: Michael Tokarev
diff --git a/testsuite/hostid/hostid-works b/testsuite/hostid/hostid-works
index bcfd717..8c20bdf 100644
--- a/testsuite/hostid/hostid-works
+++ b/testsuite/hostid/hostid-works
@@ -1,8 +1,6 @@
h=x$(busybox hostid)
# Is $h a sequence of hex numbers?
-x="${h//[0123456789abcdef]/x}"
-x="${x//xxx/x}"
-x="${x//xxx/x}"
-x="${x//xxx/x}"
-x="${x//xx/x}"
-test x"$x" = x"x"
+case "$h" in
+ x*[!0-9a-f]*) false;;
+ *) true;;
+esac
diff --git a/testsuite/testing.sh b/testsuite/testing.sh
index e7e64e5..84e00d1 100644
--- a/testsuite/testing.sh
+++ b/testsuite/testing.sh
@@ -56,10 +56,9 @@ optional()
{
SKIP=
while test "$1"; do
- if test x"${OPTIONFLAGS/*:$1:*/y}" != x"y"; then
- SKIP=1
- return
- fi
+ case "${OPTIONFLAGS}" in
+ *:$1:*) SKIP=1; return;;
+ esac
shift
done
}
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: testsuite and "bashisms"
10.11.2013 19:39, Michael Tokarev wrote:
10.11.2013 19:25, Michael Tokarev wrpte:
Another question/issue with the testsuite.
'
The testsuite uses ${var/search/replace} construct
heavily. It is implemented in bash and in busybox
ash, but not, for example, in dash, and it is not
in POSIX either.
So when the system /bin/sh does not implement this
construct, los of tests fails like this:
Actually there are just 2 places which are trivial to fix,
and the following patch does just that.
Actually there are more of these, and the original patch
was wrong. Applied is another version which actually
works (and tested) and fixes more places, together with
$((n++) and `type -p'.
With these changes, I can now run the testsuite on default
debian install.
Thanks,
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: testsuite and "bashisms"
10.11.2013 20:09, Michael Tokarev wrote:
10.11.2013 19:39, Michael Tokarev wrote:
10.11.2013 19:25, Michael Tokarev wrpte:
Another question/issue with the testsuite.
'
The testsuite uses ${var/search/replace} construct
heavily. It is implemented in bash and in busybox
ash, but not, for example, in dash, and it is not
in POSIX either.
So when the system /bin/sh does not implement this
construct, los of tests fails like this:
Actually there are just 2 places which are trivial to fix,
and the following patch does just that.
Actually there are more of these, and the original patch
was wrong. Applied is another version which actually
works (and tested) and fixes more places, together with
$((n++) and `type -p'.
Attached, not applied. Actually attached now :)
With these changes, I can now run the testsuite on default
debian install.
Thanks,
/mjt
From: Michael Tokarev
Subject: fix bashisms in testsuite/
These places use ${var/search/replace}, $((n++) and
`type -p' constructs which are not-so-standard.
Replace with equivalent constructs.
Signed-off-by: Michael Tokarev
diff --git a/testsuite/hostid/hostid-works b/testsuite/hostid/hostid-works
index bcfd717..8c20bdf 100644
--- a/testsuite/hostid/hostid-works
+++ b/testsuite/hostid/hostid-works
@@ -1,8 +1,6 @@
h=x$(busybox hostid)
# Is $h a sequence of hex numbers?
-x="${h//[0123456789abcdef]/x}"
-x="${x//xxx/x}"
-x="${x//xxx/x}"
-x="${x//xxx/x}"
-x="${x//xx/x}"
-test x"$x" = x"x"
+case "$h" in
+ x*[!0-9a-f]*) false;;
+ *) true;;
+esac
diff --git a/testsuite/md5sum.tests b/testsuite/md5sum.tests
index 1068b08..1680cf4 100755
--- a/testsuite/md5sum.tests
+++ b/testsuite/md5sum.tests
@@ -30,7 +30,7 @@ result=`(
n=0
while test $n -le 999; do
echo "$text" | head -c $n | "$sum"
- : $((n++))
+ n=$(($n+1))
done | "$sum"
)`
diff --git a/testsuite/testing.sh b/testsuite/testing.sh
index e7e64e5..f5b7569 100644
--- a/testsuite/testing.sh
+++ b/testsuite/testing.sh
@@ -56,10 +56,10 @@ optional()
{
SKIP=
while test "$1"; do
- if test x"${OPTIONFLAGS/*:$1:*/y}" != x"y"; then
- SKIP=1
- return
- fi
+ case "${OPTIONFLAGS}" in
+ *:$1:*) ;;
+ *) SKIP=1; return ;;
+ esac
shift
done
}
diff --git a/testsuite/which/which-uses-default-path b/testsuite/which/which-uses-default-path
index 63ceb9f..1b3ac66 100644
--- a/testsuite/which/which-uses-default-path
+++ b/testsuite/which/which-uses-default-path
@@ -1,4 +1,4 @@
-BUSYBOX=$(type -p busybox)
+BUSYBOX=$(command -pv busybox)
SAVED_PATH=$PATH
unset PATH
$BUSYBOX which ls
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] do not fail build if MAXSYMLINKS isn't defined
This is needed for, eg, hurd, which is known to have no constraints. Signed-off-by: Michael Tokarev diff --git a/libbb/xreadlink.c b/libbb/xreadlink.c index ec95af2..a610de8 100644 --- a/libbb/xreadlink.c +++ b/libbb/xreadlink.c @@ -8,6 +8,12 @@ #include "libbb.h" +/* some systems (eg Hurd) does not have MAXSYMLINKS definition, + * set it to some reasonable value if it isn't defined */ +#ifndef MAXSYMLINKS +# define MAXSYMLINKS 20 +#endif + /* * NOTE: This function returns a malloced char* that you will have to free * yourself. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] expand: use printable_string instead of hard-coding implementation
Signed-off-by: Michael Tokarev
diff --git a/coreutils/expand.c b/coreutils/expand.c
index 25bbffc..8d376ff 100644
--- a/coreutils/expand.c
+++ b/coreutils/expand.c
@@ -78,11 +78,7 @@ static void expand(FILE *file, unsigned tab_size, unsigned
opt)
unsigned len;
*ptr = '\0';
# if ENABLE_UNICODE_SUPPORT
- {
- uni_stat_t uni_stat;
- printable_string(&uni_stat, ptr_strbeg);
- len = uni_stat.unicode_width;
- }
+ len = unicode_strwidth(ptr_strbeg);
# else
len = ptr - ptr_strbeg;
# endif
@@ -138,12 +134,9 @@ static void unexpand(FILE *file, unsigned tab_size,
unsigned opt)
printf("%*s%.*s", len, "", n, ptr);
# if ENABLE_UNICODE_SUPPORT
{
- char c;
- uni_stat_t uni_stat;
- c = ptr[n];
+ char c = ptr[n];
ptr[n] = '\0';
- printable_string(&uni_stat, ptr);
- len = uni_stat.unicode_width;
+ len = unicode_strwidth(ptr);
ptr[n] = c;
}
# else
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] expand: use printable_string instead of hard-coding implementation
That meant to be unicode_strwidth() not printable_string(). Typo in the subject. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
busybox testsuite on non-linux
Hello. Here are a few tests from the testsuite which fails on debian-hurd and debian-kfreebsd. awk handles non-existing file correctly on hurd ENOENT is 0x4002, the test expects 2. It is not portable to expect certain errno values. Different OSes may use different values for the same error, that's what is for. I'm not sure what this test should be testing. 2 possible solutions: 1) test for ERRNO!=0 instead of ERRNO itself, or 2) print value of ENOENT using a tiny C program and compare with that. pidof this does not print its own pid on hurd or freebsd testing "pidof this" "pidof pidof.tests | grep -o -w $$" "$$\n" "" "" most likely the process is named 'sh pidof.tests', not pidof.tests This test fails on both kfreebsd and hurd systems - it does not print its own pid, `pidof pidof.tests' prints nothig. tar symlinks mode (both kfreebsd and hurd) --- expected +++ actual @@ -1,9 +1,9 @@ input_dir/input_file -input_dir/input_soft -> input_file +input_dir/input_soft -> input_dir/input_file input_file -> input_dir/input_file -input_soft -> input_dir/input_soft +input_soft -> input_file Ok: 0 -rwxrx input_dir/input_file -lrwxrwxrwx input_file +-rwxrx input_dir/input_soft -rwxrx input_file -lrwxrwxrwx input_file +lrwxr-xr-x input_file kfreebsd: group on files is inherited from parent dir. cpio tests fail. FAIL: cpio extracts zero-sized hardlinks --- expected +++ actual @@ -1,4 +1,4 @@ 1 blocks 0 --rw-r--r-- 2 2952 1009 0 x --rw-r--r-- 2 2952 1009 0 y +-rw-r--r-- 2 2952 112 0 x +-rw-r--r-- 2 2952 112 0 y Mabe remove (using sed, in $FILTER_LS) the group column for testing? Note the same may happen on linux too, depending on the filesystem in use and even filesystem mount options (-o grpid or -o bsdgroups for a few linux filesystems). du tests fail on kfreebsd filesystems: du-k-works 16+64Kb files in a dir, `du -k .' is expected to be one of 80, 84 or 88, actual is 82. du-l-works - same issue, result expected to be 144, 148, 152 or 156, actual is 146 I'm not sure why these sizes are multiple of 4Kb. As you can see, on a bsd system the directory size is different. Maybe any number between, say, 80 and 88 should be ok? That's all for now, but I haven't enabled all applets. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox testsuite on non-linux
09.12.2013 17:51, Michael Tokarev пишет: Forgot to comment on this: > tar symlinks mode (both kfreebsd and hurd) > --- expected > +++ actual > @@ -1,9 +1,9 @@ > input_dir/input_file > -input_dir/input_soft -> input_file > +input_dir/input_soft -> input_dir/input_file > input_file -> input_dir/input_file > -input_soft -> input_dir/input_soft > +input_soft -> input_file > Ok: 0 > -rwxrx input_dir/input_file > -lrwxrwxrwx input_file > +-rwxrx input_dir/input_soft > -rwxrx input_file > -lrwxrwxrwx input_file > +lrwxr-xr-x input_file On both kfreebsd and hurd, ln directory/ performs the linking of the _target_ of the symlink, not the symlink itself. So while in this test, we expect input_dir/input_soft to be a symlink (hardlinked with input_soft), it actually is a hardlink with input_file. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] do not use gethostbyname() for hostname -s
There's no reason to call gethostbyname() on the value returned
by uname() when asked just for a short name of a host. This may
also be wrong, when uname is set to one value, but in /etc/hosts
(or elsewhere) the "canonical" name is different. This is often
the case for localhost entry in /etc/hosts:
127.0.0.1 localhost myname
With this content of /etc/hosts, and uname being set to myname,
busybox hostname -s will return localhost, while regular
hostname utility returns myname.
Fix this by not calling gethostbyname() for the simple `hostname -s'
use.
Signed-off-by: Michael Tokarev
diff --git a/networking/hostname.c b/networking/hostname.c
index d2516b5..1e68116 100644
--- a/networking/hostname.c
+++ b/networking/hostname.c
@@ -106,12 +106,13 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
OPT_i = 0x4,
OPT_s = 0x8,
OPT_F = 0x10,
- OPT_dfis = 0xf,
+ OPT_dfi = 0x7,
};
unsigned opts;
char *buf;
char *hostname_str;
+ char *p;
#if ENABLE_LONG_OPTS
applet_long_options =
@@ -134,10 +135,9 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
if (applet_name[0] == 'd') /* dnsdomainname? */
opts = OPT_d;
- if (opts & OPT_dfis) {
+ if (opts & OPT_dfi) {
/* Cases when we need full hostname (or its part) */
struct hostent *hp;
- char *p;
hp = xgethostbyname(buf);
p = strchrnul(hp->h_name, '.');
@@ -159,6 +159,10 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
bb_putchar('\n');
}
}
+ } else if (opts & OPT_s) {
+ p = strchrnul(buf, '.');
+ *p = '\0';
+ puts(buf);
} else if (opts & OPT_F) {
/* Set the hostname */
do_sethostname(hostname_str, 1);
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] do not use gethostbyname() for hostname -s
10.12.2013 01:40, Tito wrote: > On Monday 09 December 2013 18:56:43 Michael Tokarev wrote: >> There's no reason to call gethostbyname() on the value returned >> by uname() when asked just for a short name of a host. This may >> also be wrong, when uname is set to one value, but in /etc/hosts >> (or elsewhere) the "canonical" name is different. This is often >> the case for localhost entry in /etc/hosts: >> >> 127.0.0.1 localhost myname >> >> With this content of /etc/hosts, and uname being set to myname, >> busybox hostname -s will return localhost, while regular >> hostname utility returns myname. >> >> Fix this by not calling gethostbyname() for the simple `hostname -s' >> use. [] > Hi, > I cannot reproduce the case you show with busybox hostname > and /etc/hosts on debian 7: Interesting. Debian7 is exactly the system where I had issues with original implementation: $ uname -n gandalf $ head -n1 /etc/hosts 127.0.0.1 localhost gandalf $ hostname -s gandalf $ busybox hostname -s localhost $ cat /etc/debian_version 7.2 $ _ _My_ /etc/hosts actually has the first line like this: # list real hostname first localhost second or else busybox return wrong name 127.0.0.1 gandalf localhost and it is dated Sep-2010, so the comment should be from 2010 or before. I changed it like shown above for this test. Today I discovered the same issue within a freshly installed debian system in a virtual machine, the generated /etc/hosts had similar line 127.0.0.1 localhost debian which resulted in busybox testsuite to fail (hostname-s-works failure due to busybox returning localhost while system hostname returns debian). This failure prompted me to try to fix this finally. The thing is that busybox hostname calls gethostbyname() on the result of uname() call, while system hostname doesn't do this. But the patch shows it too. > Even modifying /etc/hosts makes no difference: > So now I'm wondering where "(or elsewhere)" could be? Well, I don't know what's wrong with our systems.. ;) > BTW.: It is better if you attach patches as my or your email client > ate the tabs and the patch doesn't apply cleanly. Almost always when someone sends patches as attachments, people complain saying it is better to send patches inline. It really is easier to reply to inline-patches adding comments to particular place in the patch, and here I agree too - it is better to send patches inline. My client can't ate tabs, -- it is more, I see the tabs in your reply exactly as they were in my initial email. I used /usr/sbin/sendmail directly to send my initial email ;) I just tried saving the patch (whole my email) from thunderbird to a temp file and applying it - it applies cleanly to both 1.21 version and current git head. Patch utility strips CRs when applying, but that's typical. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] do not use gethostbyname() for hostname -s
16.12.2013 06:29, Denys Vlasenko пишет:
> On Monday 09 December 2013 18:56, Michael Tokarev wrote:
>> There's no reason to call gethostbyname() on the value returned
>> by uname() when asked just for a short name of a host. This may
>> also be wrong, when uname is set to one value, but in /etc/hosts
>> (or elsewhere) the "canonical" name is different. This is often
>> the case for localhost entry in /etc/hosts:
>>
>> 127.0.0.1 localhost myname
>>
>> With this content of /etc/hosts, and uname being set to myname,
>> busybox hostname -s will return localhost, while regular
>> hostname utility returns myname.
>
> Can you send strace of regular hostname's run?
> I would like to see whether it does any name resolution...
Well. That's in fact *exactly* what I did here to find out why they
differ.
Here we go:
$ strace hostname
...
brk(0) = 0x232b000
brk(0x234c000) = 0x234c000
uname({sys="Linux", node="gandalf", ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fdd63c9a000
write(1, "gandalf\n", 8gandalf
)= 8
exit_group(0) = ?
(it isn't interesting to see anything before the call to uname(2),
since it is the only way to get system name which might be processed
further using dns).
$ strace hostname -s
...
brk(0) = 0x8ca000
brk(0x8eb000) = 0x8eb000
uname({sys="Linux", node="gandalf", ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4f34853000
write(1, "gandalf\n", 8gandalf
)= 8
exit_group(0) = ?
With a "long" hostname:
# hostname gandalf.local
$ strace hostname -s
...
brk(0) = 0xe71000
brk(0xe92000) = 0xe92000
uname({sys="Linux", node="gandalf.local", ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f9364ec4000
write(1, "gandalf\n", 8gandalf
)= 8
exit_group(0) = ?
$ strace hostname
...
brk(0) = 0x25b1000
brk(0x25d2000) = 0x25d2000
uname({sys="Linux", node="gandalf.local", ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2f185b8000
write(1, "gandalf.local\n", 14gandalf.local
) = 14
exit_group(0) = ?
In other words, without -d (domain) or -f (fqdn), hostname just
does the string operations against the result of uname(2).
However, with -d or -f added (with or withot -s), it calls
gethostbyname(), and strace shows this too (not provided, it
is quite large).
Thanks,
/mjt
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Why '-c DEV' option for switch_root?
17.12.2013 01:57, Laurent Bercot wrote: > >> And here the question: How is it simpler to maintain? squashfs is >> a read only file system, so you can't change things directly. >> Same as in initramfs: You need a copy of the root file system >> tree to put in your changes, then you need to create your new >> root file system (squashfs on one hand, cpio archiv on the other >> hand). Then you need to install your new root file system to the >> flash. How can you feel this being simpler to maintain? > > A real filesystem (squashfs or otherwise) is independent from the > kernel. This gives you more flexibility. You don't have to reboot to > test it in a real live working environment. You can develop it in an > emulator to avoid cross-compiling. You can copy the archive around > and mount it as is on another machine. You can keep your userland > firmware and your kernel entirely separate, and even perform live > firmware upgrades. initramfs is no more different from squashfs here. It is not supposed to be kernel-dependent (or environment-dependent), and you dont need to reboot to test it. Guys, seriously, this (almost religious) question has been discussed so many times back when initrd has been introduced in kernel.. The same arguments are being repeated now. initramfs gives you flexibility. It is mostly due to this reason all general-purpose distributions adopted it. For a general-purpose machine there's no need to build its own kernel unless you use it in a very special environment or for some very very special task. Not using some mechanism for initial boot environment basically forces you to do so, unless you're using just a simplest configuration. And this is time to configure, build and test (with reboots!) stuff, which isn't cheap. If you don't need or like this, you're not forced to use initramfs. There's no need to re-iterate all this again after 10+ years. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
