From vda.linux at googlemail.com Mon Oct 1 05:01:27 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 1 Oct 2007 13:01:27 +0100
Subject: Remove common patterns -- second try
In-Reply-To: <9b06e8d20709301153p1bc3cf10jca4315701eb0a42a@mail.gmail.com>
References: <9b06e8d20709300730k1ad7396cmec3bae6522075eac@mail.gmail.com>
<200709301739.55931.vda.linux@googlemail.com>
<9b06e8d20709301153p1bc3cf10jca4315701eb0a42a@mail.gmail.com>
Message-ID: <200710011301.28118.vda.linux@googlemail.com>
I applied bigger part of it. Thanks. See 6.patch.
7.patch is a part which is not applied, as it is slower.
On Sunday 30 September 2007 19:53, Lo?c Greni? wrote:
> While I'm at it: bb_verror_msg is written in such a way that msg can have
> an embedded NUL char. Is it important ? Otherwise the function can be
> simplified (using strcat or vasprintf instead of moving pointers around).
strcat and vasprintf are slower than msg[i++] = 'c' and strcpy.
No need to kill yourself for the last byte or two.
> PS: with my local gcc, whenever bb_simple_perror_msg is declared in
> networking/libiproute/iproute.c, the function do_iproute takes 40 bytes
> more. I've removed from the patch the kludge that I've used here but
> I don't know whether this is a general problem.
It's a gcc problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6.patch
Type: text/x-diff
Size: 26523 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071001/ef062e02/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7.patch
Type: text/x-diff
Size: 1751 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071001/ef062e02/attachment-0003.bin
From vapier at gentoo.org Mon Oct 1 06:02:01 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 1 Oct 2007 09:02:01 -0400
Subject: svn commit: trunk/busybox: archival coreutils libbb miscutils
netwo etc...
In-Reply-To: <20071001120512.E26D1A688A@busybox.net>
References: <20071001120512.E26D1A688A@busybox.net>
Message-ID: <200710010902.02009.vapier@gentoo.org>
On Monday 01 October 2007, vda at busybox.net wrote:
> Author: vda
> Date: 2007-10-01 05:05:12 -0700 (Mon, 01 Oct 2007)
> New Revision: 20160
>
> Log:
> printf("%s\n") -> puts()
should add a src test for this
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20071001/5cb21b8c/attachment.pgp
From mike-busybox at tiedyenetworks.com Mon Oct 1 12:54:24 2007
From: mike-busybox at tiedyenetworks.com (Mike)
Date: Mon, 01 Oct 2007 12:54:24 -0700
Subject: Coupla bugs ? syslogd -C, logger, losetup
Message-ID: <47015070.3030300@tiedyenetworks.com>
Howdy,
syslogd option paramater -C is not recognised in 1.7.1.
I poked around and the culprit appears to be an extra semicolon in
the options parameter declaration for it. This trivial patch seems to do
the trick for me (compiled + tested minimally).
diff -ur busybox-1.7.1.orig/sysklogd/syslogd.c
busybox-1.7.1/sysklogd/syslogd.c
--- busybox-1.7.1.orig/sysklogd/syslogd.c 2007-09-03
11:48:35.000000000 +0000
+++ busybox-1.7.1/sysklogd/syslogd.c 2007-09-29 16:53:12.000000000 +0000
@@ -159,7 +159,7 @@
USE_FEATURE_ROTATE_LOGFILE("b:" ) \
USE_FEATURE_REMOTE_LOG( "R:" ) \
USE_FEATURE_REMOTE_LOG( "L" ) \
- USE_FEATURE_IPC_SYSLOG( "C::")
+ USE_FEATURE_IPC_SYSLOG( "C:")
#define OPTION_DECL *opt_m, *opt_l \
USE_FEATURE_ROTATE_LOGFILE(,*opt_s) \
USE_FEATURE_ROTATE_LOGFILE(,*opt_b) \
Also, losetup seems to not be working correctly and I can't seem to get
it to work with my compressed loop device /dev/cloop/[0-7]. It looks
like a flub with parsing argv but I ran out of time looking at it.
ALSO, I just noticed, logger seems to only take the first argument on
the command like for squirting into syslog. eg:
logger this is a test
will only put 'this' into syslog and omit the rest. Past behaviour was
to stuff everything into syslog. I can work around it by enclosing stuff
in quotes but the previous behavior, I think, is more desireable.
Thanks.
--
Do not try to make the creditors stop calling, for that is impossibe.
Instead, only try to realise the truth: THERE IS NO PHONE!
From kztakada at sm.sony.co.jp Tue Oct 2 02:52:23 2007
From: kztakada at sm.sony.co.jp (Kazuo TAKADA)
Date: Tue, 02 Oct 2007 18:52:23 +0900
Subject: [PATCH] tail can't handle the /proc directory
Message-ID: <200710020952.AA00877@JPC20007704.sm.sony.co.jp>
Hi,
I found bug in busybox 1.7.2 and before.
The tail command can't handle the /proc directory and doesn't return
from a while loop.
For example:
----------------------------------------
% ./busybox tail /proc/meminfo
(It doesn't exit...)
----------------------------------------
The patch below can resolve this problem.
----------------------------------------------------------------------
--- coreutils/tail.c.orig 2007-09-03 20:48:40.000000000 +0900
+++ coreutils/tail.c 2007-10-02 17:54:34.000000000 +0900
@@ -51,7 +51,7 @@
struct stat sbuf;
end = current = lseek(fd, 0, SEEK_CUR);
- if (!fstat(fd, &sbuf))
+ if (!fstat(fd, &sbuf) && sbuf.st_size)
end = sbuf.st_size;
lseek(fd, end < current ? 0 : current, SEEK_SET);
r = safe_read(fd, buf, count);
----------------------------------------------------------------------
'man fstat' said:
>Linux Notes
:
> For most files under the /proc directory, stat() does not return the
> file size in the st_size field; instead the field is returned with
> the value 0.
Therefore, fstat() returns 0(=SUCCESS) and sbuf.st_size is set with
value 0. As a result, 'end' becomes 0 and lseek(fd, 0, SEEK_SET) is
executed over and over again.
Best regards,
Kazuo TAKADA
From vda.linux at googlemail.com Tue Oct 2 02:55:39 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 2 Oct 2007 10:55:39 +0100
Subject: Coupla bugs ? syslogd -C, logger, losetup
In-Reply-To: <47015070.3030300@tiedyenetworks.com>
References: <47015070.3030300@tiedyenetworks.com>
Message-ID: <200710021055.39651.vda.linux@googlemail.com>
On Monday 01 October 2007 20:54, Mike wrote:
> Howdy,
>
> syslogd option paramater -C is not recognised in 1.7.1.
>
> I poked around and the culprit appears to be an extra semicolon in
> the options parameter declaration for it. This trivial patch seems to do
> the trick for me (compiled + tested minimally).
>
>
> diff -ur busybox-1.7.1.orig/sysklogd/syslogd.c
> busybox-1.7.1/sysklogd/syslogd.c
> --- busybox-1.7.1.orig/sysklogd/syslogd.c 2007-09-03
> 11:48:35.000000000 +0000
> +++ busybox-1.7.1/sysklogd/syslogd.c 2007-09-29 16:53:12.000000000 +0000
> @@ -159,7 +159,7 @@
> USE_FEATURE_ROTATE_LOGFILE("b:" ) \
> USE_FEATURE_REMOTE_LOG( "R:" ) \
> USE_FEATURE_REMOTE_LOG( "L" ) \
> - USE_FEATURE_IPC_SYSLOG( "C::")
> + USE_FEATURE_IPC_SYSLOG( "C:")
> #define OPTION_DECL *opt_m, *opt_l \
> USE_FEATURE_ROTATE_LOGFILE(,*opt_s) \
> USE_FEATURE_ROTATE_LOGFILE(,*opt_b) \
Double :: means that the parameter is optional.
In this case, you _must_ specify parameter without space:
Ok: busybox syslogd -n -C8
Bad: busybox syslogd -n -C 8
Help text is showing this for you:
$ busybox syslogd --help
BusyBox v1.8.0.svn (2007-10-01 13:07:24 IST) multi-call binary
Usage: syslogd [OPTION]...
System logging utility.
Note that this version of syslogd ignores /etc/syslog.conf.
Options:
-n Run in foreground
-O FILE Log to given file (default=/var/log/messages)
-l n Set local log level
-S Smaller logging output
-s SIZE Max size (KB) before rotate (default=200KB, 0=off)
-b NUM Number of rotated logs to keep (default=1, max=99, 0=purge)
-R HOST[:PORT] Log to IP or hostname on PORT (default PORT=514/UDP)
-L Log locally and via network (default is network only if -R)
-C[size(KiB)] Log to shared mem buffer (read it using logread)
^^^ no space!
> Also, losetup seems to not be working correctly and I can't seem to get
> it to work with my compressed loop device /dev/cloop/[0-7]. It looks
> like a flub with parsing argv but I ran out of time looking at it.
You need to do better than that. At least specify what
sequence of commands doesn't work.
For me, the following works:
# dd if=/dev/zero bs=1M count=32 >/tmp/image
32+0 records in
32+0 records out
33554432 bytes (34 MB) copied, 0.091392 seconds, 367 MB/s
# mke2fs /tmp/image
mke2fs 1.38 (30-Jun-2005)
image is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
8192 inodes, 32768 blocks
1638 blocks (5.00%) reserved for the super user
First data block=1
4 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
8193, 24577
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# busybox losetup /dev/loop/0 /tmp/image
# mount /dev/loop/0 /mnt/tmp
# ls -l /mnt/tmp
drwx------ 2 root root 12288 Oct 2 10:50 lost+found
> ALSO, I just noticed, logger seems to only take the first argument on
> the command like for squirting into syslog. eg:
>
> logger this is a test
>
> will only put 'this' into syslog and omit the rest. Past behaviour was
> to stuff everything into syslog. I can work around it by enclosing stuff
> in quotes but the previous behavior, I think, is more desireable.
Fixed, thanks.
--
vda
From vda.linux at googlemail.com Tue Oct 2 03:14:52 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 2 Oct 2007 11:14:52 +0100
Subject: [PATCH] tail can't handle the /proc directory
In-Reply-To: <200710020952.AA00877@JPC20007704.sm.sony.co.jp>
References: <200710020952.AA00877@JPC20007704.sm.sony.co.jp>
Message-ID: <200710021114.52995.vda.linux@googlemail.com>
On Tuesday 02 October 2007 10:52, Kazuo TAKADA wrote:
> Hi,
>
> I found bug in busybox 1.7.2 and before.
> The tail command can't handle the /proc directory and doesn't return
> from a while loop.
>
> For example:
> ----------------------------------------
> % ./busybox tail /proc/meminfo
> (It doesn't exit...)
> ----------------------------------------
>
> The patch below can resolve this problem.
>
> ----------------------------------------------------------------------
> --- coreutils/tail.c.orig 2007-09-03 20:48:40.000000000 +0900
> +++ coreutils/tail.c 2007-10-02 17:54:34.000000000 +0900
> @@ -51,7 +51,7 @@
> struct stat sbuf;
>
> end = current = lseek(fd, 0, SEEK_CUR);
> - if (!fstat(fd, &sbuf))
> + if (!fstat(fd, &sbuf) && sbuf.st_size)
> end = sbuf.st_size;
> lseek(fd, end < current ? 0 : current, SEEK_SET);
> r = safe_read(fd, buf, count);
> ----------------------------------------------------------------------
I am applying this patch (see attached). Does it work for you?
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-1.7.2-tail.patch
Type: text/x-diff
Size: 1062 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071002/eabd3c63/attachment.bin
From kztakada at sm.sony.co.jp Tue Oct 2 03:28:41 2007
From: kztakada at sm.sony.co.jp (Kazuo TAKADA)
Date: Tue, 02 Oct 2007 19:28:41 +0900
Subject: [PATCH] tail can't handle the /proc directory
In-Reply-To: <200710021114.52995.vda.linux@googlemail.com>
References: <200710021114.52995.vda.linux@googlemail.com>
Message-ID: <200710021028.AA00878@JPC20007704.sm.sony.co.jp>
>On Tuesday 02 October 2007 10:52, Kazuo TAKADA wrote:
>> Hi,
>>
>> I found bug in busybox 1.7.2 and before.
>> The tail command can't handle the /proc directory and doesn't return
>> from a while loop.
{snip..}
>
>I am applying this patch (see attached). Does it work for you?
>--
>vda
OK, it works.
Thanks.
--------
Kazuo TAKADA
From loic.grenie at gmail.com Tue Oct 2 05:17:35 2007
From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=)
Date: Tue, 2 Oct 2007 14:17:35 +0200
Subject: unzip concatenated gzip files
Message-ID: <9b06e8d20710020517x5a9c4e98t12fca5aace7c0359@mail.gmail.com>
This patch tries to allow the unzipping of concatenated gzip files.
Test:
% echo First > first
% gzip first
% echo Second > second
% gzip second
% cat first.gz second.gz > total.gz
% ./busybox gunzip total.gz
% cat total
First
Second
%
If there are no errors, this should address Debian's bug
#402482
.
The feature costs 400 bytes on i386. I've removed a couple of
initializations that (look) useless (to me). I've also added a feature
for message "decompression OK, trailing garbage ignored".
Lo?c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20071002/b2b8054d/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gunzip.diff
Type: text/x-diff
Size: 8855 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071002/b2b8054d/attachment-0001.bin
From vda.linux at googlemail.com Tue Oct 2 07:05:53 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 2 Oct 2007 15:05:53 +0100
Subject: Coupla bugs ? syslogd -C, logger, losetup
In-Reply-To: <47022645.4040504@tiedyenetworks.com>
References: <47015070.3030300@tiedyenetworks.com>
<200710021055.39651.vda.linux@googlemail.com>
<47022645.4040504@tiedyenetworks.com>
Message-ID: <200710021505.53444.vda.linux@googlemail.com>
On Tuesday 02 October 2007 12:06, Mike wrote:
>
> The syslogd paramater is broke. Previous versions allows "-C 4096",
> whereas 1.7.1 doesn't. Removing the space makes it incompatible with
> scripts and so forth. Also forcing there to be no space makes it's
> option parsing unlike practically every other code out there. We should
> strive for compatibillity as removing the space adds no value. So lets
> fix the parser
Parsing of -Cn has not changed since at least 1.1.0
Previous versions of syslogd were ignoring non option arguments.
I downloaded busybox-1.1.0, added debug printf:
while ((opt = getopt(argc, argv, "m:nO:s:Sb:R:LC::")) > 0) {
...
}
+printf("shm_size=%u\n", shm_size);
built and ran it like this:
$ ./busybox syslogd -n -C 64
shm_size=16384
syslogd: Could not connect to socket /dev/log: Address already in use
$ ./busybox syslogd -n -C64
shm_size=65536
syslogd: Could not connect to socket /dev/log: Address already in use
IOW: syslogd -C 64 *is ignoring 64*. 64 becomes first non-option
parameter and is ignored by syslogd from busybox 1.1.0.
Current syslogd refuses to start when it sees non-option arguments.
If you are dissatisfied with this behavior, please propose
a solution.
> instead of bashing me, ok?
Hmm.
> losetup is broke as I stated and does not function in real life.
> Previous versions do, however, and I spent quite a good time trying to
> figue out why 1.00 and others work whereas 1.7.1 doesn't. I don't have
> to "do better" than reporting my real life experience and if you get
> defensive and make these disrespectful and rude comments to me again in
> the future, I'll just document your bugs elsewhere and maintain a
> private tree as I do for many of these other little projects and we
> won't have this discourse again.
Give me a sequence of commands where losetup fails.
I will try to reproduce and subsequently fix.
--
vda
From kztakada at sm.sony.co.jp Tue Oct 2 19:31:26 2007
From: kztakada at sm.sony.co.jp (Kazuo TAKADA)
Date: Wed, 03 Oct 2007 11:31:26 +0900
Subject: [PATCH] dd doesn't return a failure status
Message-ID: <200710030231.AA00881@JPC20007704.sm.sony.co.jp>
Hi,
If the dd command fails in a sequence of copying, it always returns
EXIT_SUCCESS. So, I can't judge whether the command had succeeded or
failed.
Its behavior doesn't conform to POSIX.
POSIX 1003.1:
http://www.opengroup.org/onlinepubs/009695399/utilities/dd.html
| EXIT STATUS
| The following exit values shall be returned:
|
| 0
| The input file was copied successfully.
| >0
| An error occurred.
For example, copy some data to a small size device repeatly.
--------------------------------------------------
(with a root account)
# ./busybox dd if=/dev/zero of=/dev/ram
dd: writing '/dev/ram': No space left on device
32769+0 records in
32768+0 records out
# echo $?
0 <= should be failed!!
# ./busybox dd if=/dev/zero of=/dev/ram count=1
1+0 records in
1+0 records out
# echo $?
0
# /bin/dd if=/dev/zero of=/dev/ram <= GNU's one
dd: writing to `/dev/ram': No space left on device
32769+0 records in
32768+0 records out
# echo $?
1
--------------------------------------------------
The old busybox-1.2.2.1 returns EXIT_FAILURE. It is the version that
dd had not reconstructed yet.
Can you accept the patch below?
write_and_stats() is the function which returns a bool value.
----------------------------------------------------------------------
--- coreutils/dd.c.orig 2007-09-03 20:48:39.000000000 +0900
+++ coreutils/dd.c 2007-10-03 10:31:50.000000000 +0900
@@ -106,7 +106,7 @@
#endif
};
size_t ibs = 512, obs = 512;
- ssize_t n, w;
+ ssize_t n, w = 0;
char *ibuf, *obuf;
/* And these are all zeroed at once! */
struct {
@@ -303,13 +303,17 @@
tmp += d;
oc += d;
if (oc == obs) {
- if (write_and_stats(ofd, obuf, obs, obs, outfile))
+ if (write_and_stats(ofd, obuf, obs, obs, outfile)) {
+ w = -1;
goto out_status;
+ }
oc = 0;
}
}
- } else if (write_and_stats(ofd, ibuf, n, obs, outfile))
+ } else if (write_and_stats(ofd, ibuf, n, obs, outfile)) {
+ w = -1;
goto out_status;
+ }
}
if (ENABLE_FEATURE_DD_IBS_OBS && oc) {
@@ -330,5 +334,5 @@
out_status:
dd_output_status(0);
- return EXIT_SUCCESS;
+ return (w >= 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}
----------------------------------------------------------------------
Best regards,
Kazuo TAKADA
From loic.grenie at gmail.com Wed Oct 3 00:13:42 2007
From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=)
Date: Wed, 3 Oct 2007 09:13:42 +0200
Subject: [PATCH] dd doesn't return a failure status
In-Reply-To: <200710030231.AA00881@JPC20007704.sm.sony.co.jp>
References: <200710030231.AA00881@JPC20007704.sm.sony.co.jp>
Message-ID: <9b06e8d20710030013x72e36396r49cdcb8c76edf7c3@mail.gmail.com>
2007/10/3, Kazuo TAKADA :
>
> Hi,
>
> If the dd command fails in a sequence of copying, it always returns
> EXIT_SUCCESS. So, I can't judge whether the command had succeeded or
> failed.
>
> Its behavior doesn't conform to POSIX.
>
> POSIX 1003.1:
> http://www.opengroup.org/onlinepubs/009695399/utilities/dd.html
> | EXIT STATUS
> | The following exit values shall be returned:
> |
> | 0
> | The input file was copied successfully.
> | >0
> | An error occurred.
>
> For example, copy some data to a small size device repeatly.
>
> --------------------------------------------------
> (with a root account)
> # ./busybox dd if=/dev/zero of=/dev/ram
> dd: writing '/dev/ram': No space left on device
> 32769+0 records in
> 32768+0 records out
> # echo $?
> 0 <= should be failed!!
>
> # ./busybox dd if=/dev/zero of=/dev/ram count=1
> 1+0 records in
> 1+0 records out
> # echo $?
> 0
>
> # /bin/dd if=/dev/zero of=/dev/ram <= GNU's one
> dd: writing to `/dev/ram': No space left on device
> 32769+0 records in
> 32768+0 records out
> # echo $?
> 1
> --------------------------------------------------
>
> The old busybox-1.2.2.1 returns EXIT_FAILURE. It is the version that
> dd had not reconstructed yet.
>
> Can you accept the patch below?
> write_and_stats() is the function which returns a bool value.
>
> ----------------------------------------------------------------------
> --- coreutils/dd.c.orig 2007-09-03 20:48:39.000000000 +0900
> +++ coreutils/dd.c 2007-10-03 10:31:50.000000000 +0900
> @@ -106,7 +106,7 @@
> #endif
> };
> size_t ibs = 512, obs = 512;
> - ssize_t n, w;
> + ssize_t n, w = 0;
> char *ibuf, *obuf;
> /* And these are all zeroed at once! */
> struct {
> @@ -303,13 +303,17 @@
> tmp += d;
> oc += d;
> if (oc == obs) {
> - if (write_and_stats(ofd, obuf,
> obs, obs, outfile))
> + if (write_and_stats(ofd, obuf,
> obs, obs, outfile)) {
> + w = -1;
> goto out_status;
> + }
> oc = 0;
> }
> }
> - } else if (write_and_stats(ofd, ibuf, n, obs, outfile))
> + } else if (write_and_stats(ofd, ibuf, n, obs, outfile)) {
> + w = -1;
> goto out_status;
> + }
> }
>
> if (ENABLE_FEATURE_DD_IBS_OBS && oc) {
> @@ -330,5 +334,5 @@
> out_status:
> dd_output_status(0);
>
> - return EXIT_SUCCESS;
> + return (w >= 0 ? EXIT_SUCCESS : EXIT_FAILURE);
> }
> ----------------------------------------------------------------------
It may be faster to do
if ((w = write_and_stats(...)))
goto out_status;
and
return w;
because write_and_stats returns 1 on failure. You can even tweak
it to return either EXIT_SUCCESS or EXIT_FAILURE and change the
if to:
if ((w = write_and_stats(...)) == EXIT_SUCCESS)
goto out_status;
(which is the same but symbolically different).
Lo?c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20071003/4f636a5d/attachment.htm
From kztakada at sm.sony.co.jp Wed Oct 3 02:38:24 2007
From: kztakada at sm.sony.co.jp (Kazuo TAKADA)
Date: Wed, 03 Oct 2007 18:38:24 +0900
Subject: [PATCH] dd doesn't return a failure status
In-Reply-To: <9b06e8d20710030013x72e36396r49cdcb8c76edf7c3@mail.gmail.com>
References: <9b06e8d20710030013x72e36396r49cdcb8c76edf7c3@mail.gmail.com>
Message-ID: <200710030938.AA00883@JPC20007704.sm.sony.co.jp>
loic.grenie at gmail.com wrote:
{snip..}
>
> It may be faster to do
>
>if ((w = write_and_stats(...)))
> goto out_status;
>
> and
>
>return w;
>
> because write_and_stats returns 1 on failure. You can even tweak
> it to return either EXIT_SUCCESS or EXIT_FAILURE and change the
> if to:
>
>if ((w = write_and_stats(...)) == EXIT_SUCCESS)
> goto out_status;
>
> (which is the same but symbolically different).
I agree with your suggestion basically and I had already tried.
But, in other lines, the variable 'w' is set with the written size by
the function 'full_write_or_warn()'.
An exit status of zero must indicate success, and a nonzero value
indicates failure, therefore, 'return w' is not appropriate.
Well, if I take care of variable's meanings, it can be written as below.
----------------------------------------------------------------------
--- coreutils/dd.c.orig 2007-09-03 20:48:39.000000000 +0900
+++ coreutils/dd.c 2007-10-03 18:19:29.000000000 +0900
@@ -54,17 +54,17 @@
return n;
}
-static bool write_and_stats(int fd, const void *buf, size_t len, size_t obs,
+static int write_and_stats(int fd, const void *buf, size_t len, size_t obs,
const char *filename)
{
ssize_t n = full_write_or_warn(fd, buf, len, filename);
if (n < 0)
- return 1;
+ return EXIT_FAILURE;
if (n == obs)
G.out_full++;
else if (n) /* > 0 */
G.out_part++;
- return 0;
+ return EXIT_SUCCESS;
}
#if ENABLE_LFS
@@ -106,7 +106,8 @@
#endif
};
size_t ibs = 512, obs = 512;
- ssize_t n, w;
+ ssize_t n;
+ int retval = EXIT_SUCCESS;
char *ibuf, *obuf;
/* And these are all zeroed at once! */
struct {
@@ -303,18 +304,21 @@
tmp += d;
oc += d;
if (oc == obs) {
- if (write_and_stats(ofd, obuf, obs, obs, outfile))
+ if ((retval = write_and_stats(ofd, obuf, obs, obs, outfile)))
goto out_status;
oc = 0;
}
}
- } else if (write_and_stats(ofd, ibuf, n, obs, outfile))
+ } else if ((retval = write_and_stats(ofd, ibuf, n, obs, outfile)))
goto out_status;
}
if (ENABLE_FEATURE_DD_IBS_OBS && oc) {
- w = full_write_or_warn(ofd, obuf, oc, outfile);
- if (w < 0) goto out_status;
+ ssize_t w = full_write_or_warn(ofd, obuf, oc, outfile);
+ if (w < 0) {
+ retval = EXIT_FAILURE;
+ goto out_status;
+ }
if (w > 0)
G.out_part++;
}
@@ -330,5 +334,5 @@
out_status:
dd_output_status(0);
- return EXIT_SUCCESS;
+ return retval;
}
----------------------------------------------------------------------
It may be clear on the point of the code's policy.
Thanks.
Kazuo TAKADA
From loic.grenie at gmail.com Wed Oct 3 02:46:27 2007
From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=)
Date: Wed, 3 Oct 2007 11:46:27 +0200
Subject: [PATCH] dd doesn't return a failure status
In-Reply-To: <200710030938.AA00883@JPC20007704.sm.sony.co.jp>
References: <9b06e8d20710030013x72e36396r49cdcb8c76edf7c3@mail.gmail.com>
<200710030938.AA00883@JPC20007704.sm.sony.co.jp>
Message-ID: <9b06e8d20710030246t4d75f125mb4af4309ff6030f6@mail.gmail.com>
2007/10/3, Kazuo TAKADA :
>
> loic.grenie at gmail.com wrote:
> {snip..}
> >
> > It may be faster to do
> >
> >if ((w = write_and_stats(...)))
> > goto out_status;
> >
> > and
> >
> >return w;
> >
> > because write_and_stats returns 1 on failure. You can even tweak
> > it to return either EXIT_SUCCESS or EXIT_FAILURE and change the
> > if to:
> >
> >if ((w = write_and_stats(...)) == EXIT_SUCCESS)
> > goto out_status;
> >
> > (which is the same but symbolically different).
>
> I agree with your suggestion basically and I had already tried.
> But, in other lines, the variable 'w' is set with the written size by
> the function 'full_write_or_warn()'.
Sorry, my bad.
Lo?c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20071003/4912b41a/attachment.htm
From vda.linux at googlemail.com Thu Oct 4 05:31:03 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 4 Oct 2007 13:31:03 +0100
Subject: unzip concatenated gzip files
In-Reply-To: <9b06e8d20710020517x5a9c4e98t12fca5aace7c0359@mail.gmail.com>
References: <9b06e8d20710020517x5a9c4e98t12fca5aace7c0359@mail.gmail.com>
Message-ID: <200710041331.03622.vda.linux@googlemail.com>
Hi,
Sorry for the delay.
On Tuesday 02 October 2007 13:17, Lo?c Greni? wrote:
> This patch tries to allow the unzipping of concatenated gzip files.
union {
unsigned char raw[8];
struct {
unsigned char gz_method;
unsigned char flags;
unsigned int mtime;
unsigned char xtra_flags;
unsigned char os_flags;
} formatted;
} header;
sizeof(header) == 12.
Hmm. Did you code internal_check_header_gzip by copy-pasting
check_header_gzip_or_die?
/* Discard original name or file comment if any */
/* Discard file comment if any */
if (header.formatted.flags & 0x18) {
bool comm = 0;
/* bit 3 set: original file name present */
/* bit 4 set: file comment present */
read_string:
do {
if (top_up(PASS_STATE 1))
return -1;
}
while (bytebuffer[bytebuffer_offset++] != 0);
What guarantees that you don't go far beyond bytebuffer's end?
Aha. I see. It's a do {} while written in an obfuscated way.
if (comm == 0 && (header.formatted.flags & 0x18) == 0x18) {
comm = 1;
goto read_string;
}
}
I will try to integrate it later this week/weekend.
Loic, please submit future patches this way:
* Patches split into parts:
* cleanups first (unneeded statements commented out, etc)
* real code changes next
* follow existing code's style:
if () {
...
}
do {
} while
instead of
if ()
{
...
}
do {
}
while
--
vda
From jsujjavanich at syntech-fuelmaster.com Thu Oct 4 15:31:47 2007
From: jsujjavanich at syntech-fuelmaster.com (Jate Sujjavanich)
Date: Thu, 4 Oct 2007 18:31:47 -0400
Subject: Gcc 4 msh expression trouble
Message-ID:
I've recently switched from gcc 3.4.0 to gcc 4.2-8 (codesourcery) for
shared library support on the Coldfire. It seems this has broken two
things: recognition of the ! inside of braces [], and messed with
variable substitution inside of backticks.
This fails: [ $i -lt 10 -a ! -e /var/snap_state ]. I can get rid of the
! and it works properly.
If I do
echo `expr $i + 1`
expr returns a syntax error. Running it as a regular command is
successful.
I am trying to find out which part of busybox/shell/msh.c to debug from
someone who is more familiar with the code. Thanks.
- Jate S.
From vda.linux at googlemail.com Thu Oct 4 16:32:08 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 5 Oct 2007 00:32:08 +0100
Subject: unzip concatenated gzip files
In-Reply-To: <9b06e8d20710041043r4146d1b9gdc3a76dea9222528@mail.gmail.com>
References: <9b06e8d20710020517x5a9c4e98t12fca5aace7c0359@mail.gmail.com>
<9b06e8d20710040830g124ac24em1dd3caadb060f3dd@mail.gmail.com>
<9b06e8d20710041043r4146d1b9gdc3a76dea9222528@mail.gmail.com>
Message-ID: <200710050032.08628.vda.linux@googlemail.com>
On Thursday 04 October 2007 18:43, Lo?c Greni? wrote:
> 2007/10/4, Lo?c Greni? :
> > Code
>
> Minor tweak (I was reserving two excessive bytes).
Unfortunately, we collided. I was working on this too,
using your patch as a base. :[
text data bss dec hex filename
770988 1029 9552 781569 bed01 busybox_old
771137 1029 9552 781718 bed96 busybox_unstripped
This patch does not introduce any new CONFIG options.
Less than 200 bytes growth.
"decompression OK, trailing garbage ignored" is commented out.
Not decided yet whether the message itself is needed.
As a bonus, now gunzip should never die without returning to main program.
It did it before on many low-probability error paths.
As a minus, it can introduce new bugs. :(
Can you test this patch?
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loic.diff
Type: text/x-diff
Size: 33601 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071005/d34b6d54/attachment-0001.bin
From vda.linux at googlemail.com Thu Oct 4 16:36:41 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 5 Oct 2007 00:36:41 +0100
Subject: unzip concatenated gzip files
In-Reply-To: <200710050032.08628.vda.linux@googlemail.com>
References: <9b06e8d20710020517x5a9c4e98t12fca5aace7c0359@mail.gmail.com>
<9b06e8d20710041043r4146d1b9gdc3a76dea9222528@mail.gmail.com>
<200710050032.08628.vda.linux@googlemail.com>
Message-ID: <200710050036.41746.vda.linux@googlemail.com>
On Friday 05 October 2007 00:32, Denys Vlasenko wrote:
> On Thursday 04 October 2007 18:43, Lo?c Greni? wrote:
> > 2007/10/4, Lo?c Greni? :
> > > Code
> >
> > Minor tweak (I was reserving two excessive bytes).
>
> Unfortunately, we collided. I was working on this too,
> using your patch as a base. :[
>
> text data bss dec hex filename
> 770988 1029 9552 781569 bed01 busybox_old
> 771137 1029 9552 781718 bed96 busybox_unstripped
>
> This patch does not introduce any new CONFIG options.
> Less than 200 bytes growth.
>
> "decompression OK, trailing garbage ignored" is commented out.
> Not decided yet whether the message itself is needed.
>
> As a bonus, now gunzip should never die without returning to main program.
> It did it before on many low-probability error paths.
>
> As a minus, it can introduce new bugs. :(
>
> Can you test this patch?
Sorry, wrong patch. This one is right.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loic.diff
Type: text/x-diff
Size: 34893 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071005/117f290e/attachment-0001.bin
From thomas at corelatus.se Fri Oct 5 09:49:09 2007
From: thomas at corelatus.se (Thomas Lange)
Date: Fri, 05 Oct 2007 18:49:09 +0200
Subject: [PATCH] tail -f read very small blocks
Message-ID: <47066B05.6090600@corelatus.se>
There is a bug in tail -f(ollow) which causes all reads
to be 4 bytes only, regardless of how many bytes remain in file.
Patch for cvs head attached.
/Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tail_follow_patch.txt
Url: http://busybox.net/lists/busybox/attachments/20071005/ddd8d9a3/attachment.txt
From vda.linux at googlemail.com Fri Oct 5 12:14:09 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 5 Oct 2007 20:14:09 +0100
Subject: [PATCH] tail -f read very small blocks
In-Reply-To: <47066B05.6090600@corelatus.se>
References: <47066B05.6090600@corelatus.se>
Message-ID: <200710052014.09279.vda.linux@googlemail.com>
On Friday 05 October 2007 17:49, Thomas Lange wrote:
> There is a bug in tail -f(ollow) which causes all reads
> to be 4 bytes only, regardless of how many bytes remain in file.
>
> Patch for cvs head attached.
Applied, thanks!
--
vda
From vda.linux at googlemail.com Fri Oct 5 12:23:15 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 5 Oct 2007 20:23:15 +0100
Subject: Gcc 4 msh expression trouble
In-Reply-To:
References:
Message-ID: <200710052023.15402.vda.linux@googlemail.com>
On Thursday 04 October 2007 23:31, Jate Sujjavanich wrote:
> I've recently switched from gcc 3.4.0 to gcc 4.2-8 (codesourcery) for
> shared library support on the Coldfire. It seems this has broken two
> things: recognition of the ! inside of braces [], and messed with
> variable substitution inside of backticks.
>
> This fails: [ $i -lt 10 -a ! -e /var/snap_state ]. I can get rid of the
> ! and it works properly.
>
> If I do
>
> echo `expr $i + 1`
>
> expr returns a syntax error. Running it as a regular command is
> successful.
Does it happen to you when you build bbox with same .config but
on i386 desktop? If yes, please send me .config.
For me it works:
$ ./busybox msh
:/usr/local/google/vda/srcdev/bbox/fix/busybox.t3$ echo `expr $i + 1`
1
:/usr/local/google/vda/srcdev/bbox/fix/busybox.t3$ exit
$ gcc -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: ../gcc-4.2.1.div/configure --prefix=/usr/app/gcc-4.2.1.div --exec-prefix=/usr/app/gcc-4.2.1.div --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/app/gcc-4.2.1.div/libexec --datadir=/usr/app/gcc-4.2.1.div/share --sysconfdir=/etc --sharedstatedir=/usr/app/gcc-4.2.1.div/var/com --localstatedir=/usr/app/gcc-4.2.1.div/var --libdir=/usr/lib --includedir=/usr/include --infodir=/usr/info --mandir=/usr/man --with-slibdir=/usr/app/gcc-4.2.1.div/lib --with-local-prefix=/usr/local --with-gxx-include-dir=/usr/app/gcc-4.2.1.div/include/g++-v3 --enable-languages=c,c++ --without-system-zlib --disable-nls --enable-threads=posix i386-pc-linux-gnu
Thread model: posix
gcc version 4.2.1
(my .config is attached)
> I am trying to find out which part of busybox/shell/msh.c to debug from
> someone who is more familiar with the code. Thanks.
When you try to find someone familiar with shell source (any shell),
people tend to duck and run.
I'm afraid you are pretty much limited to sticking debug
prints / watching things under debugger until you see
where msh starts to act differently with different gcc.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.bz2
Type: application/x-bzip2
Size: 4086 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071005/f7fb5730/attachment.bin
From wharms at bfs.de Sat Oct 6 02:37:41 2007
From: wharms at bfs.de (walter harms)
Date: Sat, 06 Oct 2007 11:37:41 +0200
Subject: Remove common patterns
In-Reply-To: <200709301720.42577.vda.linux@googlemail.com>
References: <9b06e8d20709300728j33b165adu50a7df07c82a424c@mail.gmail.com>
<200709301720.42577.vda.linux@googlemail.com>
Message-ID: <47075765.7010109@bfs.de>
Denys Vlasenko wrote:
> On Sunday 30 September 2007 15:28, Lo?c Greni? wrote:
>> I've tried to remove "common patterns" in the code.
>> First try: s/printf("%s", /puts(/ and s/fprintf(fp, "%s",
>> \(.*\))/fputs(\1, fp)/
>> Patch attached.
>
> - printf("%s", error_message(ctx->errcode));
> + puts(error_message(ctx->errcode));
>
>
> These are not equivalent. puts is adding "\n".
>
> Apart from this - applied, thanks.
> --
I am sorry but is the printf -> puts replacement not done
automagicly by gcc ?
(http://www.ciselant.de/projects/gcc_printf/gcc_printf.html)
re,
wh
From buehmann at users.berlios.de Sat Oct 6 06:31:10 2007
From: buehmann at users.berlios.de (=?ISO-8859-15?Q?Andreas_B=FChmann?=)
Date: Sat, 06 Oct 2007 15:31:10 +0200
Subject: ash busy waiting for imaginary child processes
Message-ID: <47078E1E.3010704@users.berlios.de>
Hello,
there seems to be a problem in the job management of ash (testet with
busybox 1.7.2 and SVN revision #20187). Please try this:
sleep 1 &
{ sleep 2; jobs; wait; echo done; } &
This prints "[1] + Running" despite the process created in line 2 not
having any child processes when "jobs" gets executed. The subsequent
"wait" then consumes 100% cpu waiting for this non-existing job to finish.
After having taken a quick look into the code, I suspect this behavior
to be connected with change #19092 (ash: make "jobs | cat" work like in
bash (was giving empty output)) but I don't know enough about the job
management to examine this more closely.
Regards,
Andreas
From Alexander at Kriegisch.name Sun Oct 7 08:24:21 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 07 Oct 2007 17:24:21 +0200
Subject: ash syntax error in nested case ... esac
Message-ID: <4708FA25.2030704@Kriegisch.name>
BB 1.7.2, ash, mipsel platform, kernel 2.6.13.1
I took the attached example script right from
http://busybox.net/downloads/BusyBox.html, originally because I wanted
to test the getopt command. I slightly modified it, but this does not
influence the outcome.
$ ./getopt.test
./getopt.test: line 14: syntax error: ";;" unexpected (expecting "done")
Another minimum example for a nested case-esac construct is in the
second attachment 'foo'. No errors there.
Is there something wrong with the 'while' loop?
--
Alexander Kriegisch
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: getopt.test
Url: http://busybox.net/lists/busybox/attachments/20071007/ee3f3378/attachment.ksh
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: foo
Url: http://busybox.net/lists/busybox/attachments/20071007/ee3f3378/attachment.diff
From pgf at brightstareng.com Sun Oct 7 08:49:28 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Sun, 07 Oct 2007 11:49:28 -0400
Subject: ash syntax error in nested case ... esac
In-Reply-To: Alexander's message of Sun, 07 Oct 2007 17:24:21 +0200.
<4708FA25.2030704@Kriegisch.name>
Message-ID: <28291.1191772168@brightstareng.com>
>
> Is there something wrong with the 'while' loop?
the problem is in your echo statements. see below.
>
> #!/bin/sh
>
> GETOPT=$(getopt -o ab:c:: -l a-long,b-long:,c-long:: -n 'example.busybox' -- "$@")
> [ $? == 0 ] || exit 1
> eval set -- "$GETOPT"
> while true ; do
> case $1 in
> -a|--a-long) echo "Option a" ; shift ;;
> -b|--b-long) echo "Option b, argument `$2'" ; shift 2 ;;
------------------------------------------------------^
the ` character starts a shell inline expansion. change it to '
> -c|--c-long)
> case "$2" in
> "") echo "Option c, no argument"; shift 2 ;;
> *) echo "Option c, argument `$2'" ; shift 2 ;;
same here----------------------------------------------------^
> esac ;;
> --) shift ; break ;;
> *) echo "Internal error!" ; exit 1 ;;
> esac
> done
[ btw, this is an excellent example of a place where debugging
was greatly sped up by using an editor with shell syntax
coloring. the odd colors in your script were immediately
apparent. (i use vile. i assume vim and emacs would be helpful
as well.) ]
paul
=---------------------
paul fox, pgf at brightstareng.com
From Alexander at Kriegisch.name Sun Oct 7 09:01:36 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 07 Oct 2007 18:01:36 +0200
Subject: ash syntax error in nested case ... esac
In-Reply-To: <28291.1191772168@brightstareng.com>
References: <28291.1191772168@brightstareng.com>
Message-ID: <470902E0.9060102@Kriegisch.name>
Thanks, Paul. How could I not have seen this? I guess that is a frequent
problem when copying and pasting code from an external source.
Denys or whoever is responsible for the web site, would you please
correct the sample script for the getopt applet on the "Command Help"
page? http://busybox.net/downloads/BusyBox.html
--
Alexander Kriegisch
Paul Fox:
> the problem is in your echo statements. see below.
> (...)
> > -b|--b-long) echo "Option b, argument `$2'" ; shift 2 ;;
> ------------------------------------------------------^
> the ` character starts a shell inline expansion. change it to '
From rep.dot.nop at gmail.com Sun Oct 7 09:19:55 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 7 Oct 2007 18:19:55 +0200
Subject: ash syntax error in nested case ... esac
In-Reply-To: <470902E0.9060102@Kriegisch.name>
References: <28291.1191772168@brightstareng.com>
<470902E0.9060102@Kriegisch.name>
Message-ID: <20071007161955.GI20951@aon.at>
On Sun, Oct 07, 2007 at 06:01:36PM +0200, Alexander Kriegisch wrote:
>Thanks, Paul. How could I not have seen this? I guess that is a frequent
>problem when copying and pasting code from an external source.
>
>Denys or whoever is responsible for the web site, would you please
The BusyBox.html is generated out of include/usage.h, or at least it
was. The file mentioned below is from Oct 24 2006, so there seems to be
something wrong in the Makefiles, it seems (the file isn't generated
anymore when you do 'make'. It used to be, IIRC).
>correct the sample script for the getopt applet on the "Command Help"
>page? http://busybox.net/downloads/BusyBox.html
This is already fixed in svn, but generating the file was broken some
time ago..
From Alexander at Kriegisch.name Sun Oct 7 09:56:39 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 07 Oct 2007 18:56:39 +0200
Subject: ash syntax error in nested case ... esac
In-Reply-To: <20071007161955.GI20951@aon.at>
References: <28291.1191772168@brightstareng.com> <470902E0.9060102@Kriegisch.name>
<20071007161955.GI20951@aon.at>
Message-ID: <47090FC7.1060900@Kriegisch.name>
Very well, Bernhard.
But generating the page is only one half of what is needed. The fact
that single quotes are replaces by backticks seems to be the other. Has
this also been fixed already?
Regards
--
Alexander Kriegisch
Bernhard Fischer:
> On Sun, Oct 07, 2007 at 06:01:36PM +0200, Alexander Kriegisch wrote:
>> Thanks, Paul. How could I not have seen this? I guess that is a frequent
>> problem when copying and pasting code from an external source.
>>
>> Denys or whoever is responsible for the web site, would you please
>
> The BusyBox.html is generated out of include/usage.h, or at least it
> was. The file mentioned below is from Oct 24 2006, so there seems to be
> something wrong in the Makefiles, it seems (the file isn't generated
> anymore when you do 'make'. It used to be, IIRC).
>
>> correct the sample script for the getopt applet on the "Command Help"
>> page? http://busybox.net/downloads/BusyBox.html
>
> This is already fixed in svn, but generating the file was broken some
> time ago..
From rep.dot.nop at gmail.com Sun Oct 7 10:12:32 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 7 Oct 2007 19:12:32 +0200
Subject: ash syntax error in nested case ... esac
In-Reply-To: <47090FC7.1060900@Kriegisch.name>
References: <28291.1191772168@brightstareng.com>
<470902E0.9060102@Kriegisch.name> <20071007161955.GI20951@aon.at>
<47090FC7.1060900@Kriegisch.name>
Message-ID: <20071007171227.GM20951@aon.at>
On Sun, Oct 07, 2007 at 06:56:39PM +0200, Alexander Kriegisch wrote:
>Very well, Bernhard.
>
>But generating the page is only one half of what is needed. The fact
>that single quotes are replaces by backticks seems to be the other. Has
>this also been fixed already?
I don't see the backticks in svn that were mentioned earlier in this thread.
So yes, to me it looks like this is fixed in svn.
From Alexander at Kriegisch.name Sun Oct 7 10:29:01 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 07 Oct 2007 19:29:01 +0200
Subject: ash syntax error in nested case ... esac
In-Reply-To: <20071007171227.GM20951@aon.at>
References: <28291.1191772168@brightstareng.com> <470902E0.9060102@Kriegisch.name>
<20071007161955.GI20951@aon.at> <47090FC7.1060900@Kriegisch.name>
<20071007171227.GM20951@aon.at>
Message-ID: <4709175D.9030907@Kriegisch.name>
Bernhard Fischer:
> I don't see the backticks in svn that were mentioned earlier in this thread.
> So yes, to me it looks like this is fixed in svn.
Confirmed. I just checked BusyBox.html after having called "make doc". :-)
Paul Fox wrote earlier:
> [ btw, this is an excellent example of a place where debugging
> was greatly sped up by using an editor with shell syntax
> coloring. the odd colors in your script were immediately
> apparent. (i use vile. i assume vim and emacs would be helpful
> as well.) ]
I agree, but in this case I just pasted the text into a stripped-down
Nano editor (no syntax highlighting compiled in) on my embedded platform...
--
Alexander Kriegisch
From vda.linux at googlemail.com Sun Oct 7 10:57:29 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 7 Oct 2007 18:57:29 +0100
Subject: ash busy waiting for imaginary child processes
In-Reply-To: <47078E1E.3010704@users.berlios.de>
References: <47078E1E.3010704@users.berlios.de>
Message-ID: <200710071857.29733.vda.linux@googlemail.com>
On Saturday 06 October 2007 14:31, Andreas B?hmann wrote:
> Hello,
>
> there seems to be a problem in the job management of ash (testet with
> busybox 1.7.2 and SVN revision #20187). Please try this:
>
> sleep 1 &
> { sleep 2; jobs; wait; echo done; } &
>
> This prints "[1] + Running" despite the process created in line 2 not
> having any child processes when "jobs" gets executed. The subsequent
> "wait" then consumes 100% cpu waiting for this non-existing job to finish.
>
> After having taken a quick look into the code, I suspect this behavior
> to be connected with change #19092 (ash: make "jobs | cat" work like in
> bash (was giving empty output)) but I don't know enough about the job
> management to examine this more closely.
Yes, it is caused by that change. Reverting. Thanks.
--
vda
From vda.linux at googlemail.com Sun Oct 7 10:59:12 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 7 Oct 2007 18:59:12 +0100
Subject: ash syntax error in nested case ... esac
In-Reply-To: <470902E0.9060102@Kriegisch.name>
References: <28291.1191772168@brightstareng.com>
<470902E0.9060102@Kriegisch.name>
Message-ID: <200710071859.12608.vda.linux@googlemail.com>
On Sunday 07 October 2007 17:01, Alexander Kriegisch wrote:
> Thanks, Paul. How could I not have seen this? I guess that is a frequent
> problem when copying and pasting code from an external source.
>
> Denys or whoever is responsible for the web site, would you please
> correct the sample script for the getopt applet on the "Command Help"
> page? http://busybox.net/downloads/BusyBox.html
How do you reach this page starting from http://busybox.net/ ?
I'm thinking about either updating, or removing help tests from there.
--
vda
From vda.linux at googlemail.com Sun Oct 7 11:06:01 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 7 Oct 2007 19:06:01 +0100
Subject: ash syntax error in nested case ... esac
In-Reply-To: <200710071859.12608.vda.linux@googlemail.com>
References: <28291.1191772168@brightstareng.com>
<470902E0.9060102@Kriegisch.name>
<200710071859.12608.vda.linux@googlemail.com>
Message-ID: <200710071906.02049.vda.linux@googlemail.com>
On Sunday 07 October 2007 18:59, Denys Vlasenko wrote:
> On Sunday 07 October 2007 17:01, Alexander Kriegisch wrote:
> > Thanks, Paul. How could I not have seen this? I guess that is a frequent
> > problem when copying and pasting code from an external source.
> >
> > Denys or whoever is responsible for the web site, would you please
> > correct the sample script for the getopt applet on the "Command Help"
> > page? http://busybox.net/downloads/BusyBox.html
>
> How do you reach this page starting from http://busybox.net/ ?
I see. "Command Help" link.
--
vda
From vda.linux at googlemail.com Sun Oct 7 12:12:47 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 7 Oct 2007 20:12:47 +0100
Subject: Remove common patterns
In-Reply-To: <47075765.7010109@bfs.de>
References: <9b06e8d20709300728j33b165adu50a7df07c82a424c@mail.gmail.com>
<200709301720.42577.vda.linux@googlemail.com>
<47075765.7010109@bfs.de>
Message-ID: <200710072012.47961.vda.linux@googlemail.com>
On Saturday 06 October 2007 10:37, walter harms wrote:
>
> Denys Vlasenko wrote:
> > On Sunday 30 September 2007 15:28, Lo?c Greni? wrote:
> >> I've tried to remove "common patterns" in the code.
> >> First try: s/printf("%s", /puts(/ and s/fprintf(fp, "%s",
> >> \(.*\))/fputs(\1, fp)/
> >> Patch attached.
> >
> > - printf("%s", error_message(ctx->errcode));
> > + puts(error_message(ctx->errcode));
> >
> >
> > These are not equivalent. puts is adding "\n".
> >
> > Apart from this - applied, thanks.
> > --
>
> I am sorry but is the printf -> puts replacement not done
> automagicly by gcc ?
>
> (http://www.ciselant.de/projects/gcc_printf/gcc_printf.html)
Yes, instead of optimizing "printf with string with no percents"
in glibc he optimized a subset of that in gcc.
I think this optimization is misplaced.
--
vda
From development at pracucci.com Tue Oct 9 06:11:08 2007
From: development at pracucci.com (Marco Pracucci)
Date: Tue, 09 Oct 2007 15:11:08 +0200
Subject: Klogd: min log level
Message-ID: <470B7DEC.4090703@pracucci.com>
Hi,
the attached patch add an option to klogd (-l) that allows to set the
minimum log level. I needed this option to only log critic messages from
kernel but, at the same time, all messages from other sources (ex. other
system daemons).
I hope it could be useful not only for me.
Marco Pracucci
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-1.7.2-klogd-min-level.diff
Type: text/x-patch
Size: 1820 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071009/c19ed3f3/attachment.bin
From development at pracucci.com Tue Oct 9 06:26:44 2007
From: development at pracucci.com (Marco Pracucci)
Date: Tue, 09 Oct 2007 15:26:44 +0200
Subject: Syslogd -l option is not documented
Message-ID: <470B8194.9080004@pracucci.com>
Hi,
the -l option of syslogd is not documented at:
http://www.busybox.net/downloads/BusyBox.html
Regards,
Marco Pracucci
From vda.linux at googlemail.com Tue Oct 9 11:02:35 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 9 Oct 2007 19:02:35 +0100
Subject: Syslogd -l option is not documented
In-Reply-To: <470B8194.9080004@pracucci.com>
References: <470B8194.9080004@pracucci.com>
Message-ID: <200710091902.35609.vda.linux@googlemail.com>
On Tuesday 09 October 2007 14:26, Marco Pracucci wrote:
> Hi,
>
> the -l option of syslogd is not documented at:
> http://www.busybox.net/downloads/BusyBox.html
Fixed. Thanks.
--
vda
From vda.linux at googlemail.com Tue Oct 9 11:49:57 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 9 Oct 2007 19:49:57 +0100
Subject: NOMMU: stack versus malloc?
Message-ID: <200710091949.57439.vda.linux@googlemail.com>
A question to people who work with NOMMU machines:
Obviously, having small stack usage is important for
small, NOMMU machines.
However, after a certain point you cannot just eliminate
stack usage, you must move it to other storage.
For example, lineedit.c currently eats 12k+ if stack.
I can convert it into malloc use.
Question: is it better or actually worse?
Line editing is invoked repeatedly, and repeated malloc/free
of random-sized blocks can increase fragmentation
-> increase memory consumption.
Please share your experience.
--
vda
From vapier at gentoo.org Tue Oct 9 11:56:49 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 9 Oct 2007 14:56:49 -0400
Subject: NOMMU: stack versus malloc?
In-Reply-To: <200710091949.57439.vda.linux@googlemail.com>
References: <200710091949.57439.vda.linux@googlemail.com>
Message-ID: <200710091456.50369.vapier@gentoo.org>
On Tuesday 09 October 2007, Denys Vlasenko wrote:
> A question to people who work with NOMMU machines:
>
> Obviously, having small stack usage is important for
> small, NOMMU machines.
>
> However, after a certain point you cannot just eliminate
> stack usage, you must move it to other storage.
>
> For example, lineedit.c currently eats 12k+ if stack.
>
> I can convert it into malloc use.
>
> Question: is it better or actually worse?
> Line editing is invoked repeatedly, and repeated malloc/free
> of random-sized blocks can increase fragmentation
> -> increase memory consumption.
it really depends on the size of the consumption ... on nommu, the default
stack is 4k, so i'd say if you're talking about more than 1k, it should be a
malloc ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20071009/997a25ae/attachment.pgp
From vda.linux at googlemail.com Tue Oct 9 12:13:56 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 9 Oct 2007 20:13:56 +0100
Subject: libbusybox is back; "individual" mode is introduced
Message-ID: <200710092013.56786.vda.linux@googlemail.com>
Hi,
In current svn:
CONFIG_BUILD_LIBBUSYBOX works again,
CONFIG_FEATURE_INDIVIDUAL now works too.
Run-tested on i386 glibc only, try on other arches.
NOMMU may significantly benefit from these -
big win due to code sharing when you have many
applets running at once.
If it doesn't work on your arch, retest on i386
and then report to the list.
--
vda
From Alexander at Kriegisch.name Tue Oct 9 12:15:48 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Tue, 09 Oct 2007 21:15:48 +0200
Subject: Syslogd -l option is not documented
In-Reply-To: <200710091902.35609.vda.linux@googlemail.com>
References: <470B8194.9080004@pracucci.com>
<200710091902.35609.vda.linux@googlemail.com>
Message-ID: <470BD364.6090708@Kriegisch.name>
>> the -l option of syslogd is not documented at:
>> http://www.busybox.net/downloads/BusyBox.html
>
> Fixed. Thanks.
Now the getopt example looks okay, too. Thanks back to you! :)
From vda.linux at googlemail.com Tue Oct 9 12:16:29 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 9 Oct 2007 20:16:29 +0100
Subject: ipkg integration ?
In-Reply-To: <200710092013.53796.fernsehass@online.de>
References: <200710092013.53796.fernsehass@online.de>
Message-ID: <200710092016.30005.vda.linux@googlemail.com>
On Tuesday 09 October 2007 19:13, Mirko P. wrote:
> is the integration of ipkg in busybox make ??
No. Please (re)send patches.
Never hesitate to resend patches in general.
Lack of response sometimes is just a result of people
being busy/ill.
--
vda
From rep.dot.nop at gmail.com Tue Oct 9 12:41:22 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Tue, 9 Oct 2007 21:41:22 +0200
Subject: NOMMU: stack versus malloc?
In-Reply-To: <200710091456.50369.vapier@gentoo.org>
References: <200710091949.57439.vda.linux@googlemail.com>
<200710091456.50369.vapier@gentoo.org>
Message-ID: <20071009194122.GS20951@aon.at>
On Tue, Oct 09, 2007 at 02:56:49PM -0400, Mike Frysinger wrote:
>On Tuesday 09 October 2007, Denys Vlasenko wrote:
>> A question to people who work with NOMMU machines:
>>
>> Obviously, having small stack usage is important for
>> small, NOMMU machines.
>>
>> However, after a certain point you cannot just eliminate
>> stack usage, you must move it to other storage.
>>
>> For example, lineedit.c currently eats 12k+ if stack.
>>
>> I can convert it into malloc use.
>>
>> Question: is it better or actually worse?
>> Line editing is invoked repeatedly, and repeated malloc/free
>> of random-sized blocks can increase fragmentation
>> -> increase memory consumption.
>
>it really depends on the size of the consumption ... on nommu, the default
>stack is 4k, so i'd say if you're talking about more than 1k, it should be a
>malloc ...
AFAIK there was RESERVE_CONFIG_BUFFER for (potentially big) stack users.
From vda.linux at googlemail.com Tue Oct 9 13:34:02 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 9 Oct 2007 21:34:02 +0100
Subject: NOMMU: stack versus malloc?
In-Reply-To: <20071009194122.GS20951@aon.at>
References: <200710091949.57439.vda.linux@googlemail.com>
<200710091456.50369.vapier@gentoo.org>
<20071009194122.GS20951@aon.at>
Message-ID: <200710092134.02849.vda.linux@googlemail.com>
On Tuesday 09 October 2007 20:41, Bernhard Fischer wrote:
> On Tue, Oct 09, 2007 at 02:56:49PM -0400, Mike Frysinger wrote:
> >On Tuesday 09 October 2007, Denys Vlasenko wrote:
> >> A question to people who work with NOMMU machines:
> >>
> >> Obviously, having small stack usage is important for
> >> small, NOMMU machines.
> >>
> >> However, after a certain point you cannot just eliminate
> >> stack usage, you must move it to other storage.
> >>
> >> For example, lineedit.c currently eats 12k+ if stack.
> >>
> >> I can convert it into malloc use.
> >>
> >> Question: is it better or actually worse?
> >> Line editing is invoked repeatedly, and repeated malloc/free
> >> of random-sized blocks can increase fragmentation
> >> -> increase memory consumption.
> >
> >it really depends on the size of the consumption ... on nommu, the default
> >stack is 4k, so i'd say if you're talking about more than 1k, it should be a
> >malloc ...
Ick... We have lots of ~4k stack users... and Makefile sets stack to 20k
IIRC, correct me if I'm wrong:
# Busybox is a stack-fatty so make sure we increase default size
# TODO: use "make stksizes" to find & fix big stack users
# (we stole scripts/checkstack.pl from the kernel... thanks guys!)
FLTFLAGS += -s 20000
> AFAIK there was RESERVE_CONFIG_BUFFER for (potentially big) stack users.
Yes. But it looks like _nobody_ benefits from big objects on stack.
So I intend to gradually move big stack users to malloc.
--
vda
From rep.dot.nop at gmail.com Tue Oct 9 13:49:07 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Tue, 9 Oct 2007 22:49:07 +0200
Subject: NOMMU: stack versus malloc?
In-Reply-To: <200710092134.02849.vda.linux@googlemail.com>
References: <200710091949.57439.vda.linux@googlemail.com>
<200710091456.50369.vapier@gentoo.org>
<20071009194122.GS20951@aon.at>
<200710092134.02849.vda.linux@googlemail.com>
Message-ID: <20071009204907.GT20951@aon.at>
On Tue, Oct 09, 2007 at 09:34:02PM +0100, Denys Vlasenko wrote:
>> AFAIK there was RESERVE_CONFIG_BUFFER for (potentially big) stack users.
>
>Yes. But it looks like _nobody_ benefits from big objects on stack.
>So I intend to gradually move big stack users to malloc.
Well, if you have a very dumb (but fast) allocator and you're very
sensitive WRT fragmentation but have enough stack space available,
then avoiding malloc() is a good thing.
From yann.morin.1998 at anciens.enib.fr Tue Oct 9 14:35:09 2007
From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN)
Date: Tue, 9 Oct 2007 23:35:09 +0200
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <200710092013.56786.vda.linux@googlemail.com>
References: <200710092013.56786.vda.linux@googlemail.com>
Message-ID: <200710092335.09630.yann.morin.1998@anciens.enib.fr>
On Tuesday 09 October 2007 21:13:56 Denys Vlasenko wrote:
> In current svn:
> CONFIG_BUILD_LIBBUSYBOX works again,
> CONFIG_FEATURE_INDIVIDUAL now works too.
> Run-tested on i386 glibc only, try on other arches.
Breaks when cross-compiling (at least for ARM) on a x86_64:
[--SNIP--]
CC util-linux/switch_root.o
CC util-linux/umount.o
AR util-linux/lib.a
LINK busybox_unstripped
Trying libraries: crypt m
Library crypt is needed
Library m is needed
Final link with: crypt m
strip: Unable to recognise the format of the input file `0_lib/libbusybox.so.1.8.0.svn_unstripped'
chmod: cannot access `0_lib/libbusybox.so.1.8.0.svn': No such file or directory
libbusybox: 0_lib/libbusybox.so.1.8.0.svn
Linking 0_lib/busybox_unstripped failed
[--SNIP--]
The reason is that we should use the cross-strip, rather than the native one,
in scripts/trylink. Patch attached.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< ?_? >==-- ?------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
?------------------------------?-------?------------------?--------------------?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-trylink_libbusybox.patch
Type: text/x-diff
Size: 898 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071009/8704c330/attachment.bin
From rep.dot.nop at gmail.com Tue Oct 9 14:41:48 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Tue, 9 Oct 2007 23:41:48 +0200
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <200710092335.09630.yann.morin.1998@anciens.enib.fr>
References: <200710092013.56786.vda.linux@googlemail.com>
<200710092335.09630.yann.morin.1998@anciens.enib.fr>
Message-ID: <20071009214147.GW20951@aon.at>
On Tue, Oct 09, 2007 at 11:35:09PM +0200, Yann E. MORIN wrote:
>Breaks when cross-compiling (at least for ARM) on a x86_64:
>The reason is that we should use the cross-strip, rather than the native one,
>in scripts/trylink. Patch attached.
>- strip -s --remove-section=.note --remove-section=.comment $EXE -o "$sharedlib_dir/libbusybox.so.$BB_VER"
>+ $STRIP -s --remove-section=.note --remove-section=.comment $EXE -o "$sharedlib_dir/libbusybox.so.$BB_VER"
This, too will fail unless you use a strip that accepts said arguments.
Didn't we have a $(STRIPCMD) that contained $STRIP plus eventual args?
From yann.morin.1998 at anciens.enib.fr Tue Oct 9 14:42:24 2007
From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN)
Date: Tue, 9 Oct 2007 23:42:24 +0200
Subject: Build system: make distclean no so clean
Message-ID: <200710092342.24957.yann.morin.1998@anciens.enib.fr>
Hello!
Just a side note:
# make distclean
[--SNIP--]
# svn stat
? 0_lib
! shell/hush_test/hush-bugs/tick.right
Not very bothersome, but just in case any one has enough make-fu to hack the
makefiles...
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< ?_? >==-- ?------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
?------------------------------?-------?------------------?--------------------?
From yann.morin.1998 at anciens.enib.fr Tue Oct 9 14:54:27 2007
From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN)
Date: Tue, 9 Oct 2007 23:54:27 +0200
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <20071009214147.GW20951@aon.at>
References: <200710092013.56786.vda.linux@googlemail.com>
<200710092335.09630.yann.morin.1998@anciens.enib.fr>
<20071009214147.GW20951@aon.at>
Message-ID: <200710092354.27117.yann.morin.1998@anciens.enib.fr>
On Tuesday 09 October 2007 23:41:48 Bernhard Fischer wrote:
> On Tue, Oct 09, 2007 at 11:35:09PM +0200, Yann E. MORIN wrote:
>
> >Breaks when cross-compiling (at least for ARM) on a x86_64:
>
> >The reason is that we should use the cross-strip, rather than the native one,
> >in scripts/trylink. Patch attached.
>
> >- strip -s --remove-section=.note --remove-section=.comment $EXE -o "$sharedlib_dir/libbusybox.so.$BB_VER"
> >+ $STRIP -s --remove-section=.note --remove-section=.comment $EXE -o "$sharedlib_dir/libbusybox.so.$BB_VER"
>
> This, too will fail unless you use a strip that accepts said arguments.
> Didn't we have a $(STRIPCMD) that contained $STRIP plus eventual args?
If we ever had it, it stayed in limbo, but... I seem to recall we had such
a beast as make macros that would check arguments against a command, and
return the argument if supported, or an alternative (or empty)...
The only two incarnations of $STRIP I could find are (spaces squeezed to fill
in a single line):
# grep -r \\\$\\\(STRIP .
Makefile: $(Q)$(STRIP) -s --remove-section=.note --remove-section=.comment \
scripts/Makefile.IMA: -$(STRIP) -s -R .note -R .comment -R .version $@
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< ?_? >==-- ?------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
?------------------------------?-------?------------------?--------------------?
From pgf at brightstareng.com Tue Oct 9 14:58:52 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Tue, 09 Oct 2007 17:58:52 -0400
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: yann.morin.1998's message of Tue, 09 Oct 2007 23:54:27 +0200.
<200710092354.27117.yann.morin.1998@anciens.enib.fr>
Message-ID: <9665.1191967132@brightstareng.com>
> The only two incarnations of $STRIP I could find are (spaces
> squeezed to fill in a single line):
>
> # grep -r \\\$\\\(STRIP .
> Makefile: $(Q)$(STRIP) -s --remove-section=3D.note --remove-section=3D.comment \
> scripts/Makefile.IMA: -$(STRIP) -s -R .note -R .comment -R .version $@
it was in 1.1.3, at least (i happen to have that handy):
$ egrep -r '\$\(STRIP' .
./Rules.mak:STRIPCMD:=$(STRIP) -s --remove-section=.note --remove-section=.comment
./Rules.mak:cmd_strip = $(STRIPCMD) $@
=---------------------
paul fox, pgf at brightstareng.com
From jsujjavanich at syntech-fuelmaster.com Tue Oct 9 15:07:53 2007
From: jsujjavanich at syntech-fuelmaster.com (Jate Sujjavanich)
Date: Tue, 9 Oct 2007 18:07:53 -0400
Subject: NOMMU: stack versus malloc?
In-Reply-To: <200710092134.02849.vda.linux@googlemail.com>
Message-ID:
The m68knommu device (Coldfire 5235) I've been working on has 16 MB of
SDRAM, so fragmentation has been more of an issue for me than overall
memory usage on uClinux. I say do things to reduce the memory usage
without increasing fragmentation. On a system with less memory, it will
eventually make your usable memory smaller no matter what total you have
free.
If you have a large buffer that must be used very often, I think you
should malloc it once, make it static/force it into the data section, or
place it on the stack. If it will be used only rarely, you might get
away with with malloc'ing the small number of times it's used.
Incidentally, the dreaded "unable to allocate memory" due to
fragmentation reared its ugly head when I was debugging busybox/msh
yesterday. After I restarted msh around 10 times.
- Jate S.
-----Original Message-----
From: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net]
On Behalf Of Denys Vlasenko
Sent: Tuesday, October 09, 2007 4:34 PM
To: Bernhard Fischer
Cc: busybox at busybox.net
Subject: Re: NOMMU: stack versus malloc?
On Tuesday 09 October 2007 20:41, Bernhard Fischer wrote:
> On Tue, Oct 09, 2007 at 02:56:49PM -0400, Mike Frysinger wrote:
> >On Tuesday 09 October 2007, Denys Vlasenko wrote:
> >> A question to people who work with NOMMU machines:
> >>
> >> Obviously, having small stack usage is important for small, NOMMU
> >> machines.
> >>
> >> However, after a certain point you cannot just eliminate stack
> >> usage, you must move it to other storage.
> >>
> >> For example, lineedit.c currently eats 12k+ if stack.
> >>
> >> I can convert it into malloc use.
> >>
> >> Question: is it better or actually worse?
> >> Line editing is invoked repeatedly, and repeated malloc/free of
> >> random-sized blocks can increase fragmentation
> >> -> increase memory consumption.
> >
> >it really depends on the size of the consumption ... on nommu, the
> >default stack is 4k, so i'd say if you're talking about more than 1k,
> >it should be a malloc ...
Ick... We have lots of ~4k stack users... and Makefile sets stack to 20k
IIRC, correct me if I'm wrong:
# Busybox is a stack-fatty so make sure we increase default size # TODO:
use "make stksizes" to find & fix big stack users # (we stole
scripts/checkstack.pl from the kernel... thanks guys!) FLTFLAGS += -s
20000
> AFAIK there was RESERVE_CONFIG_BUFFER for (potentially big) stack
users.
Yes. But it looks like _nobody_ benefits from big objects on stack.
So I intend to gradually move big stack users to malloc.
--
vda
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************
From rep.dot.nop at gmail.com Tue Oct 9 15:22:57 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Wed, 10 Oct 2007 00:22:57 +0200
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <200710092013.56786.vda.linux@googlemail.com>
References: <200710092013.56786.vda.linux@googlemail.com>
Message-ID: <20071009222257.GX20951@aon.at>
On Tue, Oct 09, 2007 at 08:13:56PM +0100, Denys Vlasenko wrote:
>Hi,
>
>In current svn:
>
>CONFIG_BUILD_LIBBUSYBOX works again,
Very nice. Thanks for your effort.
What do you think about also providing an option to use the normal
busybox as a whole as .so (i.e. a PIE)?
A potential use-case would be for people who currently clutter their
apps with system() calls. Those could use the normal foo_main() "API"
instead.
cheers,
From ynakam at hitachisoft.jp Tue Oct 9 16:58:04 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Wed, 10 Oct 2007 08:58:04 +0900
Subject: [patch] setsebool applet
Message-ID: <20071010084255.806C.YNAKAM@hitachisoft.jp>
Hi.
This patch is support for setsebool applet.
setsebool is to set boolean parameters of SELinux.
It is useful to manage SELinux system.
getsebool is included in BusyBox, but setsebool
is not included yet.
Please include this applet.
Regards,
--
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
SELinux Policy Editor: http://seedit.sourceforge.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setsebool.patch
Type: application/octet-stream
Size: 3029 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071010/f4125f76/attachment.obj
From vda.linux at googlemail.com Wed Oct 10 02:59:52 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 10 Oct 2007 10:59:52 +0100
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <200710092335.09630.yann.morin.1998@anciens.enib.fr>
References: <200710092013.56786.vda.linux@googlemail.com>
<200710092335.09630.yann.morin.1998@anciens.enib.fr>
Message-ID: <200710101059.52846.vda.linux@googlemail.com>
On Tuesday 09 October 2007 22:35, Yann E. MORIN wrote:
> On Tuesday 09 October 2007 21:13:56 Denys Vlasenko wrote:
> > In current svn:
> > CONFIG_BUILD_LIBBUSYBOX works again,
> > CONFIG_FEATURE_INDIVIDUAL now works too.
> > Run-tested on i386 glibc only, try on other arches.
>
> Breaks when cross-compiling (at least for ARM) on a x86_64:
>
> [--SNIP--]
> CC util-linux/switch_root.o
> CC util-linux/umount.o
> AR util-linux/lib.a
> LINK busybox_unstripped
> Trying libraries: crypt m
> Library crypt is needed
> Library m is needed
> Final link with: crypt m
> strip: Unable to recognise the format of the input file `0_lib/libbusybox.so.1.8.0.svn_unstripped'
> chmod: cannot access `0_lib/libbusybox.so.1.8.0.svn': No such file or directory
> libbusybox: 0_lib/libbusybox.so.1.8.0.svn
> Linking 0_lib/busybox_unstripped failed
> [--SNIP--]
>
> The reason is that we should use the cross-strip, rather than the native one,
> in scripts/trylink. Patch attached.
Applied, thanks.
--
vda
From vda.linux at googlemail.com Wed Oct 10 03:04:55 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 10 Oct 2007 11:04:55 +0100
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <20071009222257.GX20951@aon.at>
References: <200710092013.56786.vda.linux@googlemail.com>
<20071009222257.GX20951@aon.at>
Message-ID: <200710101104.55709.vda.linux@googlemail.com>
On Tuesday 09 October 2007 23:22, Bernhard Fischer wrote:
> On Tue, Oct 09, 2007 at 08:13:56PM +0100, Denys Vlasenko wrote:
> >Hi,
> >
> >In current svn:
> >
> >CONFIG_BUILD_LIBBUSYBOX works again,
>
> Very nice. Thanks for your effort.
>
> What do you think about also providing an option to use the normal
> busybox as a whole as .so (i.e. a PIE)?
It should be easy. I only need to look how e.g. glibc makes it so that
/lib/libc.so.6 is runnable by itself.
> A potential use-case would be for people who currently clutter their
> apps with system() calls. Those could use the normal foo_main() "API"
> instead.
foo_main() won't work in many cases. Many applets leak memory
("exiting frees it all anyway") or outright exit without returning
from main().
NOFORK applets are the only ones which are safe for such usage
(modulo bugs).
--
vda
From jw5 at os.inf.tu-dresden.de Wed Oct 10 02:57:57 2007
From: jw5 at os.inf.tu-dresden.de (Jean Wolter)
Date: Wed, 10 Oct 2007 11:57:57 +0200
Subject: ip tunnel parameter parsing bug
Message-ID: <86abqrthp6.fsf@erwin.inf.tu-dresden.de>
A non-text attachment was scrubbed...
Name: ip-tunnel.patch
Type: text/x-diff
Size: 655 bytes
Desc: ip tunnel parameter patch
Url : http://busybox.net/lists/busybox/attachments/20071010/4d6a958f/attachment.bin
From tomy at kalkitech.in Wed Oct 10 05:04:03 2007
From: tomy at kalkitech.in (tomy)
Date: Wed, 10 Oct 2007 17:34:03 +0530
Subject: busybox compilation error
Message-ID: <1253727029.20071010173403@kalkitech.in>
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20071010/cea53bbe/attachment.htm
From tomy at kalkitech.in Wed Oct 10 05:38:08 2007
From: tomy at kalkitech.in (tomy)
Date: Wed, 10 Oct 2007 18:08:08 +0530
Subject: busybox compilation error
Message-ID: <1882001093.20071010180808@kalkitech.in>
hi,
I am compiling busybox 1.7.2 using make "ARCH=armCROSS_COMPILE=armv5l-linux-", but while compiling it is giving an error like
Trying libraries: crypt m
Library crypt is needed
Library m is needed
Final link with: crypt m
What will be the reason for this.
After that I tried
"make ARCH=armCROSS_COMPILE=armv5l-linux- install" Then it is creating binaries, but all binaries are in big size (around 752K).
Why this much big size..
With Regards,
Tomy Devasia
From vda.linux at googlemail.com Wed Oct 10 07:38:11 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 10 Oct 2007 15:38:11 +0100
Subject: ip tunnel parameter parsing bug
In-Reply-To: <86abqrthp6.fsf@erwin.inf.tu-dresden.de>
References: <86abqrthp6.fsf@erwin.inf.tu-dresden.de>
Message-ID: <200710101538.12211.vda.linux@googlemail.com>
On Wednesday 10 October 2007 10:57, Jean Wolter wrote:
> Hello,
>
> in 1.7.1 ip tunnel ist not able to execute the following command:
>
> ip tunnel add 6in4 mode sit local 127.0.0.1 remote 212.224.0.188
>
> The attached patch fixes this.
Applied, thanks. Will be in 1.7.3
--
vda
From vda.linux at googlemail.com Wed Oct 10 07:54:27 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 10 Oct 2007 15:54:27 +0100
Subject: busybox compilation error
In-Reply-To: <1882001093.20071010180808@kalkitech.in>
References: <1882001093.20071010180808@kalkitech.in>
Message-ID: <200710101554.27593.vda.linux@googlemail.com>
On Wednesday 10 October 2007 13:38, tomy wrote:
> hi,
> I am compiling busybox 1.7.2 using make "ARCH=armCROSS_COMPILE=armv5l-linux-",
Hmm you have a typo above, I think.
> but while compiling it is giving an error like
> Trying libraries: crypt m
> Library crypt is needed
> Library m is needed
> Final link with: crypt m
> What will be the reason for this.
It's not an error. Do you have busybox executable after this step?
If yes, then it worked.
> After that I tried
> "make ARCH=armCROSS_COMPILE=armv5l-linux- install" Then it is creating binaries, but all binaries are in big size (around 752K).
>
> Why this much big size..
I personally don't use make install, maybe something is broken there.
Let me test...
$ make install
$ ls -l _install/bin
lrwxrwxrwx 1 vda eng 7 Oct 10 15:50 addgroup -> busybox
lrwxrwxrwx 1 vda eng 7 Oct 10 15:50 adduser -> busybox
lrwxrwxrwx 1 vda eng 7 Oct 10 15:50 ash -> busybox
-rwxr-xr-x 1 vda eng 751328 Oct 10 15:50 busybox
lrwxrwxrwx 1 vda eng 7 Oct 10 15:50 cat -> busybox
lrwxrwxrwx 1 vda eng 7 Oct 10 15:50 catv -> busybox
...
This was with CONFIG_INSTALL_APPLET_SYMLINKS=y
Without it:
$ ls -li _install/bin
7719226 -rwxr-xr-x 263 vda eng 751328 Oct 10 15:52 addgroup
7719226 -rwxr-xr-x 263 vda eng 751328 Oct 10 15:52 adduser
7719226 -rwxr-xr-x 263 vda eng 751328 Oct 10 15:52 ash
7719226 -rwxr-xr-x 263 vda eng 751328 Oct 10 15:52 busybox
7719226 -rwxr-xr-x 263 vda eng 751328 Oct 10 15:52 cat
7719226 -rwxr-xr-x 263 vda eng 751328 Oct 10 15:52 catv
....
These are all hardlinks to the same inode# 7719226.
IIUC make install works ok.
--
vda
From impulze at impulze.org Wed Oct 10 10:44:22 2007
From: impulze at impulze.org (Daniel Mierswa)
Date: Wed, 10 Oct 2007 19:44:22 +0200
Subject: ifupdown scripts (1.7.2 patch)
Message-ID: <470D0F76.6030705@impulze.org>
Hey guys,
i felt the need to provide a patch since probably some won't use those
scripts called if an interface comes up/down maybe because it also pulls
in run-parts (which wasn't selected in 1.7.2 anyway). So i provided a
patch which makes it all optional. Hope you guys can do something useful
with it. The patch applies fine to version 1.7.1 and 1.7.2. Other
versions weren't tested.
--
Mierswa, Daniel
If you still don't like it, that's ok: that's why I'm boss. I simply
know better than you do.
--- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.7.2-ifupdown_scripts.patch
Url: http://busybox.net/lists/busybox/attachments/20071010/4b46b3d9/attachment.diff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://busybox.net/lists/busybox/attachments/20071010/4b46b3d9/attachment.pgp
From impulze at impulze.org Wed Oct 10 11:00:35 2007
From: impulze at impulze.org (Daniel Mierswa)
Date: Wed, 10 Oct 2007 20:00:35 +0200
Subject: ifupdown scripts (1.7.2 patch)
In-Reply-To: <470D0F76.6030705@impulze.org>
References: <470D0F76.6030705@impulze.org>
Message-ID: <470D1343.3000003@impulze.org>
I forgot some tabs and added an extra whitespace in usage.h. I
re-submitted the patch with fixed whitespacing.
--
Mierswa, Daniel
If you still don't like it, that's ok: that's why I'm boss. I simply
know better than you do.
--- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.7.2-ifupdown_scripts.patch
Url: http://busybox.net/lists/busybox/attachments/20071010/71f0dbb2/attachment.diff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://busybox.net/lists/busybox/attachments/20071010/71f0dbb2/attachment.pgp
From vapier at gentoo.org Wed Oct 10 15:58:10 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 10 Oct 2007 18:58:10 -0400
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <200710101104.55709.vda.linux@googlemail.com>
References: <200710092013.56786.vda.linux@googlemail.com>
<20071009222257.GX20951@aon.at>
<200710101104.55709.vda.linux@googlemail.com>
Message-ID: <200710101858.10714.vapier@gentoo.org>
On Wednesday 10 October 2007, Denys Vlasenko wrote:
> On Tuesday 09 October 2007 23:22, Bernhard Fischer wrote:
> > On Tue, Oct 09, 2007 at 08:13:56PM +0100, Denys Vlasenko wrote:
> > >Hi,
> > >
> > >In current svn:
> > >
> > >CONFIG_BUILD_LIBBUSYBOX works again,
> >
> > Very nice. Thanks for your effort.
> >
> > What do you think about also providing an option to use the normal
> > busybox as a whole as .so (i.e. a PIE)?
>
> It should be easy. I only need to look how e.g. glibc makes it so that
> /lib/libc.so.6 is runnable by itself.
that's a different issue and one you shouldnt care about ... building busybox
as a PIE and exporting relevant symbols via --export-dynamic is what you
should check out i think ...
the libc.so hack just adds a little bit of code and sets it as the entry point
when generating the libc.so.6 ... it isnt a PIE
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20071010/bb267f68/attachment.pgp
From vapier at gentoo.org Wed Oct 10 16:00:32 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 10 Oct 2007 19:00:32 -0400
Subject: NOMMU: stack versus malloc?
In-Reply-To: <200710092134.02849.vda.linux@googlemail.com>
References: <200710091949.57439.vda.linux@googlemail.com>
<20071009194122.GS20951@aon.at>
<200710092134.02849.vda.linux@googlemail.com>
Message-ID: <200710101900.33383.vapier@gentoo.org>
On Tuesday 09 October 2007, Denys Vlasenko wrote:
> On Tuesday 09 October 2007 20:41, Bernhard Fischer wrote:
> > On Tue, Oct 09, 2007 at 02:56:49PM -0400, Mike Frysinger wrote:
> > >On Tuesday 09 October 2007, Denys Vlasenko wrote:
> > >> A question to people who work with NOMMU machines:
> > >>
> > >> Obviously, having small stack usage is important for
> > >> small, NOMMU machines.
> > >>
> > >> However, after a certain point you cannot just eliminate
> > >> stack usage, you must move it to other storage.
> > >>
> > >> For example, lineedit.c currently eats 12k+ if stack.
> > >>
> > >> I can convert it into malloc use.
> > >>
> > >> Question: is it better or actually worse?
> > >> Line editing is invoked repeatedly, and repeated malloc/free
> > >> of random-sized blocks can increase fragmentation
> > >> -> increase memory consumption.
> > >
> > >it really depends on the size of the consumption ... on nommu, the
> > > default stack is 4k, so i'd say if you're talking about more than 1k,
> > > it should be a malloc ...
>
> Ick... We have lots of ~4k stack users... and Makefile sets stack to 20k
> IIRC, correct me if I'm wrong:
>
> # Busybox is a stack-fatty so make sure we increase default size
> # TODO: use "make stksizes" to find & fix big stack users
> # (we stole scripts/checkstack.pl from the kernel... thanks guys!)
> FLTFLAGS += -s 20000
we set the stack to 20k because of all the fatty stack buffers ;) ... so this
is a chicken & egg argument
thinking about it more, fragmentation tends to be a much worse issue on no-mmu
than OOM, so allocating/freeing small buffers over the place would be
nasty ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20071010/46087326/attachment.pgp
From kaigai at ak.jp.nec.com Wed Oct 10 19:30:37 2007
From: kaigai at ak.jp.nec.com (KaiGai Kohei)
Date: Thu, 11 Oct 2007 11:30:37 +0900
Subject: [PATCH] SELinux support in passwd/chpasswd
Message-ID: <470D8ACD.2060401@ak.jp.nec.com>
Hi,
The attached patch provides two features related to SELinux.
The one is to preserve the security context of password files
when these are modified.
The other is additional checks in userspace. It prevents
root user can modify other's password entry without appropriate
permissions.
Please apply this patch, or reply your comment.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sebusybox-passwd.2.patch
Type: text/x-patch
Size: 2809 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20071011/001d9c32/attachment.bin
From Alexander at Kriegisch.name Wed Oct 10 23:11:05 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Thu, 11 Oct 2007 08:11:05 +0200
Subject: "exec /sbin/init" does not use inittab
Message-ID: <470DBE79.20908@Kriegisch.name>
Hi!
I use kernel_args init=/my/script on my embedded platform with BB 1.7.2.
Thus, my Ash shell script (sets up an NFS root) replaces init, but
explicitly calls it when done:
> exec /sbin/init
Thus, init gets PID 1 and starts working on /etc/init.d/rc.S (*not* rcS,
but rc.S).
My /etc/inittab looks like this:
> ::restart:/sbin/init
>
> # Start mini_fo before rc.S
> ::sysinit:/etc/init.d/rc.mini_fo
> ::sysinit:/etc/init.d/rc.S
>
> # Start an "askfirst" shell on the console
> ttyS0::askfirst:-/bin/sh
>
> # Stuff to do before rebooting
> ::shutdown:/bin/sh -c /var/post_install
The thing is, rc.mini_fo is not called. It would exit quickly and do
nothing but print some messages anyway in the case of an NFS root, but
at least it should be called. As soon as I decativate my kernel_args
'init=...' parameter, rc.mini_fo is called normally. The difference is
that in the former case init is called by the kernel, in the latter by
my custom init shell script.
Well, I am not an expert here and would like to know how I can make it
work. I read this in the description of init:
> This version of init is designed to be run only by the kernel.
But I do not know the implications of this warning. Init has several
menuconfig options which are currently defined as follows:
> [*] init
> [ ] debugging aid
> [*] Support reading an inittab file
> [ ] Support running commands with a controlling-tty
> [*] Enable init to write to syslog
> [ ] Be _extra_ quiet on boot
> [ ] Support dumping core for child processes (debugging only)
> [ ] Support running init from within an initrd (not initramfs)
> [*] poweroff, halt, and reboot
> [ ] mesg
Regards
--
Alexander Kriegisch
From landau_alex at yahoo.com Wed Oct 10 23:29:24 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Wed, 10 Oct 2007 23:29:24 -0700 (PDT)
Subject: NOMMU: stack versus malloc?
In-Reply-To:
Message-ID: <174463.93216.qm@web62509.mail.re1.yahoo.com>
--- Jate Sujjavanich wrote:
> The m68knommu device (Coldfire 5235) I've been working on has 16 MB of
> SDRAM, so fragmentation has been more of an issue for me than overall
> memory usage on uClinux. I say do things to reduce the memory usage
> without increasing fragmentation. On a system with less memory, it will
> eventually make your usable memory smaller no matter what total you have
> free.
>
> If you have a large buffer that must be used very often, I think you
> should malloc it once, make it static/force it into the data section, or
> place it on the stack. If it will be used only rarely, you might get
> away with with malloc'ing the small number of times it's used.
>
> Incidentally, the dreaded "unable to allocate memory" due to
> fragmentation reared its ugly head when I was debugging busybox/msh
> yesterday. After I restarted msh around 10 times.
>
> - Jate S.
>
I second that. Even on a 64MB Blackfin box, I saw many "unable to allocate memory"
messages due to fragmentation. Busybox was not the cause, but still I'd prefer not seeing
these messages.
Interestingly, switching toolchanins from bfin-uclinux to bfin-linux-uclibc made this
problem manifest itself much less often.
Alex
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
From Alexander at Kriegisch.name Wed Oct 10 23:33:50 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Thu, 11 Oct 2007 08:33:50 +0200
Subject: "exec /sbin/init" does not use inittab
In-Reply-To: <9b06e8d20710102316p403be59cod0b75be9463f6d0e@mail.gmail.com>
References: <470DBE79.20908@Kriegisch.name>
<9b06e8d20710102316p403be59cod0b75be9463f6d0e@mail.gmail.com>
Message-ID: <470DC3CE.7020809@Kriegisch.name>
Lo?c Greni?:
>> I use kernel_args init=/my/script on my embedded platform with BB 1.7.2.
>> Thus, my Ash shell script (sets up an NFS root) replaces init, but
>> explicitly calls it when done:
>>> exec /sbin/init
>
> Maybe you can try
>
> exec /sbin/init "$@"
Actually no. My script gets no arguments it could forward.
--
Alexander Kriegisch
From vasili3000 at hotmail.com Thu Oct 11 01:54:50 2007
From: vasili3000 at hotmail.com (Vassilios Zafiropoulos)
Date: Thu, 11 Oct 2007 08:54:50 +0000
Subject: login: This applet requires root privileges!
Message-ID:
dear list,
I am experiencing great problems booting a system from initramfs.
I am using a statically-built busybox binary as the initramfs system tool. The system itself, residing in a partition on the hard drive, is built from scratch using
buildroot, and has busybox, again.
After creating the initramfs archive, and linking it to the kernel, i would boot it inside qemu, and everything goes fine. I can mount all pseudo-filesystems, as required by mdev, and finally mount the 'real' root filesystem on a directory, local to the initramfs filesystem, namely /root.
Problems arise when i try to finish the bool process, executing the /root/sbin/init program.
Doing
# exec switch_root /root /sbin/init
does manage to run the init program, which spawns the login prompt, BUT
i can never log in because:
Welcome to the Erik's uClibc development environment.
uclibc login: root
login: This applet requires root privileges!
I am pretty desparate on this problem ,please help.
vasilis.
_________________________________________________________________
Connect to the next generation of MSN Messenger?
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
From vda.linux at googlemail.com Thu Oct 11 03:14:06 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 11 Oct 2007 11:14:06 +0100
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <200710101104.55709.vda.linux@googlemail.com>
References: <200710092013.56786.vda.linux@googlemail.com>
<20071009222257.GX20951@aon.at>
<200710101104.55709.vda.linux@googlemail.com>
Message-ID: <200710111114.06683.vda.linux@googlemail.com>
On Wednesday 10 October 2007 11:04, Denys Vlasenko wrote:
> On Tuesday 09 October 2007 23:22, Bernhard Fischer wrote:
> > On Tue, Oct 09, 2007 at 08:13:56PM +0100, Denys Vlasenko wrote:
> > >Hi,
> > >
> > >In current svn:
> > >
> > >CONFIG_BUILD_LIBBUSYBOX works again,
> >
> > Very nice. Thanks for your effort.
> >
> > What do you think about also providing an option to use the normal
> > busybox as a whole as .so (i.e. a PIE)?
>
> It should be easy. I only need to look how e.g. glibc makes it so that
> /lib/libc.so.6 is runnable by itself.
Bernhard, can you elaborate? Do you want to use libbusybox
as a "real" library "? I.e. link other programs against it
beside busybox apllets?
I added stuff to svn which makes libbusybox export _only_ XXX_main
functions. This minimizes size, but will preclude you from calling
any other function.
I looked into making libbusybox.so executanle itself, but
it looks like that needs a lot of linker magic for questionable
gain - I can have tiny (less than 3k) "busybox" executable
linked against it providing the same functionality.
Any specific reasons why do you like to have
PIE busybox-which-is-also-libbusybox?
--
vda
From vda.linux at googlemail.com Thu Oct 11 03:26:30 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 11 Oct 2007 11:26:30 +0100
Subject: NOMMU: stack versus malloc?
In-Reply-To: <200710101900.33383.vapier@gentoo.org>
References: <200710091949.57439.vda.linux@googlemail.com>
<200710092134.02849.vda.linux@googlemail.com>
<200710101900.33383.vapier@gentoo.org>
Message-ID: <200710111126.30727.vda.linux@googlemail.com>
> > > >> For example, lineedit.c currently eats 12k+ if stack.
> > > >>
> > > >> I can convert it into malloc use.
> > > >>
> > > >> Question: is it better or actually worse?
> > > >> Line editing is invoked repeatedly, and repeated malloc/free
> > > >> of random-sized blocks can increase fragmentation
> > > >> -> increase memory consumption.
> > > >
> > > >it really depends on the size of the consumption ... on nommu, the
> > > > default stack is 4k, so i'd say if you're talking about more than 1k,
> > > > it should be a malloc ...
> >
> > Ick... We have lots of ~4k stack users... and Makefile sets stack to 20k
> > IIRC, correct me if I'm wrong:
> >
> > # Busybox is a stack-fatty so make sure we increase default size
> > # TODO: use "make stksizes" to find & fix big stack users
> > # (we stole scripts/checkstack.pl from the kernel... thanks guys!)
> > FLTFLAGS += -s 20000
>
> we set the stack to 20k because of all the fatty stack buffers ;) ... so this
> is a chicken & egg argument
Argument? I'm not trying to argue here, I am trying to understand
the situation with stack usage on NOMMU front before I go and
"fix" stuff which maybe doesn't need fixing.
> thinking about it more, fragmentation tends to be a much worse issue on no-mmu
> than OOM, so allocating/freeing small buffers over the place would be
> nasty ...
How malloc works on NOMMU? What happens when you have no brk space because
there is another process "above" you? Any URLs to memory management
in userspace on NOMMU?
--
vda
From Johan.Adolfsson at axis.com Thu Oct 11 05:56:15 2007
From: Johan.Adolfsson at axis.com (Johan Adolfsson)
Date: Thu, 11 Oct 2007 14:56:15 +0200
Subject: NOMMU: stack versus malloc?
In-Reply-To: <200710111126.30727.vda.linux@googlemail.com>
Message-ID: <006901c80c06$1bf09d70$01935e0a@se.axis.com>
> > we set the stack to 20k because of all the fatty stack
> buffers ;) ... so this
> > is a chicken & egg argument
>
> Argument? I'm not trying to argue here, I am trying to understand
> the situation with stack usage on NOMMU front before I go and
> "fix" stuff which maybe doesn't need fixing.
>
> > thinking about it more, fragmentation tends to be a much
> worse issue on no-mmu
> > than OOM, so allocating/freeing small buffers over the
> place would be
> > nasty ...
>
> How malloc works on NOMMU? What happens when you have no brk
> space because
> there is another process "above" you? Any URLs to memory management
> in userspace on NOMMU?
> --
> vda
Sorry, no pointers but here are some thoughts I hopefully recall correctly
from the time before our chip got an MMU and we used NO_MMU uClinux and
uClibc.
Things may have improved a lot since then so take it with a grain of salt:
* uClibc has/had a few different allocator implementations
* I believe we used the one where each malloc() goes to the kernel to
allocate a chunk. The overhead of each allocated memory chunk was fairly
high
(32 bytes?)
* Fragmentation is a bitch - use the stack if you can.
If the page size is X, it was better to allocate X-overhead to avoid using
two pages if you dont really need the exact amount.
If you normally only need a small amount of memory I would say:
First have a small buffer on the stack - if more is needed use malloc().
That will probably cost a few extra bytes of code, but may be worth it in
terms of smaller normal stack usage and less fragmentation.
Could possibly be implemented something like this:
char staticbuf[BUF_SIZE];
char *buf = staticbuf;
buf = buf_realloc(buf, newsize, staticbuf);
buf_free(buf, staticbuf);
where buf_realloc() and buf_free() compares buf and staticbuf and does the
right thing (i.e. malloc() instead of realloc if buf == static
and no free if buf == staticbuf.
Some macro magic might hide the ugly details and make the behaviour
controlled by config options.
/Johan
From rep.dot.nop at gmail.com Thu Oct 11 07:23:04 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 11 Oct 2007 16:23:04 +0200
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <200710111114.06683.vda.linux@googlemail.com>
References: <200710092013.56786.vda.linux@googlemail.com>
<20071009222257.GX20951@aon.at>
<200710101104.55709.vda.linux@googlemail.com>
<200710111114.06683.vda.linux@googlemail.com>
Message-ID: <20071011142304.GA6458@aon.at>
On Thu, Oct 11, 2007 at 11:14:06AM +0100, Denys Vlasenko wrote:
>On Wednesday 10 October 2007 11:04, Denys Vlasenko wrote:
>> On Tuesday 09 October 2007 23:22, Bernhard Fischer wrote:
>> > On Tue, Oct 09, 2007 at 08:13:56PM +0100, Denys Vlasenko wrote:
>> > >Hi,
>> > >
>> > >In current svn:
>> > >
>> > >CONFIG_BUILD_LIBBUSYBOX works again,
>> >
>> > Very nice. Thanks for your effort.
>> >
>> > What do you think about also providing an option to use the normal
>> > busybox as a whole as .so (i.e. a PIE)?
>>
>> It should be easy. I only need to look how e.g. glibc makes it so that
>> /lib/libc.so.6 is runnable by itself.
>
>Bernhard, can you elaborate? Do you want to use libbusybox
>as a "real" library "? I.e. link other programs against it
>beside busybox apllets?
I was more thinking about exporting a (rather complete; nm -g
--defined-only) sym table via the busybox binary itself. This would be
an alternative to the separate libbusybox from the 1.[23].x series.
>I added stuff to svn which makes libbusybox export _only_ XXX_main
>functions. This minimizes size, but will preclude you from calling
>any other function.
>
>I looked into making libbusybox.so executanle itself, but
>it looks like that needs a lot of linker magic for questionable
>gain - I can have tiny (less than 3k) "busybox" executable
>linked against it providing the same functionality.
>
>Any specific reasons why do you like to have
>PIE busybox-which-is-also-libbusybox?
I don't have a real use-case right now (I used to do this a while back
for XXX_main and some helpers from libbb, fwiw)
but it could be used to either
-) use XXX_main in other progs
-) use stuff from {*/,}lib*/*c in other progs
-) replace zlib, provided that a compatible interface is exported (not
yet implemented, IIRC)
The zlib case would be a very, very nice thing to have, IMO (in case you
already drained your TODO list too much :)
What do you think?
From vapier at gentoo.org Thu Oct 11 07:33:34 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 11 Oct 2007 10:33:34 -0400
Subject: NOMMU: stack versus malloc?
In-Reply-To: <174463.93216.qm@web62509.mail.re1.yahoo.com>
References: <174463.93216.qm@web62509.mail.re1.yahoo.com>
Message-ID: <200710111033.35128.vapier@gentoo.org>
On Thursday 11 October 2007, Alex Landau wrote:
> Interestingly, switching toolchanins from bfin-uclinux to bfin-linux-uclibc
> made this problem manifest itself much less often.
makes perfect sense ... FLAT files do not share anything and so require a big
fat contiguous region everytime they get executed ... FDPIC ELF files share
all .text sections and only require the writable .data to be allocated
everytime they get executed
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20071011/0f7b6beb/attachment.pgp
From Alexander at Kriegisch.name Thu Oct 11 08:11:16 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Thu, 11 Oct 2007 17:11:16 +0200
Subject: "exec /sbin/init" does not use inittab
In-Reply-To: <470DBE79.20908@Kriegisch.name>
References: <470DBE79.20908@Kriegisch.name>
Message-ID: <470E3D14.5070700@Kriegisch.name>
Hi!
I just learned that I am stupid the hard way:
> I use kernel_args init=/my/script on my embedded platform with BB
> 1.7.2. Thus, my Ash shell script (sets up an NFS root) replaces init,
> but explicitly calls it when done:
>> exec /sbin/init
Actually my code was
> exec /sbin/init >/dev/console 2>&1
but /dev/console was still a normal file on my NFS root, because
makedevs had not run yet. Thus, the output went to that file instead of
to my serial console. Doh! #-)
Forgive me, init does exactly what it is supposed to.
--
Alexander Kriegisch
From vda.linux at googlemail.com Thu Oct 11 10:49:07 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 11 Oct 2007 18:49:07 +0100
Subject: libbusybox is back; "individual" mode is introduced
In-Reply-To: <20071011142304.GA6458@aon.at>
References: <200710092013.56786.vda.linux@googlemail.com>
<200710111114.06683.vda.linux@googlemail.com>
<20071011142304.GA6458@aon.at>
Message-ID: <200710111849.07328.vda.linux@googlemail.com>
On Thursday 11 October 2007 15:23, Bernhard Fischer wrote:
> >I looked into making libbusybox.so executanle itself, but
> >it looks like that needs a lot of linker magic for questionable
> >gain - I can have tiny (less than 3k) "busybox" executable
> >linked against it providing the same functionality.
> >
> >Any specific reasons why do you like to have
> >PIE busybox-which-is-also-libbusybox?
>
> I don't have a real use-case right now (I used to do this a while back
> for XXX_main and some helpers from libbb, fwiw)
> but it could be used to either
> -) use XXX_main in other progs
> -) use stuff from {*/,}lib*/*c in other progs
> -) replace zlib, provided that a compatible interface is exported (not
> yet implemented, IIRC)
As of today, *all* busybox code goes to libbusybox
if CONFIG_BUILD_LIBBUSYBOX=y, busybox binary is only
a really trivial thunk:
text data bss dec hex filename
988 260 4 1252 4e4 busybox
745254 12570 12032 769856 bbf40 libbusybox.so.1.8.0.svn
This basically gives you what you want in terms
of minimizing size of the on-disk files.
PIE approach will combine these two files. Maybe it is
aesthetically nicer, but no real win in size.
> The zlib case would be a very, very nice thing to have, IMO
You mean - ability to use zlip (de)compressor from busybox?
> (in case you
> already drained your TODO list too much :)
My TODO list is
- have NOMMU test config running in qemu (need help with this)
- attack "invisible" sources of mem consumption,
like stack usage
- phase out lash in favor of hush
- improve hush
--
vda
From vda.linux at googlemail.com Thu Oct 11 12:30:36 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 11 Oct 2007 20:30:36 +0100
Subject: login: This applet requires root privileges!
In-Reply-To:
References:
Message-ID: <200710112030.36591.vda.linux@googlemail.com>
On Thursday 11 October 2007 09:54, Vassilios Zafiropoulos wrote:
>
> dear list,
>
> I am experiencing great problems booting a system from initramfs.
> I am using a statically-built busybox binary as the initramfs system tool. The system itself, residing in a partition on the hard drive, is built from scratch using
> buildroot, and has busybox, again.
>
> After creating the initramfs archive, and linking it to the kernel, i would boot it inside qemu, and everything goes fine. I can mount all pseudo-filesystems, as required by mdev, and finally mount the 'real' root filesystem on a directory, local to the initramfs filesystem, namely /root.
>
> Problems arise when i try to finish the bool process, executing the /root/sbin/init program.
> Doing
> # exec switch_root /root /sbin/init
> does manage to run the init program, which spawns the login prompt, BUT
> i can never log in because:
>
> Welcome to the Erik's uClibc development environment.
>
> uclibc login: root
> login: This applet requires root privileges!
you seem to run getty's not under uid 0.
If applet is run under uid 0, you cannot reach that message:
static void check_suid(const struct bb_applet *applet)
{
gid_t rgid; /* real gid */
if (ruid == 0) /* set by parse_config_file() */
return; /* run by root - no need to check more */
...
if (applet->need_suid == _BB_SUID_ALWAYS) {
/* Real uid is not 0. If euid isn't 0 too, suid bit
* is most probably not set on our executable */
if (geteuid())
bb_error_msg_and_die("applet requires root privileges!");
--
vda
From loic.grenie at gmail.com Thu Oct 11 12:49:42 2007
From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=)
Date: Thu, 11 Oct 2007 21:49:42 +0200
Subject: kbd_mode
Message-ID: <9b06e8d20710111249h41533424n25ee1b1d56d08b82@mail.gmail.com>
This patch to add a kbd_mode applet.
It supports neither long options nor -m "mode" option.
Bloatiness:
% ./scripts/bloat-o-meter busybox_unpatched busybox_unstripped
function old new delta
.rodata 61791 62006 +215
kbd_mode_main - 182 +182
packed_usage 12107 12184 +77
applets 1596 1608 +12
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 3/0 up/down: 486/0) Total: 486 bytes
From Alexander at Kriegisch.name Thu Oct 11 19:34:05 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Fri, 12 Oct 2007 04:34:05 +0200
Subject: Ash + telnetd: telnet client hangs after exit
Message-ID: <470EDD1D.2090201@Kriegisch.name>
BB 1.7.2 and many old versions down to 1.4.x, I don't know exactly.
Platform: mipsel
We have had this problem for months, maybe 1-2 years, with different BB
versions, but now I think it is time to report it:
On my embedded system there is BB running telnetd. The shell is ash. A
client logs in and works until he types "exit". After that the session
is terminated, but the telnet client hanngs waiting for - I don't know
what. I can reproduce it with several telnet clients. It does not happen
with Dropbear sshd, so I strongly assume it is a BB problem.
Interestingly, the session exits cleanly if I call "setconsole -r"
during the telnet session.
I have attached two sets of log files generated like this:
> strace -p 1186 -p 742 -f -ff -s 100 -o /ash-telnet-ok.log
PID 742 is telnetd, 1131/1186 are ash, respectively. The ash protocols
are just there for completeness, they are identical. The telnetd logs
differ, though.
Maybe somebody can find out what is wrong here. It might be a similar
case to "ash endless loop after ssh client is killed" (April 20-29,
2007), I don't know.
Regards
--
Alexander Kriegisch
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ash-telnet-ok.log.742
Url: http://busybox.net/lists/busybox/attachments/20071012/285decf4/attachment.diff
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ash-telnet-bad.log.742
Url: http://busybox.net/lists/busybox/attachments/20071012/285decf4/attachment-0001.diff
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ash-telnet-ok.log.1186
Url: http://busybox.net/lists/busybox/attachments/20071012/285decf4/attachment-0002.diff
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ash-telnet-bad.log.1131
Url: http://busybox.net/lists/busybox/attachments/20071012/285decf4/attachment-0003.diff
From kothamasusatish at gmail.com Thu Oct 11 21:18:18 2007
From: kothamasusatish at gmail.com (satish kumar)
Date: Fri, 12 Oct 2007 09:48:18 +0530
Subject: cramfs optimization ...
Message-ID: <80154fc80710112118t142149b2q601c8fd8e1ec34d4@mail.gmail.com>
hi all,
iam trying to implement readpages instead of readpage for cramfs
... is anybody dng same ??
how to improve cramfs readpage?..
regards
satish
From rajeevb at intoto.com Thu Oct 11 23:23:20 2007
From: rajeevb at intoto.com (Rajeev Bansal)
Date: Fri, 12 Oct 2007 11:53:20 +0530
Subject: Unable to mount root fs on unknown-block(202,3)
Message-ID: <470F12D8.5030505@intoto.com>
Hello All,
I am trying to build a custom initrd using the busybox. In my initrd I
have modified the /sbin/init to a init script which I am mentioning below,
#!/bin/sh -e
# Set up filesystem as root and pivot into it.
export PATH
insmod /lib/uhci-hcd.ko
insmod /lib/ohci-hcd.ko
insmod /lib/ehci-hcd.ko
insmod /lib/mbcache.ko
insmod /lib/jbd.ko
insmod /lib/ext3.ko
insmod /lib/scsi_mod.ko
insmod /lib/sd_mod.ko
insmod /lib/libata.ko
insmod /lib/ata_generic.ko
insmod /lib/ata_piix.ko
insmod /lib/scsi_wait_scan.ko
insmod /lib/sg.ko
rmmod scsi_wait_scan.ko
insmod /lib/e1000.ko
mount /proc
umount initrd 2>/dev/null || true
mount -t tmpfs -o size=100M tmpfs /
umount /proc
cp -a $(ls -1 / |grep -v '\(lost+found\|mnt\|proc\)') /mnt
cd /mnt
mkdir proc
mount /proc
/bin/bash --login
I burnt an ISO image in a CD with this initrd and Kernel image, when I
tries to boot using the CD I am getting the following logs on the kernel
and in last my Kernel gives the Panic.
ISOLINUX 3.51 2007-06-10 Copyright (C) 1994-2007 H. Peter Anvin
boot:
Loading /install.386/vmlinuz.................................
Loading
/install.386/initrd.gz..................................................
................................................................................
...................................................................
Ready.
Linux version 2.6.21-1.3194.fc7
(kojibuilder at xenbuilder4.fedora.phx.redhat.com)
(gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Wed May 23
22:35:01 EDT 2
007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009e000 end:
000000000009
e000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009e000 size: 0000000000002000 end:
00000000000a
0000 type: 2
copy_e820_map() start: 00000000000e4000 size: 000000000001c000 end:
000000000010
0000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000003fde0000 end:
000000003fee
0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000003fee0000 size: 0000000000009000 end:
000000003fee
9000 type: 3
copy_e820_map() start: 000000003fee9000 size: 0000000000017000 end:
000000003ff0
0000 type: 4
copy_e820_map() start: 000000003ff00000 size: 0000000000100000 end:
000000004000
0000 type: 2
copy_e820_map() start: 00000000fec00000 size: 0000000000010000 end:
00000000fec1
0000 type: 2
copy_e820_map() start: 00000000fee00000 size: 0000000000001000 end:
00000000fee0
1000 type: 2
copy_e820_map() start: 00000000ff000000 size: 0000000001000000 end:
000000010000
0000 type: 2
BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
BIOS-e820: 000000003fee0000 - 000000003fee9000 (ACPI data)
BIOS-e820: 000000003fee9000 - 000000003ff00000 (ACPI NVS)
BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
126MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f5ff0
Using x86 segment limits to approximate NX protection
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 229376
HighMem 229376 -> 261856
early_node_map[1] active PFN ranges
0: 0 -> 261856
DMI present.
Using APIC driver default
ACPI: RSDP 000F5FC0, 0014 (r0 PTLTD )
ACPI: RSDT 3FEE2C62, 0038 (r1 PTLTD RSDT 6040000 LTP 0)
ACPI: FACP 3FEE8EC2, 0074 (r1 INTEL 6040000 PTL 3)
ACPI: DSDT 3FEE4086, 4E3C (r1 INTEL GLENWOOD 6040000 MSFT 100000E)
ACPI: FACS 3FEE9FC0, 0040
ACPI: MCFG 3FEE8F36, 003C (r1 PTLTD MCFG 6040000 LTP 0)
ACPI: APIC 3FEE8F72, 0066 (r1 PTLTD APIC 6040000 LTP 0)
ACPI: BOOT 3FEE8FD8, 0028 (r1 PTLTD $SBFTBL$ 6040000 LTP 1)
ACPI: SSDT 3FEE2C9A, 13EC (r1 PmRef CpuPm 3000 INTL 20050228)
ACPI: PM-Timer IO Port: 0x1008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfecc0000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 32, address 0xfecc0000, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode: Flat. Using 2 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
Built 1 zonelists. Total pages: 259811
Kernel command line: vga=normal initrd=/install.386/initrd.gz
console=ttyS0,9600
BOOT_IMAGE=/install.386/vmlinuz
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c077c000 soft=c075c000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 3192.217 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1020936k/1047424k available (2066k kernel code, 25736k reserved,
1092k d
ata, 240k init, 129920k highmem)
virtual kernel memory layout:
fixmap : 0xffc56000 - 0xfffff000 (3748 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB)
lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
.init : 0xc071b000 - 0xc0757000 ( 240 kB)
.data : 0xc0604a4a - 0xc0715cb4 (1092 kB)
.text : 0xc0400000 - 0xc0604a4a (2066 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6387.45 BogoMIPS
(lpj=3193727)
Security Framework v1.0.0 initialized
SELinux: Initializing.
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 14k freed
ACPI: Core revision 20070126
CPU0: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 0a
Total of 1 processors activated (6387.45 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Brought up 1 CPUs
Time: 6:02:57 Date: 09/12/107
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd72e, last bus=15
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: PXH quirk detected, disabling MSI for SHPC device
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 11 14 15) *5
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 *10 11 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
Time: tsc clocksource has been installed.
pnp: 00:01: iomem range 0xfed14000-0xfed17fff has been reserved
pnp: 00:01: iomem range 0xfed13000-0xfed13fff has been reserved
pnp: 00:01: iomem range 0xfed18000-0xfed1bfff has been reserved
pnp: 00:01: iomem range 0xf0000000-0xf3ffffff has been reserved
PCI: Bridge: 0000:01:00.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: ee100000-ee1fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.0
IO window: 4000-4fff
MEM window: ee200000-ee2fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
IO window: 5000-5fff
MEM window: ee300000-ee3fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.2
IO window: 6000-6fff
MEM window: ee400000-ee4fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.3
IO window: 7000-7fff
MEM window: ee500000-ee5fffff
PREFETCH window: disabled.
PCI: Ignore bogus resource 6 [0:0] of 0000:0f:00.0
PCI: Bridge: 0000:00:1e.0
IO window: 8000-8fff
MEM window: ee600000-ee6fffff
PREFETCH window: ef000000-efffffff
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1572864 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
checking if image is initramfs...<6>Switched to high resolution mode on
CPU 0
it is
Freeing initrd memory: 12436k freed
Simple Boot Flag at 0x38 set to 0x1
apm: BIOS not found.
audit: initializing netlink socket (disabled)
audit(1192168974.269:1): initialized
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
ksign: Installing public key data
Loading keyring
- Added public key 65F8109C338BBD41
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is
not pres
ent [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is
not pres
ent [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is
not pres
ent [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is
not pres
ent [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is
not pres
ent [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is
not pres
ent [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is
not pres
ent [20070126]
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.102 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
?serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:0a: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
usbcore: registered new interface driver libusual
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: PS/2 Controller [PNP0303:KBC0,PNP0f13:MSE0] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
Magic number: 11:520:13
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
VFS: Cannot open root device "" or unknown-block(202,3)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(202,3)
Please let me know what I am missing in the configuration.
Thanks
Rajeev Bansal.
********************************************************************************
This email message (including any attachments) is for the sole use of the intended recipient(s)
and may contain confidential, proprietary and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended recipient,
please immediately notify the sender by reply email and destroy all copies of the original message.
Thank you.
Intoto Inc.
From chris at edesix.com Fri Oct 12 01:41:45 2007
From: chris at edesix.com (Chris Paulson-Ellis)
Date: Fri, 12 Oct 2007 09:41:45 +0100
Subject: [PATCH] httpd: request file range support
Message-ID: <470F3349.2030700@edesix.com>
This patch adds a new FEATURE_HTTPD_RANGE supporting partial file downloads, requested with the HTTP Range header.
I have tested all 4 combinations of FEATURE_HTTPD_RANGE & FEATURE_HTTPD_USE_SENDFILE.
Regards,
Chris.
---
--- busybox-1.7.2/networking/Config.in.orig 2007-09-03 12:48:27.000000000 +0100
+++ busybox-1.7.2/networking/Config.in 2007-10-11 17:54:08.000000000 +0100
@@ -183,6 +183,14 @@
'/path/e404.html' file instead of the terse '404 NOT FOUND'
message.
+config FEATURE_HTTPD_RANGE
+ bool "Enable support for partial file requests"
+ default n
+ depends on HTTPD
+ help
+ This option adds support for the HTTP Range header. Only
+ a single range per request in byte units is supported.
+
config IFCONFIG
bool "ifconfig"
default n
--- busybox-1.7.2/networking/httpd.c.orig 2007-09-30 00:54:12.000000000 +0100
+++ busybox-1.7.2/networking/httpd.c 2007-10-11 17:52:02.000000000 +0100
@@ -253,6 +253,10 @@
#if ENABLE_FEATURE_HTTPD_ERROR_PAGES
const char *http_error_page[ARRAY_SIZE(http_response_type)];
#endif
+#if ENABLE_FEATURE_HTTPD_RANGE
+ off_t range_start; /* -1 - unspecified */
+ off_t range_end; /* -1 - unspecified */
+#endif
};
#define G (*ptr_to_globals)
#define verbose (G.verbose )
@@ -279,11 +283,15 @@
#define hdr_ptr (G.hdr_ptr )
#define hdr_cnt (G.hdr_cnt )
#define http_error_page (G.http_error_page )
+#define range_start (G.range_start )
+#define range_end (G.range_end )
#define INIT_G() do { \
PTR_TO_GLOBALS = xzalloc(sizeof(G)); \
USE_FEATURE_HTTPD_BASIC_AUTH(g_realm = "Web Server Authentication";) \
bind_addr_or_port = "80"; \
ContentLength = -1; \
+ USE_FEATURE_HTTPD_RANGE(range_start = -1;) \
+ USE_FEATURE_HTTPD_RANGE(range_end = -1;) \
} while (0)
@@ -921,6 +929,30 @@
}
#endif
+#if ENABLE_FEATURE_HTTPD_RANGE
+ if( ContentLength == -1 ) {
+ range_start = -1;
+ range_end = -1;
+ } else if (range_start == -1 && range_end != -1) {
+ /* range_end is suffix length */
+ range_start = ContentLength - range_end;
+ range_end = ContentLength - 1;
+ } else if (range_start != -1 && range_end == -1) {
+ range_end = ContentLength - 1;
+ }
+
+ if (range_start != -1 && range_end != -1) {
+ if (range_end >= ContentLength || range_end < range_start) {
+ range_start = -1;
+ range_end = -1;
+ } else {
+ len += sprintf(iobuf + len, "Content-Range: bytes %"OFF_FMT"d-%"OFF_FMT"d/%"OFF_FMT"d\r\n",
+ range_start, range_end, ContentLength);
+ ContentLength = range_end - range_start + 1;
+ }
+ }
+#endif
+
if (ContentLength != -1) { /* file */
strftime(tmp_str, sizeof(tmp_str), RFC1123FMT, gmtime(&last_mod));
len += sprintf(iobuf + len, "Last-Modified: %s\r\n%s %"OFF_FMT"d\r\n",
@@ -1372,6 +1404,7 @@
const char *const *table;
const char *try_suffix;
ssize_t count;
+ size_t remaining;
#if ENABLE_FEATURE_HTTPD_USE_SENDFILE
off_t offset = 0;
#endif
@@ -1424,24 +1457,45 @@
signal(SIGPIPE, SIG_IGN);
#if ENABLE_FEATURE_HTTPD_USE_SENDFILE
+#if ENABLE_FEATURE_HTTPD_RANGE
+ if (range_start != -1) {
+ offset = range_start;
+ remaining = ContentLength;
+ } else
+#endif
+ remaining = MAXINT(ssize_t) - 0xffff;
do {
/* byte count (3rd arg) is rounded down to 64k */
- count = sendfile(1, f, &offset, MAXINT(ssize_t) - 0xffff);
+ count = sendfile(1, f, &offset, remaining);
if (count < 0) {
if (offset == 0)
goto fallback;
goto fin;
}
+#if ENABLE_FEATURE_HTTPD_RANGE
+ if (range_start != -1)
+ remaining -= count;
+#endif
} while (count > 0);
log_and_exit();
fallback:
#endif
- while ((count = safe_read(f, iobuf, IOBUF_SIZE)) > 0) {
+#if ENABLE_FEATURE_HTTPD_RANGE
+ if (range_start != -1) {
+ remaining = ContentLength;
+ } else
+#endif
+ remaining = IOBUF_SIZE;
+ while ((count = safe_read(f, iobuf, MIN(remaining, IOBUF_SIZE))) > 0) {
ssize_t n = count;
count = full_write(1, iobuf, count);
if (count != n)
break;
+#if ENABLE_FEATURE_HTTPD_RANGE
+ if (range