From roberto.foglietta at gmail.com Fri Dec 1 00:11:37 2006 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Fri, 1 Dec 2006 09:11:37 +0100 Subject: busybox current status In-Reply-To: <200611301410.07437.rob@landley.net> References: <200611300014.47607.vda.linux@googlemail.com> <200611301410.07437.rob@landley.net> Message-ID: 2006/11/30, Rob Landley : > On Thursday 30 November 2006 7:20 am, Roberto A. Foglietta wrote: > > 2006/11/30, Denis Vlasenko : > > sorry but I have not SVN access, so I have to use daily snapshots. > > Everybody has anonymous svn access. You can check stuff out any time you like > without any credentials, you just can't check anything _in_ without an ssh > account. The company firewall blocks every connections execpt throught port 80 Cheers, -- /roberto From farmatito at tiscali.it Fri Dec 1 05:08:56 2006 From: farmatito at tiscali.it (Tito) Date: Fri, 1 Dec 2006 14:08:56 +0100 Subject: [PATCH] passwd more size reduction. In-Reply-To: <200612010021.27556.vda.linux@googlemail.com> References: <200611302215.02857.farmatito@tiscali.it> <200612010021.27556.vda.linux@googlemail.com> Message-ID: <200612011408.56500.farmatito@tiscali.it> On Friday 01 December 2006 00:21, Denis Vlasenko wrote: > On Thursday 30 November 2006 22:15, Tito wrote: > > Hi, > > this patchreduces size of passwd. > > Bloatmeter says: > > function old new delta > > passwd_main 1771 1779 +8 > > .rodata 134358 134102 -256 > > ------------------------------------------------------------------------------ > > (add/remove: 0/0 grow/shrink: 1/1 up/down: 8/-256) Total: -248 bytes > > > > but it seems not taking into account the removal of > > the static void set_filesize_limit(int blocks) > > function. > > Too late. ;) I just cut it down by 500 bytes. > > # size passwd.o > text data bss dec hex filename > 2805 0 0 2805 af5 passwd.o > > bbox 1.2.1: > size passwd.o > text data bss dec hex filename > 4674 0 160 4834 12e2 passwd.o > > Current svn version is attached. > -- > vda > Hi Denis, you can use this patch as it applies just with some fuzz to current svn: root at box:~/Desktop/busybox/loginutils# patch -p1 -E Hi, Ever since the str_to_num (sp?) changes, trunk fails to build for me with the errors below. LD applets/built-in.o applets/busybox.o: In function `bb_strtoi': busybox.c:(.text.bb_strtoi+0x0): multiple definition of `bb_strtoi' applets/applets.o:applets.c:(.text.bb_strtoi+0x0): first defined here applets/busybox.o: In function `bb_strtou': busybox.c:(.text.bb_strtou+0x0): multiple definition of `bb_strtou' applets/applets.o:applets.c:(.text.bb_strtou+0x0): first defined here applets/busybox.o: In function `bb_strtou32': busybox.c:(.text.bb_strtou32+0x0): multiple definition of `bb_strtou32' applets/applets.o:applets.c:(.text.bb_strtou32+0x0): first defined here applets/busybox.o: In function `xatoi': busybox.c:(.text.xatoi+0x0): multiple definition of `xatoi' applets/applets.o:applets.c:(.text.xatoi+0x0): first defined here applets/busybox.o: In function `xatoi_sfx': busybox.c:(.text.xatoi_sfx+0x0): multiple definition of `xatoi_sfx' applets/applets.o:applets.c:(.text.xatoi_sfx+0x0): first defined here applets/busybox.o: In function `xatoi_range': busybox.c:(.text.xatoi_range+0x0): multiple definition of `xatoi_range' applets/applets.o:applets.c:(.text.xatoi_range+0x0): first defined here applets/busybox.o: In function `xatoi_range_sfx': busybox.c:(.text.xatoi_range_sfx+0x0): multiple definition of `xatoi_range_sfx' applets/applets.o:applets.c:(.text.xatoi_range_sfx+0x0): first defined here applets/busybox.o: In function `xstrtoi_range': busybox.c:(.text.xstrtoi_range+0x0): multiple definition of `xstrtoi_range' applets/applets.o:applets.c:(.text.xstrtoi_range+0x0): first defined here applets/busybox.o: In function `xstrtoi_range_sfx': busybox.c:(.text.xstrtoi_range_sfx+0x0): multiple definition of `xstrtoi_range_sfx' applets/applets.o:applets.c:(.text.xstrtoi_range_sfx+0x0): first defined here applets/busybox.o: In function `xatou': busybox.c:(.text.xatou+0x0): multiple definition of `xatou' applets/applets.o:applets.c:(.text.xatou+0x0): first defined here applets/busybox.o: In function `xatou32': busybox.c:(.text.xatou32+0x0): multiple definition of `xatou32' etc, etc. I had a patch somewhere, but apparently a 'make clean' happily rm'ed my *.diff. Quite annoying. From rob at landley.net Fri Dec 1 10:41:19 2006 From: rob at landley.net (Rob Landley) Date: Fri, 1 Dec 2006 13:41:19 -0500 Subject: busybox current status In-Reply-To: References: <200611300014.47607.vda.linux@googlemail.com> <200611301410.07437.rob@landley.net> Message-ID: <200612011341.20521.rob@landley.net> On Friday 01 December 2006 3:11 am, Roberto A. Foglietta wrote: > 2006/11/30, Rob Landley : > > On Thursday 30 November 2006 7:20 am, Roberto A. Foglietta wrote: > > > 2006/11/30, Denis Vlasenko : > > > sorry but I have not SVN access, so I have to use daily snapshots. > > > > Everybody has anonymous svn access. You can check stuff out any time you like > > without any credentials, you just can't check anything _in_ without an ssh > > account. > > The company firewall blocks every connections execpt throught port 80 I know mercurial can be accessed entirely through http (hg co static-http://blah/blah/blah) but when I just downloaded tailor and tried to convert the svn repository to hg to throw a copy in the ~landley directory on busybox, it died because busybox.net's version of svn is too old (doesn't support the --limit command to svn log). Sorry about your company. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From vda.linux at googlemail.com Fri Dec 1 13:39:06 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Fri, 1 Dec 2006 22:39:06 +0100 Subject: [PATCH] passwd more size reduction. In-Reply-To: <200612011408.56500.farmatito@tiscali.it> References: <200611302215.02857.farmatito@tiscali.it> <200612010021.27556.vda.linux@googlemail.com> <200612011408.56500.farmatito@tiscali.it> Message-ID: <200612012239.06448.vda.linux@googlemail.com> On Friday 01 December 2006 14:08, Tito wrote: > Hi Denis, > you can use this patch as it applies just with some fuzz > to current svn: > > root at box:~/Desktop/busybox/loginutils# patch -p1 -E patching file passwd.c > Hunk #1 succeeded at 52 (offset 8 lines). > Hunk #2 succeeded at 61 (offset 8 lines). > Hunk #3 succeeded at 75 (offset 8 lines). > Hunk #4 succeeded at 111 (offset 6 lines). > Hunk #5 succeeded at 138 (offset 6 lines). > Hunk #6 succeeded at 226 (offset 6 lines). > Hunk #7 succeeded at 247 (offset 6 lines). > Hunk #8 succeeded at 267 (offset 6 lines). > Hunk #9 succeeded at 325 (offset 6 lines). > > I inspected the patched file and compile tested it and everything seems to be ok. Applied with minor changes. Thanks. -- vda From psmith at netezza.com Fri Dec 1 14:35:18 2006 From: psmith at netezza.com (Paul Smith) Date: Fri, 01 Dec 2006 17:35:18 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <200611300044.51959.vda.linux@googlemail.com> References: <1164825325.14542.15.camel@localhost> <200611300044.51959.vda.linux@googlemail.com> Message-ID: <1165012518.14542.199.camel@localhost> On Thu, 2006-11-30 at 00:44 +0100, Denis Vlasenko wrote: > On Wednesday 29 November 2006 19:35, Paul Smith wrote: > > > > This works fine if I run that command from the shell, but it fails > > during a real reboot. Annotating the script I can see that when I kill > > the process it dies, but it's still there as a zombie (Z), so pidof > > still finds it and thinks that it hasn't died yet. > > > > I'm assuming that while busybox init is running my script, it's not > > handling SIGCHLD signals and cleaning up zombies like it usually does, > > so that's why my process is never reaped. > > > > > > Now, of course I could make my script more complex and use ps with awk > > or sed to find the pids of only non-zombie versions of my daemons, but > > it seems like init should not leave zombies around like this. There are > > a number of options, of course: the simplest one might be to set SIG_IGN > > on SIGCHLD before init starts shutdown processing. Because we're > > rebooting anyway we don't really need to handle SIGCHLD anymore, and > > SIG_IGN will let the kernel clean up the process immediately. > > Please try it, and send a patch. Of course, once you look at the code life gets more complex :). The loop in init starts any unstarted RESPAWN and ASKFIRST commands, then it sleeps for one second, then it does a wait() to sleep until one of its children dies. Once that happens it reaps all the children that have died: for each one it sets the PID to 0, then it goes back to the beginning of the loop. Since the PID is 0, the RESPAWN and ASKFIRST commands that exited will be restarted. Then we sleep for 1 second, wait for a child death, reap children, and on and on. So, the problem I'm seeing is because the same run() function is used to start a command regardless of why it's being started (the state of the system). This is nice, but the standard run() command will block all signals, including SIGCHLD, while the command is being run. This makes sense normally, since you don't want to miss reaping one child while you're starting another one. But in the case of shutdown and ctlaltdel and restart, this doesn't make sense since you're exiting anyway. So, my proposed change is to modify init.c:run() so that if the action is SHUTDOWN, CTLALTDEL, or RESTART, we don't block SIGCHLD before we fork the action. I'll make the change and test it; if anyone thinks of a reason this is wrong or ill-behaved let me know. Cheers! PS. What's the portability requirements for BB? I notice that we're using SIG_IGN for SIGCHLD: in the original POSIX spec this was undefined... you had to install a handler to wait() or else you got zombies. In the newer POSIX/SUS specs SIG_IGN on SIGCHLD will have the kernel release the zombie without needing a wait(). I suppose if it's working for current BB users, we should leave well enough alone. -- ----------------------------------------------------------------------------- Paul D. Smith http://netezza.com "Please remain calm--I may be mad, but I am a professional."--Mad Scientist ----------------------------------------------------------------------------- These are my opinions--Netezza takes no responsibility for them. From psmith at netezza.com Fri Dec 1 16:08:29 2006 From: psmith at netezza.com (Paul Smith) Date: Fri, 01 Dec 2006 19:08:29 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <1165012518.14542.199.camel@localhost> References: <1164825325.14542.15.camel@localhost> <200611300044.51959.vda.linux@googlemail.com> <1165012518.14542.199.camel@localhost> Message-ID: <1165018109.1850.6.camel@localhost> On Fri, 2006-12-01 at 17:35 -0500, Paul Smith wrote: > So, my proposed change is to modify init.c:run() so that if the action > is SHUTDOWN, CTLALTDEL, or RESTART, we don't block SIGCHLD before we > fork the action. > PS. What's the portability requirements for BB? I notice that we're > using SIG_IGN for SIGCHLD: in the original POSIX spec this was > undefined... you had to install a handler to wait() or else you got > zombies. In the newer POSIX/SUS specs SIG_IGN on SIGCHLD will have the > kernel release the zombie without needing a wait(). I suppose if it's > working for current BB users, we should leave well enough alone. Doh! I misread (sorry, I'm doing 27 things at once here). BB doesn't use SIG_IGN with SIGCHLD, it only uses SIG_DFL. So, no worries about portability. OK, we don't need to avoid blocking SIGCHLD (I'm not really sure why we're going to the trouble of blocking SIGCHLD while we fork in run() but I guess it certainly can't hurt). We just need to have the code that's waiting for the action to complete, also wait for any other child that dies in the meantime (during a shutdown/restart/ctlaltdel). I'll work on that this weekend. -- ----------------------------------------------------------------------------- Paul D. Smith http://netezza.com "Please remain calm--I may be mad, but I am a professional."--Mad Scientist ----------------------------------------------------------------------------- These are my opinions--Netezza takes no responsibility for them. From rob at landley.net Sat Dec 2 09:13:45 2006 From: rob at landley.net (Rob Landley) Date: Sat, 2 Dec 2006 12:13:45 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <1165012518.14542.199.camel@localhost> References: <1164825325.14542.15.camel@localhost> <200611300044.51959.vda.linux@googlemail.com> <1165012518.14542.199.camel@localhost> Message-ID: <200612021213.45719.rob@landley.net> On Friday 01 December 2006 5:35 pm, Paul Smith wrote: > Of course, once you look at the code life gets more complex :). This is a big reason I try to focus on what I want the new code to do, rather than be unduly influenced by what the old code was doing. (I generally try to figure out why it was doing it, but that's not the same as buying into it.) > The loop in init starts any unstarted RESPAWN and ASKFIRST commands, then > it sleeps for one second, then it does a wait() to sleep until one of > its children dies. The reason init programs want to sit in a wait() loop is so that they can restart things that die. But if all you want to do is reap zombies (such as during shutdown), set the SIGCHLD handler to SIG_IGNORE. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From roberto.foglietta at gmail.com Sat Dec 2 11:50:34 2006 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Sat, 2 Dec 2006 20:50:34 +0100 Subject: busybox current status In-Reply-To: <200612010003.56601.vda.linux@googlemail.com> References: <200611300014.47607.vda.linux@googlemail.com> <200612010003.56601.vda.linux@googlemail.com> Message-ID: 2006/12/1, Denis Vlasenko : > On Thursday 30 November 2006 13:20, Roberto A. Foglietta wrote: [cut] > > the bug n.347 is not anymore open in 1.2.2.1 you please close it > > http://bugs.busybox.net/view.php?id=347 > > bug comment says: > In my opinion this bug was fixed in 1.2.2.1 at least > [root at GEDX0327 busybox-1.2.2.1]# _install/bin/busybox tar tvjf pippo.tar.bz2 > tar: Decompression failed > tar: Short header > > It means that tar detects uncompressor output which isn't a multiple > of tar block size. But it can so happen that corrupted archive > will end so that uncompressed output wil end at block boundary > (1/512 chance). > I hope this solve your dubts (and I hope to have understood your msg): [roberto at nbraf busybox]$ dd if=/dev/zero bs=512 count=1 >pippo.tar entrati 1+0 record usciti 1+0 record [roberto at nbraf busybox]$ gzip pippo.tar [roberto at nbraf busybox]$ ./busybox tar xvzf pippo.tar.gz tar: short read [roberto at nbraf busybox]$ echo $? 1 Cheers, From vda.linux at googlemail.com Sat Dec 2 12:24:56 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat, 2 Dec 2006 21:24:56 +0100 Subject: busybox current status In-Reply-To: References: <200611300014.47607.vda.linux@googlemail.com> <200612010003.56601.vda.linux@googlemail.com> Message-ID: <200612022124.56209.vda.linux@googlemail.com> On Saturday 02 December 2006 20:50, Roberto A. Foglietta wrote: > I hope this solve your dubts (and I hope to have understood your msg): > > [roberto at nbraf busybox]$ dd if=/dev/zero bs=512 count=1 >pippo.tar > entrati 1+0 record > usciti 1+0 record > [roberto at nbraf busybox]$ gzip pippo.tar > [roberto at nbraf busybox]$ ./busybox tar xvzf pippo.tar.gz > tar: short read You have a valid compressed file (so gzip returns 0), which isn't a valid tar file. Our tar handles this correctly. What is handled incorrectly is when gzip returns !0, but tar ignores that and happily eats truncated input. If it will so happen that truncated input is a valid tar file (just a few thousand tarred files are cut off at the tail), tar will terminate with exit code 0. Which is a lie. Files were not extracted without errors. -- vda From psmith at netezza.com Sat Dec 2 12:35:29 2006 From: psmith at netezza.com (Paul Smith) Date: Sat, 02 Dec 2006 15:35:29 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <200612021213.45719.rob@landley.net> References: <1164825325.14542.15.camel@localhost> <200611300044.51959.vda.linux@googlemail.com> <1165012518.14542.199.camel@localhost> <200612021213.45719.rob@landley.net> Message-ID: <1165091729.364.3.camel@homebase> On Sat, 2006-12-02 at 12:13 -0500, Rob Landley wrote: > > The loop in init starts any unstarted RESPAWN and ASKFIRST commands, then > > it sleeps for one second, then it does a wait() to sleep until one of > > its children dies. > > The reason init programs want to sit in a wait() loop is so that they can > restart things that die. But if all you want to do is reap zombies (such as > during shutdown), set the SIGCHLD handler to SIG_IGNORE. As I mentioned in one of my earlier emails, this is not portable. Although current versions of the POSIX/SUS spec require SIGCHLD set to SIG_IGN to reap children, older versions of POSIX did not require that; in fact the behavior was undefined (ditto for BSD). I'm not sure what the portability requirements are for BusyBox, but it's not difficult at all to handle this without resorting to SIG_IGN so we might as well do so. I'll send a patch tomorrow or Monday. Cheers! From roberto.foglietta at gmail.com Sat Dec 2 13:48:39 2006 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Sat, 2 Dec 2006 22:48:39 +0100 Subject: busybox current status In-Reply-To: <200612010003.56601.vda.linux@googlemail.com> References: <200611300014.47607.vda.linux@googlemail.com> <200612010003.56601.vda.linux@googlemail.com> Message-ID: 2006/12/1, Denis Vlasenko : > On Thursday 30 November 2006 13:20, Roberto A. Foglietta wrote: > > > > To do: > > > > > > * more fishing in bug database > > > > the bug n.615 still open and I have updated patch to 1.2.2.1 and today > > snapshot (in attachment) > > http://bugs.busybox.net/view.php?id=615 > > - if (temp) { > - *no_newline = !(len && temp[len-1] == '\n'); > + if (temp && len > 0) { > + endzero += !temp[len-1]; > + *no_newline = !(temp[len-1]=='\n'); > if (!*no_newline) temp[len-1] = 0; > break; > > old code: if len == 0: 'break' is taken > new code: if len == 0: 'break' is not taken > is it ok? > I tested your patch but it seems it does not work at least against with 2006-12-01 Cheers, -- /roberto From roberto.foglietta at gmail.com Sat Dec 2 13:53:24 2006 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Sat, 2 Dec 2006 22:53:24 +0100 Subject: busybox current status In-Reply-To: References: <200611300014.47607.vda.linux@googlemail.com> <200612010003.56601.vda.linux@googlemail.com> Message-ID: 2006/12/2, Roberto A. Foglietta : > 2006/12/1, Denis Vlasenko : > > On Thursday 30 November 2006 13:20, Roberto A. Foglietta wrote: > > > > > > To do: > > > > > > > > * more fishing in bug database > > > > > > the bug n.615 still open and I have updated patch to 1.2.2.1 and today > > > snapshot (in attachment) > > > http://bugs.busybox.net/view.php?id=615 > > > > - if (temp) { > > - *no_newline = !(len && temp[len-1] == '\n'); > > + if (temp && len > 0) { > > + endzero += !temp[len-1]; > > + *no_newline = !(temp[len-1]=='\n'); > > if (!*no_newline) temp[len-1] = 0; > > break; > > > > old code: if len == 0: 'break' is taken > > new code: if len == 0: 'break' is not taken > > is it ok? > > > > I tested your patch but it seems it does not work at least against > with 2006-12-01 > [roberto at nbraf busybox]$ tar xvjf busybox-20061201.tar.bz2 [roberto at nbraf busybox]$ cd busybox [roberto at nbraf busybox]$ patch -p1 < ../../sed_rev16754.patch [roberto at nbraf busybox]$ echo -n thingy >z1 [roberto at nbraf busybox]$ echo -n again >z2 [roberto at nbraf busybox]$ ./busybox sed "s/i/z/" z1 z2 | hexdump -vC 00000000 74 68 7a 6e 67 79 61 67 61 7a 6e |thzngyagazn| 0000000b [roberto at nbraf busybox]$ sed "s/i/z/" z1 z2 | hexdump -vC 00000000 74 68 7a 6e 67 79 0a 61 67 61 7a 6e |thzngy.agazn| 0000000c Cheers, -- /roberto From rob at landley.net Sat Dec 2 14:04:34 2006 From: rob at landley.net (Rob Landley) Date: Sat, 2 Dec 2006 17:04:34 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <1165091729.364.3.camel@homebase> References: <1164825325.14542.15.camel@localhost> <200612021213.45719.rob@landley.net> <1165091729.364.3.camel@homebase> Message-ID: <200612021704.35022.rob@landley.net> On Saturday 02 December 2006 3:35 pm, Paul Smith wrote: > On Sat, 2006-12-02 at 12:13 -0500, Rob Landley wrote: > > > > The loop in init starts any unstarted RESPAWN and ASKFIRST commands, then > > > it sleeps for one second, then it does a wait() to sleep until one of > > > its children dies. > > > > The reason init programs want to sit in a wait() loop is so that they can > > restart things that die. But if all you want to do is reap zombies (such as > > during shutdown), set the SIGCHLD handler to SIG_IGNORE. > > As I mentioned in one of my earlier emails, this is not portable. > Although current versions of the POSIX/SUS spec require SIGCHLD set to > SIG_IGN to reap children, older versions of POSIX did not require that; > in fact the behavior was undefined (ditto for BSD). So you say that behavior required by SUSv3 isn't something you're willing to rely on, yet BusyBox has been targeting susv3 for how many years now? (The austin group was when?) My lack of caring is deep, and profound. > I'm not sure what the portability requirements are for BusyBox SUSv3. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From vda.linux at googlemail.com Sat Dec 2 14:05:14 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat, 2 Dec 2006 23:05:14 +0100 Subject: busybox current status In-Reply-To: References: <200611300014.47607.vda.linux@googlemail.com> <200612010003.56601.vda.linux@googlemail.com> Message-ID: <200612022305.14458.vda.linux@googlemail.com> On Saturday 02 December 2006 22:48, Roberto A. Foglietta wrote: > 2006/12/1, Denis Vlasenko : > > On Thursday 30 November 2006 13:20, Roberto A. Foglietta wrote: > > > > > > To do: > > > > > > > > * more fishing in bug database > > > > > > the bug n.615 still open and I have updated patch to 1.2.2.1 and today > > > snapshot (in attachment) > > > http://bugs.busybox.net/view.php?id=615 > > > > - if (temp) { > > - *no_newline = !(len && temp[len-1] == '\n'); > > + if (temp && len > 0) { > > + endzero += !temp[len-1]; > > + *no_newline = !(temp[len-1]=='\n'); > > if (!*no_newline) temp[len-1] = 0; > > break; > > > > old code: if len == 0: 'break' is taken > > new code: if len == 0: 'break' is not taken > > is it ok? > > > > I tested your patch but it seems it does not work at least against > with 2006-12-01 I sent you new sed.c which has that fixed. Roberto, I was looking into your patch busybox-20061130_sed.patch. I have some problems with it. Try to limit usage of static data. Try to make code easier to understand. sed code is convoluted enough already, have heart for poor souls (probably you, a year from now) which will come later and will try to figure out how it works. It's best to try to make it so that C code itself is easy to read, but if you have clever but obscure trick, document how it works in comments. Reread your comments when you generate patch for submission. I frequently find my own comments too cryptic and edit them again. About that particular patch: "static char prisubst" variable name is not descriptive. Is it used to skip subst commands (if I read the code right)? Why it is called prisubst and not skip_next_subst? -- vda From rob at landley.net Sat Dec 2 14:07:49 2006 From: rob at landley.net (Rob Landley) Date: Sat, 2 Dec 2006 17:07:49 -0500 Subject: busybox current status In-Reply-To: References: <200611300014.47607.vda.linux@googlemail.com> Message-ID: <200612021707.49987.rob@landley.net> On Saturday 02 December 2006 4:53 pm, Roberto A. Foglietta wrote: > [roberto at nbraf busybox]$ tar xvjf busybox-20061201.tar.bz2 > [roberto at nbraf busybox]$ cd busybox > [roberto at nbraf busybox]$ patch -p1 < ../../sed_rev16754.patch > [roberto at nbraf busybox]$ echo -n thingy >z1 > [roberto at nbraf busybox]$ echo -n again >z2 > [roberto at nbraf busybox]$ ./busybox sed "s/i/z/" z1 z2 | hexdump -vC > 00000000 74 68 7a 6e 67 79 61 67 61 7a 6e |thzngyagazn| > 0000000b > [roberto at nbraf busybox]$ sed "s/i/z/" z1 z2 | hexdump -vC > 00000000 74 68 7a 6e 67 79 0a 61 67 61 7a 6e |thzngy.agazn| > 0000000c svn 16070 is the last version of this I made a code change to, and that worked just fine. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Sat Dec 2 14:08:27 2006 From: rob at landley.net (Rob Landley) Date: Sat, 2 Dec 2006 17:08:27 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <1165091729.364.3.camel@homebase> References: <1164825325.14542.15.camel@localhost> <200612021213.45719.rob@landley.net> <1165091729.364.3.camel@homebase> Message-ID: <200612021708.27799.rob@landley.net> On Saturday 02 December 2006 3:35 pm, Paul Smith wrote: > On Sat, 2006-12-02 at 12:13 -0500, Rob Landley wrote: > > > > The loop in init starts any unstarted RESPAWN and ASKFIRST commands, then > > > it sleeps for one second, then it does a wait() to sleep until one of > > > its children dies. > > > > The reason init programs want to sit in a wait() loop is so that they can > > restart things that die. But if all you want to do is reap zombies (such as > > during shutdown), set the SIGCHLD handler to SIG_IGNORE. > > As I mentioned in one of my earlier emails, this is not portable. P.S. Not portable to what? Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From vda.linux at googlemail.com Sat Dec 2 14:27:35 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat, 2 Dec 2006 23:27:35 +0100 Subject: busybox current status In-Reply-To: <200612021707.49987.rob@landley.net> References: <200611300014.47607.vda.linux@googlemail.com> <200612021707.49987.rob@landley.net> Message-ID: <200612022327.35682.vda.linux@googlemail.com> On Saturday 02 December 2006 23:07, Rob Landley wrote: > On Saturday 02 December 2006 4:53 pm, Roberto A. Foglietta wrote: > > [roberto at nbraf busybox]$ tar xvjf busybox-20061201.tar.bz2 > > [roberto at nbraf busybox]$ cd busybox > > [roberto at nbraf busybox]$ patch -p1 < ../../sed_rev16754.patch > > [roberto at nbraf busybox]$ echo -n thingy >z1 > > [roberto at nbraf busybox]$ echo -n again >z2 > > [roberto at nbraf busybox]$ ./busybox sed "s/i/z/" z1 z2 | hexdump -vC > > 00000000 74 68 7a 6e 67 79 61 67 61 7a 6e |thzngyagazn| > > 0000000b > > [roberto at nbraf busybox]$ sed "s/i/z/" z1 z2 | hexdump -vC > > 00000000 74 68 7a 6e 67 79 0a 61 67 61 7a 6e |thzngy.agazn| > > 0000000c > > svn 16070 is the last version of this I made a code change to, and that worked > just fine. sed NUL support was added to svn in two patches. Second one fixes this issue. Already in svn. There are still unfixed problems, but there are no regressions. -- vda From rob at landley.net Sat Dec 2 14:36:55 2006 From: rob at landley.net (Rob Landley) Date: Sat, 2 Dec 2006 17:36:55 -0500 Subject: busybox current status In-Reply-To: <200612022305.14458.vda.linux@googlemail.com> References: <200611300014.47607.vda.linux@googlemail.com> <200612022305.14458.vda.linux@googlemail.com> Message-ID: <200612021736.56265.rob@landley.net> On Saturday 02 December 2006 5:05 pm, Denis Vlasenko wrote: > I sent you new sed.c which has that fixed. I'm not going to test that statement. :) > Roberto, I was looking into your patch busybox-20061130_sed.patch. > I have some problems with it. > > Try to limit usage of static data. > > Try to make code easier to understand. sed code is convoluted enough > already, have heart for poor souls (probably you, a year from now) > which will come later and will try to figure out how it works. When I started with busybox, the first thing I did was upgrade the sed that was there to make it actually _work_ with the ./configure stages of binutils and gcc. (This took something like a month.) I never actually went back and redid the structure I'd inherited (my goal was minimally intrustive changes), but for toybox I'm writing a new one. > It's best to try to make it so that C code itself is easy to read, > but if you have clever but obscure trick, document how it works > in comments. One of my early patches to the thing added an overview, because I wanted to document what had been hard for me to understand by reading the thing: http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/editors/sed.c?rev=7583&r1=7560&r2=7583 Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From vda.linux at googlemail.com Sat Dec 2 14:57:21 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat, 2 Dec 2006 23:57:21 +0100 Subject: trunk compilation broken In-Reply-To: <20061201171423.GA27853@aon.at> References: <20061201171423.GA27853@aon.at> Message-ID: <200612022357.21849.vda.linux@googlemail.com> On Friday 01 December 2006 18:14, Bernhard Fischer wrote: > Hi, > > Ever since the str_to_num (sp?) changes, trunk fails to build for me > with the errors below. Can you try replacing "extern inline" with "extern inline attribute ((always_inline))" here: include/xatonum.h: extern inline unsigned long bb_strtou(const char *arg, char **endp, int base) { return bb_strtoull(arg, endp, base); } [several of them exist there] If that doesn't work, try replacing with "static inline". Although that will allow gcc to NOT inline those functions if it so decides, but emit separate copy in each .o file. Not good for code size. -- vda From psmith at netezza.com Sat Dec 2 15:02:29 2006 From: psmith at netezza.com (Paul Smith) Date: Sat, 02 Dec 2006 18:02:29 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <200612021704.35022.rob@landley.net> References: <1164825325.14542.15.camel@localhost> <200612021213.45719.rob@landley.net> <1165091729.364.3.camel@homebase> <200612021704.35022.rob@landley.net> Message-ID: <1165100549.364.27.camel@homebase> On Sat, 2006-12-02 at 17:04 -0500, Rob Landley wrote: > So you say that behavior required by SUSv3 isn't something you're willing to > rely on, yet BusyBox has been targeting susv3 for how many years now? (The > austin group was when?) I've been subscribed to this mailing list for about 27 hours now. I have no idea whether BusyBox targets SUSv3, much less how long it has done so. I'm perfectly happy to rely on it if that's the project's standard. Many free software projects take a much more lax position on OS requirements. > > I'm not sure what the portability requirements are for BusyBox > > SUSv3. Excellent! That definitely makes things simpler. Cheers! From rob at landley.net Sat Dec 2 15:30:12 2006 From: rob at landley.net (Rob Landley) Date: Sat, 2 Dec 2006 18:30:12 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <1165100549.364.27.camel@homebase> References: <1164825325.14542.15.camel@localhost> <200612021704.35022.rob@landley.net> <1165100549.364.27.camel@homebase> Message-ID: <200612021830.12557.rob@landley.net> On Saturday 02 December 2006 6:02 pm, Paul Smith wrote: > On Sat, 2006-12-02 at 17:04 -0500, Rob Landley wrote: > > > So you say that behavior required by SUSv3 isn't something you're willing to > > rely on, yet BusyBox has been targeting susv3 for how many years now? (The > > austin group was when?) > > I've been subscribed to this mailing list for about 27 hours now. I > have no idea whether BusyBox targets SUSv3, much less how long it has > done so. I'm perfectly happy to rely on it if that's the project's > standard. Many free software projects take a much more lax position on > OS requirements. I wrote this during my tenure as maintainer, which is now over: http://busybox.net/FAQ.html#standards What Denis decides to do is up to him (it's his baby now), but last I checked he was still ok with that. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From vda.linux at googlemail.com Sun Dec 3 01:32:10 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 3 Dec 2006 10:32:10 +0100 Subject: I will be somewhat less available for a week Message-ID: <200612031032.10278.vda.linux@googlemail.com> Well, subject says it all. I will be reading my mail, but I am not sure whether I will have access to svn. -- vda From vda.linux at googlemail.com Sun Dec 3 01:30:20 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 3 Dec 2006 10:30:20 +0100 Subject: busybox current status In-Reply-To: <200612021736.56265.rob@landley.net> References: <200611300014.47607.vda.linux@googlemail.com> <200612022305.14458.vda.linux@googlemail.com> <200612021736.56265.rob@landley.net> Message-ID: <200612031030.20064.vda.linux@googlemail.com> On Saturday 02 December 2006 23:36, Rob Landley wrote: > > Roberto, I was looking into your patch busybox-20061130_sed.patch. > > I have some problems with it. > > > > Try to limit usage of static data. > > > > Try to make code easier to understand. sed code is convoluted enough > > already, have heart for poor souls (probably you, a year from now) > > which will come later and will try to figure out how it works. > > When I started with busybox, the first thing I did was upgrade the sed that > was there to make it actually _work_ with the ./configure stages of binutils > and gcc. (This took something like a month.) > > I never actually went back and redid the structure I'd inherited (my goal was > minimally intrustive changes), but for toybox I'm writing a new one. I'm usually not rewriting stuff from scratch (maybe because I am lazy). Will be happy to see/test/use your new code - it's usually both very good and much smaller. Thank you for your work. -- vda From roberto.foglietta at gmail.com Sun Dec 3 02:12:00 2006 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Sun, 3 Dec 2006 11:12:00 +0100 Subject: busybox current status In-Reply-To: <200612022305.14458.vda.linux@googlemail.com> References: <200611300014.47607.vda.linux@googlemail.com> <200612010003.56601.vda.linux@googlemail.com> <200612022305.14458.vda.linux@googlemail.com> Message-ID: 2006/12/2, Denis Vlasenko : > Roberto, I was looking into your patch busybox-20061130_sed.patch. > I have some problems with it. > > Try to limit usage of static data. > ok, prisubst could be passed as an argument pointer as no_newline. I just used static thinking: I will found a solution and after I will make it more beauty after > Try to make code easier to understand. sed code is convoluted enough > already, have heart for poor souls (probably you, a year from now) > which will come later and will try to figure out how it works. ok, you are right but sed is difficult itself I did not added much more complexity. > About that particular patch: "static char prisubst" variable name > is not descriptive. Is it used to skip subst commands (if I read > the code right)? Why it is called prisubst and not skip_next_subst? yes you are right... the name was PRIor SUBSTitution, not so bad thinking I would have changed it after I made it works in something like no_newline 4th: I have not left for tomorow what I would have been done for today! ;-) Cheers, -- /roberto From yuwend at gmail.com Sun Dec 3 07:01:14 2006 From: yuwend at gmail.com (Yuwen Dai) Date: Sun, 3 Dec 2006 23:01:14 +0800 Subject: miscutils/nmeter.c:19: warning: redefinition of `ulong' Message-ID: Dear all, When I built the current svn source, the following error showed up: miscutils/nmeter.c:19: warning: redefinition of `ulong' /usr/include/sys/types.h:151: warning: `ulong' previously declared here make[1]: *** [miscutils/nmeter.o] Error 1 make: *** [miscutils] Error 2 other info: $ uname -a Linux latitude 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux $ gcc --version gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) It seems a bug. Best regards, Dai Yuwen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061203/a27a5246/attachment.html From yuwend at gmail.com Sun Dec 3 07:32:23 2006 From: yuwend at gmail.com (Yuwen Dai) Date: Sun, 3 Dec 2006 23:32:23 +0800 Subject: undefined reference to `bb_makedev' Message-ID: Dear all, When I built the current svn source, I got this error: LINK busybox_unstripped /usr/bin/ld: Warning: gc-sections option ignored archival/libunarchive/lib.a(get_header_cpio.o)(.text.get_header_cpio+0x321): In function `get_header_cpio': : undefined reference to `bb_makedev' I saw bb_makedev is defined in libbb/makedev.c surrounded by #ifdef __GLIBC__, should I define this macro? Best regards, Yuwen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061203/2f1e48dd/attachment.htm From rob at landley.net Sun Dec 3 12:56:04 2006 From: rob at landley.net (Rob Landley) Date: Sun, 3 Dec 2006 15:56:04 -0500 Subject: busybox current status In-Reply-To: <200612031030.20064.vda.linux@googlemail.com> References: <200611300014.47607.vda.linux@googlemail.com> <200612021736.56265.rob@landley.net> <200612031030.20064.vda.linux@googlemail.com> Message-ID: <200612031556.04767.rob@landley.net> On Sunday 03 December 2006 4:30 am, Denis Vlasenko wrote: > > I never actually went back and redid the structure I'd inherited (my goal was > > minimally intrustive changes), but for toybox I'm writing a new one. > > I'm usually not rewriting stuff from scratch (maybe because I am lazy). I find writing code easier than reading code. This is a trap I try not to fall into, since often the existing code has been debugged for years and now handles all sorts of strange corner cases that are totally undocumented anywhere except in the implementation. Joel Spolsky wrote a couple articles about this: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000027.html Doing a minimally invasive set of changes to sed and preserving as much of the existing structure as possible was a learning exercise on my part (and also a response to the fact that I didn't have a _clue_ how sed worked, and thus if I broke stuff outside of the test cases I was trying to fix, I'd have no way of knowing). That said, once you understand the problem you generally _can_ write a much smaller version. (Joel's deep in the proprietary software tradition, and doesn't fully understand either open source or hobbyist programming.) But you can't skip the "understanding the problem" step. (For example, with command shells I've been studying on and off for a year, and consider myself about halfway there.) > Will be happy to see/test/use your new code - it's usually both > very good and much smaller. Thank you for your work. You're welcome to it (it's GPLv2), but I don't know how much use it'll be. I'm designing toybox around very different principles. For example, the "union of global structs" thing I mentioned idly here months ago is integral to how toybox works: it can't parse command line options without it. There's a global "struct toys toys;" that contains data supplied to all commands, and a "toy.command" (ala toy.df or toy.mdev) that's the union with data for this particular command. The command line parsing is integrated into the overall toybox infrastructure, so each command's arguments are parsed from toybox_main(), before the command_main() gets run. The getopt-like string telling get_optlfags() how to parse the arguments for this command is one of the arguments to the NEWTOY() macro in toys/toylist.h, and the data that would have gone into varargs in busybox instead goes into the first fiew fields of the appropriate "toy" union. For example, with the "df" command has the following in toys/toylist.h: struct df_data { struct arg_list *fstype; long units; }; USE_DF(NEWTOY(df, "Pkt*a", TOYFLAG_USR|TOYFLAG_SBIN)) Because of that, when df_main() gets run, toys.optflags is already filled out based on the flags seen (so "a" sets flag 1, "t" sets flag 2, "k" sets flag 4, and "p" sets flag 8. This order makes more sense to me because it's the same order boolean digits go in: values are supposed to increase as you go to the left.) The * after t means this takes an argument and it can occur more than once so it should be a list, and since that's the first entry returning an argument it stores its result in toy.df.fstype. Note that toy.df.fstype isn't filled out by option parsing, so it's initialized to 0. Remaining arguments are copied into toys.optargs[], and although that array of char * is malloced, the strings it points to aren't (they're the raw environment data) and shouldn't be freed. (toys.optargs[] itself is freed by the return to toybox_main().) You can still access the raw unmodified argument list through toys.argv[], they're not permuted and parsing them shouldn't change what appears in "ps". That's just one example of the infrastructure being different. I haven't used any code from BusyBox yet, although I'm starting to port over some of the applets I wrote. (Which includes going through the svn history to make sure I know where it all came from. Currently I've just taken stuff I'm the only contributor to.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From yuwend at gmail.com Sun Dec 3 22:43:24 2006 From: yuwend at gmail.com (Yuwen Dai) Date: Mon, 4 Dec 2006 14:43:24 +0800 Subject: miscutils/nmeter.c:19: warning: redefinition of `ulong' In-Reply-To: References: Message-ID: On 12/3/06, Yuwen Dai wrote: > > Dear all, > > When I built the current svn source, the following error showed up: > > miscutils/nmeter.c:19: warning: redefinition of `ulong' > /usr/include/sys/types.h:151: warning: `ulong' previously declared here > make[1]: *** [miscutils/nmeter.o] Error 1 > make: *** [miscutils] Error 2 > > other info: > $ uname -a > Linux latitude 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux > $ gcc --version > gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) > > It seems a bug. On a Redhat Linux box, I compiled this applet successfully. The version of glibc is 2.3.4, higher than that of in Debian sarge, whose glibc is 2.3.2. Since C99 uses a new , is it better to use somthing like int64_t ? Yuwen Best regards, > Dai Yuwen > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061204/f04f6222/attachment.html From wharms at bfs.de Mon Dec 4 00:30:13 2006 From: wharms at bfs.de (walter harms) Date: Mon, 04 Dec 2006 09:30:13 +0100 Subject: miscutils/nmeter.c:19: warning: redefinition of `ulong' In-Reply-To: References: Message-ID: <4573DC95.4050902@bfs.de> ulong != int64_t far better would be a s/ulong/unsigned long/g trivia: ulong is a BSDism so far i know re, wh Yuwen Dai wrote: > On 12/3/06, Yuwen Dai wrote: >> >> Dear all, >> >> When I built the current svn source, the following error showed up: >> >> miscutils/nmeter.c:19: warning: redefinition of `ulong' >> /usr/include/sys/types.h:151: warning: `ulong' previously declared here >> make[1]: *** [miscutils/nmeter.o] Error 1 >> make: *** [miscutils] Error 2 >> >> other info: >> $ uname -a >> Linux latitude 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux >> $ gcc --version >> gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) >> >> It seems a bug. > > > On a Redhat Linux box, I compiled this applet successfully. The > version of > glibc is 2.3.4, higher than that of in Debian sarge, whose glibc is 2.3.2. > > Since C99 uses a new , is it better to use somthing like > int64_t > ? > > Yuwen > > > > > Best regards, >> Dai Yuwen >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From bornland at gmx.at Mon Dec 4 02:31:52 2006 From: bornland at gmx.at (Thomas =?iso-8859-1?q?Fr=F6hlich?=) Date: Mon, 4 Dec 2006 11:31:52 +0100 Subject: _FILE_OFFSET_BITS why this? Message-ID: <200612041131.52656.bornland@gmx.at> Hi! I will compile the svn version, but in the last days I have some problems. :( My GCC is arm-linux-uclibc-gcc (GCC) 3.3.3 My make command, after some trys: 'make ARCH=arm CROSS_COMPILE=/usr/local/src/buildroot/build_arm_nofpu/staging_dir/bin/arm-linux-uclibc-' all will compile nice until: CC util-linux/more.o util-linux/more.c:107:5: "_FILE_OFFSET_BITS" is not defined make[1]: *** [util-linux/more.o] Error 1 make: *** [util-linux] Error 2 Why is _FILE_OFFSET_BITS for arm important? in the file is #if _FILE_OFFSET_BITS == 64 len += printf("(%d%% of %lld bytes)", (int) (100 * ((double) ftell(file) / (double) st.st_size)), (long long)st.st_size); #else len += printf("(%d%% of %ld bytes)", (int) (100 * ((double) ftell(file) / (double) st.st_size)), (long)st.st_size); #endif but it's the same to 1.2.0. in Makefile.flags:15: $(if $(CONFIG_LFS),-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64) is this right? thxs for help! regards Thomas From kbechler at bakertillypoland.eu Mon Dec 4 03:17:24 2006 From: kbechler at bakertillypoland.eu (Konrad Bechler) Date: Mon, 04 Dec 2006 12:17:24 +0100 Subject: reboot problem Message-ID: <457403C4.20906@bakertillypoland.eu> Hi, I've got the same problem as described at http://busybox.net/lists/busybox/2005-June/014687.html I use WRAP 1E board based on SC1100 CPU. After 'reboot' command i can see, all processes has been killed, busybox going to reboot system, but nothing happens. I've got extra line contains only one char - a dot. Could someone help me with this problem? Maybe some patch against busybox v. 1.2.2.1? Thanks -- Regards, Konrad From Johnicholas-Hines at IDEXX.com Mon Dec 4 08:05:37 2006 From: Johnicholas-Hines at IDEXX.com (Hines, Johnicholas) Date: Mon, 4 Dec 2006 11:05:37 -0500 Subject: tftp segfault in 1.1.3 Message-ID: <3F4FE8951F7D314DB337D3693C9CFE7D20B31952@taz.namerica.idexxi.com> Hi, I found a way to make busybox tftp segfault. I don't know if it is already known and fixed in current versions of busybox, but I searched the mailing list archives, and couldn't find anything. It's not really a big problem because you just get a segfault message where you should get a usage message. I'm using v1.1.3. # tftp -g 172.31.10.176 using server "172.31.10.176", remotefile "(null)", localfile "(null)". Segmentation fault Just trying to be helpful. Johnicholas Hines From E.Spakman at inter.nl.net Mon Dec 4 04:00:21 2006 From: E.Spakman at inter.nl.net (Eric Spakman) Date: Mon, 4 Dec 2006 13:00:21 +0100 (CET) Subject: reboot problem In-Reply-To: <457403C4.20906@bakertillypoland.eu> References: <457403C4.20906@bakertillypoland.eu> Message-ID: <40691.145.221.24.8.1165233621.squirrel@webmail.inter.nl.net> Konrad, > Hi, > > > I've got the same problem as described at > http://busybox.net/lists/busybox/2005-June/014687.html > I use WRAP 1E board based on SC1100 CPU. > After 'reboot' command i can see, all processes has been killed, busybox > going to reboot system, but nothing happens. I've got extra line contains > only one char - a dot. > > Could someone help me with this problem? Maybe some patch against > busybox v. 1.2.2.1? > This has nothing todo with busybox, but with the WRAP board not having a keyboard controller. This is also described in the WRAP manual AFAIK. Adding "append reboot=bios" in your bootloader configuration should help. > Thanks > > > -- > Regards, > Konrad > Regards, Eric From psmith at netezza.com Mon Dec 4 11:51:42 2006 From: psmith at netezza.com (Paul Smith) Date: Mon, 04 Dec 2006 14:51:42 -0500 Subject: init not processing SIGCHLD during reboot? In-Reply-To: <200611300044.51959.vda.linux@googlemail.com> References: <1164825325.14542.15.camel@localhost> <200611300044.51959.vda.linux@googlemail.com> Message-ID: <1165261902.1573.18.camel@localhost> On Thu, 2006-11-30 at 00:44 +0100, Denis Vlasenko wrote: > On Wednesday 29 November 2006 19:35, Paul Smith wrote: > > I'm having a problem where init is not handling SIGCHLD while it's > > running my shutdown scripts when I type reboot. > > [...] Annotating the script I can see that when I kill > > the process it dies, but it's still there as a zombie (Z), so pidof > > still finds it and thinks that it hasn't died yet. > > > > I'm assuming that while busybox init is running my script, it's not > > handling SIGCHLD signals and cleaning up zombies like it usually does, > > so that's why my process is never reaped. > > > Please try it, and send a patch. Hi all. Please find a patch enclosed that resolves this behavior for me. This is against the latest SVN as of this morning. 2006-12-04 Paul Smith During shutdown init does not reap children while it's waiting for a command to finish. This leaves processes killed by commands as zombies, which fools pidof and other methods of determining whether a process died or not. * init/init.c (waitfor): Add a new argument specifying whether we should wait for just the PID of the child, or wait for any child. If the latter, use -1 as the pid in waitpid(2). (run): These calls to waitfor() wait for a specific pid. (run_actions): For SHUTDOWN, CTLALTDEL, and RESTART actions we wait for any PID. For SYSINIT and WAIT we wait for the specific PID of the command we run (as before). -- ----------------------------------------------------------------------------- Paul D. Smith http://netezza.com "Please remain calm--I may be mad, but I am a professional."--Mad Scientist ----------------------------------------------------------------------------- These are my opinions--Netezza takes no responsibility for them. -------------- next part -------------- A non-text attachment was scrubbed... Name: reap-init.patch Type: text/x-patch Size: 2118 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061204/f613b38c/attachment.bin From floydpink at gmail.com Mon Dec 4 12:22:57 2006 From: floydpink at gmail.com (Jason Schoon) Date: Mon, 4 Dec 2006 14:22:57 -0600 Subject: tftp segfault in 1.1.3 In-Reply-To: <3F4FE8951F7D314DB337D3693C9CFE7D20B31952@taz.namerica.idexxi.com> References: <3F4FE8951F7D314DB337D3693C9CFE7D20B31952@taz.namerica.idexxi.com> Message-ID: <78a54e1b0612041222n16a06e58oa2afb6bad6845f08@mail.gmail.com> On 12/4/06, Hines, Johnicholas wrote: > > Hi, > > I found a way to make busybox tftp segfault. I don't know if it is already > known and fixed in current versions of busybox, but I searched the mailing > list archives, and couldn't find anything. It's not really a big problem > because you just get a segfault message where you should get a usage > message. > > I'm using v1.1.3. > > # tftp -g 172.31.10.176 > using server "172.31.10.176", remotefile "(null)", localfile "(null)". > Segmentation fault > > Just trying to be helpful. > > Johnicholas Hines Fixed in SVN and release 1.2. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061204/9552cfab/attachment.htm From yuwend at gmail.com Mon Dec 4 17:57:33 2006 From: yuwend at gmail.com (Yuwen Dai) Date: Tue, 5 Dec 2006 09:57:33 +0800 Subject: miscutils/nmeter.c:19: warning: redefinition of `ulong' In-Reply-To: <4573DC95.4050902@bfs.de> References: <4573DC95.4050902@bfs.de> Message-ID: On 12/4/06, walter harms wrote: > > ulong !> > far better would be a s/ulong/unsigned long/g > trivia: ulong is a BSDism so far i know yeah, I had a wrong concept. The point is: how to build buzybox with a older verson of glibc and headers. The busybox developer seem use a higher verrsion of glibc, didn't notice this issue. Yuwen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061205/ef4c136e/attachment.html From yuwend at gmail.com Thu Dec 7 21:39:23 2006 From: yuwend at gmail.com (Yuwen Dai) Date: Fri, 8 Dec 2006 13:39:23 +0800 Subject: considering using autoconfig? Message-ID: Dear all, When I was testing the svn version of busybox, I found busybox could be compiled with a higher glibc version, while could not with a lower version. For example, the macro `__GLIBC__' referenced in makedev.c is defined in different header files. Are busybox developer considering using autoconfig? best regards, Yuwen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061208/4a495f87/attachment.html From yuwend at gmail.com Thu Dec 7 23:58:11 2006 From: yuwend at gmail.com (Yuwen Dai) Date: Fri, 8 Dec 2006 15:58:11 +0800 Subject: [PATCH]makedev.c Message-ID: Hi, Since libbb/makedev.c cannot be compiled under glibc2.3.2, Debain Sarge. I included --- libbb/makedev_orig.c 2006-12-08 15:52:40.141154816 +0800 +++ libbb/makedev.c 2006-12-08 15:52:38.634383880 +0800 @@ -7,6 +7,7 @@ */ /* We do not include libbb.h - #define makedev() is there! */ +#include #include #ifdef __GLIBC__ Best regards, Dai Yuwen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061208/eeb35066/attachment.htm -------------- next part -------------- --- libbb/makedev_orig.c 2006-12-08 15:52:40.141154816 +0800 +++ libbb/makedev.c 2006-12-08 15:52:38.634383880 +0800 @@ -7,6 +7,7 @@ */ /* We do not include libbb.h - #define makedev() is there! */ +#include #include #ifdef __GLIBC__ From wharms at bfs.de Fri Dec 8 00:08:23 2006 From: wharms at bfs.de (walter harms) Date: Fri, 08 Dec 2006 09:08:23 +0100 Subject: considering using autoconfig? In-Reply-To: References: Message-ID: <45791D77.5080104@bfs.de> Hi Dai, your observation is true but stuff like this can be handled in platform.h since libc is the only library busybox links again aufoconf would be overkill. second to this bb is used by embedded developers they basicly have a kernel (perhaps modified) an libc (with custom externsion ?) and bb. As you have seen it is easy to identify the problem and fix it, adding that you may have custom extensions it is easy to imagine that nightmare of testing you need. ntl: feel free to improve the libc detection ! disclaimer: that is my view not that of the bb ml :) re, wh Yuwen Dai wrote: > Dear all, > > When I was testing the svn version of busybox, I found busybox could be > compiled with a higher glibc version, while could not with a lower version. > For example, the macro `__GLIBC__' referenced in makedev.c is defined in > different header files. Are busybox developer considering using > autoconfig? > > best regards, > Yuwen > > > ------------------------------------------------------------------------ > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From rob at landley.net Fri Dec 8 10:44:18 2006 From: rob at landley.net (Rob Landley) Date: Fri, 8 Dec 2006 13:44:18 -0500 Subject: considering using autoconfig? In-Reply-To: References: Message-ID: <200612081344.18742.rob@landley.net> On Friday 08 December 2006 12:39 am, Yuwen Dai wrote: > Dear all, > > When I was testing the svn version of busybox, I found busybox could be > compiled with a higher glibc version, while could not with a lower version. > For example, the macro `__GLIBC__' referenced in makedev.c is defined in > different header files. Are busybox developer considering using autoconfig? I always considered autoconf and automake to be some of the worst examples of the Free Software Foundations' bloat, lack of taste, and outright insanity. Not that it's my decision anymore, but it would be easier, more portable, and more reliable to write a configuration system from scratch, by hand, than to use autoconf. (For one thing, autoconf and cross-compiling just don't mix. For another it doesn't magically make things work on platforms they didn't work on before, it's the developer who has to add tests and use the results.) > best regards, > Yuwen Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From cristian.ionescu-idbohrn at axis.com Fri Dec 8 11:13:35 2006 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 8 Dec 2006 20:13:35 +0100 (CET) Subject: expr applet bug? Message-ID: <0612082007540.11453@somehost> There seems to be a bug in expr (both 1.1.3 and svn): # ./busybox expr xyz0 : '[^0-9]\+\([0-9]\+\)' returns 0 on stdout and an error code 1. # ./busybox expr xyz1 : '[^0-9]\+\([0-9]\+\)' returns 1 on stdout and an error code 0. Cheers, Cristian From strange at nsk.no-ip.org Fri Dec 8 11:23:39 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 8 Dec 2006 19:23:39 +0000 Subject: expr applet bug? In-Reply-To: <0612082007540.11453@somehost> References: <0612082007540.11453@somehost> Message-ID: <20061208192338.GA1235@nsk.no-ip.org> On Fri, Dec 08, 2006 at 08:13:35PM +0100, Cristian Ionescu-Idbohrn wrote: > There seems to be a bug in expr (both 1.1.3 and svn): > > # ./busybox expr xyz0 : '[^0-9]\+\([0-9]\+\)' > > returns 0 on stdout and an error code 1. > > # ./busybox expr xyz1 : '[^0-9]\+\([0-9]\+\)' > > returns 1 on stdout and an error code 0. > I get the same behaviour from GNU's expr. What behaviour did you expect? -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061208/c81be7b1/attachment.pgp From cristian.ionescu-idbohrn at axis.com Fri Dec 8 11:47:34 2006 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 8 Dec 2006 20:47:34 +0100 (CET) Subject: expr applet bug? In-Reply-To: <20061208192338.GA1235@nsk.no-ip.org> References: <0612082007540.11453@somehost> <20061208192338.GA1235@nsk.no-ip.org> Message-ID: <0612082036340.11453@somehost> On Fri, 8 Dec 2006, Luciano Miguel Ferreira Rocha wrote: > On Fri, Dec 08, 2006 at 08:13:35PM +0100, Cristian Ionescu-Idbohrn wrote: > > There seems to be a bug in expr (both 1.1.3 and svn): > > > > # ./busybox expr xyz0 : '[^0-9]\+\([0-9]\+\)' > > > > returns 0 on stdout and an error code 1. > > > > # ./busybox expr xyz1 : '[^0-9]\+\([0-9]\+\)' > > > > returns 1 on stdout and an error code 0. > > > > I get the same behaviour from GNU's expr. Isn't that a bug too? Does bb need to imitate bugs too? > What behaviour did you expect? Obviously success in both cases mentioned above (from both GNU and bb expr). I do expect an error on: # ./busybox expr 0xyz0 : '[^0-9]\+\([0-9]\+\)' but not on: # ./busybox expr xyz0 : '[^0-9]\+\([0-9]\+\)' Cheers, Cristian From strange at nsk.no-ip.org Fri Dec 8 12:13:23 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 8 Dec 2006 20:13:23 +0000 Subject: expr applet bug? In-Reply-To: <0612082036340.11453@somehost> References: <0612082007540.11453@somehost> <20061208192338.GA1235@nsk.no-ip.org> <0612082036340.11453@somehost> Message-ID: <20061208201323.GB1235@nsk.no-ip.org> On Fri, Dec 08, 2006 at 08:47:34PM +0100, Cristian Ionescu-Idbohrn wrote: > Isn't that a bug too? Does bb need to imitate bugs too? It's the defined behaviour in the documentation: Exit status is: * 0 if EXPRESSION is neither null nor 0, * 1 if EXPRESSION is null or 0, * 2 if EXPRESSION is syntactically invalid, * and 3 if an error occurred. I suggest: # check text against regex (first argument) check() { regex="$1" shift result=$(./busybox expr "${*}" : "$regex") [ -z "$result" ] && return 1 return 0 } $ check '[^0-9]\+\([0-9]\+\)' xyz0 ; echo $?: $result 0: 0 $ check '[^0-9]\+\([0-9]\+\)' 0xyz0 ; echo $?: $result 1: -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061208/91beb077/attachment.pgp From cristian.ionescu-idbohrn at axis.com Sat Dec 9 09:38:04 2006 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sat, 9 Dec 2006 18:38:04 +0100 (CET) Subject: expr applet bug? In-Reply-To: <20061208201323.GB1235@nsk.no-ip.org> References: <0612082007540.11453@somehost> <20061208192338.GA1235@nsk.no-ip.org> <0612082036340.11453@somehost> <20061208201323.GB1235@nsk.no-ip.org> Message-ID: <0612091827510.4921@somehost> Thanks for pointing me to the docs. On Fri, 8 Dec 2006, Luciano Miguel Ferreira Rocha wrote: > On Fri, Dec 08, 2006 at 08:47:34PM +0100, Cristian Ionescu-Idbohrn wrote: > > Isn't that a bug too? Does bb need to imitate bugs too? > > It's the defined behaviour in the documentation: > > Exit status is: > * 0 if EXPRESSION is neither null nor 0, > * 1 if EXPRESSION is null or 0, So, the line above is what IMO is a bug. The exit status should not be 1 when the EXPRESSION is a perfectly valid 0. > I suggest: Thanks for the workaround, but it's bloat :( > # check text against regex (first argument) > check() { > regex="$1" > shift > result=$(./busybox expr "${*}" : "$regex") > [ -z "$result" ] && return 1 > return 0 > } > > $ check '[^0-9]\+\([0-9]\+\)' xyz0 ; echo $?: $result > 0: 0 > $ check '[^0-9]\+\([0-9]\+\)' 0xyz0 ; echo $?: $result > 1: All that (slow) shell code... Wouldn't it be easier to fix the bug? Cheers, Cristian From strange at nsk.no-ip.org Sat Dec 9 09:44:24 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sat, 9 Dec 2006 17:44:24 +0000 Subject: expr applet bug? In-Reply-To: <0612091827510.4921@somehost> References: <0612082007540.11453@somehost> <20061208192338.GA1235@nsk.no-ip.org> <0612082036340.11453@somehost> <20061208201323.GB1235@nsk.no-ip.org> <0612091827510.4921@somehost> Message-ID: <20061209174424.GA11041@nsk.no-ip.org> On Sat, Dec 09, 2006 at 06:38:04PM +0100, Cristian Ionescu-Idbohrn wrote: > > Exit status is: > > * 0 if EXPRESSION is neither null nor 0, > > * 1 if EXPRESSION is null or 0, > > So, the line above is what IMO is a bug. The exit status should not be > 1 when the EXPRESSION is a perfectly valid 0. But expr is commonly used for math code, and most people want a result of 0 to be special. The expected behaviour is subject to the user's opinion and desire, but I wouldn't call the current behaviour a bug. > > Thanks for the workaround, but it's bloat :( It's only a wrapper for the program. > > # check text against regex (first argument) > > check() { > > regex="$1" > > shift > > result=$(./busybox expr "${*}" : "$regex") > > [ -z "$result" ] && return 1 > > return 0 > > } > > > > $ check '[^0-9]\+\([0-9]\+\)' xyz0 ; echo $?: $result > > 0: 0 > > $ check '[^0-9]\+\([0-9]\+\)' 0xyz0 ; echo $?: $result > > 1: > > All that (slow) shell code... All the work is done by expr. The shell code only checks the output and error code and sets the error code to 0 if the output is 0. It's the behaviour you want. > Wouldn't it be easier to fix the bug? You have the code, you can change your version. Don't be surprised if other people's code that use expr gets broken by your change. But I suppose there isn't much code using expr out there. -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061209/e5835b94/attachment.pgp From vda.linux at googlemail.com Sat Dec 9 18:24:22 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 10 Dec 2006 03:24:22 +0100 Subject: _FILE_OFFSET_BITS why this? In-Reply-To: <200612041131.52656.bornland@gmx.at> References: <200612041131.52656.bornland@gmx.at> Message-ID: <200612100324.22415.vda.linux@googlemail.com> On Monday 04 December 2006 11:31, Thomas Fr?hlich wrote: > Hi! > > I will compile the svn version, but in the last days I have some > problems. :( > My GCC is arm-linux-uclibc-gcc (GCC) 3.3.3 > My make command, after some trys: 'make ARCH=arm > CROSS_COMPILE=/usr/local/src/buildroot/build_arm_nofpu/staging_dir/bin/arm-linux-uclibc-' > > all will compile nice until: > CC util-linux/more.o > util-linux/more.c:107:5: "_FILE_OFFSET_BITS" is not defined > make[1]: *** [util-linux/more.o] Error 1 > make: *** [util-linux] Error 2 > > Why is _FILE_OFFSET_BITS for arm important? > > in the file is > > #if _FILE_OFFSET_BITS == 64 > len += printf("(%d%% of %lld bytes)", > (int) (100 * ((double) ftell(file) / > (double) st.st_size)), (long long)st.st_size); > #else > len += printf("(%d%% of %ld bytes)", > (int) (100 * ((double) ftell(file) / > (double) st.st_size)), (long)st.st_size); > #endif > > but it's the same to 1.2.0. > > in Makefile.flags:15: $(if $(CONFIG_LFS),-D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64) > > is this right? Fallout from -Wundef. Fixed in svn, thanks. -- vda From vda.linux at googlemail.com Sat Dec 9 18:34:43 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 10 Dec 2006 03:34:43 +0100 Subject: undefined reference to `bb_makedev' In-Reply-To: References: Message-ID: <200612100334.44016.vda.linux@googlemail.com> On Sunday 03 December 2006 16:32, Yuwen Dai wrote: > Dear all, > > When I built the current svn source, I got this error: > > LINK busybox_unstripped > /usr/bin/ld: Warning: gc-sections option ignored Hmm... What is your arch? Version of gcc and ld? > archival/libunarchive/lib.a(get_header_cpio.o)(.text.get_header_cpio+0x321): > In function `get_header_cpio': > : undefined reference to `bb_makedev' > > > I saw bb_makedev is defined in libbb/makedev.c surrounded by #ifdef > __GLIBC__, should I define this macro? No. You should investigate how come get_header_cpio.c managed to reference bb_makedev here: file_header->device = makedev(major, minor); Because as far as I can see, makedev is mapped to bb_makedev AND bb_makedev is defined under the very same #ifdef: include/libbb.h: #ifdef __GLIBC__ /* At least glibc has horrendously large inline for this, so wrap it */ extern unsigned long long bb_makedev(unsigned int major, unsigned int minor); #undef makedev #define makedev(a,b) bb_makedev(a,b) #endif libbb/makedev.c: #ifdef __GLIBC__ /* At least glibc has horrendously large inline for this, so wrap it */ /* uclibc people please check - do we need "&& !__UCLIBC__" above? */ unsigned long long bb_makedev(unsigned int major, unsigned int minor) { return makedev(major, minor); } #endif So, how come __GLIBC__ was defined in get_header_cpio.c and _wasn't_ defined in makedev.c?? Or maybe makedev.o is not linked in? -- vda From vda.linux at googlemail.com Sat Dec 9 19:08:19 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 10 Dec 2006 04:08:19 +0100 Subject: busybox --gc-sections thing In-Reply-To: <20061207215945.id6zyuxl2qswo0c8@webmail.bur.st> References: <20061207215945.id6zyuxl2qswo0c8@webmail.bur.st> Message-ID: <200612100408.19363.vda.linux@googlemail.com> On Thursday 07 December 2006 13:59, shevek at bur.st wrote: > Denis, > > I am merely an occaisional user of busybox, but I am troubled by the > current status. > > 1) no sig for latest release > > 2) latest release was to address an issue which seems to be due to an > unwise default setting that saves only 5k? why not simply set the > default to not use the --gc-sections thing, and allow people to switch > it on at-their-own-risk? Because garbage collecting unused sections at link time is the Right Thing to do. It's strange that unix linkers started to have this feature only now. Borland's Turbo Pascal had something like that years ago. bbox project was going to great pains to work around that, but this feature of ld looks more mature now, so why we shouldn't use it? It saves size. > 3) your comment that glibc is useless for static linking flies in the > face of popular opinion and widespread practice, as well as busybox > documentation and precedent... Static glibc sucks in ~400k into even simplest executables ("Hello world"-class). With that kind of bloat, you can use non-busyboxed utilities as well. Static glibc cannot do name resolution. Forget "ping " - it won't work. (Didn't check recently - maybe fixed now). > http://www.busybox.net/lists/busybox/2006-November/025240.html > > http://www.busybox.net/lists/busybox/2006-April/020147.html > > From the two messages above, and reading your comments about 1.2.2.1 > it seems to me, a mere occaisional user who has not been following the > mailing lists, that you have taken a stance and are unwilling to back > down, therefore have not implemented an obvious workaround. Is this I am willing to automatically drop --gc-sections option to ld if we know that we do "glibc+static" thing. Q: how to detect that we are doing that thing? > possible? I have no grounds to criticise you, but I hope for more from > the maintainer of the app. -- vda From vda.linux at googlemail.com Sat Dec 9 19:09:54 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 10 Dec 2006 04:09:54 +0100 Subject: miscutils/nmeter.c:19: warning: redefinition of `ulong' In-Reply-To: References: <4573DC95.4050902@bfs.de> Message-ID: <200612100409.54190.vda.linux@googlemail.com> On Tuesday 05 December 2006 02:57, Yuwen Dai wrote: > On 12/4/06, walter harms wrote: > > > > ulong != int64_t > > > > far better would be a s/ulong/unsigned long/g > > > trivia: ulong is a BSDism so far i know > > yeah, I had a wrong concept. > > The point is: how to build buzybox with a older verson of glibc and > headers. The busybox developer seem use a higher verrsion of glibc, didn't > notice this issue. ulong is not used in nmeter. I removed the typedef in svn. -- vda From yuwend at gmail.com Sat Dec 9 20:34:00 2006 From: yuwend at gmail.com (Yuwen Dai) Date: Sun, 10 Dec 2006 12:34:00 +0800 Subject: CONFIG_DEBUG Message-ID: Dear all, I'd thought CONFIG_DEBUG was related to compiling option like "-g" so that I could debug by using GDB. But it seems not. So what is CONFIG_DEBUG for? regards, Yuwen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061210/4688a18d/attachment.htm From yann.morin.1998 at anciens.enib.fr Sun Dec 10 06:19:40 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun, 10 Dec 2006 15:19:40 +0100 Subject: busybox --gc-sections thing In-Reply-To: <200612100408.19363.vda.linux@googlemail.com> References: <20061207215945.id6zyuxl2qswo0c8@webmail.bur.st> <200612100408.19363.vda.linux@googlemail.com> Message-ID: <200612101519.40763.yann.morin.1998@anciens.enib.fr> Denis, all, On Sunday 10 December 2006 040, Denis Vlasenko wrote: > Static glibc cannot do name resolution. Forget "ping " - > it won't work. (Didn't check recently - maybe fixed now). Yes it does. *But* you have to have at least one of those: libnss_{compat,dns,files,hesiod,nis{,plus}}*.so And, yes, those are shared libraries, and you need them to be present even if your binary was statically linked. NSS stands for Name Service Switch, and is configured via /etc/nsswitch.conf. And those libraries are linked against libc.so and ld-linux.so, then you'll have to have the shared C library and the dynamic loader as well! Thus, compiling static binaries, which require name services (eg. DNS), with glibc anyway sucks in libc.so and at least one of the libnss libraries... So, stay away from static linking with glibc. Use uClibc. 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 floydpink at gmail.com Sun Dec 10 06:58:04 2006 From: floydpink at gmail.com (Jason Schoon) Date: Sun, 10 Dec 2006 08:58:04 -0600 Subject: busybox --gc-sections thing In-Reply-To: <200612101519.40763.yann.morin.1998@anciens.enib.fr> References: <20061207215945.id6zyuxl2qswo0c8@webmail.bur.st> <200612100408.19363.vda.linux@googlemail.com> <200612101519.40763.yann.morin.1998@anciens.enib.fr> Message-ID: <78a54e1b0612100658l280bb347ja499b41cf30046ae@mail.gmail.com> On 12/10/06, Yann E. MORIN wrote: > > Denis, all, > > On Sunday 10 December 2006 040, Denis Vlasenko wrote: > > Static glibc cannot do name resolution. Forget "ping " - > > it won't work. (Didn't check recently - maybe fixed now). > > Yes it does. *But* you have to have at least one of those: > libnss_{compat,dns,files,hesiod,nis{,plus}}*.so > > And, yes, those are shared libraries, and you need them to be present even > if > your binary was statically linked. NSS stands for Name Service Switch, and > is > configured via /etc/nsswitch.conf. > > And those libraries are linked against libc.so and ld-linux.so, then > you'll > have to have the shared C library and the dynamic loader as well! > > Thus, compiling static binaries, which require name services (eg. DNS), > with > glibc anyway sucks in libc.so and at least one of the libnss libraries... > > So, stay away from static linking with glibc. Use uClibc. > > Regards, > Yann E. MORIN. Well said. There really isn't much of a reason to statically link with glibc. If you do, you can live with seeing Busybox spit out some warnings. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061210/b161679d/attachment.html From s.maiti at tcs.com Sun Dec 10 21:49:50 2006 From: s.maiti at tcs.com (s.maiti at tcs.com) Date: Mon, 11 Dec 2006 11:19:50 +0530 Subject: Need help regarding upgrading busybox Message-ID: Hi All, I am using linux-2.4.25 kernel and ELDK3.1 toolchain for my Custom PPC(MPC8260) board. I am using the ramdisk image which is come along with the ELDK. With this board is coming up. Now I wanted to upgrade my busybox-0.65 to busybox-1.1.3 So I installed the new busy box and copied the bin sbin and usr directories to the filesytem . When i tried to do tftp it is giving following errors. Looking up port of RPC 100005/1 on 172.18.18.59 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 56k init kmod: runaway modprobe loop assumed and stopped kmod: runaway modprobe loop assumed and stopped kmod: failed to exec /sbin/modprobe -s -k binfmt-4c46, errno = 8 (endless loop) With the old busybox it is working fine. Please kindly help me in this regard. Souvik Maiti Tata Consultancy Services Mailto: s.maiti at tcs.com Website: http://www.tcs.com =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061211/b70dc204/attachment.html From parmarsatpal at gmail.com Sun Dec 10 23:55:08 2006 From: parmarsatpal at gmail.com (satpal parmar) Date: Mon, 11 Dec 2006 13:25:08 +0530 Subject: how to run udcpc Message-ID: <457d2dc30612102355u5dbc58a4l3038c5a604712548@mail.gmail.com> Hi all; I am learning to use buzy box.So kindly bear with my naive questions. I am trying to run udcpc( uhcp clinet program with busybox) on am ARM 9 based board. For that I configured buzybox with clinet support.On porting I evoked clinet as :udcpc -i -b eth0. I confirmed through ps that clinet if running.But it get hanged. Anyone please help me to run udcpc of buzybox. Is there any other configuration to be done. Just in case you find this revlevent Ping is working fine. I have pf_packet support enable. Thanks in advance. satpal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061211/bf5a923d/attachment.htm From mormo at spray.se Mon Dec 11 00:48:49 2006 From: mormo at spray.se (mormo) Date: Mon, 11 Dec 2006 08:48:49 +0000 Subject: BusyBox init with udevd problem Message-ID: <13955891307943@lycos-europe.com> An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061211/cb59df1a/attachment.html From rep.nop at aon.at Mon Dec 11 02:18:48 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon, 11 Dec 2006 11:18:48 +0100 Subject: Need help regarding upgrading busybox In-Reply-To: References: Message-ID: <20061211101848.GA20661@aon.at> On Mon, Dec 11, 2006 at 11:19:50AM +0530, s.maiti at tcs.com wrote: >Hi All, >I am using linux-2.4.25 kernel and ELDK3.1 toolchain for my Custom >PPC(MPC8260) board. I am using the ramdisk image which is come along with >the ELDK. > >With this board is coming up. >Now I wanted to upgrade my busybox-0.65 to busybox-1.1.3 The current stable release is 1.2.2.1 > So I installed the new busy box and copied the bin sbin and usr >directories to the filesytem . When i tried to do tftp it is giving >following errors. > >Looking up port of RPC 100005/1 on 172.18.18.59 >VFS: Mounted root (nfs filesystem). >Freeing unused kernel memory: 56k init >kmod: runaway modprobe loop assumed and stopped >kmod: runaway modprobe loop assumed and stopped >kmod: failed to exec /sbin/modprobe -s -k binfmt-4c46, errno = 8 (endless >loop) > > >With the old busybox it is working fine. > >Please kindly help me in this regard. > >Souvik Maiti >Tata Consultancy Services >Mailto: s.maiti at tcs.com >Website: http://www.tcs.com >=====-----=====-----===== >Notice: The information contained in this e-mail >message and/or attachments to it may contain >confidential or privileged information. If you are >not the intended recipient, any dissemination, use, >review, distribution, printing or copying of the >information contained in this e-mail message >and/or attachments to it are strictly prohibited. If >you have received this communication in error, >please notify us by reply e-mail or telephone and >immediately and permanently delete the message >and any attachments. Thank you Posting stuff like this crap to a publically archived mailing-list is complete and utter nonsense. binfmt-4c64: Not a busybox problem. Most likely, you compiled your modules for the wrong arch or busybox for the wrong arch. From roberto.foglietta at gmail.com Mon Dec 11 06:12:54 2006 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Mon, 11 Dec 2006 15:12:54 +0100 Subject: how to run udcpc In-Reply-To: <457d2dc30612102355u5dbc58a4l3038c5a604712548@mail.gmail.com> References: <457d2dc30612102355u5dbc58a4l3038c5a604712548@mail.gmail.com> Message-ID: 2006/12/11, satpal parmar : > Hi all; > > I am learning to use buzy box.So kindly bear with my naive questions. I am > trying to run udcpc( uhcp clinet program with busybox) on am ARM 9 based > board. > > For that I configured buzybox with clinet support.On porting I evoked clinet > as :udcpc -i -b eth0. I confirmed through ps that clinet if running.But it > get hanged. I will appreciate s/buzybox/busybox/g but probably I lack in sense of humor ;-) I would have done: udhcpc -b -i eth0 -s /etc/udhcpc-script where /etc/udhcpc-script, for example: # cat /etc/udhcpc-script #!/bin/sh echo "******************************** $1 ********* $interface $ip" if test "$1" = "bound"; then echo $interface $ip netmask $subnet broadcast $broadcast ifconfig $interface $ip netmask $subnet broadcast $broadcast up ############### DNS ############### rm -f /etc/resolv.conf if test -n "$domain"; then echo "search $domain" > /etc/resolv.conf fi for i in $dns; do echo "nameserver $i" >> /etc/resolv.conf done ############### HOSTNAME ############### test -z "$hostname" && hostname=$ip hostname $hostname echo hostname: $hostname.$domain ifconfig $interface | egrep . ############### GATEWAY ############### test -n "$router" && route add default gw $router route -n; echo fi I hope this help. Cheers, -- /roberto From cristian.ionescu-idbohrn at axis.com Mon Dec 11 08:00:40 2006 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 11 Dec 2006 17:00:40 +0100 (CET) Subject: expr applet bug? In-Reply-To: <20061209174424.GA11041@nsk.no-ip.org> References: <0612082007540.11453@somehost> <20061208192338.GA1235@nsk.no-ip.org> <0612082036340.11453@somehost> <20061208201323.GB1235@nsk.no-ip.org> <0612091827510.4921@somehost> <20061209174424.GA11041@nsk.no-ip.org> Message-ID: <0612111215380.11453@somehost> On Sat, 9 Dec 2006, Luciano Miguel Ferreira Rocha wrote: > On Sat, Dec 09, 2006 at 06:38:04PM +0100, Cristian Ionescu-Idbohrn wrote: > > > Exit status is: > > > * 0 if EXPRESSION is neither null nor 0, > > > * 1 if EXPRESSION is null or 0, > > > > So, the line above is what IMO is a bug. The exit status should > > not be 1 when the EXPRESSION is a perfectly valid 0. > > But expr is commonly used for math code, and most people want a > result of 0 to be special. Nevertheless the MATCH option is there too. > The expected behaviour is subject to the user's opinion and desire, > but I wouldn't call the current behaviour a bug. I'm inclined to agree with you. Still... > > Thanks for the workaround, but it's bloat :( > > It's only a wrapper for the program. Yes, but I'm running expr on a "slow" embeded system and I need to save every cycle I can. More shell code == bad. > All the work is done by expr. The shell code only checks the output > and error code and sets the error code to 0 if the output is 0. It's > the behaviour you want. Yes. That's what I want and I somehow have to pay for it. > > Wouldn't it be easier to fix the bug? > You have the code, you can change your version. Don't be surprised > if other people's code that use expr gets broken by your change. But > I suppose there isn't much code using expr out there. FWIW, I found a discrepancy between bb-expr and gnu-expr: busybox: expr xyz0 : '[^0-9]\+\([0-9]\+\)' res=0, err=1 busybox: expr xyz00 : '[^0-9]\+\([0-9]\+\)' res=00, err=0 <--- gnu: expr xyz0 : '[^0-9]\+\([0-9]\+\)' res=0, err=1 expr xyz00 : '[^0-9]\+\([0-9]\+\)' res=00, err=1 As you can see, gnu-expr returns exit status 1 for both xyz0 and xyz00, but bb-expr doesn't. Cheers, Cristian From rep.nop at aon.at Mon Dec 11 08:32:12 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon, 11 Dec 2006 17:32:12 +0100 Subject: expr applet bug? In-Reply-To: <0612111215380.11453@somehost> References: <0612082007540.11453@somehost> <20061208192338.GA1235@nsk.no-ip.org> <0612082036340.11453@somehost> <20061208201323.GB1235@nsk.no-ip.org> <0612091827510.4921@somehost> <20061209174424.GA11041@nsk.no-ip.org> <0612111215380.11453@somehost> Message-ID: <20061211163212.GA23446@aon.at> On Mon, Dec 11, 2006 at 05:00:40PM +0100, Cristian Ionescu-Idbohrn wrote: >On Sat, 9 Dec 2006, Luciano Miguel Ferreira Rocha wrote: > >> On Sat, Dec 09, 2006 at 06:38:04PM +0100, Cristian Ionescu-Idbohrn wrote: >> > > Exit status is: >> > > * 0 if EXPRESSION is neither null nor 0, >> > > * 1 if EXPRESSION is null or 0, >> > >> > So, the line above is what IMO is a bug. The exit status should >> > not be 1 when the EXPRESSION is a perfectly valid 0. Wrong. Mandated by the std. See http://www.opengroup.org/onlinepubs/009695399/utilities/expr.html#tag_04_50_14 but see below >> >> But expr is commonly used for math code, and most people want a >> result of 0 to be special. > >Nevertheless the MATCH option is there too. > >> The expected behaviour is subject to the user's opinion and desire, >> but I wouldn't call the current behaviour a bug. > >I'm inclined to agree with you. Still... > >> > Thanks for the workaround, but it's bloat :( >> >> It's only a wrapper for the program. > >Yes, but I'm running expr on a "slow" embeded system and I need to >save every cycle I can. More shell code == bad. > >> All the work is done by expr. The shell code only checks the output >> and error code and sets the error code to 0 if the output is 0. It's >> the behaviour you want. > >Yes. That's what I want and I somehow have to pay for it. > >> > Wouldn't it be easier to fix the bug? >> You have the code, you can change your version. Don't be surprised >> if other people's code that use expr gets broken by your change. But >> I suppose there isn't much code using expr out there. > >FWIW, I found a discrepancy between bb-expr and gnu-expr: > >busybox: expr xyz0 : '[^0-9]\+\([0-9]\+\)' > res=0, err=1 >busybox: expr xyz00 : '[^0-9]\+\([0-9]\+\)' > res=00, err=0 <--- Yes, that's a bug, 00 == 0x0 == 0 thus has to ret 1 Care to send a patch against trunk? It'd be awesome if you could whip up a testcase for the testharness. Bonus points if you convert expr*/* into an expr.tests :) cheers and TIA, > >gnu: expr xyz0 : '[^0-9]\+\([0-9]\+\)' > res=0, err=1 > expr xyz00 : '[^0-9]\+\([0-9]\+\)' > res=00, err=1 > >As you can see, gnu-expr returns exit status 1 for both xyz0 and >xyz00, but bb-expr doesn't. From rob at landley.net Mon Dec 11 08:53:53 2006 From: rob at landley.net (Rob Landley) Date: Mon, 11 Dec 2006 11:53:53 -0500 Subject: busybox --gc-sections thing In-Reply-To: <78a54e1b0612100658l280bb347ja499b41cf30046ae@mail.gmail.com> References: <20061207215945.id6zyuxl2qswo0c8@webmail.bur.st> <200612101519.40763.yann.morin.1998@anciens.enib.fr> <78a54e1b0612100658l280bb347ja499b41cf30046ae@mail.gmail.com> Message-ID: <200612111153.53875.rob@landley.net> On Sunday 10 December 2006 9:58 am, Jason Schoon wrote: > Well said. There really isn't much of a reason to statically link with > glibc. If you do, you can live with seeing Busybox spit out some warnings. Last I checked the warnings didn't actually _fix_ anything, so the resulting binary is still broken (thanks to glibc's stdio going "boing" with gc-sections), and when you redirect output it disappears. Statically linking against uClibc works. With glibc, the only option is to disable --gc-sections. (And given how bloated statically linking against glibc already is, the difference in the resulting binary size is a rounding error.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Mon Dec 11 09:39:43 2006 From: rob at landley.net (Rob Landley) Date: Mon, 11 Dec 2006 12:39:43 -0500 Subject: Need help regarding upgrading busybox In-Reply-To: References: Message-ID: <200612111239.43640.rob@landley.net> On Monday 11 December 2006 12:49 am, s.maiti at tcs.com wrote: > Hi All, > I am using linux-2.4.25 kernel and ELDK3.1 toolchain for my Custom > PPC(MPC8260) board. I am using the ramdisk image which is come along with > the ELDK. > > With this board is coming up. > Now I wanted to upgrade my busybox-0.65 to busybox-1.1.3 > So I installed the new busy box So you've confirmed that all your symlinks are ok, then? Did you actually remove the old busybox from the system, or is this in addition to it? > and copied the bin sbin and usr > directories to the filesytem. When i tried to do tftp it is giving > following errors. (Ok, so your shell came up. Was busybox providing that shell?) Nice to have some idea if at least baseline functionality is working with the new thing, and that your toolchain is ok and so on. Is BusyBox providing your tftp client? > Looking up port of RPC 100005/1 on 172.18.18.59 > VFS: Mounted root (nfs filesystem). > Freeing unused kernel memory: 56k init > kmod: runaway modprobe loop assumed and stopped > kmod: runaway modprobe loop assumed and stopped > kmod: failed to exec /sbin/modprobe -s -k binfmt-4c46, errno = 8 (endless > loop) Is busybox providing your modprobe? (Was busybox providing your old modprobe?) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From carsten.hausel at ivv.de Mon Dec 11 13:02:23 2006 From: carsten.hausel at ivv.de (carsten.hausel at ivv.de) Date: Mon, 11 Dec 2006 22:02:23 +0100 Subject: Carsten Hausel ist =?ISO-8859-1?Q?au=DFer_Haus=2E?= Message-ID: Ich werde ab 11.12.2006 nicht im B?ro sein. Ich kehre zur?ck am 16.12.2006. Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten. From cshore at wightman.ca Mon Dec 11 22:10:06 2006 From: cshore at wightman.ca (Daniel Dickinson) Date: Tue, 12 Dec 2006 01:10:06 -0500 Subject: Compilation fails with bbconfigopts.h:13 hmm, unterminated Message-ID: <1165903806.3455.8.camel@kath.fionavar.dd> With both busybox 1.2.2 and 1.2.2.1 I get the error message "...bbconfigopts.h:13 hmmm, unterminated" which results in compilation failing. Checking bbconfigopts.h it seems every line has a linefeed then what should be the closing quote. http://busybox.net/lists/busybox/attachments/20061003/e64e1406/attachment.html describes the same problem, and the fix is in: http://www.busybox.net/lists/busybox/2006-October/024879.html The author of those messages mentioned Ubuntu; I am using Xubuntu. You asked him about the version of awk; for me, awk reports: GNU Awk 3.1.5 and sed is: GNU sed version 4.1.5 and for free, make is: GNU Make 3.81 Does any of that help? Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/busybox/attachments/20061212/e9ae3618/attachment.pgp From martyn.welch at radstone.co.uk Tue Dec 12 04:30:06 2006 From: martyn.welch at radstone.co.uk (Martyn Welch) Date: Tue, 12 Dec 2006 12:30:06 -0000 Subject: Busybox tar failing to compile on snapshot of uClibc Message-ID: Hi, I've been trying to compile busybox as part of buildroot. I am using yesterdays snapshots of uClibc and busybox. It seems that tar.c uses "bzero", which seems to be no longer provided in uClibc. I have managed to get busybox to compile by removing tar from the build options, though I seem to end up with a binary for which all commands are hdparm! Any ideas? Thank you in advance for any help (sorry if this is a bit of a newbie question), Martyn ________________________________________________________________________ This e-mail has been scanned for all viruses by Star.The service is powered by MessageLabs. ________________________________________________________________________ From rep.nop at aon.at Tue Dec 12 04:52:38 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue, 12 Dec 2006 13:52:38 +0100 Subject: Busybox tar failing to compile on snapshot of uClibc In-Reply-To: References: Message-ID: <20061212125238.GA30226@aon.at> On Tue, Dec 12, 2006 at 12:30:06PM -0000, Martyn Welch wrote: >Hi, > >I've been trying to compile busybox as part of buildroot. > >I am using yesterdays snapshots of uClibc and busybox. It seems that >tar.c uses "bzero", which seems to be no longer provided in uClibc. That's not really correct. If you want the SUSv3 LEGACY stuff, then turn it on. See make uclibc-menuconfig That said, i fixed tar to not use that legacy crap. See r16850. > >I have managed to get busybox to compile by removing tar from the build >options, though I seem to end up with a binary for which all commands >are hdparm! Sounds like a broken toolchain. From rob at landley.net Tue Dec 12 11:21:51 2006 From: rob at landley.net (Rob Landley) Date: Tue, 12 Dec 2006 14:21:51 -0500 Subject: Busybox tar failing to compile on snapshot of uClibc In-Reply-To: <20061212125238.GA30226@aon.at> References: <20061212125238.GA30226@aon.at> Message-ID: <200612121421.52636.rob@landley.net> On Tuesday 12 December 2006 7:52 am, Bernhard Fischer wrote: > On Tue, Dec 12, 2006 at 12:30:06PM -0000, Martyn Welch wrote: > >Hi, > > > >I've been trying to compile busybox as part of buildroot. > > > >I am using yesterdays snapshots of uClibc and busybox. It seems that > >tar.c uses "bzero", which seems to be no longer provided in uClibc. > > That's not really correct. If you want the SUSv3 LEGACY stuff, then turn > it on. See make uclibc-menuconfig > > That said, i fixed tar to not use that legacy crap. See r16850. In toybox I've got a check if bzero exists, and if not I implement it in the library. I don't know why they deprecate it, bzero() is one less function argument for _the_ single most common use of memset(). And I'm not humoring them. You're welcome to kowtow to standards bodies however you want. Let me know when your build environment contains sccs: http://www.opengroup.org/onlinepubs/009695399/utilities/sccs.html Or when you've restricted df -p to use 32 bit integers on 64-bit platforms: http://www.opengroup.org/onlinepubs/009695399/utilities/df.html http://www.unix.org/version2/whatsnew/lp64_wp.html Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From vda.linux at googlemail.com Tue Dec 12 16:48:47 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Wed, 13 Dec 2006 01:48:47 +0100 Subject: RFC: busybox 1.2.3? Message-ID: <200612130148.47851.vda.linux@googlemail.com> Hi people, It seems I fixed "make release" to actually work again. I am thinking about releasing next version so that people will try & break changed stuff. I think kernel's way of having bugfix releases with fourth number (x.y.z.N) will work for us too. Any thoughts what should be done before releasing 1.2.3? -- vda From rob at landley.net Tue Dec 12 18:22:29 2006 From: rob at landley.net (Rob Landley) Date: Tue, 12 Dec 2006 21:22:29 -0500 Subject: RFC: busybox 1.2.3? In-Reply-To: <200612130148.47851.vda.linux@googlemail.com> References: <200612130148.47851.vda.linux@googlemail.com> Message-ID: <200612122122.30254.rob@landley.net> On Tuesday 12 December 2006 7:48 pm, Denis Vlasenko wrote: > Hi people, > > It seems I fixed "make release" to actually work again. > I am thinking about releasing next version so that > people will try & break changed stuff. > > I think kernel's way of having bugfix releases > with fourth number (x.y.z.N) will work for us too. Actually, the _third_ number was the bugfix release number. You added a 1.2.2.1 yourself (which I thought strange at the time). > Any thoughts what should be done before releasing 1.2.3? The established numbering scheme says that would be a bugfix release, and 1.3.0 would be the next -devel release. It's up to you what you want to do, of course... Rob > -- > vda > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rep.nop at aon.at Wed Dec 13 09:52:13 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed, 13 Dec 2006 18:52:13 +0100 Subject: CONFIG_DEBUG In-Reply-To: References: Message-ID: <20061213175213.GA22856@aon.at> On Sun, Dec 10, 2006 at 12:34:00PM +0800, Yuwen Dai wrote: >Dear all, > >I'd thought CONFIG_DEBUG was related to compiling option like "-g" so that I Right. This was apparently lost when moving to the kbuild infrastructure. Fixed in r16900 Thanks for noticing this. From vda.linux at googlemail.com Wed Dec 13 15:55:54 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Thu, 14 Dec 2006 00:55:54 +0100 Subject: RFC: busybox 1.2.3? In-Reply-To: <200612122122.30254.rob@landley.net> References: <200612130148.47851.vda.linux@googlemail.com> <200612122122.30254.rob@landley.net> Message-ID: <200612140055.55012.vda.linux@googlemail.com> On Wednesday 13 December 2006 03:22, Rob Landley wrote: > On Tuesday 12 December 2006 7:48 pm, Denis Vlasenko wrote: > > Hi people, > > > > It seems I fixed "make release" to actually work again. > > I am thinking about releasing next version so that > > people will try & break changed stuff. > > > > I think kernel's way of having bugfix releases > > with fourth number (x.y.z.N) will work for us too. > > Actually, the _third_ number was the bugfix release number. So be it. It is going to be busybox-1.3.0 -- vda From vda.linux at googlemail.com Wed Dec 13 16:59:05 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Thu, 14 Dec 2006 01:59:05 +0100 Subject: Busybox 1.3.0 is available Message-ID: <200612140159.05625.vda.linux@googlemail.com> Hi people, Tarball is already in http://busybox.net/downloads/, busybox.net webpage will be updated soon. Bug fixes will go into 1.3.x, new development into current svn and eventually 1.4.0. -- vda From trevor at vocaro.com Wed Dec 13 21:09:25 2006 From: trevor at vocaro.com (Trevor Harmon) Date: Wed, 13 Dec 2006 21:09:25 -0800 Subject: Getting started with mdev Message-ID: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> Hi, I need some help getting started with mdev. I tried to find some documentation on it, but there doesn't seem to be much out there. I started with an empty /dev, but that causes a failure on boot: "Warning: unable to open an initial console." I then manually created an entry for /dev/console, and that allows the system to boot, but /dev still isn't being populated. All I see is the /dev/console entry I created myself. And yet, the system seems to be running fine otherwise. I also note that there is no /sys directory, even though I have CONFIG_SYSFS enabled in my kernel. Is this why mdev is not populating /dev? In BusyBox, I have CONFIG_FEATURE_MDEV_CONF turned off. I don't think I need any special mdev rules; all I have is an Ethernet controller and a couple of serial ports. I just want to avoid having to create the entire /dev tree manually. Thanks for any pointers, Trevor From rep.nop at aon.at Thu Dec 14 00:25:45 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu, 14 Dec 2006 09:25:45 +0100 Subject: RFC: busybox 1.2.3? In-Reply-To: <200612130148.47851.vda.linux@googlemail.com> References: <200612130148.47851.vda.linux@googlemail.com> Message-ID: <20061214082545.GA29586@aon.at> On Wed, Dec 13, 2006 at 01:48:47AM +0100, Denis Vlasenko wrote: >Hi people, > >It seems I fixed "make release" to actually work again. >I am thinking about releasing next version so that >people will try & break changed stuff. > >I think kernel's way of having bugfix releases >with fourth number (x.y.z.N) will work for us too. > >Any thoughts what should be done before releasing 1.2.3? There is one long-standing bug that would be really nice if it was finally fixed for good: - Specifying a path to df doesn't work. There's also a bugreport about this (or two): $ ./busybox df -k / ; echo $? Filesystem 1k-blocks Used Available Use% Mounted on 0 $ df -k / ; echo $? Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 67282996 58701576 7214292 90% / 0 $ grep hda1 /proc/mounts /dev/hda1 / ext3 rw,data=ordered,usrquota,grpquota 0 0 /dev/hda1 /dev/.static/dev ext3 rw,data=ordered,usrquota,grpquota 0 0 Another one that looks like it will affect several cases where busybox is used (desktop boot system): - IIRC readlink -f /nonexisting_file does print the nonexisting file in current coreutils as oopposed to our impl. It's used in several sysv scripts in distros, i think, so we should match the current coreutils impl. $ ./busybox readlink -f /nono ; echo $? 1 $ readlink -f /nono ; echo $? /nono 0 $ readlink --version | head -n 1 readlink (GNU coreutils) 5.97 Some notes concerning the release branch: 1) please don't forget to do a svn cp ../trunk/busybox .../branches/busybox-1_3-stable This should be done for any release. 2) Please create a tag for the actual 1.3.0 release (in the -stable branch, perhaps). This should imo be done for any release. 3) Please do not forget to remove the -Werror from Makefile.flags for the stable series. It may be nice to have for development, but breaking to build for users because of it sounds like it will trigger complaints.. From Kim.Heino at bluegiga.com Thu Dec 14 02:20:33 2006 From: Kim.Heino at bluegiga.com (Kim B. Heino) Date: Thu, 14 Dec 2006 12:20:33 +0200 Subject: BusyBox 1.3.0 without CONFIG_FEATURE_TAR_GNU_EXTENSIONS Message-ID: <45812571.8050908@bluegiga.com> Hello, If I don't enable CONFIG_FEATURE_TAR_GNU_EXTENSIONS option, BusyBox fails to compile: CC archival/libunarchive/get_header_tar.o archival/libunarchive/get_header_tar.c: In function `get_header_tar': archival/libunarchive/get_header_tar.c:77: warning: label `again' defined but not used make[2]: *** [archival/libunarchive/get_header_tar.o] Error 1 The fix is simple, you have to change > again: to > #if ENABLE_FEATURE_TAR_GNU_EXTENSIONS > again: > #endif From rep.nop at aon.at Thu Dec 14 03:39:19 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu, 14 Dec 2006 12:39:19 +0100 Subject: svn commit: trunk/busybox/coreutils In-Reply-To: <20061214112759.1036B485A4@busybox.net> References: <20061214112759.1036B485A4@busybox.net> Message-ID: <20061214113919.GA32239@aon.at> On Thu, Dec 14, 2006 at 03:27:59AM -0800, aldot at busybox.net wrote: >Author: aldot >Date: 2006-12-14 03:27:58 -0800 (Thu, 14 Dec 2006) >New Revision: 16919 > >Log: >- minor shrinkage Note that from the looks, we have alot of places that would benefit from being changed to last_char_is() respectively our other path-handling functions (concat_path_file et al). Also, there seem to be several users of the pattern if last character is 'c' nullify pos_of_c To name just two: the hunk below du.c:125 ff cheers, > >Modified: > trunk/busybox/coreutils/diff.c > > >Changeset: >Modified: trunk/busybox/coreutils/diff.c >=================================================================== >--- trunk/busybox/coreutils/diff.c 2006-12-14 08:12:18 UTC (rev 16918) >+++ trunk/busybox/coreutils/diff.c 2006-12-14 11:27:58 UTC (rev 16919) >@@ -1105,10 +1105,12 @@ > > /* Check for trailing slashes. */ > >- if (p1[strlen(p1) - 1] == '/') >- p1[strlen(p1) - 1] = '\0'; >- if (p2[strlen(p2) - 1] == '/') >- p2[strlen(p2) - 1] = '\0'; >+ dp1 = last_char_is(p1, '/'); >+ if (dp1 != NULL) >+ *dp1 = '\0'; >+ dp2 = last_char_is(p2, '/'); >+ if (dp2 != NULL) >+ *dp2 = '\0'; > > /* Get directory listings for p1 and p2. */ > > >_______________________________________________ >busybox-cvs mailing list >busybox-cvs at busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox-cvs > From Kim.Heino at bluegiga.com Thu Dec 14 06:16:39 2006 From: Kim.Heino at bluegiga.com (Kim B. Heino) Date: Thu, 14 Dec 2006 16:16:39 +0200 Subject: BusyBox 1.3.0 ar/dpkg is broken Message-ID: <45815CC7.1030106@bluegiga.com> Hello, The new xstrtoul() and xatou() functions broke ar and dpkg commands in BusyBox 1.3.0: dpkg: invalid number '100644 4 This is because get_header_ar() function is passing the binary header: typed->mode = xstrtoul(ar.formatted.mode, 8); typed->mtime = xatou(ar.formatted.date); ... typed->size = xatoul(ar.formatted.size); One way to fix this is to add strtoul's endptr parameter to xstrtoul() too. Another way is to use some other functions in get_header_ar() to parse header. Any suggestions? From rob at landley.net Thu Dec 14 09:17:33 2006 From: rob at landley.net (Rob Landley) Date: Thu, 14 Dec 2006 12:17:33 -0500 Subject: RFC: busybox 1.2.3? In-Reply-To: <200612140055.55012.vda.linux@googlemail.com> References: <200612130148.47851.vda.linux@googlemail.com> <200612122122.30254.rob@landley.net> <200612140055.55012.vda.linux@googlemail.com> Message-ID: <200612141217.33920.rob@landley.net> On Wednesday 13 December 2006 6:55 pm, Denis Vlasenko wrote: > On Wednesday 13 December 2006 03:22, Rob Landley wrote: > > On Tuesday 12 December 2006 7:48 pm, Denis Vlasenko wrote: > > > Hi people, > > > > > > It seems I fixed "make release" to actually work again. > > > I am thinking about releasing next version so that > > > people will try & break changed stuff. > > > > > > I think kernel's way of having bugfix releases > > > with fourth number (x.y.z.N) will work for us too. > > > > Actually, the _third_ number was the bugfix release number. > > So be it. It is going to be busybox-1.3.0 I look forward to it. :) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Thu Dec 14 09:21:23 2006 From: rob at landley.net (Rob Landley) Date: Thu, 14 Dec 2006 12:21:23 -0500 Subject: Busybox 1.3.0 is available In-Reply-To: <200612140159.05625.vda.linux@googlemail.com> References: <200612140159.05625.vda.linux@googlemail.com> Message-ID: <200612141221.23432.rob@landley.net> On Wednesday 13 December 2006 7:59 pm, Denis Vlasenko wrote: > Hi people, > > Tarball is already in http://busybox.net/downloads/, > busybox.net webpage will be updated soon. > > Bug fixes will go into 1.3.x, new development into > current svn and eventually 1.4.0. Just an FYI, for the web page notice I only put the (stable) tag on the end of ones that were bugfix-only releases. (This was apparently too subtle to be a useful distinction for people to pick up on...) Congratulations. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From aurel at gnuage.org Thu Dec 14 10:28:40 2006 From: aurel at gnuage.org (Aurelien Jacobs) Date: Thu, 14 Dec 2006 19:28:40 +0100 Subject: Busybox 1.3.0 is available In-Reply-To: <200612140159.05625.vda.linux@googlemail.com> References: <200612140159.05625.vda.linux@googlemail.com> Message-ID: <20061214192840.83a5a572.aurel@gnuage.org> On Thu, 14 Dec 2006 01:59:05 +0100 Denis Vlasenko wrote: > Hi people, > > Tarball is already in http://busybox.net/downloads/, > busybox.net webpage will be updated soon. defconfig don't compile here on amd64. There are 2 problems. The first attached patch fixes this: CC libbb/bb_pwd.o CC libbb/bb_strtonum.o libbb/bb_strtonum.c:102: error: conflicting types for 'bb_strtou' include/xatonum.h:140: error: previous declaration of 'bb_strtou' was here libbb/bb_strtonum.c:114: error: conflicting types for 'bb_strtoi' include/xatonum.h:141: error: previous declaration of 'bb_strtoi' was here make[1]: *** [libbb/bb_strtonum.o] Error 1 make: *** [libbb] Error 2 The second attached patch fixes that: CC networking/udhcp/dhcpd.o CC networking/udhcp/dhcprelay.o cc1: warnings being treated as errors networking/udhcp/dhcprelay.c: In function 'dhcprelay_loop': networking/udhcp/dhcprelay.c:287: warning: passing argument 6 of 'recvfrom' from incompatible pointer type make[1]: *** [networking/udhcp/dhcprelay.o] Error 1 make: *** [networking/udhcp] Error 2 Note that this second error is in fact just a warning. (It was really a bad idea to have -Werror in a release IMHO) Aurel -------------- next part -------------- A non-text attachment was scrubbed... Name: bb_fix1.diff Type: text/x-diff Size: 662 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061214/0cc5f4bd/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bb_fix2.diff Type: text/x-diff Size: 477 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061214/0cc5f4bd/attachment-0001.bin From bock at blacknet.de Thu Dec 14 11:34:37 2006 From: bock at blacknet.de (Goetz Bock) Date: Thu, 14 Dec 2006 20:34:37 +0100 Subject: Getting started with mdev In-Reply-To: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> References: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> Message-ID: <20061214193437.GN17104@priv.blacknet.de> On Wed, Dec 13 '06 at 21:09, Trevor Harmon wrote: > I need some help getting started with mdev. I tried to find some > documentation on it, but there doesn't seem to be much out there. IIRC there were a few files you should add to your static /dev: console, null, than you need to add /sys to your filsystem, and mount the sysfs there mount -t sysfs none /sys once that is done you can run mdev in scan mode to populate /dev mdev -s that should be it. -- /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting \ / (c) 2006 Creative Commons, Attribution-ShareAlike 2.0 de X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] From E.Spakman at inter.nl.net Thu Dec 14 13:50:54 2006 From: E.Spakman at inter.nl.net (Eric Spakman) Date: Thu, 14 Dec 2006 22:50:54 +0100 (CET) Subject: Busybox 1.3.0 is available In-Reply-To: <200612140159.05625.vda.linux@googlemail.com> References: <200612140159.05625.vda.linux@googlemail.com> Message-ID: <1376.213.51.237.6.1166133054.squirrel@webmail.internl.net> Hi Denis, A few bugs in this latest release. -start-stop-daemon When running start-stop-daemon the response is always "already running", no matter what you try to start, either something that exist or doesn't exist. An example: start-stop-daemon --start --exec bogus bogus already running 6 This problem doesn't seem to occur when you use the --pidfile option. -ifupdown When running ifup on an interface that doesn't exist but has been configured in /etc/network/interfaces, you get a segmentation fault. This wasn't the case with busybox 1.2.2.1. Regards, Eric > Hi people, > > > Tarball is already in http://busybox.net/downloads/, > busybox.net webpage will be updated soon. > > Bug fixes will go into 1.3.x, new development into > current svn and eventually 1.4.0. -- > vda _______________________________________________ > busybox mailing list busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > From trevor at vocaro.com Thu Dec 14 13:58:25 2006 From: trevor at vocaro.com (Trevor Harmon) Date: Thu, 14 Dec 2006 13:58:25 -0800 Subject: Getting started with mdev In-Reply-To: <20061214193437.GN17104@priv.blacknet.de> References: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> <20061214193437.GN17104@priv.blacknet.de> Message-ID: On Dec 14, 2006, at 11:34 AM, Goetz Bock wrote: > IIRC there were a few files you should add to your static /dev: > console, > null, Hmm... /dev/console is the only one I needed to boot and run BusyBox. > How would I find out what the rest are? Given that /dev is such an important and fundamental part of Linux, it seems like this would be written down somewhere. > than you need to add /sys to your filsystem, and mount the sysfs there > > mount -t sysfs none /sys > > once that is done you can run mdev in scan mode to populate /dev > > mdev -s > > that should be it. That worked; thanks! I noticed that mdev created a lot of "standard" entries in /dev, including null. I assume that means I don't have to worry about manually creating them? Also, what's the standard practice of having the above commands run on every boot? Do I simply dump them into /etc/rc.sh? Trevor From rob at landley.net Thu Dec 14 14:04:11 2006 From: rob at landley.net (Rob Landley) Date: Thu, 14 Dec 2006 17:04:11 -0500 Subject: Getting started with mdev In-Reply-To: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> References: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> Message-ID: <200612141704.12195.rob@landley.net> On Thursday 14 December 2006 12:09 am, Trevor Harmon wrote: > Hi, > > I need some help getting started with mdev. I tried to find some > documentation on it, but there doesn't seem to be much out there. My fault. What do you need? > I started with an empty /dev, but that causes a failure on boot: > "Warning: unable to open an initial console." You need /dev/console in your initramfs. This is a funky kernel thing. I don't know why they don't just create it, ask linux-kernel. The default initramfs has one. > I then manually created an entry for /dev/console, and that allows > the system to boot, but /dev still isn't being populated. All I see > is the /dev/console entry I created myself. And yet, the system seems > to be running fine otherwise. Your init script needs to do: mount -t sysfs /sys /sys mdev -s Also, I tend to do: mount -t tmpfs /dev /dev Before calling mdev. That's optional, but it gives you a writeable tmpfs instance, which you can "mount --move" from initramfs to your final root device, and doesn't have anything left over from last time if your / is writeable. > I also note that there is no /sys directory, even though I have > CONFIG_SYSFS enabled in my kernel. Is this why mdev is not > populating /dev? You have to mount it. Did you run mdev? "mdev -s" will scan /sys and create all the devices it finds under /dev. "echo /sbin/mdev > /proc/sys/kernel/hotplug" should register the sucker so it'll get called each time a device is inserted or removed, so it can update /dev. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Thu Dec 14 14:11:04 2006 From: rob at landley.net (Rob Landley) Date: Thu, 14 Dec 2006 17:11:04 -0500 Subject: RFC: busybox 1.2.3? In-Reply-To: <20061214082545.GA29586@aon.at> References: <200612130148.47851.vda.linux@googlemail.com> <20061214082545.GA29586@aon.at> Message-ID: <200612141711.04738.rob@landley.net> On Thursday 14 December 2006 3:25 am, Bernhard Fischer wrote: > There is one long-standing bug that would be really nice if it was > finally fixed for good: > > - Specifying a path to df doesn't work. There's also a bugreport about > this (or two): Last I checked, the df in toybox handled this just fine. :P > Some notes concerning the release branch: > 1) please don't forget to do a > svn cp ../trunk/busybox .../branches/busybox-1_3-stable > This should be done for any release. I never did this. Bernhard's been agitating for this forever. Keeping two forks in sync is an insane pain, I just backported svn commits from the development version. (If it wasn't fixed in -devel, it obviously wasn't that important.) Personally, I think if he wants his branch, he should maintain it, but it's up to you what you do. > 3) Please do not forget to remove the -Werror from Makefile.flags for > the stable series. It may be nice to have for development, but breaking > to build for users because of it sounds like it will trigger > complaints.. I don't care about complaints, but gcc 4.1.x is broken. It produces warnings about "possible use before initialization" of things that provably _aren't_. (However, -Werror was the only way to keep certain developers from introducing new warnings into the tree on a regular basis and never fixing them.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From trevor at vocaro.com Thu Dec 14 14:31:33 2006 From: trevor at vocaro.com (Trevor Harmon) Date: Thu, 14 Dec 2006 14:31:33 -0800 Subject: BusyBox 1.3.0 without CONFIG_FEATURE_TAR_GNU_EXTENSIONS In-Reply-To: <45812571.8050908@bluegiga.com> References: <45812571.8050908@bluegiga.com> Message-ID: <808F6C75-4903-4F8F-A0EC-065BCC7A17AA@vocaro.com> On Dec 14, 2006, at 2:20 AM, Kim B. Heino wrote: > If I don't enable CONFIG_FEATURE_TAR_GNU_EXTENSIONS option, BusyBox > fails to compile: I was experiencing the same problem after upgrading from 1.2.2 to 1.3.0. Didn't know what the fix was, though; thanks for the tip. Trevor From trevor at vocaro.com Thu Dec 14 14:39:26 2006 From: trevor at vocaro.com (Trevor Harmon) Date: Thu, 14 Dec 2006 14:39:26 -0800 Subject: Getting started with mdev In-Reply-To: <200612141704.12195.rob@landley.net> References: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> <200612141704.12195.rob@landley.net> Message-ID: <48FFCF18-D225-4D0D-A0FF-86BE12784127@vocaro.com> On Dec 14, 2006, at 2:04 PM, Rob Landley wrote: > My fault. What do you need? A simple docs/mdev.txt file summarizing the key points mentioned in this thread would have helped a lot. > You need /dev/console in your initramfs. This is a funky kernel > thing. I > don't know why they don't just create it, ask linux-kernel. The > default > initramfs has one. What is the "default" initramfs? Trevor From rob at landley.net Thu Dec 14 14:41:14 2006 From: rob at landley.net (Rob Landley) Date: Thu, 14 Dec 2006 17:41:14 -0500 Subject: Getting started with mdev In-Reply-To: References: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> <20061214193437.GN17104@priv.blacknet.de> Message-ID: <200612141741.15315.rob@landley.net> On Thursday 14 December 2006 4:58 pm, Trevor Harmon wrote: > > IIRC there were a few files you should add to your static /dev: > > console, > > null, > > Hmm... /dev/console is the only one I needed to boot and run BusyBox. /dev/console is the only one used by the kernel _before_ execing init. (In the 2.6.19 kernel, it's init/main.c line 768.) > > > > How would I find out what the rest are? Given that /dev is such an > important and fundamental part of Linux, it seems like this would be > written down somewhere. lanana.org lists all known devices. > > than you need to add /sys to your filsystem, and mount the sysfs there > > > > mount -t sysfs none /sys > > > > once that is done you can run mdev in scan mode to populate /dev > > > > mdev -s > > > > that should be it. > > That worked; thanks! I noticed that mdev created a lot of "standard" > entries in /dev, including null. I assume that means I don't have to > worry about manually creating them? Yup. There are entries for them under /sys, so mdev makes 'em. > Also, what's the standard practice of having the above commands run > on every boot? Do I simply dump them into /etc/rc.sh? Yup. Personally, I mount a tmpfs on /dev so you don't have to worry about debris between boots. (If mdev sees that a device already exists, it'll skip trying to create it, but mdev -s won't delete anything that's already there. Since tmpfs starts empty, they complement each other nicely.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From vda.linux at googlemail.com Thu Dec 14 15:08:39 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Fri, 15 Dec 2006 00:08:39 +0100 Subject: BusyBox 1.3.0 ar/dpkg is broken In-Reply-To: <45815CC7.1030106@bluegiga.com> References: <45815CC7.1030106@bluegiga.com> Message-ID: <200612150008.39605.vda.linux@googlemail.com> On Thursday 14 December 2006 15:16, Kim B. Heino wrote: > Hello, > > The new xstrtoul() and xatou() functions broke ar and dpkg commands in > BusyBox 1.3.0: > > dpkg: invalid number '100644 4 > > This is because get_header_ar() function is passing the binary header: > > typed->mode > typed->mtime > ... > typed->size > > One way to fix this is to add strtoul's endptr parameter to xstrtoul() > too. Another way is to use some other functions in get_header_ar() to > parse header. bb_strtoXX. > Any suggestions? Does this patch work better? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.3.0.dpkg_ar.patch Type: text/x-diff Size: 1129 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061215/4b5f9699/attachment.bin From rob at landley.net Thu Dec 14 15:09:41 2006 From: rob at landley.net (Rob Landley) Date: Thu, 14 Dec 2006 18:09:41 -0500 Subject: Getting started with mdev In-Reply-To: <48FFCF18-D225-4D0D-A0FF-86BE12784127@vocaro.com> References: <5BB8B364-4455-463B-800F-93DC0D97EBD0@vocaro.com> <200612141704.12195.rob@landley.net> <48FFCF18-D225-4D0D-A0FF-86BE12784127@vocaro.com> Message-ID: <200612141809.41698.rob@landley.net> On Thursday 14 December 2006 5:39 pm, Trevor Harmon wrote: > On Dec 14, 2006, at 2:04 PM, Rob Landley wrote: > > > My fault. What do you need? > > A simple docs/mdev.txt file summarizing the key points mentioned in > this thread would have helped a lot. > > > You need /dev/console in your initramfs. This is a funky kernel > > thing. I > > don't know why they don't just create it, ask linux-kernel. The > > default > > initramfs has one. > > What is the "default" initramfs? If you don't supply an initramfs, you get one with three entries: /dev, /dev/console, and /root. Why that? Because that was the example output from scripts/gen_initramfs_list.sh when you ran it with no arguments, which the kernel was doing for a dozen or so versions when you hadn't specified an initramfs location in the kernel's .config. By the time anybody noticed, the kernel had developed a dependency on the /dev/console entry in there. :) These days, gen_initramfs_list.sh produces this default .config file when you give it the -d option, and outputs nothing when you run it with no arguments. This is considered an improvement. As far as I know, nothing depends on the /root entry. It was just part of the example config file. (You need the /dev entry to have a directory to put /dev/console in.) Rob -- "Perfection is reached, not when there is no longer anything to