[PATCH] iproute: support onelink route option and print route flags

2014-07-28 Thread Michael Tokarev
Signed-off-by: Michael Tokarev m...@tls.msk.ru --- 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 ---

Fwd: [PATCH] iproute: support onelink route option and print route flags

2014-07-28 Thread Michael Tokarev
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=busybox@busybox.net, \ relay=smtp1.osuosl.org[140.211.166.138]:25,

Re: Fwd: [PATCH] iproute: support onelink route option and print route flags

2014-07-28 Thread Michael Tokarev
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=busybox@busybox.net, \

Re: Fwd: [PATCH] iproute: support onelink route option and print route flags

2014-07-28 Thread Baruch Siach
Hi Michael, On Mon, Jul 28, 2014 at 10:23:40AM +0400, 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]:

Re: Fwd: [PATCH] iproute: support onelink route option and print route flags

2014-07-28 Thread Michael Tokarev
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.

Re: [PATCH 1/2] find: use sysconf(_SC_ARG_MAX) to determine the command-line size limit

2014-07-28 Thread Bartosz Gołaszewski
2014-07-03 14:27 GMT+02:00 Bartosz Gołaszewski bartekg...@gmail.com: Hi Denys, have you read my message from June 10th in this thread? Could you review the patches I attached back then? Busybox still uses ARG_MAX as default, which is smaller than sysconf(_SC_ARG_MAX) on every system I

Re: [PATCH 2/3] seq: match f's type with strlen() result type

2014-07-28 Thread Guilherme Maciel Ferreira
Hi, 2014-07-26 15:05 GMT-03:00 walter harms wha...@bfs.de: actually strlen() returns size_t. When you really need this to be correct you should use size_t. I know. I simply didn't see anywhere nearby using size_t, then I assumed unsigned was used instead. But, I'd rather use size_t! Did you

Re: [PATCH 1/3] tail: turn i to unsigned integer

2014-07-28 Thread Guilherme Maciel Ferreira
Hi, 2014-07-26 15:02 GMT-03:00 walter harms wha...@bfs.de: what is the advantage ? I think correctness is a good advantage. I mean, why use a signed integer, if this variable works as (and with) unsigned integers only? re, wh Am 26.07.2014 19:37, schrieb Guilherme Maciel Ferreira: The

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Timo Teras
On Sun, 27 Jul 2014 21:50:28 +0200 Denys Vlasenko vda.li...@googlemail.com wrote: On Mon, Jul 21, 2014 at 1:14 PM, Timo Teräs timo.te...@iki.fi wrote: display_header() code to parse meminfo as is was buggy: - uninitialized variables were used if meminfo was not as expected - meminfo

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Ralf Friedl
Timo Teras wrote: On Sun, 27 Jul 2014 21:50:28 +0200 Denys Vlasenko vda.li...@googlemail.com wrote: Applied, thanks! Thanks, though I noticed now a weirdness that did not happen before. +static void parse_meminfo(unsigned long meminfo[MI_MAX]) +{ ... + memset(meminfo, 0,

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Timo Teras
On Mon, 28 Jul 2014 16:27:37 +0200 Ralf Friedl ralf.fri...@online.de wrote: Timo Teras wrote: On Sun, 27 Jul 2014 21:50:28 +0200 Denys Vlasenko vda.li...@googlemail.com wrote: Applied, thanks! Thanks, though I noticed now a weirdness that did not happen before. +static void

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Bartosz Gołaszewski
2014-07-28 17:25 GMT+02:00 Timo Teras timo.te...@iki.fi: So something like: diff --git a/procps/top.c b/procps/top.c index 62f9421..119c32b 100644 --- a/procps/top.c +++ b/procps/top.c @@ -536,7 +536,7 @@ static void parse_meminfo(unsigned long meminfo[MI_MAX]) FILE *f;

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Timo Teras
On Mon, 28 Jul 2014 17:52:41 +0200 Bartosz Gołaszewski bartekg...@gmail.com wrote: 2014-07-28 17:25 GMT+02:00 Timo Teras timo.te...@iki.fi: So something like: diff --git a/procps/top.c b/procps/top.c index 62f9421..119c32b 100644 --- a/procps/top.c +++ b/procps/top.c @@ -536,7

Re: [PATCH v2] top: fix and merge code to parse /proc/meminfo

2014-07-28 Thread Bartosz Gołaszewski
2014-07-28 18:48 GMT+02:00 Timo Teras timo.te...@iki.fi: I was taking sizeof of individual element: meminfo[0]. Alternative would be sizeof *meminfo. I prefer not to expand to the actual type. It's easier to change if needed, and the correctness more obvious as you don't need to look what was