From max at kiyon.com Sat Jul 1 00:22:47 2006 From: max at kiyon.com (Max Okumoto) Date: Sat Jul 1 00:29:40 2006 Subject: Question about ifupdown.c and udhcpc In-Reply-To: Message-ID: <20060701072247.99137.qmail@web504.biz.mail.mud.yahoo.com> Some ethernet drivers detect at the phy level if there is cable attached. They will not allow you to ifconfig up the interface. So dhcpd will fail on the open of the interface. One way around this problem is to fork a program/script to monitor the interface and which it succeeds, to invoke dhcpd. Max Dave Hylands wrote: Hi, I've been looking into a problem where udhcpc sometimes hangs around and sometimes goes away. I think I've narrowed the behaviour down to this: 1 - If I bring the ethernet adapter up and no cable is plugged in, then udhcpc quits after a few seconds. 2 - If I bring the ethernet adapter up and the cable is plugged in, then udhcpc hangs around, even across multiple cable removal/insertions. I looked at the networking/ifupdown.c and saw this: if (execable("/sbin/udhcpc")) { return( execute("udhcpc -n -p /var/run/udhcpc.%iface%.pid -i " in the dhcp_up routine. The -n option tells udhcpc to quit if it can't get a lease, which would be the case if the cable isn't plugged in. So my question is: is this the expected behaviour? Do I have something else misconfigured? Should cable insertion/removals have any impact on udhcp? -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060701/2a8e7329/attachment.htm From rpjday at mindspring.com Sat Jul 1 04:20:58 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sat Jul 1 04:22:33 2006 Subject: yanking all that "#if 0" and "#if 1" stuff Message-ID: now that 1.2.0 is out, i'm prepared to submit/commit patches to rip out/clean up everything surrounded by those meaningless preprocessor directives. speak now or ... well, don't. rday From rep.nop at aon.at Sat Jul 1 09:02:41 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jul 1 09:02:55 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: <20060701150001.97A7F120127@busybox.net> References: <20060701150001.97A7F120127@busybox.net> Message-ID: <20060701160241.GG21958@aon.at> On Sat, Jul 01, 2006 at 08:00:01AM -0700, rpjday@busybox.net wrote: >Author: rpjday >Date: 2006-07-01 07:59:54 -0700 (Sat, 01 Jul 2006) >New Revision: 15572 >Modified: trunk/busybox/networking/ifupdown.c >=================================================================== >--- trunk/busybox/networking/ifupdown.c 2006-07-01 14:52:12 UTC (rev 15571) >+++ trunk/busybox/networking/ifupdown.c 2006-07-01 14:59:54 UTC (rev 15572) >@@ -43,11 +43,7 @@ > #define MAX_INTERFACE_LENGTH 10 > #endif > >-#if 0 >-#define debug_noise(fmt, args...) printf(fmt, ## args) >-#else > #define debug_noise(fmt, args...) >-#endif > > /* Forward declaration */ > struct interface_defn_t; Whoever that may be.. Doing stuff like this is nonsense, to say the least. You're breaking the conventient possibility to turn on debugging facilities with what reasoning again? Either do it right (export the debug_noise into config / remove all debugging support completely; Exporting it is pointless, imo and removing it is of questionable use anyway since it's easier to tell people to toggle that single #if 0 to see why they fail than to delve into a blind indirect debugging session in order to help them) or just leave it alone. From rep.nop at aon.at Sat Jul 1 09:06:41 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jul 1 09:06:50 2006 Subject: svn commit: trunk/busybox: e2fsprogs e2fsprogs/blkid e2fsprogs/ext2 etc... In-Reply-To: <20060701150920.C4731120127@busybox.net> References: <20060701150920.C4731120127@busybox.net> Message-ID: <20060701160641.GH21958@aon.at> On Sat, Jul 01, 2006 at 08:09:20AM -0700, rpjday@busybox.net wrote: >Author: rpjday >Date: 2006-07-01 08:09:17 -0700 (Sat, 01 Jul 2006) >New Revision: 15573 > >Log: >Yet more "#if 0" content removed. > > >Modified: [] > trunk/busybox/scripts/objsizes > > >Changeset: [] >Modified: trunk/busybox/scripts/objsizes >=================================================================== >--- trunk/busybox/scripts/objsizes 2006-07-01 14:59:54 UTC (rev 15572) >+++ trunk/busybox/scripts/objsizes 2006-07-01 15:09:17 UTC (rev 15573) >@@ -4,5 +4,4 @@ > find -name '*.o' | sed 's:^\./::' | xargs size | grep '^ *[0-9]' \ > | while read text data bss dec hex filename; do > printf "%9d %11d %9d %9d %s\n" $((text+data)) $text $data $bss "$filename" >-done \ >-| sort >+done Was that changed on purpose or are you also leaking stuff unintentionally? From rpjday at mindspring.com Sat Jul 1 09:41:26 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sat Jul 1 09:51:06 2006 Subject: my outgoing mail server has died Message-ID: <8038906.1151772086174.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> i'm trying to reply to bernhard's recent e-mails and, while i can *fetch* my mail just fine, i can't send normally so i'm reduced to doing it through a browser until the server comes back. argh. so i've seen bernhard's posts but i'll wait until mail is once again functioning before i respond, to not break the threading. rday From rob at landley.net Sat Jul 1 10:19:44 2006 From: rob at landley.net (Rob Landley) Date: Sat Jul 1 10:19:51 2006 Subject: [PATCH] shell/lash.c: set environment variable In-Reply-To: <7f45d9390606301501mfb302f6q128117a39649e44@mail.gmail.com> References: <7f45d9390604211052v64dbb27aydd912021bc6ebb9c@mail.gmail.com> <200606131502.28115.rob@landley.net> <7f45d9390606301501mfb302f6q128117a39649e44@mail.gmail.com> Message-ID: <200607011319.44516.rob@landley.net> On Friday 30 June 2006 6:01 pm, Shaun Jackman wrote: > On 6/13/06, Rob Landley wrote: > > Ok, svn 15378. I shrank enough from lash with the previous checkin that > > I didn't feel guilty about adding one more feature. :) > > Oops, Rob. You mistakenly checked in my buggy patch from 2006-04-21. > The bug-fixed version was posted on 2006-05-25. Here is an aggregate > patch reverting the former and applying the latter. Applied. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Sat Jul 1 10:45:32 2006 From: rob at landley.net (Rob Landley) Date: Sat Jul 1 10:45:38 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <7f45d9390606301519n54768df5nbeae4b5856f713e5@mail.gmail.com> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606091126.43394.rob@landley.net> <7f45d9390606301519n54768df5nbeae4b5856f713e5@mail.gmail.com> Message-ID: <200607011345.32354.rob@landley.net> On Friday 30 June 2006 6:19 pm, Shaun Jackman wrote: > On 6/9/06, Rob Landley wrote: > > On Thursday 08 June 2006 6:22 pm, Shaun Jackman wrote: > > > On 6/8/06, Shaun Jackman wrote: > > > > I agree. I'd also like to see CROSS_COMPILER_PREFIX renamed to > > > > CROSS_COMPILE, as Linux names it. It makes sense to do it at the same > > > > time it's remove from .config. > > > > > > I just noticed that although the config option was named > > > CROSS_COMPILER_PREFIX, the make variable was named CROSS. So, do the > > > maintainers prefer to keep the make variable named CROSS, or switch to > > > the Linux name, CROSS_COMPILE? I can see benefits to both, but we > > > should pick one definitively. > > > > Go with CROSS_COMPILE. You only have to build three things for a minimal > > embedded system: the Linux Kernel, uClibc, and BusyBox. It would be nice > > if they all worked roughly the same way... > > As discussed above. Please apply. > > Cheers, > Shaun > > 2006-06-30 Shaun Jackman > > * (CROSS) Rename to CROSS_COMPILE and move its configuration to > .config.mak. This patch doesn't seem current. Rob -- Never bet against the cheap plastic solution. From rpjday at mindspring.com Sat Jul 1 11:19:22 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sat Jul 1 11:32:55 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: <20060701160241.GG21958@aon.at> References: <20060701150001.97A7F120127@busybox.net> <20060701160241.GG21958@aon.at> Message-ID: On Sat, 1 Jul 2006, Bernhard Fischer wrote: > On Sat, Jul 01, 2006 at 08:00:01AM -0700, rpjday@busybox.net wrote: > >Author: rpjday > >Date: 2006-07-01 07:59:54 -0700 (Sat, 01 Jul 2006) > >New Revision: 15572 > > >Modified: trunk/busybox/networking/ifupdown.c > >=================================================================== > >--- trunk/busybox/networking/ifupdown.c 2006-07-01 14:52:12 UTC (rev 15571) > >+++ trunk/busybox/networking/ifupdown.c 2006-07-01 14:59:54 UTC (rev 15572) > >@@ -43,11 +43,7 @@ > > #define MAX_INTERFACE_LENGTH 10 > > #endif > > > >-#if 0 > >-#define debug_noise(fmt, args...) printf(fmt, ## args) > >-#else > > #define debug_noise(fmt, args...) > >-#endif > > > > /* Forward declaration */ > > struct interface_defn_t; > > Whoever that may be.. > Doing stuff like this is nonsense, to say the least. um ... no, it isn't, since the notion of removing "dead" or "unused" code in the source tree has been discussed more than once before, and no one seemed all that upset by the suggestion at the time. > You're breaking the conventient possibility to turn on debugging > facilities with what reasoning again? because that's an immensely silly way to include conditional debugging code. if an individual maintainer wants to include that sort of thing, then they should at least do it using a meaningful directive, such as #ifdef DEBUG even better, each maintainer could use package-specific directives, like #ifdef HTTPD_DEBUG or something like that. there's absolutely nothing wrong with maintainers wanting the ability to turn on debugging in their own packages, but using "#if 0" to deal with it is just plain silly since it requires manual editing, rather than being able to simply define the appropriate macro at build time. more to the point, using "#if 0" *anywhere* in the source tree is utterly uninformative. when you see it, it may not be clear whether that's truly dead, obsolete code or questionable code or debugging code or code that's there for future consideration or code that people forgot about five years ago or what. now, in some cases, it's clear based on a comment, as in httpd.c: typedef enum { HTTP_OK = 200, HTTP_MOVED_TEMPORARILY = 302, HTTP_BAD_REQUEST = 400, /* malformed syntax */ HTTP_UNAUTHORIZED = 401, /* authentication needed, respond with auth hdr */ HTTP_NOT_FOUND = 404, HTTP_FORBIDDEN = 403, HTTP_REQUEST_TIMEOUT = 408, HTTP_NOT_IMPLEMENTED = 501, /* used for unrecognized requests */ HTTP_INTERNAL_SERVER_ERROR = 500, #if 0 /* future use */ HTTP_CONTINUE = 100, HTTP_SWITCHING_PROTOCOLS = 101, HTTP_CREATED = 201, ... but it would *still* make more sense to use one of: #ifdef TODO #ifdef FUTURE_WORK #ifdef NOT_DONE_HERE_YET or something like that. personally, i'd simply ban the use of "#if 0" outright and force people to choose their directives so that they're more meaningful. there's simply no defense for either of "#if 0" or "#if 1" and, one way or another, they should all be either removed or rewritten to be more informative. rday From vda.linux at googlemail.com Sat Jul 1 11:41:21 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat Jul 1 11:41:30 2006 Subject: [RFC] nmeter applet In-Reply-To: <200606301608.11234.rob@landley.net> References: <200606301716.44450.vda.linux@gmail.com> <200606301608.11234.rob@landley.net> Message-ID: <200607012041.21175.vda.linux@gmail.com> On Friday 30 June 2006 22:08, Rob Landley wrote: > On Friday 30 June 2006 11:16 am, Denis Vlasenko wrote: > > Hello Rob, folks, > > > # nmeter "%t cpu %c bio %b net %[if]n" > > 17:03:28 cpu [..........] bio 0 0 net 2452 4582 > > 17:03:29 cpu [U.........] bio 0 16k net 17k 18k > > 17:03:30 cpu [D.........] bio 204k 0 net 11k 11k > > 17:03:31 cpu [..........] bio 0 0 net 108k 7078 > > Any way to get it to do \r instead of \n so it could just repaint the same > line over and over? (Might be a fun thing to have on one's desktop then...) Already there (insert %r somewhere in the string). > > The version which can be compiled and tried by anyone (standalone, > > not integrated into bbox) is below. IIRC it compiles into ~10K > > static binary with dietlibc. > > I threw it into my "pending" folder. Remind me about it next week. Right now > I'm putting together 1.2.0 for release this evening. Ok, then. I will send you a properly patch in ~1 week. -- vda From rep.nop at aon.at Sat Jul 1 11:56:33 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jul 1 11:56:37 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: References: <20060701150001.97A7F120127@busybox.net> <20060701160241.GG21958@aon.at> Message-ID: <20060701185632.GI21958@aon.at> On Sat, Jul 01, 2006 at 02:19:22PM -0400, Robert P. J. Day wrote: >On Sat, 1 Jul 2006, Bernhard Fischer wrote: > >> On Sat, Jul 01, 2006 at 08:00:01AM -0700, rpjday@busybox.net wrote: >> >Author: rpjday >> >Date: 2006-07-01 07:59:54 -0700 (Sat, 01 Jul 2006) >> >New Revision: 15572 >> >> >Modified: trunk/busybox/networking/ifupdown.c >> >=================================================================== >> >--- trunk/busybox/networking/ifupdown.c 2006-07-01 14:52:12 UTC (rev 15571) >> >+++ trunk/busybox/networking/ifupdown.c 2006-07-01 14:59:54 UTC (rev 15572) >> >@@ -43,11 +43,7 @@ >> > #define MAX_INTERFACE_LENGTH 10 >> > #endif >> > >> >-#if 0 >> >-#define debug_noise(fmt, args...) printf(fmt, ## args) >> >-#else >> > #define debug_noise(fmt, args...) >> >-#endif >> > >> > /* Forward declaration */ >> > struct interface_defn_t; >> >> Whoever that may be.. >> Doing stuff like this is nonsense, to say the least. > >um ... no, it isn't, since the notion of removing "dead" or "unused" >code in the source tree has been discussed more than once before, and >no one seemed all that upset by the suggestion at the time. > >> You're breaking the conventient possibility to turn on debugging >> facilities with what reasoning again? > >because that's an immensely silly way to include conditional debugging >code. if an individual maintainer wants to include that sort of >thing, then they should at least do it using a meaningful directive, >such as > >#ifdef DEBUG > >even better, each maintainer could use package-specific directives, >like > >#ifdef HTTPD_DEBUG > >or something like that. there's absolutely nothing wrong with >maintainers wanting the ability to turn on debugging in their own >packages, but using "#if 0" to deal with it is just plain silly since >it requires manual editing, rather than being able to simply define >the appropriate macro at build time. > >more to the point, using "#if 0" *anywhere* in the source tree is >utterly uninformative. when you see it, it may not be clear whether >that's truly dead, obsolete code or questionable code or debugging >code or code that's there for future consideration or code that people >forgot about five years ago or what. > >now, in some cases, it's clear based on a comment, as in httpd.c: > >typedef enum >{ > HTTP_OK = 200, > HTTP_MOVED_TEMPORARILY = 302, > HTTP_BAD_REQUEST = 400, /* malformed syntax */ > HTTP_UNAUTHORIZED = 401, /* authentication needed, respond with auth hdr */ > HTTP_NOT_FOUND = 404, > HTTP_FORBIDDEN = 403, > HTTP_REQUEST_TIMEOUT = 408, > HTTP_NOT_IMPLEMENTED = 501, /* used for unrecognized requests */ > HTTP_INTERNAL_SERVER_ERROR = 500, >#if 0 /* future use */ > HTTP_CONTINUE = 100, > HTTP_SWITCHING_PROTOCOLS = 101, > HTTP_CREATED = 201, > ... > >but it would *still* make more sense to use one of: > >#ifdef TODO >#ifdef FUTURE_WORK >#ifdef NOT_DONE_HERE_YET > >or something like that. personally, i'd simply ban the use of "#if 0" >outright and force people to choose their directives so that they're >more meaningful. there's simply no defense for either of "#if 0" or >"#if 1" and, one way or another, they should all be either removed or >rewritten to be more informative. Did you read my remark (the one you didn't quote here and which boiled down to parts of what you wrote above)? Either remove it completely or export it to the config system, nothing in between. In the case of e.g. ifupdown.c you did remove it partially, which buys absolutely nothing except removing an occurance of '#if 0'. PS: also, please don't forget to update the boilerplates while you are touching files, TIA. From erik at hovland.org Sat Jul 1 12:05:44 2006 From: erik at hovland.org (Erik Hovland) Date: Sat Jul 1 12:05:50 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606251839.45256.rob@landley.net> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606242037.42631.rob@landley.net> <200606251142.37121.rob@landley.net> <200606251839.45256.rob@landley.net> Message-ID: <20060701190544.GE10152@hovland.org> First off, thanks for paying such close attention to the patchset. All of it was useful information. On Sun, Jun 25, 2006 at 06:39:44PM -0400, Rob Landley wrote: > getty.c: Wow this code is a mess, but you ask a good question: what does it > mean if TIOCSPGRP fails? Can that happen? Let's see, in 2.6.17, > drivers/char/tty_io.c, the function tiocspgrp() can > return -ENOTTY, -EFAULT, -EINVAL, or -EPERM. So basically if you feed it a > bad pointer, aren't root, try to call it on something that isn't a tty, or > haven't got a process group to associate it with. Of these "aren't root" > and "isn't a tty" are probably worth reporting, yeah. > > On the other hand, report them _where_ (To the tty? The console? The system > log?), and is exiting the correct response (which error() will do, notice > it's declared ATTRIBUTE_NORETURN). > > As for the strncpy->memcpy change, where did you get the idea ut_id wasn't a > string? Try "man 3 setutent" and look at the example code, and tracing back > where we get "line" in our code, it's options.tty which comes from > parse_args() which is getting it from the command line. I got the idea from an erroneous utmp.h. Sorry for the mistake. E -- Erik Hovland mail: erik@hovland.org web: http://hovland.org/ PGP/GPG public key available on request From pgf at brightstareng.com Sat Jul 1 12:51:43 2006 From: pgf at brightstareng.com (Paul Fox) Date: Sat Jul 1 12:51:51 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: rpjday's message of Sat, 01 Jul 2006 14:19:22 -0400. Message-ID: <24983.1151783503@brightstareng.com> > > > > > >-#if 0 > > >-#define debug_noise(fmt, args...) printf(fmt, ## args) > > >-#else > > > #define debug_noise(fmt, args...) > > >-#endif > > > > > > /* Forward declaration */ > > > struct interface_defn_t; > > > > Whoever that may be.. > > Doing stuff like this is nonsense, to say the least. > > um ... no, it isn't, since the notion of removing "dead" or "unused" > code in the source tree has been discussed more than once before, and > no one seemed all that upset by the suggestion at the time. that code is clearly not "dead". it's someone being lazy. (i.e. all they have to do to run on debugging is change a single character in the source file.) if you don't want it to be "#if 0", change it to "#if DEBUG", but don't remove the entire thing. if you do that, you might as well go through the file and remove all the invocations of that macro, too. > code. if an individual maintainer wants to include that sort of > thing, then they should at least do it using a meaningful directive, > such as > > #ifdef DEBUG exactly. fix it for them, don't rip it out. it will make it harder for the next person to debug, and, in general, i'd say we want busybox to be easier to debug. (and frankly, i don't care about a centralized scheme -- no one ever debugs more than one applet at a time, and local schemes are usually sufficient.) paul =--------------------- paul fox, pgf@brightstareng.com From rpjday at mindspring.com Sat Jul 1 13:22:27 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sat Jul 1 13:23:56 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: <24983.1151783503@brightstareng.com> References: <24983.1151783503@brightstareng.com> Message-ID: On Sat, 1 Jul 2006, Paul Fox wrote: > > > > > > > >-#if 0 > > > >-#define debug_noise(fmt, args...) printf(fmt, ## args) > > > >-#else > > > > #define debug_noise(fmt, args...) > > > >-#endif > > > > > > > > /* Forward declaration */ > > > > struct interface_defn_t; > > > > > > Whoever that may be.. > > > Doing stuff like this is nonsense, to say the least. > > > > um ... no, it isn't, since the notion of removing "dead" or "unused" > > code in the source tree has been discussed more than once before, and > > no one seemed all that upset by the suggestion at the time. > > that code is clearly not "dead". it's someone being lazy. (i.e. > all they have to do to run on debugging is change a single character > in the source file.) if you don't want it to be "#if 0", change it > to "#if DEBUG", but don't remove the entire thing. if you do that, > you might as well go through the file and remove all the invocations > of that macro, too. admittedly, when i go back and look at the changes i committed, that is the one example where, if i had looked at it for a couple more seconds, i would have made a different decision. yours and bernhard's points are well taken. on that note, would someone like to suggest a standard for what maintainers should use if they want to do that sort of thing in their own code? i'm leery of something as generic as "#ifdef DEBUG" since that just *begs* to have code start clashing. rday From pgf at brightstareng.com Sat Jul 1 13:36:14 2006 From: pgf at brightstareng.com (Paul Fox) Date: Sat Jul 1 13:36:22 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: rpjday's message of Sat, 01 Jul 2006 16:22:27 -0400. Message-ID: <25945.1151786174@brightstareng.com> > > on that note, would someone like to suggest a standard for what > maintainers should use if they want to do that sort of thing in their > own code? i'm leery of something as generic as "#ifdef DEBUG" since > that just *begs* to have code start clashing. as a first cut at something that doesn't need to be all that "standard", i'd suggest _DEBUG, like "HTTPD_DEBUG". paul =--------------------- paul fox, pgf@brightstareng.com From rpjday at mindspring.com Sat Jul 1 13:36:48 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sat Jul 1 13:38:16 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: <25945.1151786174@brightstareng.com> References: <25945.1151786174@brightstareng.com> Message-ID: On Sat, 1 Jul 2006, Paul Fox wrote: > > on that note, would someone like to suggest a standard for what > > maintainers should use if they want to do that sort of thing in > > their own code? i'm leery of something as generic as "#ifdef > > DEBUG" since that just *begs* to have code start clashing. > > as a first cut at something that doesn't need to be all that > "standard", i'd suggest _DEBUG, like "HTTPD_DEBUG". that was my original suggestion. :-) i'm good with that. rday From ghostviewer at web.de Sun Jul 2 02:46:57 2006 From: ghostviewer at web.de (Rainer Herrendoerfer) Date: Sun Jul 2 03:07:49 2006 Subject: Buildroot: make exits with errors Message-ID: <44A79611.20007@web.de> Hi, I tried compiling buildroot following the instructions on http://buildroot.uclibc.org/buildroot.html but make didn't run through. I did: ~/buildroot$ make menuconfig ~/buildroot$ make -d 2>&1 |tee logfile Here is some tail from the logfile (omitted lots of checking lines): ... checking ... checking for unistd.h... (cached) yes updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: executing default-1 commands Adding multilib support to Makefile in /home/raina/Desktop/buildroot/toolchain_build_i586/gcc-4.0.3/zlib multidirs=64 with_multisubdir= Running configure in multilib subdirs 64 pwd: /home/raina/Desktop/buildroot/toolchain_build_i586/gcc-4.0.3-final/zlib Running configure in multilib subdir 64 pwd: /home/raina/Desktop/buildroot/toolchain_build_i586/gcc-4.0.3-final mkdir 64 configure: creating cache ./config.cache checking build system type... i386-pc-linux-gnu checking ... ... checking ... checking whether to build static libraries... yes creating libtool updating cache ./config.cache configure: loading cache ./config.cache checking how to run the C preprocessor... gcc -m64 -E checking for memcpy... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. Reaping losing child 0x080c3838 PID 11125 make[1]: *** [configure-zlib] Error 1 Removing child 0x080c3838 PID 11125 from chain. make[1]: Leaving directory `/home/raina/Desktop/buildroot/toolchain_build_i586/gcc-4.0.3-final' Reaping losing child 0x08651818 PID 9366 make: *** [/home/raina/Desktop/buildroot/toolchain_build_i586/gcc-4.0.3-final/.compiled] Error 2 Removing child 0x08651818 PID 9366 from chain. Some Informtion on the building system: $ cc --version gcc.real (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) $ uname -a Linux ubuntu 2.6.15-25-386 #1 PREEMPT Wed Jun 14 11:25:49 UTC 2006 i686 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 3200+ stepping : 0 cpu MHz : 2200.206 cache size : 512 KB Any hints are welcome Rainer From rep.nop at aon.at Sun Jul 2 06:36:54 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jul 2 06:37:05 2006 Subject: exporting argc/argv to applets Message-ID: <20060702133654.GJ21958@aon.at> Hi, FYI, I've been pondering ?) landley's suggestion to export argc and argv globally, so we wouldn't have to pass it around as arguments. >From a cursory look, this doesn't seem to be a good idea, though: text data bss dec hex filename 862418 10156 644740 1517314 172702 busybox.old 865586 10156 644708 1520450 173342 busybox Could very well be that i did something wrong/incomplete, admittedly. ?) http://busybox.net/~aldot/bb/bb.argc.00g.diff Is completely untested and most likely breaks at least the shells in subtle ways. From floydpink at gmail.com Sun Jul 2 08:05:34 2006 From: floydpink at gmail.com (Jason Schoon) Date: Sun Jul 2 08:05:41 2006 Subject: Buildroot: make exits with errors In-Reply-To: <44A79611.20007@web.de> References: <44A79611.20007@web.de> Message-ID: <78a54e1b0607020805s3f87b36r179dd7e85230f1d@mail.gmail.com> On 7/2/06, Rainer Herrendoerfer wrote: > > Hi, > I tried compiling buildroot following the instructions on > http://buildroot.uclibc.org/buildroot.html > but make didn't run through. I did: Any hints are welcome > Rainer My hint would be to try the buildroot list, not the busybox list. Currently, unfortunately, the uclibc list is as close as you will get ( uclibc.org). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060702/251169d3/attachment.html From rpjday at mindspring.com Sun Jul 2 08:36:12 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 08:37:39 2006 Subject: any reason to *not* support hex escapes? Message-ID: libbb/process_escape_sequence.c: -------------------------------- #define WANT_HEX_ESCAPES 1 ... #ifdef WANT_HEX_ESCAPES ... etc etc. any reason to not support this feature unconditionally? rday From rpjday at mindspring.com Sun Jul 2 08:41:51 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 08:43:14 2006 Subject: any value in configuring minimum password length? Message-ID: libbb/obscure.c --------------- #define MINLEN 6 any value in taking the extra step and allowing this to be changed during configuration? rday From rep.nop at aon.at Sun Jul 2 08:49:05 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jul 2 08:49:09 2006 Subject: any value in configuring minimum password length? In-Reply-To: References: Message-ID: <20060702154905.GK21958@aon.at> On Sun, Jul 02, 2006 at 11:41:51AM -0400, Robert P. J. Day wrote: > >libbb/obscure.c >--------------- > >#define MINLEN 6 > > any value in taking the extra step and allowing this to be changed >during configuration? put it in libbb/Config.in if you feel like config CONFIG_PASSWORD_MINLEN int "description" default 6 range 5 255 /* or the like */ help help text here From rep.nop at aon.at Sun Jul 2 08:57:23 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jul 2 08:57:29 2006 Subject: any reason to *not* support hex escapes? In-Reply-To: References: Message-ID: <20060702155723.GM21958@aon.at> On Sun, Jul 02, 2006 at 11:36:12AM -0400, Robert P. J. Day wrote: > >libbb/process_escape_sequence.c: >-------------------------------- > >#define WANT_HEX_ESCAPES 1 >... >#ifdef WANT_HEX_ESCAPES ... > >etc etc. > > any reason to not support this feature unconditionally? libbb/Config.in ? Not sure if these are worth exposing in the menu-thing. Leaving them in the file so one can hand-tweak if needed is about as good for me but admittedly limits the number of people who may turn it off if they know that they will not need it. From rpjday at mindspring.com Sun Jul 2 09:06:06 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 09:07:29 2006 Subject: any value in configuring minimum password length? In-Reply-To: <20060702154905.GK21958@aon.at> References: <20060702154905.GK21958@aon.at> Message-ID: On Sun, 2 Jul 2006, Bernhard Fischer wrote: > On Sun, Jul 02, 2006 at 11:41:51AM -0400, Robert P. J. Day wrote: > > > >libbb/obscure.c > >--------------- > > > >#define MINLEN 6 > > > > any value in taking the extra step and allowing this to be changed > >during configuration? > > put it in libbb/Config.in if you feel like > > config CONFIG_PASSWORD_MINLEN > int "description" > default 6 > range 5 255 /* or the like */ > help > help text here i'm assuming something like the following would be sufficient, yes? Index: libbb/obscure.c =================================================================== --- libbb/obscure.c (revision 15578) +++ libbb/obscure.c (working copy) @@ -46,11 +46,6 @@ #include "libbb.h" - -/* passwords should consist of 6 (to 8 characters) */ -#define MINLEN 6 - - static int string_checker_helper(const char *p1, const char *p2) __attribute__ ((__pure__)); static int string_checker_helper(const char *p1, const char *p2) @@ -101,12 +96,12 @@ int length; int mixed = 0; /* Add 1 for each type of characters to the minlen of password */ - int size = MINLEN + 8; + int size = CONFIG_PASSWORD_MINLEN + 8; const char *p; char hostname[255]; /* size */ - if (!new_p || (length = strlen(new_p)) < MINLEN) + if (!new_p || (length = strlen(new_p)) < CONFIG_PASSWORD_MINLEN) return("too short"); /* no username as-is, as sub-string, reversed, capitalized, doubled */ Index: libbb/Config.in =================================================================== --- libbb/Config.in (revision 15578) +++ libbb/Config.in (working copy) @@ -5,6 +5,13 @@ menu "Busybox Library Tuning" +config CONFIG_PASSWORD_MINLEN + int "Minimum password length" + default 6 + range 5 32 + help + Minimum allowable password length. + config CONFIG_MD5_SIZE_VS_SPEED int " MD5: Trade Bytes for Speed" default 2 rday From rpjday at mindspring.com Sun Jul 2 09:34:00 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 09:35:24 2006 Subject: any reason to *not* support hex escapes? In-Reply-To: <20060702155723.GM21958@aon.at> References: <20060702155723.GM21958@aon.at> Message-ID: On Sun, 2 Jul 2006, Bernhard Fischer wrote: > On Sun, Jul 02, 2006 at 11:36:12AM -0400, Robert P. J. Day wrote: > > > >libbb/process_escape_sequence.c: > >-------------------------------- > > > >#define WANT_HEX_ESCAPES 1 > >... > >#ifdef WANT_HEX_ESCAPES ... > > > >etc etc. > > > > any reason to not support this feature unconditionally? > > libbb/Config.in ? > > Not sure if these are worth exposing in the menu-thing. Leaving them > in the file so one can hand-tweak if needed is about as good for me > but admittedly limits the number of people who may turn it off if > they know that they will not need it. but is there any obvious reason why someone would explicitly *not* want that feature in the first place? also, given how that routine works, shouldn't the routine return an unsigned char rather than just a plain char? after all, it's quite possible to be handed an escape sequence of \377, no? rday From rep.nop at aon.at Sun Jul 2 11:17:21 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jul 2 11:17:27 2006 Subject: any value in configuring minimum password length? In-Reply-To: References: <20060702154905.GK21958@aon.at> Message-ID: <20060702181720.GN21958@aon.at> On Sun, Jul 02, 2006 at 12:06:06PM -0400, Robert P. J. Day wrote: >On Sun, 2 Jul 2006, Bernhard Fischer wrote: > >> On Sun, Jul 02, 2006 at 11:41:51AM -0400, Robert P. J. Day wrote: >> > >> >libbb/obscure.c >> >--------------- >> > >> >#define MINLEN 6 >> > >> > any value in taking the extra step and allowing this to be changed >> >during configuration? >> >> put it in libbb/Config.in if you feel like >> >> config CONFIG_PASSWORD_MINLEN >> int "description" >> default 6 >> range 5 255 /* or the like */ >> help >> help text here > >i'm assuming something like the following would be sufficient, yes? Yes (didn't look closely if 32 is proper, though). From rep.nop at aon.at Sun Jul 2 11:23:27 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jul 2 11:23:31 2006 Subject: any reason to *not* support hex escapes? In-Reply-To: References: <20060702155723.GM21958@aon.at> Message-ID: <20060702182327.GP21958@aon.at> On Sun, Jul 02, 2006 at 12:34:00PM -0400, Robert P. J. Day wrote: >On Sun, 2 Jul 2006, Bernhard Fischer wrote: > >> On Sun, Jul 02, 2006 at 11:36:12AM -0400, Robert P. J. Day wrote: >> > >> >libbb/process_escape_sequence.c: >> >-------------------------------- >> > >> >#define WANT_HEX_ESCAPES 1 >> >... >> >#ifdef WANT_HEX_ESCAPES ... >> > >> >etc etc. >> > >> > any reason to not support this feature unconditionally? >> >> libbb/Config.in ? >> >> Not sure if these are worth exposing in the menu-thing. Leaving them >> in the file so one can hand-tweak if needed is about as good for me >> but admittedly limits the number of people who may turn it off if >> they know that they will not need it. > >but is there any obvious reason why someone would explicitly *not* >want that feature in the first place? size / creeping featureitis. > >also, given how that routine works, shouldn't the routine return an >unsigned char rather than just a plain char? after all, it's quite >possible to be handed an escape sequence of \377, no? Could very well be, i admit that i didn't look. Please fix this aspect if it is not ok as it is. From rpjday at mindspring.com Sun Jul 2 11:29:17 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 11:30:58 2006 Subject: any value in configuring minimum password length? In-Reply-To: <20060702181720.GN21958@aon.at> References: <20060702154905.GK21958@aon.at> <20060702181720.GN21958@aon.at> Message-ID: On Sun, 2 Jul 2006, Bernhard Fischer wrote: > On Sun, Jul 02, 2006 at 12:06:06PM -0400, Robert P. J. Day wrote: > >On Sun, 2 Jul 2006, Bernhard Fischer wrote: > > > >> On Sun, Jul 02, 2006 at 11:41:51AM -0400, Robert P. J. Day wrote: > >> > > >> >libbb/obscure.c > >> >--------------- > >> > > >> >#define MINLEN 6 > >> > > >> > any value in taking the extra step and allowing this to be changed > >> >during configuration? > >> > >> put it in libbb/Config.in if you feel like > >> > >> config CONFIG_PASSWORD_MINLEN > >> int "description" > >> default 6 > >> range 5 255 /* or the like */ > >> help > >> help text here > > > >i'm assuming something like the following would be sufficient, yes? > > Yes (didn't look closely if 32 is proper, though). it's just a number i pulled out of thin air. if someone has an idea of a proper range for password length, let me know. otherwise, i'll just commit the change with a possible range of 5-32 and it can always be tweaked later. rday From farmatito at tiscali.it Sun Jul 2 12:47:18 2006 From: farmatito at tiscali.it (Tito) Date: Sun Jul 2 12:47:49 2006 Subject: any value in configuring minimum password length? In-Reply-To: References: <20060702181720.GN21958@aon.at> Message-ID: <200607022147.19261.farmatito@tiscali.it> On Sunday 2 July 2006 20:29, Robert P. J. Day wrote: > On Sun, 2 Jul 2006, Bernhard Fischer wrote: > > > On Sun, Jul 02, 2006 at 12:06:06PM -0400, Robert P. J. Day wrote: > > >On Sun, 2 Jul 2006, Bernhard Fischer wrote: > > > > > >> On Sun, Jul 02, 2006 at 11:41:51AM -0400, Robert P. J. Day wrote: > > >> > > > >> >libbb/obscure.c > > >> >--------------- > > >> > > > >> >#define MINLEN 6 > > >> > > > >> > any value in taking the extra step and allowing this to be changed > > >> >during configuration? > > >> > > >> put it in libbb/Config.in if you feel like > > >> > > >> config CONFIG_PASSWORD_MINLEN > > >> int "description" > > >> default 6 > > >> range 5 255 /* or the like */ > > >> help > > >> help text here > > > > > >i'm assuming something like the following would be sufficient, yes? > > > > Yes (didn't look closely if 32 is proper, though). > > it's just a number i pulled out of thin air. if someone has an idea > of a proper range for password length, let me know. otherwise, i'll > just commit the change with a possible range of 5-32 and it can always > be tweaked later. > > rday Hi, While at it fix also this comment: - /* Add 1 for each type of characters to the minlen of password */ + /* Add 2 for each type of characters to the minlen of password */ int size = MINLEN + 8; Ciao, Tito From rpjday at mindspring.com Sun Jul 2 12:47:11 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 12:48:51 2006 Subject: all source and header files now have standard vi directives Message-ID: i just committed a sizable change that standardizes all source and header files to have the single vi editing directive line at the beginning of the file, and everything still seems to compile. if this commit caused any problems, feel free to fix it or let me know. rday From rpjday at mindspring.com Sat Jul 1 05:51:23 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 12:50:01 2006 Subject: [PATCH] get rid of all "register" storage class specifiers Message-ID: i've suggested this before, and no one seemed to have any major objections. note the number of register specifiers in msh.c. yeesh. in any event, i can commit this later if no one has a problem with it. rday -------------- next part -------------- diff -pru busybox/archival/gzip.c busybox.new/archival/gzip.c --- busybox/archival/gzip.c 2006-06-26 06:57:37.000000000 -0400 +++ busybox.new/archival/gzip.c 2006-07-01 08:39:50.000000000 -0400 @@ -484,7 +484,7 @@ static void send_bits(int value, int len */ static unsigned bi_reverse(unsigned code, int len) { - register unsigned res = 0; + unsigned res = 0; do { res |= code & 1; @@ -782,7 +782,7 @@ static void check_match(IPos start, IPos */ static void lm_init(ush * flags) { - register unsigned j; + unsigned j; /* Initialize the hash table. */ memset(head, 0, HASH_SIZE * sizeof(*head)); @@ -832,9 +832,9 @@ static void lm_init(ush * flags) static int longest_match(IPos cur_match) { unsigned chain_length = max_chain_length; /* max hash chain length */ - register uch *scan = window + strstart; /* current string */ - register uch *match; /* matched string */ - register int len; /* length of current match */ + uch *scan = window + strstart; /* current string */ + uch *match; /* matched string */ + int len; /* length of current match */ int best_len = prev_length; /* best match length so far */ IPos limit = strstart > (IPos) MAX_DIST ? strstart - (IPos) MAX_DIST : NIL; @@ -848,9 +848,9 @@ static int longest_match(IPos cur_match) #if HASH_BITS < 8 || MAX_MATCH != 258 # error Code too clever #endif - register uch *strend = window + strstart + MAX_MATCH; - register uch scan_end1 = scan[best_len - 1]; - register uch scan_end = scan[best_len]; + uch *strend = window + strstart + MAX_MATCH; + uch scan_end1 = scan[best_len - 1]; + uch scan_end = scan[best_len]; /* Do not waste too much time if we already have a good match: */ if (prev_length >= good_match) { @@ -937,7 +937,7 @@ static void check_match(IPos start, IPos */ static void fill_window(void) { - register unsigned n, m; + unsigned n, m; unsigned more = (unsigned) (window_size - (ulg) lookahead - (ulg) strstart); /* Amount of free space at the end of the window. */ @@ -1005,7 +1005,7 @@ static ulg deflate(void) IPos prev_match; /* previous match */ int flush; /* set if current block must be flushed */ int match_available = 0; /* set if previous match exists */ - register unsigned match_length = MIN_MATCH - 1; /* length of best match */ + unsigned match_length = MIN_MATCH - 1; /* length of best match */ /* Process the input block. */ while (lookahead != 0) { diff -pru busybox/archival/libunarchive/decompress_unzip.c busybox.new/archival/libunarchive/decompress_unzip.c --- busybox/archival/libunarchive/decompress_unzip.c 2006-06-26 06:57:37.000000000 -0400 +++ busybox.new/archival/libunarchive/decompress_unzip.c 2006-07-01 08:39:24.000000000 -0400 @@ -514,7 +514,7 @@ static int inflate_stored(int my_n, int static int inflate_block(int *e) { unsigned t; /* block type */ - register unsigned int b; /* bit buffer */ + unsigned int b; /* bit buffer */ unsigned int k; /* number of bits in bit buffer */ /* make local bit buffer */ diff -pru busybox/coreutils/echo.c busybox.new/coreutils/echo.c --- busybox/coreutils/echo.c 2006-06-26 06:57:54.000000000 -0400 +++ busybox.new/coreutils/echo.c 2006-07-01 08:40:11.000000000 -0400 @@ -71,7 +71,7 @@ int bb_echo(int ATTRIBUTE_UNUSED argc, c just_echo: #endif while (*argv) { - register int c; + int c; while ((c = *(*argv)++)) { if (c == eflag) { /* Check for escape seq. */ diff -pru busybox/coreutils/od.c busybox.new/coreutils/od.c --- busybox/coreutils/od.c 2006-06-26 06:57:54.000000000 -0400 +++ busybox.new/coreutils/od.c 2006-07-01 08:40:02.000000000 -0400 @@ -35,7 +35,7 @@ static void odoffset(int argc, char ***argvp) { - register char *num, *p; + char *num, *p; int base; char *end; diff -pru busybox/coreutils/test.c busybox.new/coreutils/test.c --- busybox/coreutils/test.c 2006-06-26 06:57:54.000000000 -0400 +++ busybox.new/coreutils/test.c 2006-07-01 08:40:19.000000000 -0400 @@ -554,7 +554,7 @@ static void initialize_group_array(void) /* Return non-zero if GID is one that we have in our groups list. */ static int is_a_group_member(gid_t gid) { - register int i; + int i; /* Short-circuit if possible, maybe saving a call to getgroups(). */ if (gid == getgid() || gid == getegid()) diff -pru busybox/coreutils/tr.c busybox.new/coreutils/tr.c --- busybox/coreutils/tr.c 2006-06-30 15:17:53.000000000 -0400 +++ busybox.new/coreutils/tr.c 2006-07-01 08:40:27.000000000 -0400 @@ -178,7 +178,7 @@ static unsigned int expand(const char *a static int complement(char *buffer, int buffer_len) { - register short i, j, ix; + short i, j, ix; char conv[ASCII + 2]; ix = 0; @@ -195,7 +195,7 @@ static int complement(char *buffer, int int tr_main(int argc, char **argv) { - register unsigned char *ptr; + unsigned char *ptr; int output_length=0, input_length; int idx = 1; int i; diff -pru busybox/editors/awk.c busybox.new/editors/awk.c --- busybox/editors/awk.c 2006-06-26 06:58:22.000000000 -0400 +++ busybox.new/editors/awk.c 2006-07-01 08:41:08.000000000 -0400 @@ -463,7 +463,7 @@ static void syntax_error(const char * co static unsigned int hashidx(const char *name) { - register unsigned int idx=0; + unsigned int idx=0; while (*name) idx = *name++ + (idx << 6) - idx; return idx; @@ -574,7 +574,7 @@ static void hash_remove(xhash *hash, con static void skip_spaces(char **s) { - register char *p = *s; + char *p = *s; while(*p == ' ' || *p == '\t' || (*p == '\\' && *(p+1) == '\n' && (++p, ++t.lineno))) { @@ -585,7 +585,7 @@ static void skip_spaces(char **s) static char *nextword(char **s) { - register char *p = *s; + char *p = *s; while (*(*s)++) ; @@ -594,7 +594,7 @@ static char *nextword(char **s) static char nextchar(char **s) { - register char c, *pps; + char c, *pps; c = *((*s)++); pps = *s; @@ -686,7 +686,7 @@ static var *setvar_u(var *v, const char /* set array element to user string */ static void setari_u(var *a, int idx, const char *s) { - register var *v; + var *v; static char sidx[12]; sprintf(sidx, "%d", idx); @@ -991,7 +991,7 @@ static void rollback_token(void) { t.rol static node *new_node(uint32_t info) { - register node *n; + node *n; n = (node *)xzalloc(sizeof(node)); n->info = info; @@ -1136,7 +1136,7 @@ static node *parse_expr(uint32_t iexp) /* add node to chain. Return ptr to alloc'd node */ static node *chain_node(uint32_t info) { - register node *n; + node *n; if (! seq->first) seq->first = seq->last = new_node(0); @@ -1355,7 +1355,7 @@ static void parse_program(char *p) static node *mk_splitter(char *s, tsplitter *spl) { - register regex_t *re, *ire; + regex_t *re, *ire; node *n; re = &spl->re[0]; diff -pru busybox/libbb/dump.c busybox.new/libbb/dump.c --- busybox/libbb/dump.c 2006-06-28 15:58:03.000000000 -0400 +++ busybox.new/libbb/dump.c 2006-07-01 08:41:50.000000000 -0400 @@ -37,9 +37,9 @@ static const char lcc[] = "diouxX"; int bb_dump_size(FS * fs) { - register FU *fu; - register int bcnt, cur_size; - register char *fmt; + FU *fu; + int bcnt, cur_size; + char *fmt; const char *p; int prec; @@ -354,7 +354,7 @@ static unsigned char *get(void) { static int ateof = 1; static unsigned char *curp=NULL, *savp; /*DBU:[dave@cray.com]initialize curp */ - register int n; + int n; int need, nread; unsigned char *tmpp; @@ -502,11 +502,11 @@ static void conv_u(PR * pr, unsigned cha static void display(void) { /* extern FU *endfu; */ - register FS *fs; - register FU *fu; - register PR *pr; - register int cnt; - register unsigned char *bp; + FS *fs; + FU *fu; + PR *pr; + int cnt; + unsigned char *bp; off_t saveaddress; unsigned char savech = 0, *savebp; @@ -650,7 +650,7 @@ static void display(void) int bb_dump_dump(char **argv) { - register FS *tfs; + FS *tfs; /* figure out the data block bb_dump_size */ for (bb_dump_blocksize = 0, tfs = bb_dump_fshead; tfs; tfs = tfs->nextfs) { diff -pru busybox/loginutils/login.c busybox.new/loginutils/login.c --- busybox/loginutils/login.c 2006-06-26 06:58:15.000000000 -0400 +++ busybox.new/loginutils/login.c 2006-07-01 08:42:03.000000000 -0400 @@ -377,7 +377,7 @@ static int is_my_tty ( const char *tty ) static void motd (void) { FILE *fp; - register int c; + int c; if (( fp = fopen ( bb_path_motd_file, "r" ))) { while (( c = getc ( fp )) != EOF ) diff -pru busybox/networking/udhcp/packet.c busybox.new/networking/udhcp/packet.c --- busybox/networking/udhcp/packet.c 2006-06-26 06:57:29.000000000 -0400 +++ busybox.new/networking/udhcp/packet.c 2006-07-01 08:43:03.000000000 -0400 @@ -87,7 +87,7 @@ uint16_t udhcp_checksum(void *addr, int /* Compute Internet Checksum for "count" bytes * beginning at location "addr". */ - register int32_t sum = 0; + int32_t sum = 0; uint16_t *source = (uint16_t *) addr; while (count > 1) { diff -pru busybox/shell/ash.c busybox.new/shell/ash.c --- busybox/shell/ash.c 2006-07-01 08:26:45.000000000 -0400 +++ busybox.new/shell/ash.c 2006-07-01 08:43:42.000000000 -0400 @@ -13472,7 +13472,7 @@ static const char op_tokens[] = { static arith_t arith (const char *expr, int *perrcode) { - register char arithval; /* Current character under analysis */ + char arithval; /* Current character under analysis */ operator lasttok, op; operator prec; diff -pru busybox/shell/lash.c busybox.new/shell/lash.c --- busybox/shell/lash.c 2006-07-01 08:26:45.000000000 -0400 +++ busybox.new/shell/lash.c 2006-07-01 08:43:55.000000000 -0400 @@ -707,10 +707,10 @@ static int get_command(FILE * source, ch return 0; } -static char* itoa(register int i) +static char* itoa(int i) { static char a[7]; /* Max 7 ints */ - register char *b = a + sizeof(a) - 1; + char *b = a + sizeof(a) - 1; int sign = (i < 0); if (sign) diff -pru busybox/shell/msh.c busybox.new/shell/msh.c --- busybox/shell/msh.c 2006-07-01 08:26:45.000000000 -0400 +++ busybox.new/shell/msh.c 2006-07-01 08:48:44.000000000 -0400 @@ -48,11 +48,6 @@ #include "cmdedit.h" - -/* Conditional use of "register" keyword */ -#define REGISTER register - - /*#define MSHDEBUG 1*/ #ifdef MSHDEBUG @@ -832,8 +827,8 @@ static char *current_prompt; int msh_main(int argc, char **argv) { - REGISTER int f; - REGISTER char *s; + int f; + char *s; int cflag; char *name, **ap; int (*iof) (struct ioarg *); @@ -1022,8 +1017,8 @@ int msh_main(int argc, char **argv) static void setdash(void) { - REGISTER char *cp; - REGISTER int c; + char *cp; + int c; char m['z' - 'a' + 1]; cp = m; @@ -1034,9 +1029,9 @@ static void setdash(void) setval(lookup("-"), m); } -static int newfile(REGISTER char *s) +static int newfile(char *s) { - REGISTER int f; + int f; DBGPRINTF7(("NEWFILE: opening %s\n", s)); @@ -1091,7 +1086,7 @@ struct op *scantree(struct op *head) static void onecommand(void) { - REGISTER int i; + int i; jmp_buf m1; DBGPRINTF(("ONECOMMAND: enter, outtree=%p\n", outtree)); @@ -1169,7 +1164,7 @@ static void leave(void) /* NOTREACHED */ } -static void warn(REGISTER char *s) +static void warn(char *s) { if (*s) { prs(s); @@ -1195,7 +1190,7 @@ static void err(char *s) static int newenv(int f) { - REGISTER struct env *ep; + struct env *ep; DBGPRINTF(("NEWENV: f=%d (indicates quitenv and return)\n", f)); @@ -1219,8 +1214,8 @@ static int newenv(int f) static void quitenv(void) { - REGISTER struct env *ep; - REGISTER int fd; + struct env *ep; + int fd; DBGPRINTF(("QUITENV: e.oenv=%p\n", e.oenv)); @@ -1237,7 +1232,7 @@ static void quitenv(void) /* * Is any character from s1 in s2? */ -static int anys(REGISTER char *s1, REGISTER char *s2) +static int anys(char *s1, char *s2) { while (*s1) if (any(*s1++, s2)) @@ -1248,7 +1243,7 @@ static int anys(REGISTER char *s1, REGIS /* * Is character c in s? */ -static int any(REGISTER int c, REGISTER char *s) +static int any(int c, char *s) { while (*s) if (*s++ == c) @@ -1256,12 +1251,12 @@ static int any(REGISTER int c, REGISTER return (0); } -static char *putn(REGISTER int n) +static char *putn(int n) { return (itoa(n)); } -static char *itoa(REGISTER int n) +static char *itoa(int n) { static char s[20]; @@ -1292,16 +1287,16 @@ static void onintr(int s) /* ANSI C static char *space(int n) { - REGISTER char *cp; + char *cp; if ((cp = getcell(n)) == 0) err("out of string space"); return (cp); } -static char *strsave(REGISTER char *s, int a) +static char *strsave(char *s, int a) { - REGISTER char *cp, *xp; + char *cp, *xp; if ((cp = space(strlen(s) + 1)) != NULL) { setarea((char *) cp, a); @@ -1314,7 +1309,7 @@ static char *strsave(REGISTER char *s, i /* * trap handling */ -static void sig(REGISTER int i) +static void sig(int i) { trapset = i; signal(i, sig); @@ -1341,11 +1336,11 @@ static void runtrap(int i) * not previously there, enter it now and * return a null value. */ -static struct var *lookup(REGISTER char *n) +static struct var *lookup(char *n) { - REGISTER struct var *vp; - REGISTER char *cp; - REGISTER int c; + struct var *vp; + char *cp; + int c; static struct var dummy; if (isdigit(*n)) { @@ -1393,9 +1388,9 @@ static void setval(struct var *vp, char * this is all so that exporting * values is reasonably painless. */ -static void nameval(REGISTER struct var *vp, char *val, char *name) +static void nameval(struct var *vp, char *val, char *name) { - REGISTER char *cp, *xp; + char *cp, *xp; char *nv; int fl; @@ -1439,7 +1434,7 @@ static void ronly(struct var *vp) vp->status |= RONLY; } -static int isassign(REGISTER char *s) +static int isassign(char *s) { DBGPRINTF7(("ISASSIGN: enter, s=%s\n", s)); @@ -1452,9 +1447,9 @@ static int isassign(REGISTER char *s) return (1); } -static int assign(REGISTER char *s, int cf) +static int assign(char *s, int cf) { - REGISTER char *cp; + char *cp; struct var *vp; DBGPRINTF7(("ASSIGN: enter, s=%s, cf=%d\n", s, cf)); @@ -1471,7 +1466,7 @@ static int assign(REGISTER char *s, int return (1); } -static int checkname(REGISTER char *cp) +static int checkname(char *cp) { DBGPRINTF7(("CHECKNAME: enter, cp=%s\n", cp)); @@ -1483,9 +1478,9 @@ static int checkname(REGISTER char *cp) return (1); } -static void putvlist(REGISTER int f, REGISTER int out) +static void putvlist(int f, int out) { - REGISTER struct var *vp; + struct var *vp; for (vp = vlist; vp; vp = vp->next) if (vp->status & f && (isalpha(*vp->name) || *vp->name == '_')) { @@ -1498,7 +1493,7 @@ static void putvlist(REGISTER int f, REG } } -static int eqname(REGISTER char *n1, REGISTER char *n2) +static int eqname(char *n1, char *n2) { for (; *n1 != '=' && *n1 != 0; n1++) if (*n2++ != *n1) @@ -1506,7 +1501,7 @@ static int eqname(REGISTER char *n1, REG return (*n2 == 0 || *n2 == '='); } -static char *findeq(REGISTER char *cp) +static char *findeq(char *cp) { while (*cp != '\0' && *cp != '=') cp++; @@ -1526,9 +1521,9 @@ static char *findeq(REGISTER char *cp) #define QMASK (CMASK&~QUOTE) #define NOT '!' /* might use ^ */ -static int gmatch(REGISTER char *s, REGISTER char *p) +static int gmatch(char *s, char *p) { - REGISTER int sc, pc; + int sc, pc; if (s == NULL || p == NULL) return (0); @@ -1561,9 +1556,9 @@ static int gmatch(REGISTER char *s, REGI return (*s == 0); } -static char *cclass(REGISTER char *p, REGISTER int sub) +static char *cclass(char *p, int sub) { - REGISTER int c, d, not, found; + int c, d, not, found; if ((not = *p == NOT) != 0) p++; @@ -1611,9 +1606,9 @@ static void initarea(void) char *getcell(unsigned nbytes) { - REGISTER int nregio; - REGISTER struct region *p, *q; - REGISTER int i; + int nregio; + struct region *p, *q; + int i; if (nbytes == 0) { puts("getcell(0)"); @@ -1679,7 +1674,7 @@ char *getcell(unsigned nbytes) static void freecell(char *cp) { - REGISTER struct region *p; + struct region *p; if ((p = (struct region *) cp) != NULL) { p--; @@ -1689,9 +1684,9 @@ static void freecell(char *cp) } } -static void freearea(REGISTER int a) +static void freearea(int a) { - REGISTER struct region *p, *top; + struct region *p, *top; top = areatop; for (p = areabot; p != top; p = p->next) @@ -1701,7 +1696,7 @@ static void freearea(REGISTER int a) static void setarea(char *cp, int a) { - REGISTER struct region *p; + struct region *p; if ((p = (struct region *) cp) != NULL) (p - 1)->area = a; @@ -1714,7 +1709,7 @@ int getarea(char *cp) static void garbage(void) { - REGISTER struct region *p, *q, *top; + struct region *p, *q, *top; top = areatop; for (p = areabot; p != top; p = p->next) { @@ -1753,8 +1748,8 @@ int yyparse(void) static struct op *pipeline(int cf) { - REGISTER struct op *t, *p; - REGISTER int c; + struct op *t, *p; + int c; DBGPRINTF7(("PIPELINE: enter, cf=%d\n", cf)); @@ -1785,8 +1780,8 @@ static struct op *pipeline(int cf) static struct op *andor(void) { - REGISTER struct op *t, *p; - REGISTER int c; + struct op *t, *p; + int c; DBGPRINTF7(("ANDOR: enter...\n")); @@ -1813,8 +1808,8 @@ static struct op *andor(void) static struct op *c_list(void) { - REGISTER struct op *t, *p; - REGISTER int c; + struct op *t, *p; + int c; DBGPRINTF7(("C_LIST: enter...\n")); @@ -1845,9 +1840,9 @@ static struct op *c_list(void) static int synio(int cf) { - REGISTER struct ioword *iop; - REGISTER int i; - REGISTER int c; + struct ioword *iop; + int i; + int c; DBGPRINTF7(("SYNIO: enter, cf=%d\n", cf)); @@ -1880,7 +1875,7 @@ static void musthave(int c, int cf) static struct op *simple(void) { - REGISTER struct op *t; + struct op *t; t = NULL; for (;;) { @@ -1907,7 +1902,7 @@ static struct op *simple(void) static struct op *nested(int type, int mark) { - REGISTER struct op *t; + struct op *t; DBGPRINTF3(("NESTED: enter, type=%d, mark=%d\n", type, mark)); @@ -1920,9 +1915,9 @@ static struct op *nested(int type, int m static struct op *command(int cf) { - REGISTER struct op *t; + struct op *t; struct wdblock *iosave; - REGISTER int c; + int c; DBGPRINTF(("COMMAND: enter, cf=%d\n", cf)); @@ -2033,7 +2028,7 @@ static struct op *command(int cf) static struct op *dowholefile(int type, int mark) { - REGISTER struct op *t; + struct op *t; DBGPRINTF(("DOWHOLEFILE: enter, type=%d, mark=%d\n", type, mark)); @@ -2047,8 +2042,8 @@ static struct op *dowholefile(int type, static struct op *dogroup(int onlydone) { - REGISTER int c; - REGISTER struct op *mylist; + int c; + struct op *mylist; c = yylex(CONTIN); if (c == DONE && onlydone) @@ -2062,8 +2057,8 @@ static struct op *dogroup(int onlydone) static struct op *thenpart(void) { - REGISTER int c; - REGISTER struct op *t; + int c; + struct op *t; if ((c = yylex(0)) != THEN) { peeksym = c; @@ -2080,8 +2075,8 @@ static struct op *thenpart(void) static struct op *elsepart(void) { - REGISTER int c; - REGISTER struct op *t; + int c; + struct op *t; switch (c = yylex(0)) { case ELSE: @@ -2104,7 +2099,7 @@ static struct op *elsepart(void) static struct op *caselist(void) { - REGISTER struct op *t; + struct op *t; t = NULL; while ((peeksym = yylex(CONTIN)) != ESAC) { @@ -2118,7 +2113,7 @@ static struct op *caselist(void) static struct op *casepart(void) { - REGISTER struct op *t; + struct op *t; DBGPRINTF7(("CASEPART: enter...\n")); @@ -2137,7 +2132,7 @@ static struct op *casepart(void) static char **pattern(void) { - REGISTER int c, cf; + int c, cf; cf = CONTIN; do { @@ -2153,7 +2148,7 @@ static char **pattern(void) static char **wordlist(void) { - REGISTER int c; + int c; if ((c = yylex(0)) != IN) { peeksym = c; @@ -2170,7 +2165,7 @@ static char **wordlist(void) /* * supporting functions */ -static struct op *list(REGISTER struct op *t1, REGISTER struct op *t2) +static struct op *list(struct op *t1, struct op *t2) { DBGPRINTF7(("LIST: enter, t1=%p, t2=%p\n", t1, t2)); @@ -2184,7 +2179,7 @@ static struct op *list(REGISTER struct o static struct op *block(int type, struct op *t1, struct op *t2, char **wp) { - REGISTER struct op *t; + struct op *t; DBGPRINTF7(("BLOCK: enter, type=%d (%s)\n", type, T_CMD_NAMES[type])); @@ -2201,9 +2196,9 @@ static struct op *block(int type, struct } /* See if given string is a shell multiline (FOR, IF, etc) */ -static int rlookup(REGISTER char *n) +static int rlookup(char *n) { - REGISTER const struct res *rp; + const struct res *rp; DBGPRINTF7(("RLOOKUP: enter, n is %s\n", n)); @@ -2219,7 +2214,7 @@ static int rlookup(REGISTER char *n) static struct op *newtp(void) { - REGISTER struct op *t; + struct op *t; t = (struct op *) tree(sizeof(*t)); t->type = 0; @@ -2234,7 +2229,7 @@ static struct op *newtp(void) return (t); } -static struct op *namelist(REGISTER struct op *t) +static struct op *namelist(struct op *t) { DBGPRINTF7(("NAMELIST: enter, t=%p, type %s, iolist=%p\n", t, @@ -2264,7 +2259,7 @@ static struct op *namelist(REGISTER stru static char **copyw(void) { - REGISTER char **wd; + char **wd; wd = getwords(wdlist); wdlist = 0; @@ -2278,7 +2273,7 @@ static void word(char *cp) static struct ioword **copyio(void) { - REGISTER struct ioword **iop; + struct ioword **iop; iop = (struct ioword **) getwords(iolist); iolist = 0; @@ -2287,7 +2282,7 @@ static struct ioword **copyio(void) static struct ioword *io(int u, int f, char *cp) { - REGISTER struct ioword *iop; + struct ioword *iop; iop = (struct ioword *) tree(sizeof(*iop)); iop->io_unit = u; @@ -2315,7 +2310,7 @@ static void yyerror(char *s) static int yylex(int cf) { - REGISTER int c, c1; + int c, c1; int atstart; if ((c = peeksym) > 0) { @@ -2446,7 +2441,7 @@ static int yylex(int cf) } -static int collect(REGISTER int c, REGISTER int c1) +static int collect(int c, int c1) { char s[2]; @@ -2481,10 +2476,10 @@ static int collect(REGISTER int c, REGIS /* "multiline commands" helper func */ /* see if next 2 chars form a shell multiline */ -static int dual(REGISTER int c) +static int dual(int c) { char s[3]; - REGISTER char *cp = s; + char *cp = s; DBGPRINTF8(("DUAL: enter, c=%d\n", c)); @@ -2499,9 +2494,9 @@ static int dual(REGISTER int c) return (c); /* String is multiline, return numeric multiline (restab) code */ } -static void diag(REGISTER int ec) +static void diag(int ec) { - REGISTER int c; + int c; DBGPRINTF8(("DIAG: enter, ec=%d\n", ec)); @@ -2521,7 +2516,7 @@ static void diag(REGISTER int ec) static char *tree(unsigned size) { - REGISTER char *t; + char *t; if ((t = getcell(size)) == NULL) { DBGPRINTF2(("TREE: getcell(%d) failed!\n", size)); @@ -2542,9 +2537,9 @@ static char *tree(unsigned size) */ -static int execute(REGISTER struct op *t, int *pin, int *pout, int act) +static int execute(struct op *t, int *pin, int *pout, int act) { - REGISTER struct op *t1; + struct op *t1; volatile int i, rv, a; char *cp, **wp, **wp2; struct var *vp; @@ -2765,12 +2760,12 @@ static int execute(REGISTER struct op *t } static int -forkexec(REGISTER struct op *t, int *pin, int *pout, int act, char **wp) +forkexec(struct op *t, int *pin, int *pout, int act, char **wp) { pid_t newpid; int i, rv; int (*shcom) (struct op *) = NULL; - REGISTER int f; + int f; char *cp = NULL; struct ioword **iopp; int resetsig; @@ -2995,9 +2990,9 @@ forkexec(REGISTER struct op *t, int *pin * 0< 1> are ignored as required * within pipelines. */ -static int iosetup(REGISTER struct ioword *iop, int pipein, int pipeout) +static int iosetup(struct ioword *iop, int pipein, int pipeout) { - REGISTER int u = -1; + int u = -1; char *cp = NULL, *msg; DBGPRINTF(("IOSETUP: iop %p, pipein %i, pipeout %i\n", iop, @@ -3071,9 +3066,9 @@ static int iosetup(REGISTER struct iowor return (0); } -static void echo(REGISTER char **wp) +static void echo(char **wp) { - REGISTER int i; + int i; prs("+"); for (i = 0; wp[i]; i++) { @@ -3086,9 +3081,9 @@ static void echo(REGISTER char **wp) static struct op **find1case(struct op *t, char *w) { - REGISTER struct op *t1; + struct op *t1; struct op **tp; - REGISTER char **wp, *cp; + char **wp, *cp; if (t == NULL) { @@ -3121,7 +3116,7 @@ static struct op **find1case(struct op * static struct op *findcase(struct op *t, char *w) { - REGISTER struct op **tp; + struct op **tp; return ((tp = find1case(t, w)) != NULL ? *tp : (struct op *) NULL); } @@ -3142,9 +3137,9 @@ static void brkset(struct brkcon *bc) * Ignore interrupt signals while waiting * unless `canintr' is true. */ -static int waitfor(REGISTER int lastpid, int canintr) +static int waitfor(int lastpid, int canintr) { - REGISTER int pid, rv; + int pid, rv; int s; int oheedint = heedint; @@ -3197,7 +3192,7 @@ static int waitfor(REGISTER int lastpid, return (rv); } -static int setstatus(REGISTER int s) +static int setstatus(int s) { exstat = s; setval(lookup("?"), putn(s)); @@ -3211,8 +3206,8 @@ static int setstatus(REGISTER int s) */ static char *rexecve(char *c, char **v, char **envp) { - REGISTER int i; - REGISTER char *sp, *tp; + int i; + char *sp, *tp; int eacces = 0, asis = 0; #ifdef CONFIG_FEATURE_SH_STANDALONE_SHELL @@ -3373,9 +3368,9 @@ static int dolabel(struct op *t) return (0); } -static int dochdir(REGISTER struct op *t) +static int dochdir(struct op *t) { - REGISTER char *cp, *er; + char *cp, *er; if ((cp = t->words[1]) == NULL && (cp = homedir->value) == NULL) er = ": no home directory"; @@ -3388,9 +3383,9 @@ static int dochdir(REGISTER struct op *t return (1); } -static int doshift(REGISTER struct op *t) +static int doshift(struct op *t) { - REGISTER int n; + int n; n = t->words[1] ? getn(t->words[1]) : 1; if (dolc < n) { @@ -3409,7 +3404,7 @@ static int doshift(REGISTER struct op *t */ static int dologin(struct op *t) { - REGISTER char *cp; + char *cp; if (interactive) { signal(SIGINT, SIG_DFL); @@ -3422,10 +3417,10 @@ static int dologin(struct op *t) return (1); } -static int doumask(REGISTER struct op *t) +static int doumask(struct op *t) { - REGISTER int i, n; - REGISTER char *cp; + int i, n; + char *cp; if ((cp = t->words[1]) == NULL) { i = umask(0); @@ -3441,9 +3436,9 @@ static int doumask(REGISTER struct op *t return (0); } -static int doexec(REGISTER struct op *t) +static int doexec(struct op *t) { - REGISTER int i; + int i; jmp_buf ex; xint *ofail; @@ -3462,8 +3457,8 @@ static int doexec(REGISTER struct op *t) static int dodot(struct op *t) { - REGISTER int i; - REGISTER char *sp, *tp; + int i; + char *sp, *tp; char *cp; int maltmp; @@ -3514,8 +3509,8 @@ static int dodot(struct op *t) static int dowait(struct op *t) { - REGISTER int i; - REGISTER char *cp; + int i; + char *cp; if ((cp = t->words[1]) != NULL) { i = getn(cp); @@ -3529,9 +3524,9 @@ static int dowait(struct op *t) static int doread(struct op *t) { - REGISTER char *cp, **wp; - REGISTER int nb = 0; - REGISTER int nl = 0; + char *cp, **wp; + int nb = 0; + int nl = 0; if (t->words[1] == NULL) { err("Usage: read name ..."); @@ -3550,15 +3545,15 @@ static int doread(struct op *t) return (nb <= 0); } -static int doeval(REGISTER struct op *t) +static int doeval(struct op *t) { return (RUN(awordlist, t->words + 1, wdchar)); } -static int dotrap(REGISTER struct op *t) +static int dotrap(struct op *t) { - REGISTER int n, i; - REGISTER int resetsig; + int n, i; + int resetsig; if (t->words[1] == NULL) { for (i = 0; i <= _NSIG; i++) @@ -3596,7 +3591,7 @@ static int dotrap(REGISTER struct op *t) static int getsig(char *s) { - REGISTER int n; + int n; if ((n = getn(s)) < 0 || n > _NSIG) { err("trap: bad signal number"); @@ -3605,7 +3600,7 @@ static int getsig(char *s) return (n); } -static void setsig(REGISTER int n, sighandler_t f) +static void setsig(int n, sighandler_t f) { if (n == 0) return; @@ -3617,8 +3612,8 @@ static void setsig(REGISTER int n, sigha static int getn(char *as) { - REGISTER char *s; - REGISTER int n, m; + char *s; + int n, m; s = as; m = 1; @@ -3645,10 +3640,10 @@ static int docontinue(struct op *t) return (brkcontin(t->words[1], 0)); } -static int brkcontin(REGISTER char *cp, int val) +static int brkcontin(char *cp, int val) { - REGISTER struct brkcon *bc; - REGISTER int nl; + struct brkcon *bc; + int nl; nl = cp == NULL ? 1 : getn(cp); if (nl <= 0) @@ -3669,7 +3664,7 @@ static int brkcontin(REGISTER char *cp, static int doexit(struct op *t) { - REGISTER char *cp; + char *cp; execflg = 0; if ((cp = t->words[1]) != NULL) @@ -3717,17 +3712,17 @@ static void rdexp(char **wp, void (*f) ( putvlist(key, 1); } -static void badid(REGISTER char *s) +static void badid(char *s) { prs(s); err(": bad identifier"); } -static int doset(REGISTER struct op *t) +static int doset(struct op *t) { - REGISTER struct var *vp; - REGISTER char *cp; - REGISTER int n; + struct var *vp; + char *cp; + int n; if ((cp = t->words[1]) == NULL) { for (vp = vlist; vp; vp = vp->next) @@ -3766,7 +3761,7 @@ static int doset(REGISTER struct op *t) return (0); } -static void varput(REGISTER char *s, int out) +static void varput(char *s, int out) { if (isalnum(*s) || *s == '_') { write(out, s, strlen(s)); @@ -3865,7 +3860,7 @@ static char **eval(char **ap, int f) */ static char **makenv(int all, struct wdblock *wb) { - REGISTER struct var *vp; + struct var *vp; DBGPRINTF5(("MAKENV: enter, all=%d\n", all)); @@ -3876,7 +3871,7 @@ static char **makenv(int all, struct wdb return (getwords(wb)); } -static char *evalstr(REGISTER char *cp, int f) +static char *evalstr(char *cp, int f) { struct wdblock *wb; @@ -3893,7 +3888,7 @@ static char *evalstr(REGISTER char *cp, return (cp); } -static int expand(char *cp, REGISTER struct wdblock **wbp, int f) +static int expand(char *cp, struct wdblock **wbp, int f) { jmp_buf ev; @@ -3941,8 +3936,8 @@ static int expand(char *cp, REGISTER str */ static char *blank(int f) { - REGISTER int c, c1; - REGISTER char *sp; + int c, c1; + char *sp; int scanequals, foundequals; DBGPRINTF3(("BLANK: enter, f=%d\n", f)); @@ -4008,9 +4003,9 @@ static char *blank(int f) /* * Get characters, substituting for ` and $ */ -static int subgetc(REGISTER char ec, int quoted) +static int subgetc(char ec, int quoted) { - REGISTER char c; + char c; DBGPRINTF3(("SUBGETC: enter, quoted=%d\n", quoted)); @@ -4039,7 +4034,7 @@ static int dollar(int quoted) int otask; struct io *oiop; char *dolp; - REGISTER char *s, c, *cp = NULL; + char *s, c, *cp = NULL; struct var *vp; DBGPRINTF3(("DOLLAR: enter, quoted=%d\n", quoted)); @@ -4141,7 +4136,7 @@ static int dollar(int quoted) static int grave(int quoted) { char *cp; - REGISTER int i; + int i; int j; int pf[2]; static char child_cmd[LINELIM]; @@ -4317,9 +4312,9 @@ static int grave(int quoted) } -static char *unquote(REGISTER char *as) +static char *unquote(char *as) { - REGISTER char *s; + char *s; if ((s = as) != NULL) while (*s) @@ -4342,8 +4337,8 @@ static char spcl[] = "[?*"; static struct wdblock *glob(char *cp, struct wdblock *wb) { - REGISTER int i; - REGISTER char *pp; + int i; + char *pp; if (cp == 0) return (wb); @@ -4384,9 +4379,9 @@ static struct wdblock *glob(char *cp, st return (wb); } -static void globname(char *we, REGISTER char *pp) +static void globname(char *we, char *pp) { - REGISTER char *np, *cp; + char *np, *cp; char *name, *gp, *dp; int k; DIR *dirp; @@ -4445,10 +4440,10 @@ static void globname(char *we, REGISTER * start..end1 / middle end * the slashes come for free */ -static char *generate(char *start1, REGISTER char *end1, char *middle, char *end) +static char *generate(char *start1, char *end1, char *middle, char *end) { char *p; - REGISTER char *op, *xp; + char *op, *xp; p = op = space((int) (end1 - start1) + strlen(middle) + strlen(end) + 2); @@ -4460,10 +4455,10 @@ static char *generate(char *start1, REGI return (p); } -static int anyspcl(REGISTER struct wdblock *wb) +static int anyspcl(struct wdblock *wb) { - REGISTER int i; - REGISTER char **wd; + int i; + char **wd; wd = wb->w_words; for (i = 0; i < wb->w_nword; i++) @@ -4479,9 +4474,9 @@ static int xstrcmp(char *p1, char *p2) /* -------- word.c -------- */ -static struct wdblock *newword(REGISTER int nw) +static struct wdblock *newword(int nw) { - REGISTER struct wdblock *wb; + struct wdblock *wb; wb = (struct wdblock *) space(sizeof(*wb) + nw * sizeof(char *)); wb->w_bsize = nw; @@ -4489,10 +4484,10 @@ static struct wdblock *newword(REGISTER return (wb); } -static struct wdblock *addword(char *wd, REGISTER struct wdblock *wb) +static struct wdblock *addword(char *wd, struct wdblock *wb) { - REGISTER struct wdblock *wb2; - REGISTER int nw; + struct wdblock *wb2; + int nw; if (wb == NULL) wb = newword(NSTART); @@ -4509,10 +4504,10 @@ static struct wdblock *addword(char *wd, } static -char **getwords(REGISTER struct wdblock *wb) +char **getwords(struct wdblock *wb) { - REGISTER char **wd; - REGISTER int nb; + char **wd; + int nb; if (wb == NULL) return ((char **) NULL); @@ -4538,7 +4533,7 @@ static void glob0(char *a0, unsigned a1, static void glob1(char *base, char *lim) { - REGISTER char *i, *j; + char *i, *j; int v2; char *lptr, *hptr; int c; @@ -4607,7 +4602,7 @@ static void glob1(char *base, char *lim) static void glob2(char *i, char *j) { - REGISTER char *index1, *index2, c; + char *index1, *index2, c; int m; m = globv; @@ -4622,7 +4617,7 @@ static void glob2(char *i, char *j) static void glob3(char *i, char *j, char *k) { - REGISTER char *index1, *index2, *index3; + char *index1, *index2, *index3; int c; int m; @@ -4646,7 +4641,7 @@ static void glob3(char *i, char *j, char static int my_getc(int ec) { - REGISTER int c; + int c; if (e.linep > elinep) { while ((c = readc()) != '\n' && c); @@ -4679,7 +4674,7 @@ static int eofc(void) static int readc(void) { - REGISTER int c; + int c; RCPRINTF(("READC: e.iop %p, e.iobase %p\n", e.iop, e.iobase)); @@ -4807,7 +4802,7 @@ static void pushio(struct ioarg *argp, i static struct io *setbase(struct io *ip) { - REGISTER struct io *xp; + struct io *xp; xp = e.iobase; e.iobase = ip; @@ -4821,9 +4816,9 @@ static struct io *setbase(struct io *ip) /* * Produce the characters of a string, then a newline, then EOF. */ -static int nlchar(REGISTER struct ioarg *ap) +static int nlchar(struct ioarg *ap) { - REGISTER int c; + int c; if (ap->aword == NULL) return (0); @@ -4838,10 +4833,10 @@ static int nlchar(REGISTER struct ioarg * Given a list of words, produce the characters * in them, with a space after each word. */ -static int wdchar(REGISTER struct ioarg *ap) +static int wdchar(struct ioarg *ap) { - REGISTER char c; - REGISTER char **wl; + char c; + char **wl; if ((wl = ap->awordlist) == NULL) return (0); @@ -4859,9 +4854,9 @@ static int wdchar(REGISTER struct ioarg * Return the characters of a list of words, * producing a space between them. */ -static int dolchar(REGISTER struct ioarg *ap) +static int dolchar(struct ioarg *ap) { - REGISTER char *wp; + char *wp; if ((wp = *ap->awordlist++) != NULL) { PUSHIO(aword, wp, *ap->awordlist == NULL ? strchar : xxchar); @@ -4870,9 +4865,9 @@ static int dolchar(REGISTER struct ioarg return (0); } -static int xxchar(REGISTER struct ioarg *ap) +static int xxchar(struct ioarg *ap) { - REGISTER int c; + int c; if (ap->aword == NULL) return (0); @@ -4886,9 +4881,9 @@ static int xxchar(REGISTER struct ioarg /* * Produce the characters from a single word (string). */ -static int strchar(REGISTER struct ioarg *ap) +static int strchar(struct ioarg *ap) { - REGISTER int c; + int c; if (ap->aword == NULL || (c = *ap->aword++) == 0) return (0); @@ -4898,9 +4893,9 @@ static int strchar(REGISTER struct ioarg /* * Produce quoted characters from a single word (string). */ -static int qstrchar(REGISTER struct ioarg *ap) +static int qstrchar(struct ioarg *ap) { - REGISTER int c; + int c; if (ap->aword == NULL || (c = *ap->aword++) == 0) return (0); @@ -4910,9 +4905,9 @@ static int qstrchar(REGISTER struct ioar /* * Return the characters from a file. */ -static int filechar(REGISTER struct ioarg *ap) +static int filechar(struct ioarg *ap) { - REGISTER int i; + int i; char c; struct iobuf *bp = ap->afbuf; @@ -4961,7 +4956,7 @@ static int filechar(REGISTER struct ioar /* * Return the characters from a here temp file. */ -static int herechar(REGISTER struct ioarg *ap) +static int herechar(struct ioarg *ap) { char c; @@ -4980,16 +4975,16 @@ static int herechar(REGISTER struct ioar */ static int gravechar(struct ioarg *ap, struct io *iop) { - REGISTER int c; + int c; if ((c = qgravechar(ap, iop) & ~QUOTE) == '\n') c = ' '; return (c); } -static int qgravechar(REGISTER struct ioarg *ap, struct io *iop) +static int qgravechar(struct ioarg *ap, struct io *iop) { - REGISTER int c; + int c; DBGPRINTF3(("QGRAVECHAR: enter, ap=%p, iop=%p\n", ap, iop)); @@ -5016,9 +5011,9 @@ static int qgravechar(REGISTER struct io /* * Return a single command (usually the first line) from a file. */ -static int linechar(REGISTER struct ioarg *ap) +static int linechar(struct ioarg *ap) { - REGISTER int c; + int c; if ((c = filechar(ap)) == '\n') { if (!multiline) { @@ -5029,7 +5024,7 @@ static int linechar(REGISTER struct ioar return (c); } -static void prs(REGISTER const char *s) +static void prs(const char *s) { if (*s) write(2, s, strlen(s)); @@ -5040,7 +5035,7 @@ static void prn(unsigned u) prs(itoa(u)); } -static void closef(REGISTER int i) +static void closef(int i) { if (i > 2) close(i); @@ -5048,7 +5043,7 @@ static void closef(REGISTER int i) static void closeall(void) { - REGISTER int u; + int u; for (u = NUFILE; u < NOFILE;) close(u++); @@ -5058,9 +5053,9 @@ static void closeall(void) /* * remap fd into Shell's fd space */ -static int remap(REGISTER int fd) +static int remap(int fd) { - REGISTER int i; + int i; int map[NOFILE]; int newfd; @@ -5088,16 +5083,16 @@ static int remap(REGISTER int fd) return (fd); } -static int openpipe(REGISTER int *pv) +static int openpipe(int *pv) { - REGISTER int i; + int i; if ((i = pipe(pv)) < 0) err("can't create pipe - try again"); return (i); } -static void closepipe(REGISTER int *pv) +static void closepipe(int *pv) { if (pv != NULL) { close(*pv++); @@ -5111,9 +5106,9 @@ static void closepipe(REGISTER int *pv) * here documents */ -static void markhere(REGISTER char *s, struct ioword *iop) +static void markhere(char *s, struct ioword *iop) { - REGISTER struct here *h, *lh; + struct here *h, *lh; DBGPRINTF7(("MARKHERE: enter, s=%p\n", s)); @@ -5147,7 +5142,7 @@ static void markhere(REGISTER char *s, s static void gethere(void) { - REGISTER struct here *h, *hp; + struct here *h, *hp; DBGPRINTF7(("GETHERE: enter...\n")); @@ -5163,11 +5158,11 @@ static void gethere(void) } } -static void readhere(char **name, REGISTER char *s, int ec) +static void readhere(char **name, char *s, int ec) { int tf; char tname[30] = ".msh_XXXXXX"; - REGISTER int c; + int c; jmp_buf ev; char myline[LINELIM + 1]; char *thenext; @@ -5224,7 +5219,7 @@ static void readhere(char **name, REGIST */ static int herein(char *hname, int xdoll) { - REGISTER int hf; + int hf; int tf; #if __GNUC__ @@ -5268,7 +5263,7 @@ static int herein(char *hname, int xdoll static void scraphere(void) { - REGISTER struct here *h; + struct here *h; DBGPRINTF7(("SCRAPHERE: enter...\n")); @@ -5282,7 +5277,7 @@ static void scraphere(void) /* unlink here temp files before a freearea(area) */ static void freehere(int area) { - REGISTER struct here *h, *hl; + struct here *h, *hl; DBGPRINTF6(("FREEHERE: enter, area=%d\n", area)); From rpjday at mindspring.com Sun Jul 2 12:51:45 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 12:53:24 2006 Subject: any value in configuring minimum password length? In-Reply-To: <200607022147.19261.farmatito@tiscali.it> References: <20060702181720.GN21958@aon.at> <200607022147.19261.farmatito@tiscali.it> Message-ID: On Sun, 2 Jul 2006, Tito wrote: > Hi, > While at it fix also this comment: > > - /* Add 1 for each type of characters to the minlen of password */ > + /* Add 2 for each type of characters to the minlen of password */ > int size = MINLEN + 8; > > Ciao, > Tito ok, done. rday From rpjday at mindspring.com Sun Jul 2 12:53:20 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 12:54:59 2006 Subject: [PATCH] get rid of all "register" storage class specifiers In-Reply-To: References: Message-ID: On Sat, 1 Jul 2006, Robert P. J. Day wrote: > i've suggested this before, and no one seemed to have any major > objections. note the number of register specifiers in msh.c. > yeesh. in any event, i can commit this later if no one has a problem > with it. > > rday you can safely ignore this post since that change has already been checked in, and doesn't seem to have hurt anything. rday From rpjday at mindspring.com Sun Jul 2 13:58:45 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jul 2 14:00:28 2006 Subject: any value in a standard for defining bit flags? Message-ID: i don't feel like doing any real work so i'm just going to pontificate. the code for defining bit flags in BB is a little chaotic as there are three standards scattered throughout the code. there's using shifts, as in tar.c: #define CTX_TEST (1 << 0) #define CTX_EXTRACT (1 << 1) #define TAR_OPT_BASEDIR (1 << 2) #define TAR_OPT_TARNAME (1 << 3) #define TAR_OPT_2STDOUT (1 << 4) #define TAR_OPT_P (1 << 5) #define TAR_OPT_VERBOSE (1 << 6) #define TAR_OPT_KEEP_OLD (1 << 7) then there's using hex literals, like in ext2_fs.h: #define EXT2_SECRM_FL 0x00000001 /* Secure deletion */ #define EXT2_UNRM_FL 0x00000002 /* Undelete */ #define EXT2_COMPR_FL 0x00000004 /* Compress file */ #define EXT2_SYNC_FL 0x00000008 /* Synchronous updates */ #define EXT2_IMMUTABLE_FL 0x00000010 /* Immutable file */ #define EXT2_APPEND_FL 0x00000020 /* writes to file may only append */ #define EXT2_NODUMP_FL 0x00000040 /* do not dump file */ #define EXT2_NOATIME_FL 0x00000080 /* do not update atime */ and finally, there's just plain integer literals, as in sort.c: /* These are sort types */ #define FLAG_n 1 /* Numeric sort */ #define FLAG_g 2 /* Sort using strtod() */ #define FLAG_M 4 /* Sort date */ /* ucsz apply to root level only, not keys. b at root level implies bb */ #define FLAG_u 8 /* Unique */ #define FLAG_c 16 /* Check: no output, exit(!ordered) */ #define FLAG_s 32 /* Stable sort, no ascii fallback at end */ #define FLAG_z 64 /* Input is null terminated, not \n */ /* These can be applied to search keys, the previous four can't */ #define FLAG_b 128 /* Ignore leading blanks */ #define FLAG_r 256 /* Reverse */ #define FLAG_d 512 /* Ignore !(isalnum()|isspace()) */ #define FLAG_f 1024 /* Force uppercase */ #define FLAG_i 2048 /* Ignore !isprint() */ #define FLAG_bb 32768 /* Ignore trailing blanks */ wouldn't it be easier to pick one and go with that? certainly, either of the first two syntaxes makes more sense than the last one, but just having a single standard couldn't hurt. and wouldn't it make more sense to use an enum rather than just a set of defines, anyway? rday From pgf at brightstareng.com Sun Jul 2 18:23:52 2006 From: pgf at brightstareng.com (Paul Fox) Date: Sun Jul 2 18:24:02 2006 Subject: any value in a standard for defining bit flags? In-Reply-To: rpjday's message of Sun, 02 Jul 2006 16:58:45 -0400. Message-ID: <2182.1151889832@brightstareng.com> > > i don't feel like doing any real work so i'm just going to > pontificate. the code for defining bit flags in BB is a little > chaotic as there are three standards scattered throughout the code. ... > wouldn't it be easier to pick one and go with that? certainly, while i'm a fan of uniformity, and consistency, in most programs, i'm also a fan of artistic license, and programmer preference. the fact is that busybox applets all come from different places, and have different authors, and many are even sometimes still synced, with greater or lesser rigor, with external codebases. while i myself would never define bit numbers in decimal, i have no problem maintaining them, or spotting errors in them. i guess all i'm getting at is that this is pretty far down on my list of busybox peeves. and since these definitions will never all appear in a single header, i'm not sure where the "easier" part of your claim comes in. (what's "easiest" when i'm writing an applet is probably to use what i find most natural.) [ i guess what i find myself thinking is that the very next step after something like this will be someone calling for a standard format for comments... ] paul > > there's using shifts, as in tar.c: > > #define CTX_TEST (1 << 0) > #define CTX_EXTRACT (1 << 1) > #define TAR_OPT_BASEDIR (1 << 2) > #define TAR_OPT_TARNAME (1 << 3) > #define TAR_OPT_2STDOUT (1 << 4) > #define TAR_OPT_P (1 << 5) > #define TAR_OPT_VERBOSE (1 << 6) > #define TAR_OPT_KEEP_OLD (1 << 7) > > then there's using hex literals, like in ext2_fs.h: > > #define EXT2_SECRM_FL 0x00000001 /* Secure deletion */ > #define EXT2_UNRM_FL 0x00000002 /* Undelete */ > #define EXT2_COMPR_FL 0x00000004 /* Compress file */ > #define EXT2_SYNC_FL 0x00000008 /* Synchronous updates */ > #define EXT2_IMMUTABLE_FL 0x00000010 /* Immutable file */ > #define EXT2_APPEND_FL 0x00000020 /* writes to file may only > append */ > #define EXT2_NODUMP_FL 0x00000040 /* do not dump file */ > #define EXT2_NOATIME_FL 0x00000080 /* do not update atime */ > > and finally, there's just plain integer literals, as in sort.c: > > /* These are sort types */ > #define FLAG_n 1 /* Numeric sort */ > #define FLAG_g 2 /* Sort using strtod() */ > #define FLAG_M 4 /* Sort date */ > /* ucsz apply to root level only, not keys. b at root level implies > bb */ > #define FLAG_u 8 /* Unique */ > #define FLAG_c 16 /* Check: no output, exit(!ordered) */ > #define FLAG_s 32 /* Stable sort, no ascii fallback at > end */ > #define FLAG_z 64 /* Input is null terminated, not \n */ > /* These can be applied to search keys, the previous four can't */ > #define FLAG_b 128 /* Ignore leading blanks */ > #define FLAG_r 256 /* Reverse */ > #define FLAG_d 512 /* Ignore !(isalnum()|isspace()) */ > #define FLAG_f 1024 /* Force uppercase */ > #define FLAG_i 2048 /* Ignore !isprint() */ > #define FLAG_bb 32768 /* Ignore trailing blanks */ > > either of the first two syntaxes makes more sense than the last one, > but just having a single standard couldn't hurt. > > and wouldn't it make more sense to use an enum rather than just a > set of defines, anyway? > > rday > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox =--------------------- paul fox, pgf@brightstareng.com From rpjday at mindspring.com Mon Jul 3 02:19:36 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 02:21:06 2006 Subject: any value in a standard for defining bit flags? In-Reply-To: <2182.1151889832@brightstareng.com> References: <2182.1151889832@brightstareng.com> Message-ID: On Sun, 2 Jul 2006, Paul Fox wrote: > > > > i don't feel like doing any real work so i'm just going to > > pontificate. the code for defining bit flags in BB is a little > > chaotic as there are three standards scattered throughout the code. > ... > > wouldn't it be easier to pick one and go with that? certainly, > > while i myself would never define bit numbers in decimal, i have > no problem maintaining them, or spotting errors in them. i guess > all i'm getting at is that this is pretty far down on my list of > busybox peeves... i *did* say i didn't feel like doing any real work. :-) i wouldn't suggest *enforcing* any kind of standard like that, but maybe just a list of recommended or suggested standards for an applet coding style? in any event, as you wrote, while defining bit flags using either hex constants or bit shifts is equally reasonable, defining them with literal power-of-two decimal constants does seem to be unnecessarily obtuse. just my $0x02c. rday p.s. the other reason i prefer a bit of a standard in this case is to visually distinguish when someone is using, say, the value 1024 as maybe a buffer size, or using it as a bit mask. if i see "1024", i might conclude it's defining an array to hold a block. if, however, i see "0x400", i'd more likely assume this was meant as a bit setting. it might occasionally make it easier to spot typoes. but i'm not going to lose any sleep over this. From rpjday at mindspring.com Mon Jul 3 02:53:25 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 02:55:04 2006 Subject: e2fsprogs/blkid/version.c can be deleted? Message-ID: it doesn't appear that that source file is part of the build process anymore and, besides, it's identical to the code in e2fsprogs/ext2fs/version.c anyway if it ever needs to be resurrected. rday From vda.linux at googlemail.com Mon Jul 3 02:52:24 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Mon Jul 3 03:17:38 2006 Subject: Fwd: Re: [klibc] klibc and what's the next step? Message-ID: <200607031152.24197.vda.linux@gmail.com> Just FYI: kernel folks are talking about small userspace which will start before root fs is mounted, and they are mentioning busybox: ---------- Forwarded Message ---------- Subject: Re: [klibc] klibc and what's the next step? Date: Sunday 02 July 2006 02:50 From: "H. Peter Anvin" To: Theodore Tso , "H. Peter Anvin" , Linus Torvalds , Jeff Bailey , Michael Tokarev , Roman Zippel , klibc@zytor.com, linux-kernel@vger.kernel.org, Pavel Machek Theodore Tso wrote: > > Well, I wouldn't be one of those folks. In fact, how big is dash and > some select set of shell utilities? If they aren't that big, it might > make sense to include them all the time so that a simple command-line > option on boot is all that's necessary in order to break into a > pre-kinit interactive shell. That would make the resulting system > more debuggable by definition. Then all we will would have to do is > make sure the distro's use the kernel-supplied kinit solution, instead > of rolling their own non-standard version. > Shared binaries, x86-64 (i386 is about 20-25% smaller): -rwxrwxr-x 1 hpa hpa 58544 Jul 1 11:41 usr/dash/sh.shared* -rwxrwxr-x 1 hpa hpa 2760 Jul 1 11:41 cat* -rwxrwxr-x 1 hpa hpa 888 Jul 1 11:41 chroot* -rwxrwxr-x 1 hpa hpa 4000 Jul 1 11:41 dd* -rwxrwxr-x 1 hpa hpa 680 Jul 1 11:41 false* -rwxrwxr-x 3 hpa hpa 1072 Jul 1 11:41 halt* -rwxrwxr-x 1 hpa hpa 1664 Jul 1 11:41 insmod* -rwxrwxr-x 1 hpa hpa 1336 Jul 1 11:41 ln* -rwxrwxr-x 1 hpa hpa 5000 Jul 1 11:41 minips* -rwxrwxr-x 1 hpa hpa 1984 Jul 1 11:41 mkdir* -rwxrwxr-x 1 hpa hpa 1704 Jul 1 11:41 mkfifo* -rwxrwxr-x 1 hpa hpa 1712 Jul 1 11:41 mknod* -rwxrwxr-x 1 hpa hpa 2184 Jul 1 11:41 mount -rwxrwxr-x 1 hpa hpa 1320 Jul 1 11:41 nuke* -rwxrwxr-x 1 hpa hpa 856 Jul 1 11:41 pivot_root* -rwxrwxr-x 3 hpa hpa 1072 Jul 1 11:41 poweroff* -rwxrwxr-x 3 hpa hpa 1072 Jul 1 11:41 reboot* -rwxrwxr-x 1 hpa hpa 864 Jul 1 11:41 sleep* -rwxrwxr-x 1 hpa hpa 672 Jul 1 11:41 true* -rwxrwxr-x 1 hpa hpa 1056 Jul 1 11:41 umount* -rwxrwxr-x 1 hpa hpa 1952 Jul 1 11:41 uname* -rw-rw-r-- 2 hpa hpa 71016 Jul 1 11:40 usr/klibc/klibc-Yy9wepARlc-x17pdZDwU1YCOiMQ.so -rwxrwxr-x 1 hpa hpa 35664 Jul 1 17:48 usr/kinit/kinit.shared* ... totalling about 193K if you include everything. For comparison, static kinit by itself is 67K (which includes ipconfig, nfsroot, etc.) For an "include everything" variant, it would probably make more sense to port busybox, and/or add more tools as dash builtins. All of these are uncompressed sizes. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ------------------------------------------------------- From rep.nop at aon.at Mon Jul 3 04:30:45 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jul 3 04:30:58 2006 Subject: Fwd: Re: [klibc] klibc and what's the next step? In-Reply-To: <200607031152.24197.vda.linux@gmail.com> References: <200607031152.24197.vda.linux@gmail.com> Message-ID: <20060703113045.GA26010@aon.at> On Mon, Jul 03, 2006 at 11:52:24AM +0200, Denis Vlasenko wrote: >Just FYI: kernel folks are talking about small userspace >which will start before root fs is mounted, and they are >mentioning busybox: The sum of on-disk bytes for their versions are 33848 Bytes. Busybox with the belowmentioned featureset (against glibc, so it's bigger than it needs to be and would be if using klibc) looks approximately like: $ size busybox text data bss dec hex filename 21345 644 8336 30325 7675 busybox $ ls -l busybox -rwxr-xr-x 1 bernhard users 23488 Jul 3 13:25 busybox Currently defined functions: busybox, cat, chroot, dd, false, halt, insmod, ln, mkdir, mkfifo, mknod, mount, pivot_root, poweroff, ps, reboot, rm, sleep, switch_root, true, umount, uname Wouldn't they need switch_root instead of pivot_root for 2.6? I did not look what 'nuke' is ment to do but set 'rm' instead. This can of course be fixed/added. >---------- Forwarded Message ---------- >Subject: Re: [klibc] klibc and what's the next step? >Date: Sunday 02 July 2006 02:50 >From: "H. Peter Anvin" >To: Theodore Tso , "H. Peter Anvin" , Linus Torvalds , Jeff Bailey , Michael Tokarev , Roman Zippel , klibc@zytor.com, linux-kernel@vger.kernel.org, Pavel Machek > >Theodore Tso wrote: >> >> Well, I wouldn't be one of those folks. In fact, how big is dash and >> some select set of shell utilities? If they aren't that big, it might >> make sense to include them all the time so that a simple command-line >> option on boot is all that's necessary in order to break into a >> pre-kinit interactive shell. That would make the resulting system >> more debuggable by definition. Then all we will would have to do is >> make sure the distro's use the kernel-supplied kinit solution, instead >> of rolling their own non-standard version. >> > >Shared binaries, x86-64 (i386 is about 20-25% smaller): > >-rwxrwxr-x 1 hpa hpa 58544 Jul 1 11:41 usr/dash/sh.shared* >-rwxrwxr-x 1 hpa hpa 2760 Jul 1 11:41 cat* >-rwxrwxr-x 1 hpa hpa 888 Jul 1 11:41 chroot* >-rwxrwxr-x 1 hpa hpa 4000 Jul 1 11:41 dd* >-rwxrwxr-x 1 hpa hpa 680 Jul 1 11:41 false* >-rwxrwxr-x 3 hpa hpa 1072 Jul 1 11:41 halt* >-rwxrwxr-x 1 hpa hpa 1664 Jul 1 11:41 insmod* >-rwxrwxr-x 1 hpa hpa 1336 Jul 1 11:41 ln* >-rwxrwxr-x 1 hpa hpa 5000 Jul 1 11:41 minips* >-rwxrwxr-x 1 hpa hpa 1984 Jul 1 11:41 mkdir* >-rwxrwxr-x 1 hpa hpa 1704 Jul 1 11:41 mkfifo* >-rwxrwxr-x 1 hpa hpa 1712 Jul 1 11:41 mknod* >-rwxrwxr-x 1 hpa hpa 2184 Jul 1 11:41 mount >-rwxrwxr-x 1 hpa hpa 1320 Jul 1 11:41 nuke* >-rwxrwxr-x 1 hpa hpa 856 Jul 1 11:41 pivot_root* >-rwxrwxr-x 3 hpa hpa 1072 Jul 1 11:41 poweroff* >-rwxrwxr-x 3 hpa hpa 1072 Jul 1 11:41 reboot* >-rwxrwxr-x 1 hpa hpa 864 Jul 1 11:41 sleep* >-rwxrwxr-x 1 hpa hpa 672 Jul 1 11:41 true* >-rwxrwxr-x 1 hpa hpa 1056 Jul 1 11:41 umount* >-rwxrwxr-x 1 hpa hpa 1952 Jul 1 11:41 uname* >-rw-rw-r-- 2 hpa hpa 71016 Jul 1 11:40 >usr/klibc/klibc-Yy9wepARlc-x17pdZDwU1YCOiMQ.so >-rwxrwxr-x 1 hpa hpa 35664 Jul 1 17:48 usr/kinit/kinit.shared* > >... totalling about 193K if you include everything. For comparison, >static kinit by itself is 67K (which includes ipconfig, nfsroot, etc.) >For an "include everything" variant, it would probably make more sense >to port busybox, and/or add more tools as dash builtins. > >All of these are uncompressed sizes. > > -hpa >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ >------------------------------------------------------- >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox > From rpjday at mindspring.com Mon Jul 3 04:53:00 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 04:54:28 2006 Subject: strangeness involving e2fsprogs header files Message-ID: in my travels through the source code, i wandered across the fact that a number of header file inclusions under e2fsprogs use relative pathnames: e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h" e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h" e2fsprogs/blkid/read.c:#include "../uuid/uuid.h" e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h" e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h" that sort of thing. i've never been a fan of locking header file names to locations like this since it will break immediately if the directories are restructured. it always seemed to be more reasonable to add extra "-I" options to the compile command so that you might do something like: #include "ext2fs/ext2_types.h" #include "ext2fs/ext2_fs.h" now, as i read e2fsprogs/Makefile.in, it would seem that that's exactly what *should* be happening: ... # XXX: FIXME: change .c to include their stuff relative to $(E2FSPROGS_SRC) E2FSPROGS_TMP_KLUDGE:=$(patsubst %,-I$(E2FSPROGS_SRC)/%,blkid e2fsck e2p ext2fs uuid) APPLETS_DEFINE-y+=$(E2FSPROGS_CFLAGS) -I$(E2FSPROGS_SRC) $(E2FSPROGS_TMP_KLUDGE) APPLETS_DEFINE-a+=$(E2FSPROGS_CFLAGS) -I$(E2FSPROGS_SRC) $(E2FSPROGS_TMP_KLUDGE) ... but if i tweak those includes to take advantage of that, the build breaks: ... CC e2fsprogs/ext2fs/mkjournal.o /home/rpjday/bbx/busybox/e2fsprogs/ext2fs/mkjournal.c:38:20: error: e2fsck.h: No such file or directory make[1]: *** [/home/rpjday/bbx/busybox/e2fsprogs/ext2fs/mkjournal.o] Error 1 make: *** [busybox] Error 2 ... if i build verbosely, here's what i get: make -C /home/rpjday/bbx/busybox \ top_srcdir=/home/rpjday/bbx/busybox \ top_builddir=/home/rpjday/bbx/busybox \ BUILD_SRC=/home/rpjday/bbx/busybox \ -f /home/rpjday/bbx/busybox/Makefile busybox gcc -I/home/rpjday/bbx/busybox/include -I/home/rpjday/bbx/busybox/include -I/home/rpjday/bbx/busybox/libbb -D_GNU_SOURCE -Wall -Wstrict-prototypes -Wshadow -funsigned-char -fno-builtin-strlen -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fno-branch-count-reg -fomit-frame-pointer -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wshadow -funsigned-char -fno-builtin-strlen -c -o /home/rpjday/bbx/busybox/e2fsprogs/ext2fs/mkjournal.o /home/rpjday/bbx/busybox/e2fsprogs/ext2fs/mkjournal.c/home/rpjday/bbx/busybox/e2fsprogs/ext2fs/mkjournal.c:38:20: error: e2fsck.h: No such file or directory make[1]: *** [/home/rpjday/bbx/busybox/e2fsprogs/ext2fs/mkjournal.o] Error 1 make: *** [busybox] Error 2 the problem appears to be that the variable APPLETS_DEFINE is being used in Rules.mak, but has no effect on the compile step, only the link step: cmd_link = $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(LDFLAGS) \ $(PROG_CFLAGS) $(PROG_LDFLAGS) $(CFLAGS_COMBINE) \ -o $@ $(LD_START_GROUP) \ $(APPLETS_DEFINE) $(APPLET_SRC) \ $(BUSYBOX_DEFINE) $(BUSYBOX_SRC) $(libraries-y) \ $(LDBUSYBOX) $(LIBRARIES) \ $(LD_END_GROUP) so adding those extra "-I" options to APPLETS_DEFINE doesn't do a whole lot of good. thoughts? rday From vda.linux at googlemail.com Mon Jul 3 05:30:12 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Mon Jul 3 05:30:28 2006 Subject: Fwd: Re: [klibc] klibc and what's the next step? In-Reply-To: <20060703113045.GA26010@aon.at> References: <200607031152.24197.vda.linux@gmail.com> <20060703113045.GA26010@aon.at> Message-ID: <200607031430.12513.vda.linux@googlemail.com> On Monday 03 July 2006 13:30, Bernhard Fischer wrote: > On Mon, Jul 03, 2006 at 11:52:24AM +0200, Denis Vlasenko wrote: > >Just FYI: kernel folks are talking about small userspace > >which will start before root fs is mounted, and they are > >mentioning busybox: > > The sum of on-disk bytes for their versions are 33848 Bytes. > Busybox with the belowmentioned featureset (against glibc, so it's > bigger than it needs to be and would be if using klibc) looks > approximately like: > > $ size busybox > text data bss dec hex filename > 21345 644 8336 30325 7675 busybox > $ ls -l busybox > -rwxr-xr-x 1 bernhard users 23488 Jul 3 13:25 busybox > > Currently defined functions: > busybox, cat, chroot, dd, false, halt, insmod, ln, mkdir, mkfifo, > mknod, mount, pivot_root, poweroff, ps, reboot, rm, sleep, switch_root, > true, umount, uname Well, I'm afraid we heed shell also, and IIRC our shells are not in particularly good shape. BTW, I do not see my own posts to the list. I just checked on busybox.net: sending of my own mails back to me is not disabled there... -- vda From pgf at brightstareng.com Mon Jul 3 05:35:10 2006 From: pgf at brightstareng.com (Paul Fox) Date: Mon Jul 3 05:35:16 2006 Subject: Fwd: Re: [klibc] klibc and what's the next step? In-Reply-To: vda.linux's message of Mon, 03 Jul 2006 14:30:12 +0200. <200607031430.12513.vda.linux@googlemail.com> Message-ID: <29571.1151930110@brightstareng.com> > > Currently defined functions: > > busybox, cat, chroot, dd, false, halt, insmod, ln, mkdir, mkfifo, > > mknod, mount, pivot_root, poweroff, ps, reboot, rm, sleep, switch_root, > > true, umount, uname > > Well, I'm afraid we heed shell also, and IIRC our shells > are not in particularly good shape. i would have thought that ash and dash were pretty much on par, since one is derived from the other, and has been synced fairly regularly, until recently, anyway. paul =--------------------- paul fox, pgf@brightstareng.com From vapier at gentoo.org Mon Jul 3 05:52:40 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Mon Jul 3 05:52:59 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: References: Message-ID: <200607030852.41067.vapier@gentoo.org> On Monday 03 July 2006 07:53, Robert P. J. Day wrote: > in my travels through the source code, i wandered across the fact > that a number of header file inclusions under e2fsprogs use relative > pathnames: > > e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h" > e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h" > e2fsprogs/blkid/read.c:#include "../uuid/uuid.h" > e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h" > e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h" this was done on purpose ... since the build system tends to be on the fragile side, using paths such as these: > #include "ext2fs/ext2_types.h" > #include "ext2fs/ext2_fs.h" is no good as they may pick up the standard e2fsprogs header files in /usr/include/ and it'd be a while before people noticed (or we'd get to chase down funky build errors) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060703/a1e78bfc/attachment.pgp From rpjday at mindspring.com Mon Jul 3 06:00:27 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 06:01:57 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: <200607030852.41067.vapier@gentoo.org> References: <200607030852.41067.vapier@gentoo.org> Message-ID: On Mon, 3 Jul 2006, Mike Frysinger wrote: > On Monday 03 July 2006 07:53, Robert P. J. Day wrote: > > in my travels through the source code, i wandered across the > > fact that a number of header file inclusions under e2fsprogs use > > relative pathnames: > > > > e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h" > > e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h" > > e2fsprogs/blkid/read.c:#include "../uuid/uuid.h" > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h" > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h" > > this was done on purpose ... since the build system tends to be on > the fragile side, using paths such as these: > > > #include "ext2fs/ext2_types.h" > > #include "ext2fs/ext2_fs.h" > > is no good as they may pick up the standard e2fsprogs header files > in /usr/include/ and it'd be a while before people noticed (or we'd > get to chase down funky build errors) oh, i realize what's happening here and why someone might want to do it this way. but if that's the case, then it's somewhat misleading for e2fsprogs/Makefile.in to contain that snippet i reproduced earlier: ... # XXX: FIXME: change .c to include their stuff relative to $(E2FSPROGS_SRC) E2FSPROGS_TMP_KLUDGE:=$(patsubst %,-I$(E2FSPROGS_SRC)/%,blkid e2fsck e2p ext2fs uuid) APPLETS_DEFINE-y+=$(E2FSPROGS_CFLAGS) -I$(E2FSPROGS_SRC) $(E2FSPROGS_TMP_KLUDGE) APPLETS_DEFINE-a+=$(E2FSPROGS_CFLAGS) -I$(E2FSPROGS_SRC) $(E2FSPROGS_TMP_KLUDGE) ... whose sole purpose would *seem* to be to allow exactly what i was talking about earlier, no? one way or the other, something here should be cleaned up to not be quite so misleading. rday p.s. personally, my attitude toward "fragile" build systems is not to accommodate them with unclean hacks, but to change the build system to make it not so fragile in the first place. i find it hard to believe that no developer would want to clean up this feature because they're afraid that they'll somehow break the build. the last time i looked, the ability to allow local header files to override system header files of the same name was pretty much a solved problem. From rpjday at mindspring.com Mon Jul 3 06:01:24 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 06:02:51 2006 Subject: is there any value to udhcp/frontend.c? Message-ID: it doesn't appear to be required by any variation of the build. rday From vapier at gentoo.org Mon Jul 3 06:06:15 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Mon Jul 3 06:06:21 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: References: <200607030852.41067.vapier@gentoo.org> Message-ID: <200607030906.16193.vapier@gentoo.org> On Monday 03 July 2006 09:00, Robert P. J. Day wrote: > p.s. personally, my attitude toward "fragile" build systems is not to > accommodate them with unclean hacks, but to change the build system to > make it not so fragile in the first place. and to put in safe guards so that when it does break, people notice right away so perhaps rename the headers by giving them a bb_ prefix :P -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060703/279a5357/attachment.pgp From rpjday at mindspring.com Mon Jul 3 06:05:44 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 06:07:10 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: <200607030852.41067.vapier@gentoo.org> References: <200607030852.41067.vapier@gentoo.org> Message-ID: On Mon, 3 Jul 2006, Mike Frysinger wrote: > On Monday 03 July 2006 07:53, Robert P. J. Day wrote: > > in my travels through the source code, i wandered across the > > fact that a number of header file inclusions under e2fsprogs use > > relative pathnames: > > > > e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h" > > e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h" > > e2fsprogs/blkid/read.c:#include "../uuid/uuid.h" > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h" > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h" > > this was done on purpose ... since the build system tends to be on > the fragile side, using paths such as these: not to belabour this point, but it would seem to me that hard-coding filenames which might break if anything is moved around is actually more "fragile" than just defining the appropriate preprocessor directives to handle this situation in general, no? rday From rpjday at mindspring.com Mon Jul 3 06:07:01 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 06:08:27 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: <200607030906.16193.vapier@gentoo.org> References: <200607030852.41067.vapier@gentoo.org> <200607030906.16193.vapier@gentoo.org> Message-ID: On Mon, 3 Jul 2006, Mike Frysinger wrote: > On Monday 03 July 2006 09:00, Robert P. J. Day wrote: > > p.s. personally, my attitude toward "fragile" build systems is not to > > accommodate them with unclean hacks, but to change the build system to > > make it not so fragile in the first place. > > and to put in safe guards so that when it does break, people notice > right away agreed. > so perhaps rename the headers by giving them a bb_ prefix :P that's certainly one possibility. rday From vapier at gentoo.org Mon Jul 3 06:10:08 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Mon Jul 3 06:10:24 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: References: <200607030852.41067.vapier@gentoo.org> Message-ID: <200607030910.08927.vapier@gentoo.org> On Monday 03 July 2006 09:05, Robert P. J. Day wrote: > On Mon, 3 Jul 2006, Mike Frysinger wrote: > > On Monday 03 July 2006 07:53, Robert P. J. Day wrote: > > > in my travels through the source code, i wandered across the > > > fact that a number of header file inclusions under e2fsprogs use > > > relative pathnames: > > > > > > e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h" > > > e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h" > > > e2fsprogs/blkid/read.c:#include "../uuid/uuid.h" > > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h" > > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h" > > > > this was done on purpose ... since the build system tends to be on > > the fragile side, using paths such as these: > > not to belabour this point, but it would seem to me that hard-coding > filenames which might break if anything is moved around is actually > more "fragile" than just defining the appropriate preprocessor > directives to handle this situation in general, no? moving things around would break a lot more than the headers -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060703/18059ff9/attachment.pgp From rep.nop at aon.at Mon Jul 3 06:16:05 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jul 3 06:16:14 2006 Subject: Fwd: Re: [klibc] klibc and what's the next step? In-Reply-To: <200607031430.12513.vda.linux@googlemail.com> References: <200607031152.24197.vda.linux@gmail.com> <20060703113045.GA26010@aon.at> <200607031430.12513.vda.linux@googlemail.com> Message-ID: <20060703131605.GA28181@aon.at> On Mon, Jul 03, 2006 at 02:30:12PM +0200, Denis Vlasenko wrote: >On Monday 03 July 2006 13:30, Bernhard Fischer wrote: >> On Mon, Jul 03, 2006 at 11:52:24AM +0200, Denis Vlasenko wrote: >> >Just FYI: kernel folks are talking about small userspace >> >which will start before root fs is mounted, and they are >> >mentioning busybox: >> >> The sum of on-disk bytes for their versions are 33848 Bytes. >> Busybox with the belowmentioned featureset (against glibc, so it's >> bigger than it needs to be and would be if using klibc) looks >> approximately like: >> >> $ size busybox >> text data bss dec hex filename >> 21345 644 8336 30325 7675 busybox >> $ ls -l busybox >> -rwxr-xr-x 1 bernhard users 23488 Jul 3 13:25 busybox >> >> Currently defined functions: >> busybox, cat, chroot, dd, false, halt, insmod, ln, mkdir, mkfifo, >> mknod, mount, pivot_root, poweroff, ps, reboot, rm, sleep, switch_root, >> true, umount, uname > >Well, I'm afraid we heed shell also, and IIRC our shells >are not in particularly good shape. well, lash works reasonably well for me. It lacks support for 'for' 'while' etc, though. lash adds about 7k to the game. > >BTW, I do not see my own posts to the list. >I just checked on busybox.net: sending of my own mails >back to me is not disabled there... They're still queued on morris and will probably be delivered during the next few hours. I don't have caps to drop mail morris is trying to send off to a non-existing domain, so we have to wait until it's smtpd gives up on them.. From rob at landley.net Mon Jul 3 09:26:56 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 09:27:14 2006 Subject: svn commit: trunk/busybox/networking In-Reply-To: References: <24983.1151783503@brightstareng.com> Message-ID: <200607031226.57469.rob@landley.net> On Saturday 01 July 2006 4:22 pm, Robert P. J. Day wrote: > on that note, would someone like to suggest a standard for what > maintainers should use if they want to do that sort of thing in their > own code? i'm leery of something as generic as "#ifdef DEBUG" since > that just *begs* to have code start clashing. I've found that debug printfs are far more meaningful to the person who put them in than to anyone else, and that leaving there "to help future developers" just clutters up the code. You'll notice how uClibc has a config option for "manuel's hidden warnings", I.E. CONFIG_MJN3_ONLY? That strikes me as a good name for that option. I'm actually pretty happy removing the debug printfs entirely if they're mostly configured out. Instrumenting code to see what it's doing generally isn't a major problem, and figuring out where you need to put the printfs is part of learning the code. And the purpose of the DEBUG toggle is to build binaries with debugging info so you can run gdb against them. (I believe this is one step beyond busybox_unstripped.) > rday Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Mon Jul 3 09:27:32 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jul 3 09:27:38 2006 Subject: is there any value to udhcp/frontend.c? In-Reply-To: References: Message-ID: <20060703162732.GA31935@aon.at> On Mon, Jul 03, 2006 at 09:01:24AM -0400, Robert P. J. Day wrote: > > it doesn't appear to be required by any variation of the build. Looks like it's only needed for the standalone project. From rob at landley.net Mon Jul 3 09:34:02 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 09:33:53 2006 Subject: any reason to *not* support hex escapes? In-Reply-To: <20060702182327.GP21958@aon.at> References: <20060702182327.GP21958@aon.at> Message-ID: <200607031234.02352.rob@landley.net> On Sunday 02 July 2006 2:23 pm, Bernhard Fischer wrote: > On Sun, Jul 02, 2006 at 12:34:00PM -0400, Robert P. J. Day wrote: > >On Sun, 2 Jul 2006, Bernhard Fischer wrote: > >> On Sun, Jul 02, 2006 at 11:36:12AM -0400, Robert P. J. Day wrote: > >> >libbb/process_escape_sequence.c: > >> >-------------------------------- > >> > > >> >#define WANT_HEX_ESCAPES 1 > >> >... > >> >#ifdef WANT_HEX_ESCAPES ... > >> > > >> >etc etc. > >> > > >> > any reason to not support this feature unconditionally? > >> > >> libbb/Config.in ? > >> > >> Not sure if these are worth exposing in the menu-thing. Leaving them > >> in the file so one can hand-tweak if needed is about as good for me > >> but admittedly limits the number of people who may turn it off if > >> they know that they will not need it. > > > >but is there any obvious reason why someone would explicitly *not* > >want that feature in the first place? > > size / creeping featureitis. I've had a todo item deal with this for over a year. It's even in my old todo list on http://landley.net/code/todo.txt sed should use bb_process_escape_sequence() Check \? to make sure it doesn't become \\ Why doesn't this work: [^\"'\n] not backslash double quote single quote newline > >also, given how that routine works, shouldn't the routine return an > >unsigned char rather than just a plain char? after all, it's quite > >possible to be handed an escape sequence of \377, no? > > Could very well be, i admit that i didn't look. Please fix this aspect > if it is not ok as it is. In busybox, char defaults to unsigned. We feed -funsigned-char to the compiler because otherwise the sign of char varies from platform to platform, which sucks. We default to unsigned so the code is naturally 8 bit clean, therefore you'd be fixing something that's not broken. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jul 3 09:38:53 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 09:38:39 2006 Subject: any value in configuring minimum password length? In-Reply-To: References: Message-ID: <200607031238.55085.rob@landley.net> On Sunday 02 July 2006 11:41 am, Robert P. J. Day wrote: > libbb/obscure.c > --------------- > > #define MINLEN 6 > > any value in taking the extra step and allowing this to be changed > during configuration? I have a largeish rewrite of the passwd code stalled in a directory here that I hope to unblock now that a release isn't pending. (I.E. maybe I can ignore this whole "maintainer" thing for a couple months and actually _write_some_code_...) Rob -- Never bet against the cheap plastic solution. From rpjday at mindspring.com Mon Jul 3 09:41:04 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 09:42:35 2006 Subject: any reason to *not* support hex escapes? In-Reply-To: <200607031234.02352.rob@landley.net> References: <20060702182327.GP21958@aon.at> <200607031234.02352.rob@landley.net> Message-ID: On Mon, 3 Jul 2006, Rob Landley wrote: > compiler because otherwise the sign of char varies from platform to > platform, which sucks. We default to unsigned so the code is > naturally 8 bit clean, therefore you'd be fixing something that's > not broken. i suspected something like that, otherwise, things would have been going wrong long before now. rday From rep.nop at aon.at Mon Jul 3 09:44:24 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jul 3 09:44:32 2006 Subject: busybox compile error form ARM core??? In-Reply-To: <200605301542.00976.rob@landley.net> References: <200605300256.47288.rob@landley.net> <20060530174500.GF14720@aon.at> <200605301542.00976.rob@landley.net> Message-ID: <20060703164424.GC31935@aon.at> On Tue, May 30, 2006 at 03:42:00PM -0400, Rob Landley wrote: >On Tuesday 30 May 2006 1:45 pm, Bernhard Fischer wrote: >> On Tue, May 30, 2006 at 10:01:50AM +0200, Peter S. Mazinger wrote: >> >On Tue, 30 May 2006, Rob Landley wrote: >> >> On Tuesday 30 May 2006 2:20 am, yangm wrote: >> >> >> >> >> >> if (!(opt & 2)) { >> >> #if defined(__uClinux__) >> > >> >for uClibc-svn non-MMU the condition to use the internal version would be >> > >> >#if defined __UCLIBC__ && !defined __ARCH_USE_MMU__ >> > >> >Peter >> > >> >> /* reexec for vfork() do continue parent */ >> >> vfork_daemon_rexec (0, 0, argc, argv, "-f"); >> >> #else >> >> daemon (0, 0); /* bb_xdaemon? */ >> >> #endif /* uClinux */ >> >> } else { >> >> Landley, what do you think? >> >> in platform.h, >> /* uclibc does not implement daemon for no-mmu systems. */ >> #if defined __UCLIBC__ && !defined __ARCH_USE_MMU__ >> #define BB_DAEMON(no_chdir, no_close, argc, argv, str) \ >> vfork_daemon_rexec(no_chdir, no_close, argc, argv, str) >> #else >> #define BB_DAEMON(no_chdir, no_close, argc, argv, str) \ >> daemon(no_chdir, no_close) >> #endif >> >> Alternatively, we can of course introduce an int bb_daemon(d,c,ac,av,s){} >> to libbb which does the same (may be bigger than the proposal above, didn't >> try). > >Actually, what I'd like is a bb_daemon(a, b) that (for the BB_NOMMU case) uses >approximately the same mechanism as the standalone shell when it needs to >exec stuff. Our argc and argv should be made available as globals so this >thing can access them. A suggestion which did this is here: http://busybox.net/lists/busybox/2006-July/022882.html It doesn't look too nice to me, size-wise.. Thoughts? > >Speaking of which, we still need a config entry that lets people change the >standalone shell's default "/proc/self/exe" to point to wherever their copy >of busybox is installed if they don't have /proc. Break that out into some >kind of bb_exec_self(argc, argv) or some such. By now this is in the tree already. > >These are both existing todo items of mine, but if somebody else wanted to >take a stab at it first... From rob at landley.net Mon Jul 3 09:56:01 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 09:55:48 2006 Subject: any value in configuring minimum password length? In-Reply-To: References: <20060702154905.GK21958@aon.at> Message-ID: <200607031256.02074.rob@landley.net> On Sunday 02 July 2006 12:06 pm, Robert P. J. Day wrote: > i'm assuming something like the following would be sufficient, yes? I consider it kind of pointless overkill, but if you really feel the need could you please make it depend on CONFIG_NITPICK? I'm trying not to bury users in a paralyzing number of choices. The reason for a minimum password length of 6 (in conjunction with the password strength checks) is due to things like cryptographic strength analysis that most users really aren't going to do themselves. I don't want to _deny_ users choices either, but we do give them the complete source code. Figuring out what should be a config options is a balancing act of presenting some users with unwanted options vs forcing others to hunt through the source code to get what they want. CONFIG_NITPICK is an attempt to compromise somewhere in the middle. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jul 3 09:58:27 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 09:58:22 2006 Subject: any value in configuring minimum password length? In-Reply-To: <200607022147.19261.farmatito@tiscali.it> References: <200607022147.19261.farmatito@tiscali.it> Message-ID: <200607031258.28209.rob@landley.net> On Sunday 02 July 2006 3:47 pm, Tito wrote: > - /* Add 1 for each type of characters to the minlen of password */ > + /* Add 2 for each type of characters to the minlen of password */ > int size = MINLEN + 8; Actually, changing the code to match the comment might be better. And if you're making MINLEN configurable, why aren't you making the increment size be configurable? (Or the number of different types of characters required before it increments the required length?) What's the rationale for exposing one but not the other? You see why I didn't want to go there? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jul 3 10:01:12 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 10:00:59 2006 Subject: any value in a standard for defining bit flags? In-Reply-To: References: Message-ID: <200607031301.12639.rob@landley.net> On Sunday 02 July 2006 4:58 pm, Robert P. J. Day wrote: > wouldn't it be easier to pick one and go with that? I see no benefit in this. As long as each applet is consistent within itself, it doesn't have to be consistent from applet to applet. > and wouldn't it make more sense to use an enum rather than just a > set of defines, anyway? Again, I don't see the benefit. (For one thing, an enum has to fit in an int, and our getopt_ulflags() returns a long. On 64 bit platforms, these ain't the same. Dunno how relevant that is to us, but still...) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jul 3 10:02:24 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 10:02:12 2006 Subject: any value in a standard for defining bit flags? In-Reply-To: <2182.1151889832@brightstareng.com> References: <2182.1151889832@brightstareng.com> Message-ID: <200607031302.24914.rob@landley.net> On Sunday 02 July 2006 9:23 pm, Paul Fox wrote: > [ i guess what i find myself thinking is that the very next step > after something like this will be someone calling for a standard > format for comments... ] Ever since we adopted c99 I've used // for single line comments, but haven't converted existing comments unless I've been in the area. And I'm ok with this. Rob -- Never bet against the cheap plastic solution. From rpjday at mindspring.com Mon Jul 3 10:02:04 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 10:03:31 2006 Subject: any value in configuring minimum password length? In-Reply-To: <200607031258.28209.rob@landley.net> References: <200607022147.19261.farmatito@tiscali.it> <200607031258.28209.rob@landley.net> Message-ID: On Mon, 3 Jul 2006, Rob Landley wrote: > On Sunday 02 July 2006 3:47 pm, Tito wrote: > > - /* Add 1 for each type of characters to the minlen of password */ > > + /* Add 2 for each type of characters to the minlen of password */ > > int size = MINLEN + 8; > > Actually, changing the code to match the comment might be better. > > And if you're making MINLEN configurable, why aren't you making the > increment size be configurable? (Or the number of different types > of characters required before it increments the required length?) > What's the rationale for exposing one but not the other? > > You see why I didn't want to go there? but, luckily, you're going to overwrite all that stuff with your massive rewrite anyway, right? :-) rday From rpjday at mindspring.com Mon Jul 3 10:02:43 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 10:04:09 2006 Subject: any value in a standard for defining bit flags? In-Reply-To: <200607031301.12639.rob@landley.net> References: <200607031301.12639.rob@landley.net> Message-ID: On Mon, 3 Jul 2006, Rob Landley wrote: > On Sunday 02 July 2006 4:58 pm, Robert P. J. Day wrote: > > wouldn't it be easier to pick one and go with that? > > I see no benefit in this. As long as each applet is consistent within itself, > it doesn't have to be consistent from applet to applet. > > > and wouldn't it make more sense to use an enum rather than just a > > set of defines, anyway? > > Again, I don't see the benefit. (For one thing, an enum has to fit > in an int, and our getopt_ulflags() returns a long. ah, quite right. carry on. rday From dalias at aerifal.cx Mon Jul 3 10:27:01 2006 From: dalias at aerifal.cx (Rich Felker) Date: Mon Jul 3 10:15:16 2006 Subject: any reason to *not* support hex escapes? In-Reply-To: References: <20060702155723.GM21958@aon.at> Message-ID: <20060703172701.GI24607@brightrain.aerifal.cx> On Sun, Jul 02, 2006 at 12:34:00PM -0400, Robert P. J. Day wrote: > On Sun, 2 Jul 2006, Bernhard Fischer wrote: > > > On Sun, Jul 02, 2006 at 11:36:12AM -0400, Robert P. J. Day wrote: > > > > > >libbb/process_escape_sequence.c: > > >-------------------------------- > > > > > >#define WANT_HEX_ESCAPES 1 > > >... > > >#ifdef WANT_HEX_ESCAPES ... > > > > > >etc etc. > > > > > > any reason to not support this feature unconditionally? > > > > libbb/Config.in ? > > > > Not sure if these are worth exposing in the menu-thing. Leaving them > > in the file so one can hand-tweak if needed is about as good for me > > but admittedly limits the number of people who may turn it off if > > they know that they will not need it. > > but is there any obvious reason why someone would explicitly *not* > want that feature in the first place? Yes, so nonportable scripts will fail rather than silently working and thus can be found/fixed when GNU users add GNU crap to them. :) Rich From rpjday at mindspring.com Mon Jul 3 10:17:10 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 3 10:18:36 2006 Subject: any reason to *not* support hex escapes? In-Reply-To: <20060703172701.GI24607@brightrain.aerifal.cx> References: <20060702155723.GM21958@aon.at> <20060703172701.GI24607@brightrain.aerifal.cx> Message-ID: On Mon, 3 Jul 2006, Rich Felker wrote: > On Sun, Jul 02, 2006 at 12:34:00PM -0400, Robert P. J. Day wrote: > > On Sun, 2 Jul 2006, Bernhard Fischer wrote: > > > > > On Sun, Jul 02, 2006 at 11:36:12AM -0400, Robert P. J. Day wrote: > > > > > > > >libbb/process_escape_sequence.c: > > > >-------------------------------- > > > > > > > >#define WANT_HEX_ESCAPES 1 > > > >... > > > >#ifdef WANT_HEX_ESCAPES ... > > > > > > > >etc etc. > > > > > > > > any reason to not support this feature unconditionally? > > > > > > libbb/Config.in ? > > > > > > Not sure if these are worth exposing in the menu-thing. Leaving > > > them in the file so one can hand-tweak if needed is about as > > > good for me but admittedly limits the number of people who may > > > turn it off if they know that they will not need it. > > > > but is there any obvious reason why someone would explicitly *not* > > want that feature in the first place? > > Yes, so nonportable scripts will fail rather than silently working > and thus can be found/fixed when GNU users add GNU crap to them. :) in that case, based on earlier discussions on this list, it should be user-selectable, no? rday From rob at landley.net Mon Jul 3 10:20:57 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 10:20:45 2006 Subject: any value in a standard for defining bit flags? In-Reply-To: References: <2182.1151889832@brightstareng.com> Message-ID: <200607031320.57613.rob@landley.net> On Monday 03 July 2006 5:19 am, Robert P. J. Day wrote: > i *did* say i didn't feel like doing any real work. :-) i wouldn't > suggest *enforcing* any kind of standard like that, but maybe just a > list of recommended or suggested standards for an applet coding style? Ah, we get back to the coding style issue. Here's the busybox coding style I actually pay attention to: 1) We use tabs for indents. These tabs are 4 spaces. Deal with it. 2) We declare functions vaguely like this: void blah(thingy *blah) { stuff } We don't put the the return type the previous line (ctags exists, if you care learn to use it). Except for function declarations, the { is on the same line as things like if and for, and "} else" is also common. The exception is when you have something like an if statement or for loop that goes more than one line, then the { at the end of it should be on its own line. I tend to prefer if (blah) thingy(); to if (blah) thingy(); both of which I prefer to if (blah) { thingy(); } But I'll live with any of them as long as you're consistent. 3) Consistency is per file, not busybox wide. The purpose of making code look like the code around it is so you can _read_ it. (If you can't read multiple styles of C code, you won't get very far as a programmer.) We do some style cleanups, but not that much. (Yes, they do occasionally introduce bugs, and it can be a real pain to track unrelated changes past them.) 4) The screen is 80 characters wide. Deal with it. You can leak a little if you've got a good reason, but generally you should break lines at 80 chars when it's reasonably feasible to do so. (Hey, the linux kernel has 80 chars wide _and_ a tabstop of 8. We've got it easy in comparison.) 5) For no readily apparent reason, we have gratuitous spaces distinguishing tests and loops from functions, ala "if (blah)" and "for (blah)" vs "function(blah)". If you don't know your test and loop keywords you really shouldn't be banging on busybox, but enough people screamed that I just want to be consistent here. We also have gratuitous spaces all over the place like "x = y" and "blah(x, y);" (This was not my doing, but in the interests of consistency I've bowed to pressure on this one to the point where I'll actually clean existing code up to look like this. I want it to be consistent more than anything else.) 6) We use c99, including things like // comments and uint32_t. > p.s. the other reason i prefer a bit of a standard in this case is to > visually distinguish when someone is using, say, the value 1024 as > maybe a buffer size, or using it as a bit mask. if i see "1024", i > might conclude it's defining an array to hold a block. if, however, i > see "0x400", i'd more likely assume this was meant as a bit setting. > it might occasionally make it easier to spot typoes. but i'm not > going to lose any sleep over this. What we actually might want in that case is a naming convention for option flags then. Not a type of constant only used contextually. (Ok, I admit that if you see octal, it's probably permission flags, but that's only because nobody really uses octal for anything else. Except maybe literal character escapes. :) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jul 3 10:21:55 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 3 10:21:39 2006 Subject: e2fsprogs/blkid/version.c can be deleted? In-Reply-To: References: Message-ID: <200607031321.55808.rob@landley.net> On Monday 03 July 2006 5:53 am, Robert P. J. Day wrote: > it doesn't appear that that source file is part of the build process > anymore and, besides, it's identical to the code in > e2fsprogs/ext2fs/version.c anyway if it ever needs to be resurrected. > > rday Kill it. That whole directory (e2fsprogs) needs a massive crapectomy and consolidation. Rob -- Never bet against the cheap plastic solution. From farmatito at tiscali.it Mon Jul 3 12:57:40 2006 From: farmatito at tiscali.it (Tito) Date: Mon Jul 3 12:58:08 2006 Subject: any value in configuring minimum password length? In-Reply-To: <200607031258.28209.rob@landley.net> References: <200607022147.19261.farmatito@tiscali.it> <200607031258.28209.rob@landley.net> Message-ID: <200607032157.41155.farmatito@tiscali.it> On Monday 3 July 2006 18:58, Rob Landley wrote: > On Sunday 02 July 2006 3:47 pm, Tito wrote: > > - /* Add 1 for each type of characters to the minlen of password */ > > + /* Add 2 for each type of characters to the minlen of password */ > > int size = MINLEN + 8; > > Actually, changing the code to match the comment might be better. The code matched the comment in the beginning, You changed it when you committed the patch without fixing the comment. So, what you want to do here: int size = MINLEN + 4; or int size = MINLEN + 8; > And if you're making MINLEN configurable, why aren't you making the increment > size be configurable? (Or the number of different types of characters > required before it increments the required length?) What's the rationale for > exposing one but not the other? Maybe it is best to not expose them at all. MINLEN was intended just for the programmer so that if this value would ever be changed to another standard fixing the code would have been easier. Ciao, Tito > You see why I didn't want to go there? > > Rob From rep.nop at aon.at Tue Jul 4 01:02:02 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jul 4 01:02:24 2006 Subject: procps In-Reply-To: <200606061143.03173.rob@landley.net> References: <200605301255.38248.rob@landley.net> <200606052233.02771.rob@landley.net> <20060606074758.GB3015@aon.at> <200606061143.03173.rob@landley.net> Message-ID: <20060704080202.GA25250@aon.at> On Tue, Jun 06, 2006 at 11:43:02AM -0400, Rob Landley wrote: >On Tuesday 06 June 2006 3:47 am, Bernhard Fischer wrote: >> Speaking of procps.. >> top (which is a memory-hog) displays as "exe". Anyone looked into this >> already or do we just not care? > >I have some pending patches for top (massaged versions of Dennis Vlasenko's >work, I think) that have been languishing in a subdirectory for a bit. I'm >pondering going over top with a shovel and doing largeish changes, but not >before 1.2.0. Rob, what's the status of this? From rep.nop at aon.at Tue Jul 4 01:27:54 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jul 4 01:28:00 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200607011345.32354.rob@landley.net> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606091126.43394.rob@landley.net> <7f45d9390606301519n54768df5nbeae4b5856f713e5@mail.gmail.com> <200607011345.32354.rob@landley.net> Message-ID: <20060704082753.GA25726@aon.at> On Sat, Jul 01, 2006 at 01:45:32PM -0400, Rob Landley wrote: >On Friday 30 June 2006 6:19 pm, Shaun Jackman wrote: >> On 6/9/06, Rob Landley wrote: >> > On Thursday 08 June 2006 6:22 pm, Shaun Jackman wrote: >> > > On 6/8/06, Shaun Jackman wrote: >> > > > I agree. I'd also like to see CROSS_COMPILER_PREFIX renamed to >> > > > CROSS_COMPILE, as Linux names it. It makes sense to do it at the same >> > > > time it's remove from .config. >> > > >> > > I just noticed that although the config option was named >> > > CROSS_COMPILER_PREFIX, the make variable was named CROSS. So, do the >> > > maintainers prefer to keep the make variable named CROSS, or switch to >> > > the Linux name, CROSS_COMPILE? I can see benefits to both, but we >> > > should pick one definitively. >> > >> > Go with CROSS_COMPILE. You only have to build three things for a minimal >> > embedded system: the Linux Kernel, uClibc, and BusyBox. It would be nice >> > if they all worked roughly the same way... >> >> As discussed above. Please apply. >> >> Cheers, >> Shaun >> >> 2006-06-30 Shaun Jackman >> >> * (CROSS) Rename to CROSS_COMPILE and move its configuration to >> .config.mak. > >This patch doesn't seem current. It is current and applied cleanly. done. From mchitale at gmail.com Tue Jul 4 02:06:54 2006 From: mchitale at gmail.com (Mayuresh Chitale) Date: Tue Jul 4 02:13:23 2006 Subject: debugs not printed in application started from rcs script. Message-ID: Hi All, I am trying to start an application in the background in rcs script. This application has some debug printfs which should get printed when the application starts. Instead I see only a few printfs at the start and then suddenly they stop appearing. But the process seems to be starting. If I redirect the output to a file I see all the debug messages as expected. I tried with latest version 1.2.0 but same thing happens. If I start the same application in background from command line everything works fine ie I see all the debug prints. I can not see all the debug prints only if I start the application in background through the startup script. Any suggestion is welcome. Thanks, Mayuresh. From sjackman at gmail.com Tue Jul 4 16:13:30 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Tue Jul 4 16:20:51 2006 Subject: Building additional binaries Message-ID: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> I had been using the following patch to build a bFLT binary in the top-level Makefile. This configuration should be accomplished in the .config.mak file in the output directory. Unfortunately, it's not as simple as adding `all: busybox.bflt' to .config.mak, because .config.mak is included from Rules.mak and by every Makefile, not just the top-level. So, I added `busybox: busybox.bflt' to .config.mak, which is a bit of a hack, but works. In any case, I thought I'd poll the mailing list for a better solution. Perhaps the `all' target of the top-level Makefile should depend on a phony `all-extra' target that could be defined by .config.mak. Cheers, Shaun --- Makefile 4f6d75d68f1f127442ffa6c934395b5742523e2b +++ Makefile 04f799f965031624109a130c6a94d83fffd1fd8c @@ -251,7 +251,7 @@ else # ifneq ($(strip $(HAVE_DOT_CONFIG)),y) -all: busybox busybox.links doc +all: busybox busybox.bflt busybox.links doc # In this section, we need .config -include $(top_builddir)/.config.cmd From rob at landley.net Tue Jul 4 21:23:49 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 4 21:23:37 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: References: Message-ID: <200607050023.49771.rob@landley.net> On Monday 03 July 2006 7:53 am, Robert P. J. Day wrote: > in my travels through the source code, i wandered across the fact > that a number of header file inclusions under e2fsprogs use relative > pathnames: > > e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h" > e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h" > e2fsprogs/blkid/read.c:#include "../uuid/uuid.h" > e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h" > e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h" That entire directory is a gigantic mess that needs a crapectomy desperately. It already doesn't build on Red Hat 9, and it only builds anywhere else by accident. > ... > # XXX: FIXME: change .c to include their stuff relative to $(E2FSPROGS_SRC) > E2FSPROGS_TMP_KLUDGE:=$(patsubst %,-I$(E2FSPROGS_SRC)/%,blkid e2fsck e2p > ext2fs uuid) Yeah, that about sums it up. Rob > thoughts? "steaming pile" comes to mind... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 4 21:26:16 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 4 21:25:58 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: <200607030852.41067.vapier@gentoo.org> References: <200607030852.41067.vapier@gentoo.org> Message-ID: <200607050026.17069.rob@landley.net> On Monday 03 July 2006 8:52 am, Mike Frysinger wrote: > side, using paths such as these: > > #include "ext2fs/ext2_types.h" > > #include "ext2fs/ext2_fs.h" > > is no good as they may pick up the standard e2fsprogs header files > in /usr/include/ and it'd be a while before people noticed (or we'd get to > chase down funky build errors) A) Either the standard #include files should work, or we shouldn't be using those names. B) The point of #include "" instead of #include <> is that it searches local directories first. This was in C89 let alone C99. Are you saying the build for this directory is so screwed up that doesn't work reliably? > -mike Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 4 21:27:22 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 4 21:27:05 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: References: <200607030852.41067.vapier@gentoo.org> Message-ID: <200607050027.23009.rob@landley.net> On Monday 03 July 2006 9:05 am, Robert P. J. Day wrote: > On Mon, 3 Jul 2006, Mike Frysinger wrote: > > On Monday 03 July 2006 07:53, Robert P. J. Day wrote: > > > in my travels through the source code, i wandered across the > > > fact that a number of header file inclusions under e2fsprogs use > > > relative pathnames: > > > > > > e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h" > > > e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h" > > > e2fsprogs/blkid/read.c:#include "../uuid/uuid.h" > > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h" > > > e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h" > > > > this was done on purpose ... since the build system tends to be on > > the fragile side, using paths such as these: > > not to belabour this point, but it would seem to me that hard-coding > filenames which might break if anything is moved around is actually > more "fragile" than just defining the appropriate preprocessor > directives to handle this situation in general, no? Yes. This directory is CRAP, it was only put in on the assumption somebody would clean it up, and I've been on the verge of removing it for a while. > rday Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 4 21:27:56 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 4 21:27:39 2006 Subject: is there any value to udhcp/frontend.c? In-Reply-To: References: Message-ID: <200607050027.56827.rob@landley.net> On Monday 03 July 2006 9:01 am, Robert P. J. Day wrote: > it doesn't appear to be required by any variation of the build. Zap it. As you can see, there is much to clean up in the tree. :) > rday Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 4 21:30:01 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 4 21:29:43 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> Message-ID: <200607050030.01851.rob@landley.net> On Tuesday 04 July 2006 7:13 pm, Shaun Jackman wrote: > I had been using the following patch to build a bFLT binary in the > top-level Makefile. This configuration should be accomplished in the > .config.mak file in the output directory. Unfortunately, it's not as > simple as adding `all: busybox.bflt' to .config.mak, because > .config.mak is included from Rules.mak and by every Makefile, not just > the top-level. So, I added `busybox: busybox.bflt' to .config.mak, > which is a bit of a hack, but works. In any case, I thought I'd poll > the mailing list for a better solution. Perhaps the `all' target of > the top-level Makefile should depend on a phony `all-extra' target > that could be defined by .config.mak. What are you trying to accomplish? You're not adding another applet to busybox, you're building an external binary with strange dependencies on busybox internals? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 4 21:30:01 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 4 21:29:56 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> Message-ID: <200607050030.01851.rob@landley.net> On Tuesday 04 July 2006 7:13 pm, Shaun Jackman wrote: > I had been using the following patch to build a bFLT binary in the > top-level Makefile. This configuration should be accomplished in the > .config.mak file in the output directory. Unfortunately, it's not as > simple as adding `all: busybox.bflt' to .config.mak, because > .config.mak is included from Rules.mak and by every Makefile, not just > the top-level. So, I added `busybox: busybox.bflt' to .config.mak, > which is a bit of a hack, but works. In any case, I thought I'd poll > the mailing list for a better solution. Perhaps the `all' target of > the top-level Makefile should depend on a phony `all-extra' target > that could be defined by .config.mak. What are you trying to accomplish? You're not adding another applet to busybox, you're building an external binary with strange dependencies on busybox internals? Rob -- Never bet against the cheap plastic solution. From vapier at gentoo.org Tue Jul 4 21:32:54 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Jul 4 21:32:53 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: <200607050026.17069.rob@landley.net> References: <200607030852.41067.vapier@gentoo.org> <200607050026.17069.rob@landley.net> Message-ID: <200607050032.55154.vapier@gentoo.org> On Wednesday 05 July 2006 00:26, Rob Landley wrote: > On Monday 03 July 2006 8:52 am, Mike Frysinger wrote: > > side, using paths such as these: > > > #include "ext2fs/ext2_types.h" > > > #include "ext2fs/ext2_fs.h" > > > > is no good as they may pick up the standard e2fsprogs header files > > in /usr/include/ and it'd be a while before people noticed (or we'd get > > to chase down funky build errors) > > A) Either the standard #include files should work, or we shouldn't be using > those names. the standard includes might work if they're from the same version, but we cant really rely on that > B) The point of #include "" instead of #include <> is that it searches > local directories first. This was in C89 let alone C99. Are you saying > the build for this directory is so screwed up that doesn't work reliably? do you really need me to copy and past the e-mails ive already sent ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/acbb0b5e/attachment.pgp From floydpink at gmail.com Tue Jul 4 21:51:41 2006 From: floydpink at gmail.com (Jason Schoon) Date: Tue Jul 4 21:51:50 2006 Subject: Building additional binaries In-Reply-To: <200607050030.01851.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> Message-ID: <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> On 7/4/06, Rob Landley wrote: > > On Tuesday 04 July 2006 7:13 pm, Shaun Jackman wrote: > > I had been using the following patch to build a bFLT binary in the > > top-level Makefile. This configuration should be accomplished in the > > .config.mak file in the output directory. Unfortunately, it's not as > > simple as adding `all: busybox.bflt' to .config.mak, because > > .config.mak is included from Rules.mak and by every Makefile, not just > > the top-level. So, I added `busybox: busybox.bflt' to .config.mak, > > which is a bit of a hack, but works. In any case, I thought I'd poll > > the mailing list for a better solution. Perhaps the `all' target of > > the top-level Makefile should depend on a phony `all-extra' target > > that could be defined by .config.mak. > > What are you trying to accomplish? You're not adding another applet to > busybox, you're building an external binary with strange dependencies on > busybox internals? He is building in bFLT format (uClinux binary flat format) rather than ELF. Seems like a worthwhile and hopefully not insurmountable task. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060704/7ceccf9a/attachment.htm From floydpink at gmail.com Tue Jul 4 21:51:41 2006 From: floydpink at gmail.com (Jason Schoon) Date: Tue Jul 4 21:57:58 2006 Subject: Building additional binaries In-Reply-To: <200607050030.01851.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> Message-ID: <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> On 7/4/06, Rob Landley wrote: > > On Tuesday 04 July 2006 7:13 pm, Shaun Jackman wrote: > > I had been using the following patch to build a bFLT binary in the > > top-level Makefile. This configuration should be accomplished in the > > .config.mak file in the output directory. Unfortunately, it's not as > > simple as adding `all: busybox.bflt' to .config.mak, because > > .config.mak is included from Rules.mak and by every Makefile, not just > > the top-level. So, I added `busybox: busybox.bflt' to .config.mak, > > which is a bit of a hack, but works. In any case, I thought I'd poll > > the mailing list for a better solution. Perhaps the `all' target of > > the top-level Makefile should depend on a phony `all-extra' target > > that could be defined by .config.mak. > > What are you trying to accomplish? You're not adding another applet to > busybox, you're building an external binary with strange dependencies on > busybox internals? He is building in bFLT format (uClinux binary flat format) rather than ELF. Seems like a worthwhile and hopefully not insurmountable task. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060704/7ceccf9a/attachment-0001.html From vapier at gentoo.org Tue Jul 4 23:40:18 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Jul 4 23:40:22 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> Message-ID: <200607050240.19180.vapier@gentoo.org> On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > He is building in bFLT format (uClinux binary flat format) rather than ELF. > Seems like a worthwhile and hopefully not insurmountable task. it's already integrated into the build system, Shaun just wants to let the user add it to the default build list -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/07a4c507/attachment.pgp From vapier at gentoo.org Tue Jul 4 23:40:18 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Jul 4 23:40:25 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> Message-ID: <200607050240.19180.vapier@gentoo.org> On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > He is building in bFLT format (uClinux binary flat format) rather than ELF. > Seems like a worthwhile and hopefully not insurmountable task. it's already integrated into the build system, Shaun just wants to let the user add it to the default build list -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/07a4c507/attachment-0001.pgp From dalias at aerifal.cx Wed Jul 5 01:03:20 2006 From: dalias at aerifal.cx (Rich Felker) Date: Wed Jul 5 00:51:12 2006 Subject: [PATCH] major performance improvement for get_line_from_file.c Message-ID: <20060705080320.GA1917@brightrain.aerifal.cx> the attached patch greatly improves performance by using fgets rather than individual getc calls in get_line_from_file.c, which is used by most utilities that process text files. it can easily be modified (see the commented lines) to use the also-attached function for handling embedded nul bytes, but as this is slower, larger, and most/all of the calling applets would not support it anyway, i doubt it's useful at this time, but i'm sending it to the list for future reference anyway. oh, one other thing included in this patch: it modifies bb_get_chunk_from_file to use size_t rather than int for the size of the string read. imo using int here is dangerous and could lead to unexpected behavior on platforms with 64bit size_t but 32bit int and maliciously-crafted input files. rich p.s. also apologies that the diff is not minimal-size. i got confused trying to translate the logic from gets to fgets so i just rewrote the function from scratch. -------------- next part -------------- Index: libbb/get_line_from_file.c =================================================================== --- libbb/get_line_from_file.c (revision 15108) +++ libbb/get_line_from_file.c (working copy) @@ -11,6 +11,7 @@ #include #include +#include #include "libbb.h" /* get_line_from_file() - This function reads an entire line from a text file, @@ -18,43 +19,43 @@ * stored and free'ed by the caller. If end is null '\n' isn't considered * and of line. If end isn't null, length of the chunk read is stored in it. */ -char *bb_get_chunk_from_file(FILE *file, int *end) +char *bb_get_chunk_from_file(FILE *f, size_t *n) { - int ch; - int idx = 0; - char *linebuf = NULL; - int linebufsz = 0; + size_t len = 0, size = 127, l; + char *buf = xmalloc(size); - while ((ch = getc(file)) != EOF) { - /* grow the line buffer as necessary */ - if (idx > linebufsz - 2) { - linebuf = xrealloc(linebuf, linebufsz += 80); - } - linebuf[idx++] = (char)ch; - if (!ch || (end && ch == '\n')) break; + for (;;) { + //if (!(l = fgets_nul(buf+len, size-len, f))) break; + if (!fgets(buf+len, size-len, f) || !(l = strlen(buf+len))) break; + if (l < size-len-1 || (n && buf[size-2] == '\n')) { + len += l; + break; + } else len = size - 1; + // safe: SIZE_MAX allocation will fail before overflow + size = 2*size+1; + buf = xrealloc(buf, size); } - if (end) *end = idx; - if (linebuf) { - if (ferror(file)) { - free(linebuf); - return NULL; - } - linebuf[idx] = 0; + + if (n) *n = len; + if (!len || ferror(f)) { + free(buf); + return NULL; } - return linebuf; + + return buf; // slower: xrealloc(buf, len+1); } /* Get line, including trailing /n if any */ char *bb_get_line_from_file(FILE *file) { - int i; + size_t i; return bb_get_chunk_from_file(file, &i); } /* Get line. Remove trailing /n */ char *bb_get_chomped_line_from_file(FILE *file) { - int i; + size_t i; char *c=bb_get_chunk_from_file(file, &i); if(i) c[--i]=0; Index: include/libbb.h =================================================================== --- include/libbb.h (revision 15108) +++ include/libbb.h (working copy) @@ -130,7 +130,7 @@ extern char *find_block_device(char *path); extern char *bb_get_line_from_file(FILE *file); extern char *bb_get_chomped_line_from_file(FILE *file); -extern char *bb_get_chunk_from_file(FILE *file, int *end); +extern char *bb_get_chunk_from_file(FILE *file, size_t *end); extern int bb_copyfd_size(int fd1, int fd2, const off_t size); extern int bb_copyfd_eof(int fd1, int fd2); extern void bb_xprint_and_close_file(FILE *file); -------------- next part -------------- #include #include /* This function implements a version of fgets than can handle embedded nul * bytes on top of the existing stdio fgets function, with reasonable * performance, assuming the string operations memset/memchr are a good bit * faster than loops full of conditionals (like a getc loop). * * The only case in which performance may be significantly slower than * fgets is when the supplied buffer is significantly oversized. This issue * could be worked around by working in smaller fgets-chunks and only * filling the "current chunk" with newline bytes. * * GNU users may want to just use getline(). However this code demonstrates * that equivalent functionality may be built on top of the standard C * library with minimal impact to performance. * * - Rich Felker, July 2006 */ size_t fgets_nul(char *s, size_t n, FILE *f) { char *p; /* Newline is the (only) safe inband signal character because fgets * will never write a newline except when it has finished reading. */ memset(s, '\n', n); /* If fgets fails completely, nothing to do. */ if (!fgets(s, n, f)) return 0; /* We have two cases here. Either... */ if ((p = memchr(s, '\n', n))) { /* ...a null byte follows the newline, in which case the * newline must actually have been read from the stream... */ if (p < s+n-1 && !p[1]) return p-s+1; /* ...or else the newline is one of the sentinels we wrote * with memset, in which case the read must have ended * prematurely with eof and the location of this sentinel * newline byte tells us how many bytes were read. */ return p-s-1; } /* If the buffer contains no newline bytes, then fgets must have used * all available (n-1) bytes. */ return n-1; } From floydpink at gmail.com Wed Jul 5 07:37:52 2006 From: floydpink at gmail.com (Jason Schoon) Date: Wed Jul 5 07:37:56 2006 Subject: Building additional binaries In-Reply-To: <200607050240.19180.vapier@gentoo.org> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> Message-ID: <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> On 7/5/06, Mike Frysinger wrote: > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > He is building in bFLT format (uClinux binary flat format) rather than ELF. > > Seems like a worthwhile and hopefully not insurmountable task. > > it's already integrated into the build system, Shaun just wants to let the > user add it to the default build list > -mike Seems (to me) like we should do something similar to the Linux kernel. They still have those options to choose whether you want support for a.out, ELF, etc. From floydpink at gmail.com Wed Jul 5 07:37:52 2006 From: floydpink at gmail.com (Jason Schoon) Date: Wed Jul 5 07:38:02 2006 Subject: Building additional binaries In-Reply-To: <200607050240.19180.vapier@gentoo.org> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> Message-ID: <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> On 7/5/06, Mike Frysinger wrote: > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > He is building in bFLT format (uClinux binary flat format) rather than ELF. > > Seems like a worthwhile and hopefully not insurmountable task. > > it's already integrated into the build system, Shaun just wants to let the > user add it to the default build list > -mike Seems (to me) like we should do something similar to the Linux kernel. They still have those options to choose whether you want support for a.out, ELF, etc. From jw5 at os.inf.tu-dresden.de Wed Jul 5 07:47:49 2006 From: jw5 at os.inf.tu-dresden.de (Jean Wolter) Date: Wed Jul 5 07:47:54 2006 Subject: ash - problem/bug with redirection and internal command In-Reply-To: <86ejz84sw4.fsf@erwin.inf.tu-dresden.de> (Jean Wolter's message of "Fri, 05 May 2006 13:23:39 +0200") References: <86ejz84sw4.fsf@erwin.inf.tu-dresden.de> Message-ID: <86r710hzvu.fsf@erwin.inf.tu-dresden.de> Jean Wolter writes: > the following sequence behaves not as expected: > > # write some file on sysfs > echo "+bond0" > /sys/class/net/bonding_masters > while true; do > echo "this statement is supposed to be executed endlessly" > done > > After this "true" and every other builtin command return false. The > following diff points to the source of the problem: This problem is still unsolved, could someone pick up this patch or the suggestion of the original ash maintainer (who essentially simply adds an unconditional clearerr(stdout))? regards, Jean From sjackman at gmail.com Wed Jul 5 08:20:42 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Wed Jul 5 08:20:47 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> Message-ID: <7f45d9390607050820i653f5458k2d1049781b0ee26b@mail.gmail.com> On 7/5/06, Jason Schoon wrote: > Seems (to me) like we should do something similar to the Linux kernel. > They still have those options to choose whether you want support for > a.out, ELF, etc. The trend in Busybox has been to relegate configure options related to the build system into .config.mak, out of the make config system. Adding `all: busybox' to .config.mak works when building from the top-level directory, but breaks running make in other subdirectories. The top-level Makefile declares _all to be the default target before it includes .config.mak, but the subdirectories do not do this. So, adding an `all: busybox' to config.mak causes all -- instead of libbb.a, for example -- to become the default target for the subdirectories. Cheers, Shaun From sjackman at gmail.com Wed Jul 5 08:20:42 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Wed Jul 5 08:22:29 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> Message-ID: <7f45d9390607050820i653f5458k2d1049781b0ee26b@mail.gmail.com> On 7/5/06, Jason Schoon wrote: > Seems (to me) like we should do something similar to the Linux kernel. > They still have those options to choose whether you want support for > a.out, ELF, etc. The trend in Busybox has been to relegate configure options related to the build system into .config.mak, out of the make config system. Adding `all: busybox' to .config.mak works when building from the top-level directory, but breaks running make in other subdirectories. The top-level Makefile declares _all to be the default target before it includes .config.mak, but the subdirectories do not do this. So, adding an `all: busybox' to config.mak causes all -- instead of libbb.a, for example -- to become the default target for the subdirectories. Cheers, Shaun From pgf at brightstareng.com Wed Jul 5 08:47:56 2006 From: pgf at brightstareng.com (Paul Fox) Date: Wed Jul 5 08:48:16 2006 Subject: ash - problem/bug with redirection and internal command In-Reply-To: jw5's message of Wed, 05 Jul 2006 16:47:49 +0200. <86r710hzvu.fsf@erwin.inf.tu-dresden.de> Message-ID: <32547.1152114476@brightstareng.com> > Jean Wolter writes: > > > the following sequence behaves not as expected: > > > > # write some file on sysfs > > echo "+bond0" > /sys/class/net/bonding_masters > > while true; do > > echo "this statement is supposed to be executed endlessly" > > done > > > > After this "true" and every other builtin command return false. The > > following diff points to the source of the problem: > > This problem is still unsolved, could someone pick up this patch or > the suggestion of the original ash maintainer (who essentially simply > adds an unconditional clearerr(stdout))? i'm guessing this problem was introduced when it became possible to build echo directly into ash, is that right? if it were a separate process, clearly the two stdout operations would be independent. if that's the case, then i agree that simply clearing the error is probably the right thing to do. this is vodz's change, referred to above: --- busybox/svn/shell/ash.c 2006-06-15 22:19:41.000000000 -0400 +++ vodz/shell/ash.c 2006-05-05 09:33:54.000000000 -0400 @@ -3473,6 +3459,7 @@ flushall(); cmddone: exitstatus |= ferror(stdout); + clearerr(stdout); commandname = savecmdname; exsig = 0; handler = savehandler; paul =--------------------- paul fox, pgf@brightstareng.com From vda.linux at googlemail.com Wed Jul 5 09:27:42 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Wed Jul 5 09:27:57 2006 Subject: [PATCH] documentation fixes and small addition Message-ID: <200607051827.42264.vda.linux@googlemail.com> Hi, Patch fixes typos in style-guide.txt and adds recommendation to use enums for defining int constants. Please apply. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: doc.patch Type: text/x-diff Size: 1633 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/16b8072a/doc.bin From rob at landley.net Wed Jul 5 08:26:25 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 09:31:25 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> Message-ID: <200607051126.25412.rob@landley.net> On Wednesday 05 July 2006 12:51 am, Jason Schoon wrote: > On 7/4/06, Rob Landley wrote: > > On Tuesday 04 July 2006 7:13 pm, Shaun Jackman wrote: > > > I had been using the following patch to build a bFLT binary in the > > > top-level Makefile. This configuration should be accomplished in the > > > .config.mak file in the output directory. Unfortunately, it's not as > > > simple as adding `all: busybox.bflt' to .config.mak, because > > > .config.mak is included from Rules.mak and by every Makefile, not just > > > the top-level. So, I added `busybox: busybox.bflt' to .config.mak, > > > which is a bit of a hack, but works. In any case, I thought I'd poll > > > the mailing list for a better solution. Perhaps the `all' target of > > > the top-level Makefile should depend on a phony `all-extra' target > > > that could be defined by .config.mak. > > > > What are you trying to accomplish? You're not adding another applet to > > busybox, you're building an external binary with strange dependencies on > > busybox internals? > > He is building in bFLT format (uClinux binary flat format) rather than ELF. > Seems like a worthwhile and hopefully not insurmountable task. Ah! I remember the earlier discussion on this now. Yes, that's a worthwhile goal. What are its dependencies? (I'm pretty sure I don't have the bflt tools on my system.) Possibly a "make busybox-flat" target or some such? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 08:24:36 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 09:31:30 2006 Subject: strangeness involving e2fsprogs header files In-Reply-To: <200607050032.55154.vapier@gentoo.org> References: <200607050026.17069.rob@landley.net> <200607050032.55154.vapier@gentoo.org> Message-ID: <200607051124.37009.rob@landley.net> On Wednesday 05 July 2006 12:32 am, Mike Frysinger wrote: > > A) Either the standard #include files should work, or we shouldn't be > > using those names. > > the standard includes might work if they're from the same version, but we > cant really rely on that All we should need are the on-disk structures. > > B) The point of #include "" instead of #include <> is that it searches > > local directories first. This was in C89 let alone C99. Are you saying > > the build for this directory is so screwed up that doesn't work reliably? > > do you really need me to copy and past the e-mails ive already sent ? No, I just need to yank this code. > -mike Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 08:27:20 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 09:31:42 2006 Subject: Building additional binaries In-Reply-To: <200607050240.19180.vapier@gentoo.org> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> Message-ID: <200607051127.21313.rob@landley.net> On Wednesday 05 July 2006 2:40 am, Mike Frysinger wrote: > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > He is building in bFLT format (uClinux binary flat format) rather than > > ELF. Seems like a worthwhile and hopefully not insurmountable task. > > it's already integrated into the build system, Shaun just wants to let the > user add it to the default build list Sigh. For 1.4 or so I'm definitely creating my own git repository. > -mike Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 08:26:25 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 09:31:45 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050030.01851.rob@landley.net> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> Message-ID: <200607051126.25412.rob@landley.net> On Wednesday 05 July 2006 12:51 am, Jason Schoon wrote: > On 7/4/06, Rob Landley wrote: > > On Tuesday 04 July 2006 7:13 pm, Shaun Jackman wrote: > > > I had been using the following patch to build a bFLT binary in the > > > top-level Makefile. This configuration should be accomplished in the > > > .config.mak file in the output directory. Unfortunately, it's not as > > > simple as adding `all: busybox.bflt' to .config.mak, because > > > .config.mak is included from Rules.mak and by every Makefile, not just > > > the top-level. So, I added `busybox: busybox.bflt' to .config.mak, > > > which is a bit of a hack, but works. In any case, I thought I'd poll > > > the mailing list for a better solution. Perhaps the `all' target of > > > the top-level Makefile should depend on a phony `all-extra' target > > > that could be defined by .config.mak. > > > > What are you trying to accomplish? You're not adding another applet to > > busybox, you're building an external binary with strange dependencies on > > busybox internals? > > He is building in bFLT format (uClinux binary flat format) rather than ELF. > Seems like a worthwhile and hopefully not insurmountable task. Ah! I remember the earlier discussion on this now. Yes, that's a worthwhile goal. What are its dependencies? (I'm pretty sure I don't have the bflt tools on my system.) Possibly a "make busybox-flat" target or some such? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 08:27:20 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 09:31:48 2006 Subject: Building additional binaries In-Reply-To: <200607050240.19180.vapier@gentoo.org> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> Message-ID: <200607051127.21313.rob@landley.net> On Wednesday 05 July 2006 2:40 am, Mike Frysinger wrote: > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > He is building in bFLT format (uClinux binary flat format) rather than > > ELF. Seems like a worthwhile and hopefully not insurmountable task. > > it's already integrated into the build system, Shaun just wants to let the > user add it to the default build list Sigh. For 1.4 or so I'm definitely creating my own git repository. > -mike Rob -- Never bet against the cheap plastic solution. From vda.linux at googlemail.com Wed Jul 5 09:31:56 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Wed Jul 5 09:32:10 2006 Subject: [PATCH] new applet: nmeter Message-ID: <200607051831.57030.vda.linux@googlemail.com> Hi, The patch adds the following applet: # ./busybox nmeter BusyBox v1.2.0 (2006.07.04-21:29+0000) multi-call binary Usage: nmeter format_string Nmeter monitors your system in real time. Format specifiers: %Nc or %[cN] monitor CPU. N - bar size, default 10 (displays: S:system U:user N:niced D:iowait I:irq i:softirq) %[niface] monitor network interface 'iface' %m monitor allocated memory %[mf] monitor free memory %[mt] monitor total memory %s monitor allocated swap %f monitor number of used file descriptors %Ni monitor total/specific IRQ rate %x monitor context switch rate %p monitor forks %[pn] monitor # of processes %b monitor block io %Nt show time (with N decimal points) %Nd milliseconds between updates (default=1000) %r print instead of at EOL Size of the applet (make objsizes): text+data text+rodata rwdata bss filename 5090 4954 136 4104 miscutils/nmeter.o Run tested. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: nmeter.patch Type: text/x-diff Size: 23763 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/10ff394c/nmeter-0001.bin From won_fang at yahoo.com.au Wed Jul 5 09:57:39 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Wed Jul 5 09:58:06 2006 Subject: Duplicated messages? Message-ID: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> Is it just me, or is everybody else getting duplicated messages in this list? -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/f1da1c77/signature.pgp From vapier at gentoo.org Wed Jul 5 10:04:37 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jul 5 10:04:39 2006 Subject: Building additional binaries In-Reply-To: <200607051127.21313.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> <200607051127.21313.rob@landley.net> Message-ID: <200607051304.37600.vapier@gentoo.org> On Wednesday 05 July 2006 11:27, Rob Landley wrote: > On Wednesday 05 July 2006 2:40 am, Mike Frysinger wrote: > > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > > He is building in bFLT format (uClinux binary flat format) rather than > > > ELF. Seems like a worthwhile and hopefully not insurmountable task. > > > > it's already integrated into the build system, Shaun just wants to let > > the user add it to the default build list > > Sigh. For 1.4 or so I'm definitely creating my own git repository. that statement doesnt make any sense considering the context -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/0b38dda9/attachment.pgp From rob at landley.net Wed Jul 5 10:05:29 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 10:05:18 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> Message-ID: <200607051305.29923.rob@landley.net> On Wednesday 05 July 2006 10:37 am, Jason Schoon wrote: > On 7/5/06, Mike Frysinger wrote: > > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > > He is building in bFLT format (uClinux binary flat format) rather than > > > ELF. Seems like a worthwhile and hopefully not insurmountable task. > > > > it's already integrated into the build system, Shaun just wants to let > > the user add it to the default build list > > -mike > > Seems (to me) like we should do something similar to the Linux kernel. > They still have those options to choose whether you want support for > a.out, ELF, etc. That's what executable formats they support, not what kernel type is generated. Specifying the kernel type you want is done via the make command line. (You always get an elf kernel, vmlinux in the top level directory, and some systems actually boot that directly. The others are generated from vmlinux.) Rob -- Never bet against the cheap plastic solution. From vapier at gentoo.org Wed Jul 5 10:07:01 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jul 5 10:06:57 2006 Subject: Building additional binaries In-Reply-To: <200607051126.25412.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <78a54e1b0607042151h88bde91hedb767a1bf6d886a@mail.gmail.com> <200607051126.25412.rob@landley.net> Message-ID: <200607051307.01560.vapier@gentoo.org> On Wednesday 05 July 2006 11:26, Rob Landley wrote: > On Wednesday 05 July 2006 12:51 am, Jason Schoon wrote: > > He is building in bFLT format (uClinux binary flat format) rather than > > ELF. Seems like a worthwhile and hopefully not insurmountable task. > > Ah! I remember the earlier discussion on this now. > > Yes, that's a worthwhile goal. What are its dependencies? (I'm pretty > sure I don't have the bflt tools on my system.) > > Possibly a "make busybox-flat" target or some such? like i said, this is already in busybox: make busybox.bflt you're missing the point of the thread -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/cea790ef/attachment.pgp From vapier at gentoo.org Wed Jul 5 10:07:31 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jul 5 10:07:29 2006 Subject: Duplicated messages? In-Reply-To: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> References: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> Message-ID: <200607051307.32305.vapier@gentoo.org> On Wednesday 05 July 2006 12:57, David Seikel wrote: > Is it just me, or is everybody else getting duplicated messages in this > list? i'm not seeing any ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/b024cac2/attachment.pgp From rep.nop at aon.at Wed Jul 5 10:15:45 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jul 5 10:15:50 2006 Subject: Duplicated messages? In-Reply-To: <200607051307.32305.vapier@gentoo.org> References: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> <200607051307.32305.vapier@gentoo.org> Message-ID: <20060705171545.GB1102@aon.at> On Wed, Jul 05, 2006 at 01:07:31PM -0400, Mike Frysinger wrote: >On Wednesday 05 July 2006 12:57, David Seikel wrote: >> Is it just me, or is everybody else getting duplicated messages in this >> list? > >i'm not seeing any ... Some people post to both the correct addr and the old @mail, this results in duplicate messages. CC'd wrong/old addr for reference.. From rep.nop at aon.at Wed Jul 5 10:15:45 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jul 5 10:22:33 2006 Subject: Duplicated messages? In-Reply-To: <200607051307.32305.vapier@gentoo.org> References: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> <200607051307.32305.vapier@gentoo.org> Message-ID: <20060705171545.GB1102@aon.at> On Wed, Jul 05, 2006 at 01:07:31PM -0400, Mike Frysinger wrote: >On Wednesday 05 July 2006 12:57, David Seikel wrote: >> Is it just me, or is everybody else getting duplicated messages in this >> list? > >i'm not seeing any ... Some people post to both the correct addr and the old @mail, this results in duplicate messages. CC'd wrong/old addr for reference.. From won_fang at yahoo.com.au Wed Jul 5 10:26:23 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Wed Jul 5 10:27:25 2006 Subject: Duplicated messages? In-Reply-To: <20060705171545.GB1102@aon.at> References: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> <200607051307.32305.vapier@gentoo.org> <20060705171545.GB1102@aon.at> Message-ID: <20060706032623.0d3368c4@cluster.meeting.humbug.org.au> On Wed, 5 Jul 2006 19:15:45 +0200 Bernhard Fischer wrote: > On Wed, Jul 05, 2006 at 01:07:31PM -0400, Mike Frysinger wrote: > >On Wednesday 05 July 2006 12:57, David Seikel wrote: > >> Is it just me, or is everybody else getting duplicated messages in > >> this list? > > > >i'm not seeing any ... > > Some people post to both the correct addr and the old @mail, this > results in duplicate messages. > > CC'd wrong/old addr for reference.. Sure enough, got that one twice. -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/ce6805a4/signature.pgp From floydpink at gmail.com Wed Jul 5 11:51:40 2006 From: floydpink at gmail.com (Jason Schoon) Date: Wed Jul 5 11:51:45 2006 Subject: Building additional binaries In-Reply-To: <200607051305.29923.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> <200607051305.29923.rob@landley.net> Message-ID: <78a54e1b0607051151u7a29a385ne3802da19726a643@mail.gmail.com> On 7/5/06, Rob Landley wrote: > > On Wednesday 05 July 2006 10:37 am, Jason Schoon wrote: > > On 7/5/06, Mike Frysinger wrote: > > > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > > > He is building in bFLT format (uClinux binary flat format) rather > than > > > > ELF. Seems like a worthwhile and hopefully not insurmountable task. > > > > > > it's already integrated into the build system, Shaun just wants to let > > > the user add it to the default build list > > > -mike > > > > Seems (to me) like we should do something similar to the Linux kernel. > > They still have those options to choose whether you want support for > > a.out, ELF, etc. > > That's what executable formats they support, not what kernel type is > generated. Specifying the kernel type you want is done via the make > command > line. (You always get an elf kernel, vmlinux in the top level directory, > and > some systems actually boot that directly. The others are generated from > vmlinux.) > True, in that case it is specifying a feature, rather than a build configuration. As Shaun pointed out, this probably belongs on the command line along with specifying cross-compiler and such. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060705/9c5cebcc/attachment.htm From dalias at aerifal.cx Wed Jul 5 12:43:49 2006 From: dalias at aerifal.cx (Rich Felker) Date: Wed Jul 5 12:31:35 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <200607051831.57030.vda.linux@googlemail.com> References: <200607051831.57030.vda.linux@googlemail.com> Message-ID: <20060705194349.GA8106@brightrain.aerifal.cx> On Wed, Jul 05, 2006 at 06:31:56PM +0200, Denis Vlasenko wrote: > Hi, > > The patch adds the following applet: > > # ./busybox nmeter > BusyBox v1.2.0 (2006.07.04-21:29+0000) multi-call binary > > Usage: nmeter format_string > > Nmeter monitors your system in real time. > > Format specifiers: > %Nc or %[cN] monitor CPU. N - bar size, default 10 > (displays: S:system U:user N:niced D:iowait I:irq i:softirq) > %[niface] monitor network interface 'iface' > %m monitor allocated memory > %[mf] monitor free memory > %[mt] monitor total memory > %s monitor allocated swap > %f monitor number of used file descriptors > %Ni monitor total/specific IRQ rate > %x monitor context switch rate > %p monitor forks > %[pn] monitor # of processes > %b monitor block io > %Nt show time (with N decimal points) > %Nd milliseconds between updates (default=1000) > %r print instead of at EOL > > Size of the applet (make objsizes): > > text+data text+rodata rwdata bss filename > 5090 4954 136 4104 miscutils/nmeter.o > > Run tested. looks rather large relative to what it does. what about removing some of the cruft from the source at least, like the non-USE_LOCALTIME cases? also imo the code would be smaller using strftime for printing times instead of inlining the hh:mm:ss string generation, etc. since strftime is already used in bb anyway. just some ideas, dunno if the maintainers will agree or not. rich From dalias at aerifal.cx Wed Jul 5 12:44:39 2006 From: dalias at aerifal.cx (Rich Felker) Date: Wed Jul 5 12:32:21 2006 Subject: Duplicated messages? In-Reply-To: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> References: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> Message-ID: <20060705194438.GE24607@brightrain.aerifal.cx> On Thu, Jul 06, 2006 at 02:57:39AM +1000, David Seikel wrote: > Is it just me, or is everybody else getting duplicated messages in this > list? It comes from a few users with misconfigured mailers which send replies to both busybox@busybox.net and busybox@mail.busybox.net, possibly due to misconfigured list software using inconsistent names in the headers...? I dunno.. Rich From vda.linux at googlemail.com Wed Jul 5 12:58:53 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Wed Jul 5 12:59:06 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <20060705194349.GA8106@brightrain.aerifal.cx> References: <200607051831.57030.vda.linux@googlemail.com> <20060705194349.GA8106@brightrain.aerifal.cx> Message-ID: <200607052158.53686.vda.linux@googlemail.com> On Wednesday 05 July 2006 21:43, Rich Felker wrote: > On Wed, Jul 05, 2006 at 06:31:56PM +0200, Denis Vlasenko wrote: > > Hi, > > > > The patch adds the following applet: > > > > # ./busybox nmeter > > BusyBox v1.2.0 (2006.07.04-21:29+0000) multi-call binary > > > > Usage: nmeter format_string > > > > Nmeter monitors your system in real time. > > > > Format specifiers: > > %Nc or %[cN] monitor CPU. N - bar size, default 10 > > (displays: S:system U:user N:niced D:iowait I:irq i:softirq) > > %[niface] monitor network interface 'iface' > > %m monitor allocated memory > > %[mf] monitor free memory > > %[mt] monitor total memory > > %s monitor allocated swap > > %f monitor number of used file descriptors > > %Ni monitor total/specific IRQ rate > > %x monitor context switch rate > > %p monitor forks > > %[pn] monitor # of processes > > %b monitor block io > > %Nt show time (with N decimal points) > > %Nd milliseconds between updates (default=1000) > > %r print instead of at EOL > > > > Size of the applet (make objsizes): > > > > text+data text+rodata rwdata bss filename > > 5090 4954 136 4104 miscutils/nmeter.o > > > > Run tested. > > looks rather large relative to what it does. Biggest functions are: +00000040 t simple_itoa +00000042 t readfile_z +00000046 t init_delay +00000055 t init_cpu +00000057 t init_time +0000005a t init_if +0000005f t collect_fd +00000066 t collect_ctx +00000066 t collect_fork +00000067 t collect_int +00000074 t collect_swp +0000007d t vrdval +000000ba t collect_time - see below why not strftime +000000c5 t collect_if +00000158 t scale - used to cleverly display positive numbers, even huge ones, in 4 characters +00000182 t collect_mem +0000021c t collect_blk - large because has both 2.4 and 2.6 functions +00000292 T nmeter_main +000002b7 t collect_cpu > What about removing some > of the cruft from the source at least, like the non-USE_LOCALTIME > cases? non-USE_LOCALE removal is ok with me, but irrelevant to the binary size. > also imo the code would be smaller using strftime for printing > times instead of inlining the hh:mm:ss string generation, etc. since > strftime is already used in bb anyway. Do you want strftime to parse "%H:%M:%S" format string _on each call_? Will strftime round to nearest last displayed digit in fractional second? Can it do fractional seconds at all, let alone with user specified resolution (number of digits after the dot)? > just some ideas, dunno if the maintainers will agree or not. Thanks, I did find some things which can be made smaller while I was looking at the source! Waiting for maintainers' words... -- vda From dalias at aerifal.cx Wed Jul 5 14:04:05 2006 From: dalias at aerifal.cx (Rich Felker) Date: Wed Jul 5 13:51:53 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <200607052158.53686.vda.linux@googlemail.com> References: <200607051831.57030.vda.linux@googlemail.com> <20060705194349.GA8106@brightrain.aerifal.cx> <200607052158.53686.vda.linux@googlemail.com> Message-ID: <20060705210405.GF24607@brightrain.aerifal.cx> On Wed, Jul 05, 2006 at 09:58:53PM +0200, Denis Vlasenko wrote: > > > Size of the applet (make objsizes): > > > > > > text+data text+rodata rwdata bss filename > > > 5090 4954 136 4104 miscutils/nmeter.o > > > > > > Run tested. > > > > looks rather large relative to what it does. > > Biggest functions are: > > +00000040 t simple_itoa Duplicates code from sprintf... Can be removed or made into sprintf wrapper, perhaps. > > also imo the code would be smaller using strftime for printing > > times instead of inlining the hh:mm:ss string generation, etc. since > > strftime is already used in bb anyway. > > Do you want strftime to parse "%H:%M:%S" format string _on each call_? > Will strftime round to nearest last displayed digit in fractional second? > Can it do fractional seconds at all, let alone with user specified > resolution (number of digits after the dot)? No, it just does struct tm which has no fractional seconds. I didn't read the code very closely to see what was needed; I just saw some repeated code to generate time strings. Rich From rep.nop at aon.at Wed Jul 5 14:31:22 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jul 5 14:31:41 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <200607052158.53686.vda.linux@googlemail.com> References: <200607051831.57030.vda.linux@googlemail.com> <20060705194349.GA8106@brightrain.aerifal.cx> <200607052158.53686.vda.linux@googlemail.com> Message-ID: <20060705213122.GF1102@aon.at> On Wed, Jul 05, 2006 at 09:58:53PM +0200, Denis Vlasenko wrote: >On Wednesday 05 July 2006 21:43, Rich Felker wrote: >> On Wed, Jul 05, 2006 at 06:31:56PM +0200, Denis Vlasenko wrote: >> > Hi, >> > >> > The patch adds the following applet: >> > >> > # ./busybox nmeter s/othervise/otherwise/g >> looks rather large relative to what it does. > >Biggest functions are: > >+00000040 t simple_itoa erm, we already have *several* itoa in there: msh, hush, ash?, lash, netstat Adding yet another impl stikes me as not really optimal. I can see that they have different maximum supported lengths, but they should be unified nevertheless. Please do not add yet another one.. Also, is there a possibility that you could use bb_common_bufsiz1 instead one of your big buffers? What about expanding S_STAT() and MALLOC_STAT()? The latter looks like it wants xmalloc() instead of malloc. >+00000042 t readfile_z >+00000046 t init_delay >+00000055 t init_cpu >+00000057 t init_time >+0000005a t init_if >+0000005f t collect_fd >+00000066 t collect_ctx >+00000066 t collect_fork >+00000067 t collect_int >+00000074 t collect_swp >+0000007d t vrdval >+000000ba t collect_time - see below why not strftime >+000000c5 t collect_if >+00000158 t scale - used to cleverly display positive numbers, > even huge ones, in 4 characters >+00000182 t collect_mem >+0000021c t collect_blk - large because has both 2.4 and 2.6 functions Perhaps it's worthwile to be able to toggle support for 2.4 and 2.6 separately in the config-machinery like we already have for modutils? I'd certainly perfer the possibility to turn off support for a series i will never run on. >+00000292 T nmeter_main >+000002b7 t collect_cpu Didn't look, but is this memset stanza really needed/benefical in collect_cpu? From sjackman at gmail.com Wed Jul 5 14:38:25 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Wed Jul 5 14:38:32 2006 Subject: Building additional binaries In-Reply-To: <78a54e1b0607051151u7a29a385ne3802da19726a643@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607050240.19180.vapier@gentoo.org> <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> <200607051305.29923.rob@landley.net> <78a54e1b0607051151u7a29a385ne3802da19726a643@mail.gmail.com> Message-ID: <7f45d9390607051438s6f635eb6weed9e98c49ea6ae2@mail.gmail.com> On 7/5/06, Jason Schoon wrote: > True, in that case it is specifying a feature, rather than a build > configuration. As Shaun pointed out, this probably belongs on the command > line along with specifying cross-compiler and such. Yes, except that it's already supported on the command line via `make busybox.bflt', as Rob pointed out. I'd like it to be possible to modify .config.mak and have busybox.bflt built by default. As I mentioned previously, adding `all: busybox.bflt' works, except that it breaks running make in subdirectories. Cheers, Shaun From ldoolitt at recycle.lbl.gov Wed Jul 5 15:02:39 2006 From: ldoolitt at recycle.lbl.gov (ldoolitt@recycle.lbl.gov) Date: Wed Jul 5 15:02:46 2006 Subject: style guide (was Re: any value in a standard for defining bit flags?) In-Reply-To: <200607031320.57613.rob@landley.net> References: <2182.1151889832@brightstareng.com> <200607031320.57613.rob@landley.net> Message-ID: <20060705220239.GA18781@recycle.lbl.gov> Rob - On Mon, Jul 03, 2006 at 01:20:57PM -0400, Rob Landley wrote: > Here's the busybox coding style I actually pay attention to: > 1) We use tabs for indents. These tabs are 4 spaces. Deal with it. That statement is a smidgen too strong. 1) We use tabs for indents. Most developers use tabs to mean 4 spaces, but since we only use tabs at the beginning of lines, almost any tab-space conversion ratio will keep the code looking sane. This concept is expanded somewhat in the BusyBox doc/style-guide.txt BTW, the "This is a block comment." section of that file uses slash-t instead of backslash-t to represent tab. That's a docu-bug. Patch to fix that, and a couple of other typos, appended. - Larry --- style-guide.txt.orig 2006-06-30 15:42:03.000000000 -0700 +++ style-guide.txt 2006-07-05 14:59:12.000000000 -0700 @@ -51,13 +51,13 @@ \s\s\s\sif (expr) {\n\tstmt; --ick.) The only exception to this rule is multi-line comments that use an asterisk at the beginning of each line, i.e.: - /t/* - /t * This is a block comment. - /t * Note that it has multiple lines - /t * and that the beginning of each line has a tab plus a space - /t * except for the opening '/*' line where the slash - /t * is used instead of a space. - /t */ + \t/* + \t * This is a block comment. + \t * Note that it has multiple lines + \t * and that the beginning of each line has a tab plus a space + \t * except for the opening '/*' line where the slash + \t * is used instead of a space. + \t */ Furthermore, The preference is that tabs be set to display at four spaces wide, but the beauty of using only tabs (and not spaces) at the beginning of @@ -234,7 +234,7 @@ Exceptions: - Enums, macros, and constant variables are occasionally written in all - upper-case with words optionally seperatedy by underscores (i.e. FIFOTYPE, + upper-case with words optionally separated by by underscores (i.e. FIFOTYPE, ISBLKDEV()). - Nobody is going to get mad at you for using 'pvar' as the name of a @@ -619,7 +619,7 @@ Furthermore, you should put a single comment (not necessarily one line, just one comment) before the block, rather than commenting each and every line. -There is an optimal ammount of commenting that a program can have; you can +There is an optimal amount of commenting that a program can have; you can comment too much as well as too little. A picture is really worth a thousand words here, the following example From ldoolitt at recycle.lbl.gov Wed Jul 5 15:04:55 2006 From: ldoolitt at recycle.lbl.gov (ldoolitt@recycle.lbl.gov) Date: Wed Jul 5 15:04:59 2006 Subject: style guide (was Re: any value in a standard for defining bit flags?) In-Reply-To: <20060705220239.GA18781@recycle.lbl.gov> References: <2182.1151889832@brightstareng.com> <200607031320.57613.rob@landley.net> <20060705220239.GA18781@recycle.lbl.gov> Message-ID: <20060705220455.GA18852@recycle.lbl.gov> Guys - On Wed, Jul 05, 2006 at 03:02:39PM -0700, ldoolitt@recycle.lbl.gov wrote: > + upper-case with words optionally separated by by underscores (i.e. FIFOTYPE, Feel free to remove the extra "by" while you're at it. Sorry for the extra noise. - Larry From vapier at gentoo.org Wed Jul 5 15:20:17 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jul 5 15:20:19 2006 Subject: style guide (was Re: any value in a standard for defining bit flags?) In-Reply-To: <20060705220239.GA18781@recycle.lbl.gov> References: <2182.1151889832@brightstareng.com> <200607031320.57613.rob@landley.net> <20060705220239.GA18781@recycle.lbl.gov> Message-ID: <200607051820.17845.vapier@gentoo.org> On Wednesday 05 July 2006 18:02, ldoolitt@recycle.lbl.gov wrote: > --- style-guide.txt > +++ style-guide.txt > @@ -51,13 +51,13 @@ > - /t/* > + \t/* > @@ -619,7 +619,7 @@ > -There is an optimal ammount of commenting that a program can have; > +There is an optimal amount of commenting that a program can have; merged, thanks -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060705/01991dcb/attachment.pgp From rob at landley.net Wed Jul 5 16:59:55 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 16:59:47 2006 Subject: Building additional binaries In-Reply-To: <200607051304.37600.vapier@gentoo.org> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607051127.21313.rob@landley.net> <200607051304.37600.vapier@gentoo.org> Message-ID: <200607051959.55695.rob@landley.net> On Wednesday 05 July 2006 1:04 pm, Mike Frysinger wrote: > On Wednesday 05 July 2006 11:27, Rob Landley wrote: > > On Wednesday 05 July 2006 2:40 am, Mike Frysinger wrote: > > > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: > > > > He is building in bFLT format (uClinux binary flat format) rather > > > > than ELF. Seems like a worthwhile and hopefully not insurmountable > > > > task. > > > > > > it's already integrated into the build system, Shaun just wants to let > > > the user add it to the default build list > > > > Sigh. For 1.4 or so I'm definitely creating my own git repository. > > that statement doesnt make any sense considering the context A general longing for better tools. I want to be aware of what's in the repository. I want to make it so that people can maintain their own trees and that merging entire sequences of patches between them is easier. (That way, you or Bernhard can queue up a dozen patches at a time and I can review 'em as I merge them, without it turning into a bunch of conflicts that I have to fix up by hand in order to actually merge.) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 17:24:29 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 17:24:18 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607051438s6f635eb6weed9e98c49ea6ae2@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <78a54e1b0607051151u7a29a385ne3802da19726a643@mail.gmail.com> <7f45d9390607051438s6f635eb6weed9e98c49ea6ae2@mail.gmail.com> Message-ID: <200607052024.29838.rob@landley.net> On Wednesday 05 July 2006 5:38 pm, Shaun Jackman wrote: > On 7/5/06, Jason Schoon wrote: > > True, in that case it is specifying a feature, rather than a build > > configuration. As Shaun pointed out, this probably belongs on the > > command line along with specifying cross-compiler and such. > > Yes, except that it's already supported on the command line via `make > busybox.bflt', as Rob pointed out. I'd like it to be possible to > modify .config.mak and have busybox.bflt built by default. As I > mentioned previously, adding `all: busybox.bflt' works, except that it > breaks running make in subdirectories. How about busybox: busybox.bflt? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 17:25:38 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 17:25:23 2006 Subject: style guide (was Re: any value in a standard for defining bit flags?) In-Reply-To: <20060705220239.GA18781@recycle.lbl.gov> References: <2182.1151889832@brightstareng.com> <200607031320.57613.rob@landley.net> <20060705220239.GA18781@recycle.lbl.gov> Message-ID: <200607052025.38626.rob@landley.net> On Wednesday 05 July 2006 6:02 pm, ldoolitt@recycle.lbl.gov wrote: > Rob - > > On Mon, Jul 03, 2006 at 01:20:57PM -0400, Rob Landley wrote: > > Here's the busybox coding style I actually pay attention to: > > 1) We use tabs for indents. These tabs are 4 spaces. Deal with it. > > That statement is a smidgen too strong. > > 1) We use tabs for indents. Most developers use tabs to mean 4 spaces, > but since we only use tabs at the beginning of lines, almost any > tab-space conversion ratio will keep the code looking sane. The tabs are four spaces. > This concept is expanded somewhat in the BusyBox doc/style-guide.txt That's Eric's style guide. Not mine. Amend it all you want, I don't enforce it and am not going to start. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 18:10:43 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 18:10:34 2006 Subject: ash - problem/bug with redirection and internal command In-Reply-To: <32547.1152114476@brightstareng.com> References: <32547.1152114476@brightstareng.com> Message-ID: <200607052110.43712.rob@landley.net> On Wednesday 05 July 2006 11:47 am, Paul Fox wrote: > if that's the case, then i agree that simply clearing the error > is probably the right thing to do. this is vodz's change, referred > to above: > > --- busybox/svn/shell/ash.c 2006-06-15 22:19:41.000000000 -0400 > +++ vodz/shell/ash.c 2006-05-05 09:33:54.000000000 -0400 > @@ -3473,6 +3459,7 @@ > flushall(); > cmddone: > exitstatus |= ferror(stdout); > + clearerr(stdout); > commandname = savecmdname; > exsig = 0; > handler = savehandler; Applied. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 18:16:11 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 18:16:30 2006 Subject: Duplicated messages? In-Reply-To: <20060705194438.GE24607@brightrain.aerifal.cx> References: <20060706025739.57bb3147@cluster.meeting.humbug.org.au> <20060705194438.GE24607@brightrain.aerifal.cx> Message-ID: <200607052116.12213.rob@landley.net> On Wednesday 05 July 2006 3:44 pm, Rich Felker wrote: > On Thu, Jul 06, 2006 at 02:57:39AM +1000, David Seikel wrote: > > Is it just me, or is everybody else getting duplicated messages in this > > list? > > It comes from a few users with misconfigured mailers which send > replies to both busybox@busybox.net and busybox@mail.busybox.net, > possibly due to misconfigured list software using inconsistent names > in the headers...? I dunno.. It happens if somebody sends a message to the old busybox@mail.busybox.net address. Most "Reply all" variants will also send a copy to the list ID, which is just busybox@busybox.net, without recognizing that busybox@mail.busybox.net is the same machine because they have independent A records in the DNS. The easy solution is don't send to mail.busybox.net. I removed that from the website a while ago, and would tweak the DNS record if I could. (I believe making mail.busybox.net a cname for busybox.net would fix it.) But that's still Erik. I should bug him... > Rich Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jul 5 18:30:52 2006 From: rob at landley.net (Rob Landley) Date: Wed Jul 5 18:31:17 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <20060705213122.GF1102@aon.at> References: <200607051831.57030.vda.linux@googlemail.com> <200607052158.53686.vda.linux@googlemail.com> <20060705213122.GF1102@aon.at> Message-ID: <200607052130.52704.rob@landley.net> I have yet to have time to look at this, but catching up on my email... On Wednesday 05 July 2006 5:31 pm, Bernhard Fischer wrote: > >+00000040 t simple_itoa > > erm, we already have *several* itoa in there: > msh, hush, ash?, lash, netstat And the xgetularg variants in libbb. (Ick. I am _going_ to remove these gratuitous bb_ prefixes that have sprouted everywhere. You have been warned...) I've been dreading the part of rewriting getopt_ulflags() that adds number parsing support so the &optarg bits can feed it a pointer to an integer. Not sure what a clean syntax for that would be yet. (Leaning towards something like "x#\x32" for a uint32_t, but how do I specify signed?) Making it not use getopt() seems fairly easy in comparison... > >+0000021c t collect_blk - large because has both 2.4 and 2.6 functions > > Perhaps it's worthwile to be able to toggle support for 2.4 and 2.6 > separately in the config-machinery like we already have for modutils? A global toggle for this? Makes sense. I'd want both allyesconfig and allnoconfig to build, though. Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Thu Jul 6 01:00:13 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jul 6 01:00:22 2006 Subject: Building additional binaries In-Reply-To: <200607051959.55695.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607051127.21313.rob@landley.net> <200607051304.37600.vapier@gentoo.org> <200607051959.55695.rob@landley.net> Message-ID: <20060706080013.GA4521@aon.at> On Wed, Jul 05, 2006 at 07:59:55PM -0400, Rob Landley wrote: >On Wednesday 05 July 2006 1:04 pm, Mike Frysinger wrote: >> On Wednesday 05 July 2006 11:27, Rob Landley wrote: >> > On Wednesday 05 July 2006 2:40 am, Mike Frysinger wrote: >> > > On Wednesday 05 July 2006 00:51, Jason Schoon wrote: >> > > > He is building in bFLT format (uClinux binary flat format) rather >> > > > than ELF. Seems like a worthwhile and hopefully not insurmountable >> > > > task. >> > > >> > > it's already integrated into the build system, Shaun just wants to let >> > > the user add it to the default build list >> > >> > Sigh. For 1.4 or so I'm definitely creating my own git repository. >> >> that statement doesnt make any sense considering the context > >A general longing for better tools. > >I want to be aware of what's in the repository. I want to make it so that >people can maintain their own trees and that merging entire sequences of >patches between them is easier. (That way, you or Bernhard can queue up a >dozen patches at a time and I can review 'em as I merge them, without it >turning into a bunch of conflicts that I have to fix up by hand in order to >actually merge.) Rob, trunk is in a really bad shape IMO. I'm feeding my fixes/enhancements to a separate branch, so i have a working base to use and develop with. I'll refrain from checking code-changes into trunk for now, so i will not interfere with anything you may decide to change there. I'm regularly pulling worthwile stuff off trunk into my branch now as i want the branch to contain less bugs than trunk does. Regularly as in it has approximately the feature-set of the 1.2.0 release (plus a bit) and has a couple of fixes i had to do to bring it back to something i could deal with. My hope is that this approach will let you clean out your backlog and get something useful done which works, without you having to deal with somebody else (at least me) introducing conflicts. > >Rob >-- >Never bet against the cheap plastic solution. >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox > From rpjday at mindspring.com Thu Jul 6 02:35:21 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Thu Jul 6 02:36:58 2006 Subject: style guide (was Re: any value in a standard for defining bit flags?) In-Reply-To: <20060705220239.GA18781@recycle.lbl.gov> References: <2182.1151889832@brightstareng.com> <200607031320.57613.rob@landley.net> <20060705220239.GA18781@recycle.lbl.gov> Message-ID: On Wed, 5 Jul 2006, ldoolitt@recycle.lbl.gov wrote: > Rob - > On Mon, Jul 03, 2006 at 01:20:57PM -0400, Rob Landley wrote: > > Here's the busybox coding style I actually pay attention to: > > 1) We use tabs for indents. These tabs are 4 spaces. Deal with it. > > That statement is a smidgen too strong. > > 1) We use tabs for indents. Most developers use tabs to mean 4 > spaces, but since we only use tabs at the beginning of lines, almost > any tab-space conversion ratio will keep the code looking sane. to a certain extent, yes. but the choice of spaces per tab is important since, if you don't take it into account, it will make a mess when you print the source file. not a big deal, just something you don't want to forget. rday From yh at bizmail.com.au Thu Jul 6 03:40:36 2006 From: yh at bizmail.com.au (Jim) Date: Thu Jul 6 03:40:14 2006 Subject: insmod module.ko Message-ID: <44ACE8A4.90106@bizmail.com.au> Hello, I am upgrading linux kernel from 2.4 to 2.6. The module objects in kernel 2.6 are all appended with .ko, this caused a problem when I call insmod MyModule.ko, the insmod added another .o and became an error "MyModule.ko.o cannot be found". How can I resolve this issue? Thank you. Jim From rep.nop at aon.at Thu Jul 6 03:58:45 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jul 6 03:58:53 2006 Subject: insmod module.ko In-Reply-To: <44ACE8A4.90106@bizmail.com.au> References: <44ACE8A4.90106@bizmail.com.au> Message-ID: <20060706105845.GA8585@aon.at> On Thu, Jul 06, 2006 at 08:40:36PM +1000, Jim wrote: >Hello, > >I am upgrading linux kernel from 2.4 to 2.6. The module objects in >kernel 2.6 are all appended with .ko, this caused a problem when I call >insmod MyModule.ko, the insmod added another .o and became an error >"MyModule.ko.o cannot be found". > >How can I resolve this issue? Enable 2.6 support in modutils From marc.leeman at gmail.com Thu Jul 6 03:58:13 2006 From: marc.leeman at gmail.com (Marc Leeman) Date: Thu Jul 6 04:28:45 2006 Subject: [gmail] Re: insmod module.ko In-Reply-To: <44ACE8A4.90106@bizmail.com.au> References: <44ACE8A4.90106@bizmail.com.au> Message-ID: <20060706105813.GI29052@scorpius.homelinux.org> > I am upgrading linux kernel from 2.4 to 2.6. The module objects in > kernel 2.6 are all appended with .ko, this caused a problem when I call > insmod MyModule.ko, the insmod added another .o and became an error > "MyModule.ko.o cannot be found". Hm, Isn't there some 2.6 option you should enable in busybox. I for one can call insmod /lib/modules/..../module.ko insmod module.ko insmod module all causing the insertion :) -- greetz, marc Jool 'Shoot him, you're the warrior, just shoot him now! D'Argo 'With what? My nose? D'Argo - Losing Time scorpius.homelinux.org 2.6.17 #2 PREEMPT Thu Jun 22 07:18:33 CEST 2006 GNU/Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://busybox.net/lists/busybox/attachments/20060706/7bf43b4c/attachment.pgp From yh at bizmail.com.au Thu Jul 6 04:36:00 2006 From: yh at bizmail.com.au (YH) Date: Thu Jul 6 04:35:36 2006 Subject: insmod module.ko In-Reply-To: <20060706105845.GA8585@aon.at> References: <44ACE8A4.90106@bizmail.com.au> <20060706105845.GA8585@aon.at> Message-ID: <44ACF5A0.3060905@bizmail.com.au> Thanks Bernhard, but sorry I am new to BusyBox, could you explain me more on how to enable 2.6 in BusyBox? Thank you. Jim Bernhard Fischer wrote: > On Thu, Jul 06, 2006 at 08:40:36PM +1000, Jim wrote: > >>Hello, >> >>I am upgrading linux kernel from 2.4 to 2.6. The module objects in >>kernel 2.6 are all appended with .ko, this caused a problem when I call >>insmod MyModule.ko, the insmod added another .o and became an error >>"MyModule.ko.o cannot be found". >> >>How can I resolve this issue? > > > Enable 2.6 support in modutils > From rep.nop at aon.at Thu Jul 6 04:55:03 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jul 6 04:55:07 2006 Subject: insmod module.ko In-Reply-To: <44ACF5A0.3060905@bizmail.com.au> References: <44ACE8A4.90106@bizmail.com.au> <20060706105845.GA8585@aon.at> <44ACF5A0.3060905@bizmail.com.au> Message-ID: <20060706115503.GC9309@aon.at> On Thu, Jul 06, 2006 at 09:36:00PM +1000, YH wrote: >Thanks Bernhard, but sorry I am new to BusyBox, could you explain me >more on how to enable 2.6 in BusyBox? make menuconfig go to "Linux Module Utilities" and set "Support version 2.6.x Linux kernels" From natanael.copa at gmail.com Thu Jul 6 06:08:44 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jul 6 06:15:18 2006 Subject: ash - problem/bug with redirection and internal command In-Reply-To: <200607052110.43712.rob@landley.net> References: <32547.1152114476@brightstareng.com> <200607052110.43712.rob@landley.net> Message-ID: <95408c820607060608q6a58803die33d5326e109954c@mail.gmail.com> 2006/7/6, Rob Landley : > > On Wednesday 05 July 2006 11:47 am, Paul Fox wrote: > > if that's the case, then i agree that simply clearing the error > > is probably the right thing to do. this is vodz's change, referred > > to above: > > > > --- busybox/svn/shell/ash.c 2006-06-15 22:19:41.000000000 -0400 > > +++ vodz/shell/ash.c 2006-05-05 09:33:54.000000000 -0400 > > @@ -3473,6 +3459,7 @@ > > flushall(); > > cmddone: > > exitstatus |= ferror(stdout); > > + clearerr(stdout); > > commandname = savecmdname; > > exsig = 0; > > handler = savehandler; > > Applied. Could this go into busybox_1_2_stable branch too? For inclusion in 1.2.1. Thanks. -- Natanael Copa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060706/051e724f/attachment.htm From rep.nop at aon.at Thu Jul 6 06:21:51 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jul 6 06:22:01 2006 Subject: ash - problem/bug with redirection and internal command In-Reply-To: <95408c820607060608q6a58803die33d5326e109954c@mail.gmail.com> References: <32547.1152114476@brightstareng.com> <200607052110.43712.rob@landley.net> <95408c820607060608q6a58803die33d5326e109954c@mail.gmail.com> Message-ID: <20060706132151.GA11220@aon.at> On Thu, Jul 06, 2006 at 03:08:44PM +0200, Natanael Copa wrote: >2006/7/6, Rob Landley : >> >>On Wednesday 05 July 2006 11:47 am, Paul Fox wrote: >>> if that's the case, then i agree that simply clearing the error >>> is probably the right thing to do. this is vodz's change, referred >>> to above: >>> >>> --- busybox/svn/shell/ash.c 2006-06-15 22:19:41.000000000 -0400 >>> +++ vodz/shell/ash.c 2006-05-05 09:33:54.000000000 -0400 >>> @@ -3473,6 +3459,7 @@ >>> flushall(); >>> cmddone: >>> exitstatus |= ferror(stdout); >>> + clearerr(stdout); >>> commandname = savecmdname; >>> exsig = 0; >>> handler = savehandler; >> >>Applied. > > > >Could this go into busybox_1_2_stable branch too? There is no busybox_1_2_stable branch. I guess the maintainer will create this branch when the http://busybox.net/downloads/Changelog.gz is populated with the changelog between the busybox_1_1_stable branch and the busybox_1_2_stable branch.. > >For inclusion in 1.2.1. > >Thanks. From natanael.copa at gmail.com Thu Jul 6 06:59:12 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jul 6 06:59:20 2006 Subject: bug in dmesg parameter parsing (busybox 1.2.0) Message-ID: <1152194352.9893.8.camel@localhost> Hi, I'm upgrading my 1.1.3 busybox to 1.2.0. I got bitten by this one: ~ $ dmesg -c dmesg: option requires an argument -- c BusyBox v1.2.0 (2006.07.06-06:53+0000) multi-call binary Usage: dmesg [-c] [-n LEVEL] [-s SIZE] Prints or controls the kernel ring buffer Options: -c Clears the ring buffer's contents after printing -n LEVEL Sets console logging level -s SIZE Use a buffer of size SIZE ~ $ dmesg -n 1 BusyBox v1.2.0 (2006.07.06-06:53+0000) multi-call binary Usage: dmesg [-c] [-n LEVEL] [-s SIZE] Prints or controls the kernel ring buffer Options: -c Clears the ring buffer's contents after printing -n LEVEL Sets console logging level -s SIZE Use a buffer of size SIZE ~ $ dmesg -s 16384 BusyBox v1.2.0 (2006.07.06-06:53+0000) multi-call binary Usage: dmesg [-c] [-n LEVEL] [-s SIZE] Prints or controls the kernel ring buffer Options: -c Clears the ring buffer's contents after printing -n LEVEL Sets console logging level -s SIZE Use a buffer of size SIZE From rep.nop at aon.at Thu Jul 6 07:38:09 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jul 6 07:38:16 2006 Subject: bug in dmesg parameter parsing (busybox 1.2.0) In-Reply-To: <1152194352.9893.8.camel@localhost> References: <1152194352.9893.8.camel@localhost> Message-ID: <20060706143809.GA12708@aon.at> On Thu, Jul 06, 2006 at 03:59:12PM +0200, Natanael Copa wrote: >Hi, > >I'm upgrading my 1.1.3 busybox to 1.2.0. > >I got bitten by this one: > >~ $ dmesg -c >dmesg: option requires an argument -- c >BusyBox v1.2.0 (2006.07.06-06:53+0000) multi-call binary > >Usage: dmesg [-c] [-n LEVEL] [-s SIZE] > >Prints or controls the kernel ring buffer > >Options: > -c Clears the ring buffer's contents after printing > -n LEVEL Sets console logging level > -s SIZE Use a buffer of size SIZE > >~ $ dmesg -n 1 This one just segfaulted on me. I rewrote it, this version Works For Me (tm): http://www.busybox.net/cgi-bin/viewcvs.cgi/branches/busybox_scratch/util-linux/dmesg.c HTH, Bernhard From rob at landley.net Thu Jul 6 07:44:07 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 07:43:53 2006 Subject: Building additional binaries In-Reply-To: <20060706080013.GA4521@aon.at> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607051959.55695.rob@landley.net> <20060706080013.GA4521@aon.at> Message-ID: <200607061044.07970.rob@landley.net> On Thursday 06 July 2006 4:00 am, Bernhard Fischer wrote: > Rob, trunk is in a really bad shape IMO. I'm feeding my > fixes/enhancements to a separate branch, so i have a working base to use > and develop with. I'll refrain from checking code-changes into trunk for > now, so i will not interfere with anything you may decide to change > there. Are the bugs and patches in bugs.busybox.net? I may have some time to take another whack at dealing with the bug backlog this weekend. I just ended my annual caffeine fast and after having one diet coke I rewrote about 1/4 of a combined mke2fs/gene2fs replacement from scratch, and I'm going to try to finish it before tackling anything else because I'm tired of having 8 gazillion half finished projects, and the e2fsprogs directories is one of the big eyesores in the tree. (This uses _nothing_ from that.) > I'm regularly pulling worthwile stuff off trunk into my branch now as i > want the branch to contain less bugs than trunk does. Regularly as in > it has approximately the feature-set of the 1.2.0 release (plus a bit) > and has a couple of fixes i had to do to bring it back to something i > could deal with. If you could queue up bug fixes for 1.2.1, that would be very useful. > My hope is that this approach will let you clean out your backlog and > get something useful done which works, without you having to deal with > somebody else (at least me) introducing conflicts. I'm trying to learn about git so we can have a toolset where all of us can work at full speed without stomping each other so much. My initramfs tutorial at OLS is sandwiched between two git tutorials, so that seems like a good time to come up to speed on it. :) Rob -- Never bet against the cheap plastic solution. From natanael.copa at gmail.com Thu Jul 6 08:00:14 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jul 6 08:00:54 2006 Subject: bug in dmesg parameter parsing (busybox 1.2.0) In-Reply-To: <20060706143809.GA12708@aon.at> References: <1152194352.9893.8.camel@localhost> <20060706143809.GA12708@aon.at> Message-ID: <1152198014.13043.9.camel@localhost> On Thu, 2006-07-06 at 16:38 +0200, Bernhard Fischer wrote: > On Thu, Jul 06, 2006 at 03:59:12PM +0200, Natanael Copa wrote: > >Hi, > > > >I'm upgrading my 1.1.3 busybox to 1.2.0. > > > >I got bitten by this one: > > > >~ $ dmesg -c > >dmesg: option requires an argument -- c > >BusyBox v1.2.0 (2006.07.06-06:53+0000) multi-call binary > > > >Usage: dmesg [-c] [-n LEVEL] [-s SIZE] > > > >Prints or controls the kernel ring buffer > > > >Options: > > -c Clears the ring buffer's contents after printing > > -n LEVEL Sets console logging level > > -s SIZE Use a buffer of size SIZE > > > >~ $ dmesg -n 1 > > This one just segfaulted on me. Because the "c:s:n:" should be "cs:n:"? --- util-linux/dmesg.c (revision 15655) +++ util-linux/dmesg.c (working copy) @@ -15,7 +15,7 @@ int dmesg_main(int argc, char *argv[]) { char *size, *level; - int flags = bb_getopt_ulflags(argc, argv, "c:s:n:", &size, &level); + int flags = bb_getopt_ulflags(argc, argv, "cs:n:", &size, &level); if (flags & 4) { if(klogctl(8, NULL, bb_xgetlarg(size, 10, 0, 10))) But it still don't work. Seems like a bug in bb_getopt_ulflags? > > I rewrote it, this version Works For Me (tm): > http://www.busybox.net/cgi-bin/viewcvs.cgi/branches/busybox_scratch/util-linux/dmesg.c Thanks! Would be nice to have this fixed in 1.2.1. From vda.linux at googlemail.com Thu Jul 6 08:37:28 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Thu Jul 6 08:37:49 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <20060705213122.GF1102@aon.at> References: <200607051831.57030.vda.linux@googlemail.com> <200607052158.53686.vda.linux@googlemail.com> <20060705213122.GF1102@aon.at> Message-ID: <200607061737.28620.vda.linux@googlemail.com> On Wednesday 05 July 2006 23:31, Bernhard Fischer wrote: > >> looks rather large relative to what it does. > > > >Biggest functions are: > > > >+00000040 t simple_itoa > > erm, we already have *several* itoa in there: > msh, hush, ash?, lash, netstat > Adding yet another impl stikes me as not really optimal. I can see that > they have different maximum supported lengths, but they should be > unified nevertheless. Please do not add yet another one.. It's a bit special. It puts string at the _end_ of provided buffer, and pads it with zeroes to specified width: simple_itoa(char *s, int sz, unsigned long v, int pad) { s += sz; *--s = '\0'; while (--sz > 0) { *--s = "0123456789"[v%10]; pad--; v /= 10; if (!v && pad <= 0) break; } return s; } Prototype is rather different from standard itoa. If I will switch to standard itoa, bloat will simply migrate to callsites instead (strlen, strncpy etc...). I prefer to have my own which does exactly what I need. > Also, is there a possibility that you could use bb_common_bufsiz1 > instead one of your big buffers? Done > What about expanding S_STAT() and MALLOC_STAT()? The latter looks like > it wants xmalloc() instead of malloc. xmalloc - done. Do you mean - get rid of macros nd expand them by hand? > >+00000042 t readfile_z > >+00000046 t init_delay > >+00000055 t init_cpu > >+00000057 t init_time > >+0000005a t init_if > >+0000005f t collect_fd > >+00000066 t collect_ctx > >+00000066 t collect_fork > >+00000067 t collect_int > >+00000074 t collect_swp > >+0000007d t vrdval > >+000000ba t collect_time - see below why not strftime > >+000000c5 t collect_if > >+00000158 t scale - used to cleverly display positive numbers, > > even huge ones, in 4 characters > >+00000182 t collect_mem > >+0000021c t collect_blk - large because has both 2.4 and 2.6 functions > > Perhaps it's worthwile to be able to toggle support for 2.4 and 2.6 > separately in the config-machinery like we already have for modutils? I mostly merged 2.4 and 2.6 code instead. The code which is different for 2.4/2.6 is just: if (is26) { i = rdval_diskstats(prepare(&proc_diskstats), data); } else { i = rdval(prepare(&proc_stat), s->lookfor, data, 1, 2); // Linux 2.4 reports bio in Kbytes, convert to sectors: data[0] *= 2; data[1] *= 2; } > I'd certainly perfer the possibility to turn off support for a series i > will never run on. > > >+00000292 T nmeter_main > >+000002b7 t collect_cpu > > Didn't look, but is this memset stanza really needed/benefical in collect_cpu? It is used fot filling the cpu bar: [SSSSSSSSSSSSSUUUUUUUUUUUUUUUUDDDDDDDDDDDDDDDDD.............] How do you propose to do it? Newer version is attached. Some of the concerns are addressed. One buglet fixed. Small change: CPU bar lost []s (use "[%c]" if you liked those). Routines by size: +00000040 t simple_itoa +00000042 t readfile_z +00000046 t init_delay +00000055 t init_cpu +00000057 t init_time +0000005a t init_if +0000005f t collect_fd +00000066 t collect_ctx +00000066 t collect_fork +00000067 t collect_int +0000006f t collect_swp +0000007d t vrdval +000000ba t collect_time +000000c5 t collect_if +00000158 t scale +0000016e t collect_mem +000001bb t collect_blk +00000281 t collect_cpu +000002a9 T nmeter_main +00000984 R applets +0000cce8 r usage_messages text+data text+rodata rwdata bss filename 4937 4801 136 8 miscutils/nmeter.o -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: nmeter4.patch Type: text/x-diff Size: 23111 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/6bdfa473/nmeter4-0001.bin From rep.nop at aon.at Thu Jul 6 08:49:49 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jul 6 08:49:53 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <200607061737.28620.vda.linux@googlemail.com> References: <200607051831.57030.vda.linux@googlemail.com> <200607052158.53686.vda.linux@googlemail.com> <20060705213122.GF1102@aon.at> <200607061737.28620.vda.linux@googlemail.com> Message-ID: <20060706154949.GA14152@aon.at> On Thu, Jul 06, 2006 at 05:37:28PM +0200, Denis Vlasenko wrote: >On Wednesday 05 July 2006 23:31, Bernhard Fischer wrote: >> >> looks rather large relative to what it does. >> > >> What about expanding S_STAT() and MALLOC_STAT()? The latter looks like >> it wants xmalloc() instead of malloc. > >xmalloc - done. Do you mean - get rid of macros nd expand them by hand? Yes. I think it would be more readable then, but that may be just me.. >> >+0000021c t collect_blk - large because has both 2.4 and 2.6 functions >> >> Perhaps it's worthwile to be able to toggle support for 2.4 and 2.6 >> separately in the config-machinery like we already have for modutils? > >I mostly merged 2.4 and 2.6 code instead. The code which is different >for 2.4/2.6 is just: > > if (is26) { > i = rdval_diskstats(prepare(&proc_diskstats), data); > } else { > i = rdval(prepare(&proc_stat), s->lookfor, data, 1, 2); > // Linux 2.4 reports bio in Kbytes, convert to sectors: > data[0] *= 2; > data[1] *= 2; > } Looks better, yes. Still should there be the possibility to turn 2.6 or 2.4 support completely off? It would save at lease the int if not more.. >> I'd certainly perfer the possibility to turn off support for a series i >> will never run on. >> >> >+00000292 T nmeter_main >> >+000002b7 t collect_cpu >> >> Didn't look, but is this memset stanza really needed/benefical in collect_cpu? > >It is used fot filling the cpu bar: > >[SSSSSSSSSSSSSUUUUUUUUUUUUUUUUDDDDDDDDDDDDDDDDD.............] > >How do you propose to do it? Ah, the memset is of course ok then. cheers, From rob at landley.net Thu Jul 6 08:23:21 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:31:35 2006 Subject: ash - problem/bug with redirection and internal command In-Reply-To: <95408c820607060608q6a58803die33d5326e109954c@mail.gmail.com> References: <32547.1152114476@brightstareng.com> <200607052110.43712.rob@landley.net> <95408c820607060608q6a58803die33d5326e109954c@mail.gmail.com> Message-ID: <200607061123.21876.rob@landley.net> On Thursday 06 July 2006 9:08 am, Natanael Copa wrote: > > Applied. > > Could this go into busybox_1_2_stable branch too? > > For inclusion in 1.2.1. I plan on including it in 1.2.1. > Thanks. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 08:19:36 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:31:40 2006 Subject: style guide (was Re: any value in a standard for defining bit flags?) In-Reply-To: References: <2182.1151889832@brightstareng.com> <20060705220239.GA18781@recycle.lbl.gov> Message-ID: <200607061119.36374.rob@landley.net> On Thursday 06 July 2006 5:35 am, Robert P. J. Day wrote: > > 1) We use tabs for indents. Most developers use tabs to mean 4 > > spaces, but since we only use tabs at the beginning of lines, almost > > any tab-space conversion ratio will keep the code looking sane. > > to a certain extent, yes. but the choice of spaces per tab is > important since, if you don't take it into account, it will make a > mess when you print the source file. not a big deal, just something > you don't want to forget. Remember the 80 character limit I mentioned? That's 80 characters with 4 space tabs. If you want to count by hand, feel free... > rday Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 09:30:54 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:31:50 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607050820i653f5458k2d1049781b0ee26b@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> <7f45d9390607050820i653f5458k2d1049781b0ee26b@mail.gmail.com> Message-ID: <200607061230.54841.rob@landley.net> On Wednesday 05 July 2006 11:20 am, Shaun Jackman wrote: > The trend in Busybox has been to relegate configure options related to > the build system into .config.mak, out of the make config system. > Adding `all: busybox' to .config.mak works when building from the > top-level directory, but breaks running make in other subdirectories. > The top-level Makefile declares _all to be the default target before > it includes .config.mak, but the subdirectories do not do this. So, > adding an `all: busybox' to config.mak causes all -- instead of > libbb.a, for example -- to become the default target for the > subdirectories. I tried to ask earlier if "busybox: busybox.bflt" to .config.mak fixed it without screwing up subdirectories. (Since those subdirectories shouldn't be building the busybox target anyway, but that's what "all" points to at the top level...) If there was a reply, I missed it. Not sure it went out, suspend/resume tends to crash my machine from time to time (yes, on Ubuntu Daffy Duck. I am so looking forward to the new suspend architecture Linus is trying to beat people over the head with until they listen...) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 08:54:16 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:31:55 2006 Subject: [PATCH] documentation fixes and small addition In-Reply-To: <200607051827.42264.vda.linux@googlemail.com> References: <200607051827.42264.vda.linux@googlemail.com> Message-ID: <200607061154.17014.rob@landley.net> On Wednesday 05 July 2006 12:27 pm, Denis Vlasenko wrote: > Hi, > > Patch fixes typos in style-guide.txt and adds recommendation > to use enums for defining int constants. A) That's Erik's old style guide, not what I actually enforce. I've been considering writing a new (much smaller) one. B) Programming tips like "static constants might bloat the code, enums won't" belong in the programming section of the FAQ. (I'd like 'em all in one place so new guys don't have to learn this stuff piecemeal quite so much.) C) I'd like to nail down exactly which versions of gcc can optimize out static stuff and which can't. (I've run tests and gotten inconsistent results. I know 3.3 couldn't, but I think 4.0 can.) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 08:59:37 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:31:57 2006 Subject: exporting argc/argv to applets In-Reply-To: <20060702133654.GJ21958@aon.at> References: <20060702133654.GJ21958@aon.at> Message-ID: <200607061159.37833.rob@landley.net> On Sunday 02 July 2006 9:36 am, Bernhard Fischer wrote: > Hi, > > FYI, I've been pondering ?) landley's suggestion to export argc > and argv globally, so we wouldn't have to pass it around as arguments. > > From a cursory look, this doesn't seem to be a good idea, though: I didn't say it was a good idea, just an idea. :) > text data bss dec hex filename > 862418 10156 644740 1517314 172702 busybox.old > 865586 10156 644708 1520450 173342 busybox > > Could very well be that i did something wrong/incomplete, admittedly. On x86 especially, registers are a scarce resource. It turns out to be smaller to deal with all stack variables (sp+offset) or all global variables (bp+offset). Switching back and forth between the two seems to result in bigger code. I dunno if it confuses the optimizer or if it's just a hard problem in a register starved environment like x86. This is the kind of micro-optimization that I try not to care too much about because it'll just drive you _crazy_ trying to think like that. But it could be what you're hitting. I'd have thought the savings from yanking the arguments from all the main() functions would have overcome that, though... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 09:30:54 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:32:00 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607050820i653f5458k2d1049781b0ee26b@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <78a54e1b0607050737l1aad9d14y114cb9cb790c7f19@mail.gmail.com> <7f45d9390607050820i653f5458k2d1049781b0ee26b@mail.gmail.com> Message-ID: <200607061230.54841.rob@landley.net> On Wednesday 05 July 2006 11:20 am, Shaun Jackman wrote: > The trend in Busybox has been to relegate configure options related to > the build system into .config.mak, out of the make config system. > Adding `all: busybox' to .config.mak works when building from the > top-level directory, but breaks running make in other subdirectories. > The top-level Makefile declares _all to be the default target before > it includes .config.mak, but the subdirectories do not do this. So, > adding an `all: busybox' to config.mak causes all -- instead of > libbb.a, for example -- to become the default target for the > subdirectories. I tried to ask earlier if "busybox: busybox.bflt" to .config.mak fixed it without screwing up subdirectories. (Since those subdirectories shouldn't be building the busybox target anyway, but that's what "all" points to at the top level...) If there was a reply, I missed it. Not sure it went out, suspend/resume tends to crash my machine from time to time (yes, on Ubuntu Daffy Duck. I am so looking forward to the new suspend architecture Linus is trying to beat people over the head with until they listen...) Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Thu Jul 6 09:39:42 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Thu Jul 6 09:39:47 2006 Subject: Building additional binaries In-Reply-To: <200607061044.07970.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607051959.55695.rob@landley.net> <20060706080013.GA4521@aon.at> <200607061044.07970.rob@landley.net> Message-ID: <7f45d9390607060939t3b353b3p5be6b13510737676@mail.gmail.com> On 7/6/06, Rob Landley wrote: > I'm trying to learn about git so we can have a toolset where all of us can > work at full speed without stomping each other so much. My initramfs > tutorial at OLS is sandwiched between two git tutorials, so that seems like a > good time to come up to speed on it. :) I really don't want to start a version-control holy war -- honest -- but I will mention that I've been using monotone to manage my busybox patches and regularly merge with the svn trunk. It's been working extremely well for me. Cheers, Shaun From vda.linux at googlemail.com Thu Jul 6 09:39:58 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Thu Jul 6 09:40:09 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <20060706154949.GA14152@aon.at> References: <200607051831.57030.vda.linux@googlemail.com> <200607061737.28620.vda.linux@googlemail.com> <20060706154949.GA14152@aon.at> Message-ID: <200607061839.58138.vda.linux@googlemail.com> On Thursday 06 July 2006 17:49, Bernhard Fischer wrote: > >> What about expanding S_STAT() and MALLOC_STAT()? The latter looks like > >> it wants xmalloc() instead of malloc. > > > >xmalloc - done. Do you mean - get rid of macros nd expand them by hand? > > Yes. I think it would be more readable then, but that may be just me.. Ok, I got rid of MALLOC_STAT, but S_STAT - it's too error-prone to do it by hand. I don't want to remove it. I also got rid of USE_LOCALTIME and unused #define. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: nmeter5.patch Type: text/x-diff Size: 22558 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/8edfb55b/nmeter5-0001.bin From rob at landley.net Thu Jul 6 09:42:54 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:42:44 2006 Subject: bug in dmesg parameter parsing (busybox 1.2.0) In-Reply-To: <20060706143809.GA12708@aon.at> References: <1152194352.9893.8.camel@localhost> <20060706143809.GA12708@aon.at> Message-ID: <200607061242.55135.rob@landley.net> On Thursday 06 July 2006 10:38 am, Bernhard Fischer wrote: > > This one just segfaulted on me. I just fixed it on the bus on the way in to work. (Three problems: 1) the c argument shouldn't have had a : after that, dunno how that got there. 2) the xgetlarg for level was using size, and 3) because xgetlarg's error message _SUCKS_ (it does a show_usage() rather than giving any specific info about the range that was violated) I dropped the range down to 2 bytes. (Which works fine, I dunno why we were nit-picking about that...) > I rewrote it, this version Works For Me (tm): > http://www.busybox.net/cgi-bin/viewcvs.cgi/branches/busybox_scratch/util-li >nux/dmesg.c Try svn 15656. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 09:56:48 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 09:56:38 2006 Subject: bug in dmesg parameter parsing (busybox 1.2.0) In-Reply-To: <1152198014.13043.9.camel@localhost> References: <1152194352.9893.8.camel@localhost> <20060706143809.GA12708@aon.at> <1152198014.13043.9.camel@localhost> Message-ID: <200607061256.48539.rob@landley.net> On Thursday 06 July 2006 11:00 am, Natanael Copa wrote: > Thanks! > > Would be nice to have this fixed in 1.2.1. The three patches currently pending for 1.2.1 are up: http://busybox.net/downloads/busybox-1.2.0.fixes.patch No immediate plans to release 1.2.1 yet though. Still waiting to see what else shakes out... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 10:05:57 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 10:06:17 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <20060706154949.GA14152@aon.at> References: <200607051831.57030.vda.linux@googlemail.com> <200607061737.28620.vda.linux@googlemail.com> <20060706154949.GA14152@aon.at> Message-ID: <200607061305.58116.rob@landley.net> On Thursday 06 July 2006 11:49 am, Bernhard Fischer wrote: > Looks better, yes. Still should there be the possibility to turn 2.6 or > 2.4 support completely off? It would save at lease the int if not more.. If we add a global "enable 2.4 support" switch, then we should remember this is here. I'm on the fence about whether a global "enable 2.6 support" switch makes sense. Considering it won't ship in a release before December, so it's effectively 2007 by then, I'm leaning against it. A 2.4 switch gives us something to hide devfs names and devfsd behind, and then the config option for the modutils stuff (which is the big one) can just become "Support 2.4 only" to disable 2.6 support, and that switch can be guarded by the global enable 2.4 support switch. That's the only case I can think of where 2.6 support is a signifcant chunk of code that 2.4 doesn't need... This has nothing to do with nmeter. :) I'll take a closer look at it (and probably merge it) this weekend. Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Thu Jul 6 09:48:05 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Thu Jul 6 10:08:20 2006 Subject: Building additional binaries In-Reply-To: <200607052024.29838.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <78a54e1b0607051151u7a29a385ne3802da19726a643@mail.gmail.com> <7f45d9390607051438s6f635eb6weed9e98c49ea6ae2@mail.gmail.com> <200607052024.29838.rob@landley.net> Message-ID: <7f45d9390607060948n5cd7bd52madee07c2b20d2d02@mail.gmail.com> On 7/5/06, Rob Landley wrote: > How about busybox: busybox.bflt? I tried this approach as well. Although a good idea, it does not work because the default target of the subdirectories is not `all'. The default target of libbb/Makefile is libbb.a. Adding `busybox: busybox.bflt' changes the default target of libbb/Makefile from libbb.a to busybox. Cheers, Shaun From rob at landley.net Thu Jul 6 10:27:04 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 10:26:50 2006 Subject: Comments on svn 15657? Message-ID: <200607061327.04603.rob@landley.net> I added a couple of minor patches in http://busybox.net/downloads/patches/svn-15657.patch This saves a little over 1100 bytes building defconfig on Ubuntu, but I dunno if it's bad against current uClibc. I'm pondering a "prevent inlining" config option... The other thing this brings up is it adds yet another "check_cc" staza which is run every time Rules.mak is sucked in, and things like "make help" are getting painfully slow. Can anybody who's better at the build system than I am think of a way we can write this stuff out to a .config.cc file that Rules.mak can include and only regenerate (by calling the check_cc) stuff if it's not there? I have a vague idea how to go about it but would be happy to leave it to somebody who already knows make well... Rob -- Never bet against the cheap plastic solution. From mszick at morethan.org Thu Jul 6 10:20:42 2006 From: mszick at morethan.org (Michael S. Zick) Date: Thu Jul 6 11:37:01 2006 Subject: [PATCH] new applet: nmeter + Off Topic In-Reply-To: <200607061305.58116.rob@landley.net> References: <200607051831.57030.vda.linux@googlemail.com> <20060706154949.GA14152@aon.at> <200607061305.58116.rob@landley.net> Message-ID: <200607061220.42942.mszick@morethan.org> On Thu July 6 2006 12:05, Rob Landley wrote: > On Thursday 06 July 2006 11:49 am, Bernhard Fischer wrote: > > Looks better, yes. Still should there be the possibility to turn 2.6 or > > 2.4 support completely off? It would save at lease the int if not more.. > > If we add a global "enable 2.4 support" switch, then we should remember this > is here. > > I'm on the fence about whether a global "enable 2.6 support" switch makes > sense. Considering it won't ship in a release before December, so it's > effectively 2007 by then, I'm leaning against it. A 2.4 switch gives us > something to hide devfs names and devfsd behind, > Would it make sense then to start adding __attribute__((depreciated)) when code on the "endangered code" list is touched? MikeZ From rpjday at mindspring.com Thu Jul 6 11:39:33 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Thu Jul 6 11:41:07 2006 Subject: [PATCH] new applet: nmeter + Off Topic In-Reply-To: <200607061220.42942.mszick@morethan.org> References: <200607051831.57030.vda.linux@googlemail.com> <20060706154949.GA14152@aon.at> <200607061305.58116.rob@landley.net> <200607061220.42942.mszick@morethan.org> Message-ID: On Thu, 6 Jul 2006, Michael S. Zick wrote: > On Thu July 6 2006 12:05, Rob Landley wrote: > > On Thursday 06 July 2006 11:49 am, Bernhard Fischer wrote: > > > Looks better, yes. Still should there be the possibility to turn 2.6 or > > > 2.4 support completely off? It would save at lease the int if not more.. > > > > If we add a global "enable 2.4 support" switch, then we should remember this > > is here. > > > > I'm on the fence about whether a global "enable 2.6 support" switch makes > > sense. Considering it won't ship in a release before December, so it's > > effectively 2007 by then, I'm leaning against it. A 2.4 switch gives us > > something to hide devfs names and devfsd behind, > > > Would it make sense then to start adding > __attribute__((depreciated)) when code on the "endangered code" list > is touched? not to be overly pedantic (who, me?) but, once and for all, it's "deprecated", not "depreciated." yours in pedantry, rday From mszick at morethan.org Thu Jul 6 11:54:09 2006 From: mszick at morethan.org (Michael S. Zick) Date: Thu Jul 6 11:54:14 2006 Subject: [PATCH] new applet: nmeter + Off Topic In-Reply-To: References: <200607051831.57030.vda.linux@googlemail.com> <200607061220.42942.mszick@morethan.org> Message-ID: <200607061354.09859.mszick@morethan.org> On Thu July 6 2006 13:39, you wrote: > On Thu, 6 Jul 2006, Michael S. Zick wrote: > > > On Thu July 6 2006 12:05, Rob Landley wrote: > > > On Thursday 06 July 2006 11:49 am, Bernhard Fischer wrote: > > > > Looks better, yes. Still should there be the possibility to turn 2.6 or > > > > 2.4 support completely off? It would save at lease the int if not more.. > > > > > > If we add a global "enable 2.4 support" switch, then we should remember this > > > is here. > > > > > > I'm on the fence about whether a global "enable 2.6 support" switch makes > > > sense. Considering it won't ship in a release before December, so it's > > > effectively 2007 by then, I'm leaning against it. A 2.4 switch gives us > > > something to hide devfs names and devfsd behind, > > > > > Would it make sense then to start adding > > __attribute__((depreciated)) when code on the "endangered code" list > > is touched? > > not to be overly pedantic (who, me?) but, once and for all, it's > "deprecated", not "depreciated." > I suppose a simple typo could have prevented you from finding the documentation. Notice you will need to enable this warning if wanted. Here is the option - spelled without the preceding '-': `deprecated' The `deprecated' attribute results in a warning if the variable is used anywhere in the source file. This is useful when identifying variables that are expected to be removed in a future version of a program. The warning also includes the location of the declaration of the deprecated variable, to enable users to easily find further information about why the variable is deprecated, or what they should do instead. Note that the warning only occurs for uses: extern int old_var __attribute__ ((deprecated)); extern int old_var; int new_fn () { return old_var; } results in a warning on line 3 but not line 2. The `deprecated' attribute can also be used for functions and types (*note Function Attributes::, *note Type Attributes::.) > yours in pedantry, > rday > No problem, I know I am not the only person to make typos. > > Mike From dalias at aerifal.cx Thu Jul 6 12:18:32 2006 From: dalias at aerifal.cx (Rich Felker) Date: Thu Jul 6 12:06:06 2006 Subject: exporting argc/argv to applets In-Reply-To: <200607061159.37833.rob@landley.net> References: <20060702133654.GJ21958@aon.at> <200607061159.37833.rob@landley.net> Message-ID: <20060706191832.GJ24607@brightrain.aerifal.cx> On Thu, Jul 06, 2006 at 11:59:37AM -0400, Rob Landley wrote: > On Sunday 02 July 2006 9:36 am, Bernhard Fischer wrote: > > Hi, > > > > FYI, I've been pondering ?) landley's suggestion to export argc > > and argv globally, so we wouldn't have to pass it around as arguments. > > > > From a cursory look, this doesn't seem to be a good idea, though: > > I didn't say it was a good idea, just an idea. :) > > > text data bss dec hex filename > > 862418 10156 644740 1517314 172702 busybox.old > > 865586 10156 644708 1520450 173342 busybox > > > > Could very well be that i did something wrong/incomplete, admittedly. > > On x86 especially, registers are a scarce resource. It turns out to be > smaller to deal with all stack variables (sp+offset) or all global variables > (bp+offset). Global variables are not bp+offset, just fixed address. The difference in size to access them is that sp+offset requires only one byte for the offset when it fits in a (signed) byte, but global variables will always have their addresses coded as 4 bytes. > Switching back and forth between the two seems to result in > bigger code. I dunno if it confuses the optimizer or if it's just a hard > problem in a register starved environment like x86. Never observed this.. can you elaborate? > I'd have thought the savings from yanking the arguments from all the main() > functions would have overcome that, though... Yes I'm a bit surprised too... Rich From dalias at aerifal.cx Thu Jul 6 12:22:11 2006 From: dalias at aerifal.cx (Rich Felker) Date: Thu Jul 6 12:09:41 2006 Subject: [PATCH] new applet: nmeter In-Reply-To: <200607061737.28620.vda.linux@googlemail.com> References: <200607051831.57030.vda.linux@googlemail.com> <200607052158.53686.vda.linux@googlemail.com> <20060705213122.GF1102@aon.at> <200607061737.28620.vda.linux@googlemail.com> Message-ID: <20060706192211.GK24607@brightrain.aerifal.cx> On Thu, Jul 06, 2006 at 05:37:28PM +0200, Denis Vlasenko wrote: > On Wednesday 05 July 2006 23:31, Bernhard Fischer wrote: > > >> looks rather large relative to what it does. > > > > > >Biggest functions are: > > > > > >+00000040 t simple_itoa > > > > erm, we already have *several* itoa in there: > > msh, hush, ash?, lash, netstat > > > Adding yet another impl stikes me as not really optimal. I can see that > > they have different maximum supported lengths, but they should be > > unified nevertheless. Please do not add yet another one.. > > It's a bit special. It puts string > at the _end_ of provided buffer, > and pads it with zeroes to specified width: Yes, but this is an implementation detail. AFAIK the caller need not rely on it working this way. > Prototype is rather different from standard itoa. There's no such thing as standard itoa. > If I will switch to standard itoa, bloat will simply migrate > to callsites instead (strlen, strncpy etc...). I prefer > to have my own which does exactly what I need. Eh? These functions are being linked anyway. Rich From vapier at gentoo.org Thu Jul 6 12:35:10 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu Jul 6 12:35:04 2006 Subject: Comments on svn 15657? In-Reply-To: <200607061327.04603.rob@landley.net> References: <200607061327.04603.rob@landley.net> Message-ID: <200607061535.11478.vapier@gentoo.org> On Thursday 06 July 2006 13:27, Rob Landley wrote: > I added a couple of minor patches in > http://busybox.net/downloads/patches/svn-15657.patch 404: Objekt nicht gefunden! -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/8af59cb7/attachment.pgp From erik_frederiksen at pmc-sierra.com Thu Jul 6 12:29:46 2006 From: erik_frederiksen at pmc-sierra.com (Erik Frederiksen) Date: Thu Jul 6 12:36:35 2006 Subject: [PATCH] Allows tar to extract from archives with pax extensions Message-ID: <1152214186.19583.5474.camel@girvin.pmc-sierra.bc.ca> This patch allows busybox tar to extract tar archives that use the pax extensions. I noticed that old versions of GNU tar extract the pax_global_header file as a regular file and duplicated that behaviour. Here's a few of Linus' thoughts on the situation. http://lkml.org/lkml/2005/6/18/5 I originally wrote this for 1.0, but the patch applied to 1.2 with no problems. I look forward to hearing your comments. Erik Frederiksen Firmware Design Engineer Co-op PMC-Sierra Saskatoon --- a/archival/libunarchive/get_header_tar.c 2005-08-16 19:29:11.000000000 -0600 +++ b/archival/libunarchive/get_header_tar.c 2006-07-06 11:47:29.000000000 -0600 @@ -144,8 +144,15 @@ file_header->mode |= S_IFREG; break; case 'x': + bb_error_msg_and_die( "pax is not tar" ); + break; case 'g': - bb_error_msg_and_die("pax is not tar"); + bb_error_msg( + "%s: Unknown file type '%c', treating as a regular file.", + file_header->name, + tar.formated.typeflag + ); + file_header->mode |= S_IFREG; break; case '7': /* Reserved for high performance files, treat as normal file */ From yann.morin.1998 at anciens.enib.fr Thu Jul 6 12:40:56 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Thu Jul 6 12:41:02 2006 Subject: [BusyBox 0000889]: modprobe won't use ' * ' symbols modules.alias In-Reply-To: <99abd967ba03a5d553e23d9a27ce106f@bugs.busybox.net> References: <99abd967ba03a5d553e23d9a27ce106f@bugs.busybox.net> Message-ID: <200607062140.56895.yann.morin.1998@anciens.enib.fr> Hello all? On Thursday 06 July 2006 213, bugs@busybox.net wrote: > http://busybox.net/bugs/view.php?id=889 Could someone with sufficient access to the bug tracker close this one for good? Or, if you trust me enough not to turn this /thing/ into a mess, give me the needed rights? Thank you, 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 | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? From rob at landley.net Thu Jul 6 13:03:34 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 13:03:20 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607060948n5cd7bd52madee07c2b20d2d02@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607052024.29838.rob@landley.net> <7f45d9390607060948n5cd7bd52madee07c2b20d2d02@mail.gmail.com> Message-ID: <200607061603.35048.rob@landley.net> On Thursday 06 July 2006 12:48 pm, Shaun Jackman wrote: > On 7/5/06, Rob Landley wrote: > > How about busybox: busybox.bflt? > > I tried this approach as well. Although a good idea, it does not work > because the default target of the subdirectories is not `all'. The > default target of libbb/Makefile is libbb.a. Adding `busybox: > busybox.bflt' changes the default target of libbb/Makefile from > libbb.a to busybox. That's a sequencing issue. Try http://busybox.net/downloads/patches/svn-15659.patch > Cheers, > Shaun Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 13:06:06 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 13:05:51 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607060939t3b353b3p5be6b13510737676@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607061044.07970.rob@landley.net> <7f45d9390607060939t3b353b3p5be6b13510737676@mail.gmail.com> Message-ID: <200607061606.06353.rob@landley.net> On Thursday 06 July 2006 12:39 pm, Shaun Jackman wrote: > On 7/6/06, Rob Landley wrote: > > I'm trying to learn about git so we can have a toolset where all of us > > can work at full speed without stomping each other so much. My initramfs > > tutorial at OLS is sandwiched between two git tutorials, so that seems > > like a good time to come up to speed on it. :) > > I really don't want to start a version-control holy war -- honest -- > but I will mention that I've been using monotone to manage my busybox > patches and regularly merge with the svn trunk. It's been working > extremely well for me. I've been meaning to take a look at mercurial too. (I _tried_ to take a look at svk, but the udhcp change Mike tried to cram down my throat had broken it with the symlink thing, and I lost interest after the first week...) The thing is, the git tutorial is something I don't even have to schedule. I'm there anyway. And it's a skill I should probably pick up to follow kernel development better... *shrug* No rush... > Cheers, > Shaun Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 13:09:29 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 13:09:16 2006 Subject: [PATCH] new applet: nmeter + Off Topic In-Reply-To: <200607061220.42942.mszick@morethan.org> References: <200607051831.57030.vda.linux@googlemail.com> <200607061305.58116.rob@landley.net> <200607061220.42942.mszick@morethan.org> Message-ID: <200607061609.29937.rob@landley.net> On Thursday 06 July 2006 1:20 pm, Michael S. Zick wrote: > Would it make sense then to start adding __attribute__((depreciated)) when > code on the "endangered code" list is touched? So you want to _add_ warnings to the tree, for code that still works and is still supported (in current versions, even if it may be removed from future ones)? I dislike warnings. I wouldn't mind the -werror flag to make the darn build break if it hits a warning, because it's either a real problem or it should shut up about it, and there's not a whole lot of middle ground there. I especially dislike warnings that you're supposed to just ignore but can't shut up, since they make all other warnings useless. This would be a "no", I think. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 13:31:21 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 13:31:13 2006 Subject: [PATCH] Allows tar to extract from archives with pax extensions In-Reply-To: <1152214186.19583.5474.camel@girvin.pmc-sierra.bc.ca> References: <1152214186.19583.5474.camel@girvin.pmc-sierra.bc.ca> Message-ID: <200607061631.22058.rob@landley.net> On Thursday 06 July 2006 3:29 pm, Erik Frederiksen wrote: > This patch allows busybox tar to extract tar archives that use the pax > extensions. I noticed that old versions of GNU tar extract the > pax_global_header file as a regular file and duplicated that behaviour. > > Here's a few of Linus' thoughts on the situation. > http://lkml.org/lkml/2005/6/18/5 > > I originally wrote this for 1.0, but the patch applied to 1.2 with no > problems. I look forward to hearing your comments. > > Erik Frederiksen > Firmware Design Engineer Co-op > PMC-Sierra Saskatoon Ooh! My comment is "Applied", although I'm going to tweak it a bit first. Combining Linus's comment with the pax spec: http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html The question is what to do about 'x' records? > case 'x': > + bb_error_msg_and_die( "pax is not tar" ); > + break; > case 'g': > - bb_error_msg_and_die("pax is not tar"); > + bb_error_msg( > + "%s: Unknown file type '%c', treating as a regular file.", > + file_header->name, > + tar.formated.typeflag > + ); > + file_header->mode |= S_IFREG; Ideally I think we just want to ignore them... http://busybox.net/downloads/patches/svn-15660.patch And if that works for everybody else, it's going into 1.2.1. :) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 13:44:50 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 13:44:38 2006 Subject: [BusyBox 0000889]: modprobe won't use ' * ' symbols modules.alias In-Reply-To: <200607062140.56895.yann.morin.1998@anciens.enib.fr> References: <99abd967ba03a5d553e23d9a27ce106f@bugs.busybox.net> <200607062140.56895.yann.morin.1998@anciens.enib.fr> Message-ID: <200607061644.50987.rob@landley.net> On Thursday 06 July 2006 3:40 pm, Yann E. MORIN wrote: > Hello all? > > On Thursday 06 July 2006 213, bugs@busybox.net wrote: > > http://busybox.net/bugs/view.php?id=889 > > Could someone with sufficient access to the bug tracker close this one for > good? > > Or, if you trust me enough not to turn this /thing/ into a mess, give me > the needed rights? I'm happy to give you developer access to the bug generator, but I dunno how. I just asked Erik... Rob -- Never bet against the cheap plastic solution. From erik_frederiksen at pmc-sierra.com Thu Jul 6 13:45:47 2006 From: erik_frederiksen at pmc-sierra.com (Erik Frederiksen) Date: Thu Jul 6 13:45:54 2006 Subject: [PATCH] Allows tar to extract from archives with pax extensions In-Reply-To: <200607061631.22058.rob@landley.net> References: <200607061631.22058.rob@landley.net> Message-ID: <1152218747.19578.5488.camel@girvin.pmc-sierra.bc.ca> On Thu, 2006-07-06 at 14:31, Rob Landley wrote: > > Ooh! > > My comment is "Applied", although I'm going to tweak it a bit first. > > Combining Linus's comment with the pax spec: > http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html > > The question is what to do about 'x' records? > > > case 'x': > > + bb_error_msg_and_die( "pax is not tar" ); > > + break; > > case 'g': > > - bb_error_msg_and_die("pax is not tar"); > > + bb_error_msg( > > + "%s: Unknown file type '%c', treating as a regular > file.", > > + file_header->name, > > + tar.formated.typeflag > > + ); > > + file_header->mode |= S_IFREG; > > Ideally I think we just want to ignore them... Yeah, ignoring the 'x' files sounds about right. In retrospect I should have changed that "pax is not tar" message. Ah, maybe next time. :) > http://busybox.net/downloads/patches/svn-15660.patch > > And if that works for everybody else, it's going into 1.2.1. :) Fantastic. I hope this helps. -erik -- Erik Frederiksen Firmware Design Engineer Co-op PMC-Sierra Saskatoon From natanael.copa at gmail.com Thu Jul 6 13:50:38 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jul 6 13:50:49 2006 Subject: bug in dmesg parameter parsing (busybox 1.2.0) In-Reply-To: <200607061256.48539.rob@landley.net> References: <1152194352.9893.8.camel@localhost> <20060706143809.GA12708@aon.at> <1152198014.13043.9.camel@localhost> <200607061256.48539.rob@landley.net> Message-ID: <1152219038.13043.46.camel@localhost> On Thu, 2006-07-06 at 12:56 -0400, Rob Landley wrote: > On Thursday 06 July 2006 11:00 am, Natanael Copa wrote: > > Thanks! > > > > Would be nice to have this fixed in 1.2.1. > > The three patches currently pending for 1.2.1 are up: > > http://busybox.net/downloads/busybox-1.2.0.fixes.patch > > No immediate plans to release 1.2.1 yet though. Still waiting to see what > else shakes out... great! Thanks! -- Natanael Copa From rob at landley.net Thu Jul 6 13:52:10 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 13:51:54 2006 Subject: Comments on svn 15657? In-Reply-To: <200607061535.11478.vapier@gentoo.org> References: <200607061327.04603.rob@landley.net> <200607061535.11478.vapier@gentoo.org> Message-ID: <200607061652.10223.rob@landley.net> On Thursday 06 July 2006 3:35 pm, Mike Frysinger wrote: > On Thursday 06 July 2006 13:27, Rob Landley wrote: > > I added a couple of minor patches in > > http://busybox.net/downloads/patches/svn-15657.patch > > 404: Objekt nicht gefunden! > -mike Sigh, try now. I forgot to run my bb-update script. (And ironically, I've been poking at morris trying to figure out where to point a file:// URL to get the svn files locally so I can host my script there from an svn trigger, so this is automatic. I have _no_ idea where the svn repository on this thing actually _is_, but I printed out all 300+ pages of the SVN manual at Timesys' expense and have slowly been using a 3 ring hole punch to fit them in a honkin' big binder. It's got to be in there somewhere...) Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Thu Jul 6 15:31:31 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Thu Jul 6 15:31:38 2006 Subject: Building additional binaries In-Reply-To: <200607061603.35048.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607052024.29838.rob@landley.net> <7f45d9390607060948n5cd7bd52madee07c2b20d2d02@mail.gmail.com> <200607061603.35048.rob@landley.net> Message-ID: <7f45d9390607061531i3bccd3acq740583740f379411@mail.gmail.com> On 7/6/06, Rob Landley wrote: > That's a sequencing issue. > > Try http://busybox.net/downloads/patches/svn-15659.patch Yep, that would work. Of course, `all:' would have to be added to every subdirectory Makefile, but that's not a huge issue I suppose. Cheers, Shaun From rob at landley.net Thu Jul 6 15:48:06 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 15:47:55 2006 Subject: Building additional binaries In-Reply-To: <7f45d9390607061531i3bccd3acq740583740f379411@mail.gmail.com> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607061603.35048.rob@landley.net> <7f45d9390607061531i3bccd3acq740583740f379411@mail.gmail.com> Message-ID: <200607061848.06782.rob@landley.net> On Thursday 06 July 2006 6:31 pm, Shaun Jackman wrote: > On 7/6/06, Rob Landley wrote: > > That's a sequencing issue. > > > > Try http://busybox.net/downloads/patches/svn-15659.patch > > Yep, that would work. Of course, `all:' would have to be added to > every subdirectory Makefile, but that's not a huge issue I suppose. > > Cheers, > Shaun I'll happily merge a patch, but I don't build in subdirectories... Rob -- Never bet against the cheap plastic solution. From yh at bizmail.com.au Thu Jul 6 16:06:36 2006 From: yh at bizmail.com.au (yh@bizmail.com.au) Date: Thu Jul 6 15:55:09 2006 Subject: insmod module.ko In-Reply-To: <20060706115503.GC9309@aon.at> References: <44ACE8A4.90106@bizmail.com.au> <20060706105845.GA8585@aon.at> <44ACF5A0.3060905@bizmail.com.au> <20060706115503.GC9309@aon.at> Message-ID: <4498.203.217.29.133.1152227196.squirrel@203.217.29.133> Thanks Bernhard. I enabled kernel 2.6, but could not build it, please see following errors from applets.a. Will a "make clean" fix it? Or, I might be missing some other things? undefined reference to `chgrp_main' undefined reference to `chown_main' undefined reference to `chvt_main' undefined reference to `id_main' undefined reference to `openvt_main' undefined reference to `readlink_main' undefined reference to `swap_on_off_main' undefined reference to `swap_on_off_main' undefined reference to `whoami_main' collect2: ld returned 1 exit status make[2]: *** [busybox] Error 1 > On Thu, Jul 06, 2006 at 09:36:00PM +1000, YH wrote: >>Thanks Bernhard, but sorry I am new to BusyBox, could you explain me >>more on how to enable 2.6 in BusyBox? > > make menuconfig > go to "Linux Module Utilities" > and set "Support version 2.6.x Linux kernels" > > From sjackman at gmail.com Thu Jul 6 16:49:54 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Thu Jul 6 16:49:59 2006 Subject: Resetting getopt Message-ID: <7f45d9390607061649l56d39fc9ya182e2a7eb58c4d3@mail.gmail.com> There seems to be a bug in every applet -- mostly shells -- that attempt to reset getopt. They all set `optind = 1;', but the getopt implementations I've read (uClibc and newlib) use the test `if (optind == 0)' to reset the getopt internals. Specifically, the static pointer that iterates through short options needs resetting. I'd recommended changing all the occurrences of `optind = 1;' to `optind = 0;'. Any thoughts of any complications this could cause? The only one I can think of is a possibly errant applet that depends on optind == 1 *before* getopt is called. All will be fine after getopt is called for the first time. Cheers, Shaun From vapier at gentoo.org Thu Jul 6 17:31:54 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu Jul 6 17:31:48 2006 Subject: insmod module.ko In-Reply-To: <4498.203.217.29.133.1152227196.squirrel@203.217.29.133> References: <44ACE8A4.90106@bizmail.com.au> <20060706115503.GC9309@aon.at> <4498.203.217.29.133.1152227196.squirrel@203.217.29.133> Message-ID: <200607062031.54698.vapier@gentoo.org> On Thursday 06 July 2006 19:06, yh@bizmail.com.au wrote: > Thanks Bernhard. I enabled kernel 2.6, but could not build it, please see > following errors from applets.a. Will a "make clean" fix it? yes, after changing .config you always need to run `make clean` first -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/e15d2c9f/attachment.pgp From vapier at gentoo.org Thu Jul 6 17:34:54 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu Jul 6 17:34:46 2006 Subject: exporting argc/argv to applets In-Reply-To: <20060706191832.GJ24607@brightrain.aerifal.cx> References: <20060702133654.GJ21958@aon.at> <200607061159.37833.rob@landley.net> <20060706191832.GJ24607@brightrain.aerifal.cx> Message-ID: <200607062034.55469.vapier@gentoo.org> On Thursday 06 July 2006 15:18, Rich Felker wrote: > Global variables are not bp+offset, just fixed address. that depends on your build ... with a non-pic binary this is correct throw in the shared busybox lib and it all goes to hell ;) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/3c9e88c5/attachment.pgp From rob at landley.net Thu Jul 6 18:32:38 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 18:32:28 2006 Subject: insmod module.ko In-Reply-To: <200607062031.54698.vapier@gentoo.org> References: <44ACE8A4.90106@bizmail.com.au> <4498.203.217.29.133.1152227196.squirrel@203.217.29.133> <200607062031.54698.vapier@gentoo.org> Message-ID: <200607062132.38446.rob@landley.net> On Thursday 06 July 2006 8:31 pm, Mike Frysinger wrote: > On Thursday 06 July 2006 19:06, yh@bizmail.com.au wrote: > > Thanks Bernhard. I enabled kernel 2.6, but could not build it, please see > > following errors from applets.a. Will a "make clean" fix it? > > yes, after changing .config you always need to run `make clean` first I have a todo item to fix that, but it's way down the list... > -mike Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jul 6 18:33:38 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 18:33:28 2006 Subject: Resetting getopt In-Reply-To: <7f45d9390607061649l56d39fc9ya182e2a7eb58c4d3@mail.gmail.com> References: <7f45d9390607061649l56d39fc9ya182e2a7eb58c4d3@mail.gmail.com> Message-ID: <200607062133.39187.rob@landley.net> On Thursday 06 July 2006 7:49 pm, Shaun Jackman wrote: > There seems to be a bug in every applet -- mostly shells -- that > attempt to reset getopt. They all set `optind = 1;', but the getopt > implementations I've read (uClibc and newlib) use the test `if (optind > == 0)' to reset the getopt internals. Specifically, the static pointer > that iterates through short options needs resetting. I'd recommended > changing all the occurrences of `optind = 1;' to `optind = 0;'. Any > thoughts of any complications this could cause? The only one I can > think of is a possibly errant applet that depends on optind == 1 > *before* getopt is called. All will be fine after getopt is called for > the first time. Resetting it to 0 should be fine. Any applet that depends on the value of optind before calling getopt is buggy. Rob -- Never bet against the cheap plastic solution. From vapier at gentoo.org Thu Jul 6 18:37:20 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu Jul 6 18:37:12 2006 Subject: insmod module.ko In-Reply-To: <200607062132.38446.rob@landley.net> References: <44ACE8A4.90106@bizmail.com.au> <200607062031.54698.vapier@gentoo.org> <200607062132.38446.rob@landley.net> Message-ID: <200607062137.20701.vapier@gentoo.org> On Thursday 06 July 2006 21:32, Rob Landley wrote: > On Thursday 06 July 2006 8:31 pm, Mike Frysinger wrote: > > On Thursday 06 July 2006 19:06, yh@bizmail.com.au wrote: > > > Thanks Bernhard. I enabled kernel 2.6, but could not build it, please > > > see following errors from applets.a. Will a "make clean" fix it? > > > > yes, after changing .config you always need to run `make clean` first > > I have a todo item to fix that, but it's way down the list... i always wondered how the kernel was so smart about it -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060706/434cb9de/attachment.pgp From rob at landley.net Thu Jul 6 18:54:01 2006 From: rob at landley.net (Rob Landley) Date: Thu Jul 6 18:53:49 2006 Subject: insmod module.ko In-Reply-To: <200607062137.20701.vapier@gentoo.org> References: <44ACE8A4.90106@bizmail.com.au> <200607062132.38446.rob@landley.net> <200607062137.20701.vapier@gentoo.org> Message-ID: <200607062154.01894.rob@landley.net> On Thursday 06 July 2006 9:37 pm, Mike Frysinger wrote: > On Thursday 06 July 2006 21:32, Rob Landley wrote: > > On Thursday 06 July 2006 8:31 pm, Mike Frysinger wrote: > > > On Thursday 06 July 2006 19:06, yh@bizmail.com.au wrote: > > > > Thanks Bernhard. I enabled kernel 2.6, but could not build it, please > > > > see following errors from applets.a. Will a "make clean" fix it? > > > > > > yes, after changing .config you always need to run `make clean` first > > > > I have a todo item to fix that, but it's way down the list... > > i always wondered how the kernel was so smart about it > -mike It's in the kernel docs: http://www.mjmwired.net/kernel/Documentation/smart-config.txt Our current config infrastructure has copied part of that, but not all of it. I just submitted an improved miniconfig patch to linux-kernel, and my next task is to resync the busybox config stuff with the current kernel .config stuff. Rewriting the dependency checking comes after that, but _also_ after finishing my mke2fs/gene2fs/tune2fs/chattr rewrite (but I'm not touching e2fsck right now) and bbsh, and finishing up the sed nul fix and the passwd thing. _Then_ I can worry about taking on a new project. (Which will probably be a rewrite of fdisk, but oh well. And then I've got to untangle the archiver shared infrastructure, add cpio creation and maybe mkisofs, dig up the old bzip2 rewrite I did... Oh, and tackle the TODO list...) Rob -- Never bet against the cheap plastic solution. From floydpink at gmail.com Thu Jul 6 18:47:22 2006 From: floydpink at gmail.com (Jason Schoon) Date: Thu Jul 6 18:54:00 2006 Subject: insmod module.ko In-Reply-To: <200607062137.20701.vapier@gentoo.org> References: <44ACE8A4.90106@bizmail.com.au> <200607062031.54698.vapier@gentoo.org> <200607062132.38446.rob@landley.net> <200607062137.20701.vapier@gentoo.org> Message-ID: <78a54e1b0607061847i6c68185ya869fd0b1767e003@mail.gmail.com> On 7/6/06, Mike Frysinger wrote: > > On Thursday 06 July 2006 21:32, Rob Landley wrote: > > On Thursday 06 July 2006 8:31 pm, Mike Frysinger wrote: > > > On Thursday 06 July 2006 19:06, yh@bizmail.com.au wrote: > > > > Thanks Bernhard. I enabled kernel 2.6, but could not build it, > please > > > > see following errors from applets.a. Will a "make clean" fix it? > > > > > > yes, after changing .config you always need to run `make clean` first > > > > I have a todo item to fix that, but it's way down the list... > > i always wondered how the kernel was so smart about it > -mike Without looking, I'm guessing that they have more explicit dependencies than we currently generate. On a sidenote, in my experience they aren't perfect either. Getting my initramfs to rebuild has sometimes required nothing short of blasting my directory clean and starting over. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060706/7a600937/attachment.html From dalias at aerifal.cx Thu Jul 6 22:08:03 2006 From: dalias at aerifal.cx (Rich Felker) Date: Thu Jul 6 21:55:39 2006 Subject: exporting argc/argv to applets In-Reply-To: <200607062034.55469.vapier@gentoo.org> References: <20060702133654.GJ21958@aon.at> <200607061159.37833.rob@landley.net> <20060706191832.GJ24607@brightrain.aerifal.cx> <200607062034.55469.vapier@gentoo.org> Message-ID: <20060707050803.GL24607@brightrain.aerifal.cx> On Thu, Jul 06, 2006 at 08:34:54PM -0400, Mike Frysinger wrote: > On Thursday 06 July 2006 15:18, Rich Felker wrote: > > Global variables are not bp+offset, just fixed address. > > that depends on your build ... with a non-pic binary this is correct Yes we're talking about i386 which always has MMU (afaik anyway), so building with PIC would be rather stupid.. > throw in the shared busybox lib and it all goes to hell ;) Also sounds like a very bad idea.. Rich From wharms at bfs.de Fri Jul 7 00:33:54 2006 From: wharms at bfs.de (walter harms) Date: Fri Jul 7 00:34:05 2006 Subject: [PATCH] add -size for find Message-ID: <44AE0E62.3080303@bfs.de> hi list, for a project i needed find -size since bb does not support find i added it. the option can be switched on/off. patch for Config.in is attached. the patch is based on vanilla bb 1.2.0. re, wh -------------- next part -------------- A non-text attachment was scrubbed... Name: Config.in.diff Type: text/x-patch Size: 480 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060707/85a28cd8/Config.in.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: find.c.diff Type: text/x-patch Size: 1383 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060707/85a28cd8/find.c.bin From ps.m at gmx.net Fri Jul 7 00:45:39 2006 From: ps.m at gmx.net (Peter S. Mazinger) Date: Fri Jul 7 00:45:58 2006 Subject: Resetting getopt In-Reply-To: <7f45d9390607061649l56d39fc9ya182e2a7eb58c4d3@mail.gmail.com> Message-ID: On Thu, 6 Jul 2006, Shaun Jackman wrote: > There seems to be a bug in every applet -- mostly shells -- that > attempt to reset getopt. They all set `optind = 1;', but the getopt from the glibc getopt.c: /* 1003.2 says this must be 1 before any call */ int optind = 1; Peter > implementations I've read (uClibc and newlib) use the test `if (optind > == 0)' to reset the getopt internals. Specifically, the static pointer > that iterates through short options needs resetting. I'd recommended > changing all the occurrences of `optind = 1;' to `optind = 0;'. Any > thoughts of any complications this could cause? The only one I can > think of is a possibly errant applet that depends on optind == 1 > *before* getopt is called. All will be fine after getopt is called for > the first time. > > Cheers, > Shaun > > -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From mingching.tiew at redtone.com Fri Jul 7 03:54:58 2006 From: mingching.tiew at redtone.com (Ming-Ching Tiew) Date: Fri Jul 7 04:27:32 2006 Subject: dmesg has no output Message-ID: <024301c6a1b3$ca34e580$0100a8c0@newlife> I am wondering what I am doing wrong on my system. I testing with busybox-1.0, busybox-1.2.0 (patched), uclibc 0.9.28, and kernel 2.6.16, 2.6.17-2. Basically my problem is that I get no output from dmesg. # dmesg # echo $? 0 'cat /proc/kmsg' also shows nothing. I am ***NOT*** saying this is a busybox problem but perhaps someone in this list has a pointer what are the things I could look at to solve it. My areas of suspicion : 1. My kernel CONFIGs. Is there anything I have to set there to get 'dmesg' working ? 2. My device files. Is there anything particular device files I need to have ? 3. Busybox CONFIGs. Is there anything there I have to watch out for ? Thanks for your help in advance. From natanael.copa at gmail.com Fri Jul 7 04:43:31 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Fri Jul 7 04:43:39 2006 Subject: dmesg has no output In-Reply-To: <024301c6a1b3$ca34e580$0100a8c0@newlife> References: <024301c6a1b3$ca34e580$0100a8c0@newlife> Message-ID: <1152272611.13043.90.camel@localhost> On Fri, 2006-07-07 at 18:54 +0800, Ming-Ching Tiew wrote: > I am wondering what I am doing wrong on my system. > > I testing with busybox-1.0, busybox-1.2.0 (patched), uclibc 0.9.28, > and kernel 2.6.16, 2.6.17-2. Basically my problem is that I get no > output from dmesg. > > # dmesg > # echo $? > 0 > > 'cat /proc/kmsg' also shows nothing. I am ***NOT*** saying > this is a busybox problem but perhaps someone in this list has > a pointer what are the things I could look at to solve it. > > My areas of suspicion : > > 1. My kernel CONFIGs. Is there anything I have to set there > to get 'dmesg' working ? Make sure you have printk enabled in your kernel. General setup ---> Configure standard kernel features (for small systems) ---> [*] Enable support for printk From dalias at aerifal.cx Fri Jul 7 05:34:26 2006 From: dalias at aerifal.cx (Rich Felker) Date: Fri Jul 7 05:21:46 2006 Subject: Resetting getopt In-Reply-To: References: <7f45d9390607061649l56d39fc9ya182e2a7eb58c4d3@mail.gmail.com> Message-ID: <20060707123426.GQ24607@brightrain.aerifal.cx> On Fri, Jul 07, 2006 at 09:45:39AM +0200, Peter S. Mazinger wrote: > On Thu, 6 Jul 2006, Shaun Jackman wrote: > > > There seems to be a bug in every applet -- mostly shells -- that > > attempt to reset getopt. They all set `optind = 1;', but the getopt > > from the glibc getopt.c: > /* 1003.2 says this must be 1 before any call */ > int optind = 1; This is expressing a requirement on the implementation, not a requirement on the application. Rich From mszick at morethan.org Fri Jul 7 06:38:16 2006 From: mszick at morethan.org (Michael S. Zick) Date: Fri Jul 7 06:38:29 2006 Subject: [PATCH] new applet: nmeter + Off Topic In-Reply-To: <200607061609.29937.rob@landley.net> References: <200607051831.57030.vda.linux@googlemail.com> <200607061220.42942.mszick@morethan.org> <200607061609.29937.rob@landley.net> Message-ID: <200607070838.16264.mszick@morethan.org> On Thu July 6 2006 15:09, Rob Landley wrote: > > I especially dislike warnings that you're supposed to just ignore but can't > shut up, since they make all other warnings useless. > > This would be a "no", I think. > Since it is controllable with its very own switch, I was thinking that it could be enabled with the other "non-release warnings" flags. I.E: You can shut it up. Not so much as a: "warning" but as: "advanced notice" that might trigger any: "we just got to have that" mails on the subject. But it seems to be a rare beast - can't say I have seen it used outside of the gcc source myself. So if it doesn't fit with your plans - super! > Rob Mike From sjackman at gmail.com Fri Jul 7 10:37:50 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Fri Jul 7 10:38:01 2006 Subject: [PATCH] Resetting getopt In-Reply-To: <200607062133.39187.rob@landley.net> References: <7f45d9390607061649l56d39fc9ya182e2a7eb58c4d3@mail.gmail.com> <200607062133.39187.rob@landley.net> Message-ID: <7f45d9390607071037q38559b17nec84d8fa7092a8a9@mail.gmail.com> On 7/6/06, Rob Landley wrote: > On Thursday 06 July 2006 7:49 pm, Shaun Jackman wrote: > > There seems to be a bug in every applet -- mostly shells -- that > > attempt to reset getopt. They all set `optind = 1;', but the getopt > > implementations I've read (uClibc and newlib) use the test `if (optind > > == 0)' to reset the getopt internals. Specifically, the static pointer > > that iterates through short options needs resetting. I'd recommended > > changing all the occurrences of `optind = 1;' to `optind = 0;'. Any > > thoughts of any complications this could cause? The only one I can > > think of is a possibly errant applet that depends on optind == 1 > > *before* getopt is called. All will be fine after getopt is called for > > the first time. > > Resetting it to 0 should be fine. Any applet that depends on the value of > optind before calling getopt is buggy. As discussed above. Please apply. Cheers, Shaun 2006-07-07 Shaun Jackman * archival/gzip.c: Set optind to 0 before calling getopt. * shell/hush.c: Ditto. * shell/lash.c: Ditto. * shell/msh.c: Ditto. --- archival/gzip.c 672bf03d09e8a91b2e710ca4b94ad2e1a333a774 +++ archival/gzip.c 61c04f49b251c814533549686870048e7708f3fd @@ -1153,7 +1153,7 @@ break; #ifdef CONFIG_GUNZIP case 'd': - optind = 1; + optind = 0; return gunzip_main(argc, argv); #endif default: ============================================================ --- shell/hush.c 5eb0f818c6816893a800208274529061be8cfdd1 +++ shell/hush.c 0e1bc4709222683ff33a1dd747956812d4ccb68a @@ -1108,7 +1108,7 @@ /* Count argc for use in a second... */ for(argc_l=0;*argv_l!=NULL; argv_l++, argc_l++); - optind = 1; + optind = 0; debug_printf("running applet %s\n", name); run_applet_by_name(name, argc_l, child->argv); } ============================================================ --- shell/lash.c d8a568319f0f16f25eaa53770b926f927760e891 +++ shell/lash.c 6280109425b1028a3daf73149bba5d4ef9615da2 @@ -1207,7 +1207,7 @@ int argc_l; for(argc_l=0; *argv_l; argv_l++, argc_l++); - optind = 1; + optind = 0; run_applet_by_name(child->argv[0], argc_l, child->argv); } ============================================================ --- shell/msh.c 6641c546644723bb90fe10772688fa1ec94d76d2 +++ shell/msh.c 7beff8013493adbebb7e7480037fb62dff408232 @@ -3169,7 +3169,7 @@ #ifdef CONFIG_FEATURE_SH_STANDALONE_SHELL char *name = c; - optind = 1; + optind = 0; if (find_applet_by_name(name)) { /* We have to exec here since we vforked. Running * run_applet_by_name() won't work and bad things -------------- next part -------------- 2006-07-07 Shaun Jackman * archival/gzip.c: Set optind to 0 before calling getopt. * shell/hush.c: Ditto. * shell/lash.c: Ditto. * shell/msh.c: Ditto. * shell/ash.c: Ditto. --- archival/gzip.c 672bf03d09e8a91b2e710ca4b94ad2e1a333a774 +++ archival/gzip.c 61c04f49b251c814533549686870048e7708f3fd @@ -1153,7 +1153,7 @@ break; #ifdef CONFIG_GUNZIP case 'd': - optind = 1; + optind = 0; return gunzip_main(argc, argv); #endif default: ============================================================ --- shell/hush.c 5eb0f818c6816893a800208274529061be8cfdd1 +++ shell/hush.c 0e1bc4709222683ff33a1dd747956812d4ccb68a @@ -1108,7 +1108,7 @@ /* Count argc for use in a second... */ for(argc_l=0;*argv_l!=NULL; argv_l++, argc_l++); - optind = 1; + optind = 0; debug_printf("running applet %s\n", name); run_applet_by_name(name, argc_l, child->argv); } ============================================================ --- shell/lash.c d8a568319f0f16f25eaa53770b926f927760e891 +++ shell/lash.c 6280109425b1028a3daf73149bba5d4ef9615da2 @@ -1207,7 +1207,7 @@ int argc_l; for(argc_l=0; *argv_l; argv_l++, argc_l++); - optind = 1; + optind = 0; run_applet_by_name(child->argv[0], argc_l, child->argv); } ============================================================ --- shell/msh.c 6641c546644723bb90fe10772688fa1ec94d76d2 +++ shell/msh.c 7beff8013493adbebb7e7480037fb62dff408232 @@ -3169,7 +3169,7 @@ #ifdef CONFIG_FEATURE_SH_STANDALONE_SHELL char *name = c; - optind = 1; + optind = 0; if (find_applet_by_name(name)) { /* We have to exec here since we vforked. Running * run_applet_by_name() won't work and bad things From sjackman at gmail.com Fri Jul 7 10:55:58 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Fri Jul 7 10:56:07 2006 Subject: bb_opt_complementally and STANDALONE_SHELL Message-ID: <7f45d9390607071055t182885d5yf8f3080dba779203@mail.gmail.com> When STANDALONE_SHELL is used on a vfork system, if an applet sets bb_opt_complementally, it will remain set when the shell calls the next applet. This issue is similar to the shell needing to clear optind before calling the next applet. Either bb_opt_complementally could be cleared in the same place that optind is cleared, or bb_opt_complementally could become an argument to bb_getopt_ulflags, which is arguably the cleaner choice. The parameter bb_applet_long_options suffers from the same situation. Proposal... extern const char *bb_opt_complementally; extern const struct option *bb_applet_long_options; extern unsigned long bb_getopt_ulflags(int argc, char **argv, const char *applet_opts, ...); ... becomes... extern unsigned long bb_getopt_ulflags(int argc, char **argv, const char *applet_opts, const char *bb_opt_complementally, const struct option *bb_applet_long_options, ...); Opinions? As a nice bonus, we can finally fix the spelling of complementally [sic]. Cheers, Shaun From sjackman at gmail.com Fri Jul 7 11:08:57 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Fri Jul 7 11:09:04 2006 Subject: bb_opt_complementally and STANDALONE_SHELL In-Reply-To: <7f45d9390607071055t182885d5yf8f3080dba779203@mail.gmail.com> References: <7f45d9390607071055t182885d5yf8f3080dba779203@mail.gmail.com> Message-ID: <7f45d9390607071108v2afaf793y9c3372b116859a19@mail.gmail.com> On 7/7/06, Shaun Jackman wrote: > When STANDALONE_SHELL is used on a vfork system, if an applet sets > bb_opt_complementally, it will remain set when the shell calls the > next applet. This issue is similar to the shell needing to clear > optind before calling the next applet. Either bb_opt_complementally > could be cleared in the same place that optind is cleared, or ... If changing the prototype of bb_getopt_ulflags seems to invasive, I propose this patch as an alternative. It works for me. Cheers, Shaun 2006-07-07 Shaun Jackman * shell/lash.c (pseudo_exec) [ENABLE_FEATURE_SH_STANDALONE_SHELL]: Clear bb_opt_complementally and bb_applet_long_options. --- shell/lash.c 6280109425b1028a3daf73149bba5d4ef9615da2 +++ shell/lash.c 77d0a727eb06192ad0dfdbd830c349ed0979f5ff @@ -1208,6 +1208,8 @@ for(argc_l=0; *argv_l; argv_l++, argc_l++); optind = 0; + bb_opt_complementally = NULL; + bb_applet_long_options = NULL; run_applet_by_name(child->argv[0], argc_l, child->argv); } -------------- next part -------------- 2006-07-07 Shaun Jackman * shell/lash.c (pseudo_exec) [ENABLE_FEATURE_SH_STANDALONE_SHELL]: Clear bb_opt_complementally and bb_applet_long_options. --- shell/lash.c 6280109425b1028a3daf73149bba5d4ef9615da2 +++ shell/lash.c 77d0a727eb06192ad0dfdbd830c349ed0979f5ff @@ -1208,6 +1208,8 @@ for(argc_l=0; *argv_l; argv_l++, argc_l++); optind = 0; + bb_opt_complementally = NULL; + bb_applet_long_options = NULL; run_applet_by_name(child->argv[0], argc_l, child->argv); } From tonyb at thekrnl.sysdev.org Fri Jul 7 11:36:32 2006 From: tonyb at thekrnl.sysdev.org (Hufnus) Date: Fri Jul 7 11:44:40 2006 Subject: Where in make menuconfig enables PRINTK Message-ID: <20060707103632.20301ae8.tonyb@sysdev.org> I cant find where to CONFIG PRINTK Y with kernel 2.4.33-rc2 menuconfig, so that busybox dmesg starts working... Any one knows under what menu that is located? thanks TonyB Fall is my favorite season in Los Angeles, watching the birds change color and fall from the trees. David Letterman (1947 - ) -- __ __ _ I N C. http://www.sysdev.org / __|\\// __|| \ __ __ / tonyb@sysdev.org \__ \ \/\__ \||)|/ O_)\/ / \/ System Tools / Utilities |___/ || ___/|_ /\___|\_/ WIntel / Linux Device Drivers From vapier at gentoo.org Fri Jul 7 13:09:04 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Fri Jul 7 13:08:53 2006 Subject: exporting argc/argv to applets In-Reply-To: <20060707050803.GL24607@brightrain.aerifal.cx> References: <20060702133654.GJ21958@aon.at> <200607062034.55469.vapier@gentoo.org> <20060707050803.GL24607@brightrain.aerifal.cx> Message-ID: <200607071609.04768.vapier@gentoo.org> On Friday 07 July 2006 01:08, Rich Felker wrote: > On Thu, Jul 06, 2006 at 08:34:54PM -0400, Mike Frysinger wrote: > > On Thursday 06 July 2006 15:18, Rich Felker wrote: > > > Global variables are not bp+offset, just fixed address. > > > > that depends on your build ... with a non-pic binary this is correct > > Yes we're talking about i386 which always has MMU (afaik anyway), so > building with PIC would be rather stupid.. not really, building busybox as a PIE in a standalone system gives some nice benefits actually due to the ability to share the relocatable code segment > > throw in the shared busybox lib and it all goes to hell ;) > > Also sounds like a very bad idea.. not when you're pressured to reduce runtime memory overhead -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060707/49bcf473/attachment.pgp From vapier at gentoo.org Fri Jul 7 13:12:13 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Fri Jul 7 13:11:59 2006 Subject: Where in make menuconfig enables PRINTK In-Reply-To: <20060707103632.20301ae8.tonyb@sysdev.org> References: <20060707103632.20301ae8.tonyb@sysdev.org> Message-ID: <200607071612.14218.vapier@gentoo.org> On Friday 07 July 2006 14:36, Hufnus wrote: > I cant find where to CONFIG PRINTK Y with kernel > 2.4.33-rc2 menuconfig, so that busybox dmesg starts working... try the linux arm kernel mailing list -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060707/2105c1b4/attachment.pgp From sjackman at gmail.com Fri Jul 7 15:03:56 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Fri Jul 7 15:04:04 2006 Subject: [PATCH]: lash: Bug fix. Avoid trying to open a NULL path. Message-ID: <7f45d9390607071503w2b5daae9j5478fb331aa0b027@mail.gmail.com> If lash starts up in non-interactive mode, it refuses to read its input from standard input. Instead it will attempt to open argv[optind], which may be NULL. Cheers, Shaun 2006-07-07 Shaun Jackman * shell/lash.c (lash_main): Bug fix. Avoid trying to open a NULL path. --- shell/lash.c 77d0a727eb06192ad0dfdbd830c349ed0979f5ff +++ shell/lash.c 611e50bbcf9647bfe9bd63d5bc4e86fd03317a21 @@ -1604,7 +1604,7 @@ printf( "\n\n%s Built-in shell (lash)\n", BB_BANNER); printf( "Enter 'help' for a list of built-in commands.\n\n"); #endif - } else if (local_pending_command==NULL) { + } else if (local_pending_command==NULL && argv[optind] != NULL) { //printf( "optind=%d argv[optind]='%s'\n", optind, argv[optind]); input = bb_xfopen(argv[optind], "r"); /* be lazy, never mark this closed */ -------------- next part -------------- 2006-07-07 Shaun Jackman * shell/lash.c (lash_main): Bug fix. Avoid trying to open a NULL path. --- shell/lash.c 77d0a727eb06192ad0dfdbd830c349ed0979f5ff +++ shell/lash.c 611e50bbcf9647bfe9bd63d5bc4e86fd03317a21 @@ -1604,7 +1604,7 @@ printf( "\n\n%s Built-in shell (lash)\n", BB_BANNER); printf( "Enter 'help' for a list of built-in commands.\n\n"); #endif - } else if (local_pending_command==NULL) { + } else if (local_pending_command==NULL && argv[optind] != NULL) { //printf( "optind=%d argv[optind]='%s'\n", optind, argv[optind]); input = bb_xfopen(argv[optind], "r"); /* be lazy, never mark this closed */ From rob at landley.net Fri Jul 7 15:19:18 2006 From: rob at landley.net (Rob Landley) Date: Fri Jul 7 15:19:43 2006 Subject: exporting argc/argv to applets In-Reply-To: <20060707050803.GL24607@brightrain.aerifal.cx> References: <20060702133654.GJ21958@aon.at> <200607062034.55469.vapier@gentoo.org> <20060707050803.GL24607@brightrain.aerifal.cx> Message-ID: <200607071819.18479.rob@landley.net> On Friday 07 July 2006 1:08 am, Rich Felker wrote: > On Thu, Jul 06, 2006 at 08:34:54PM -0400, Mike Frysinger wrote: > > On Thursday 06 July 2006 15:18, Rich Felker wrote: > > > Global variables are not bp+offset, just fixed address. > > > > that depends on your build ... with a non-pic binary this is correct > > Yes we're talking about i386 which always has MMU (afaik anyway), so > building with PIC would be rather stupid.. Go look at http://www.gentoo.org/proj/en/hardened/pic-internals.xml sections 3 and 4, and contemplate that like standard system libraries, BusyBox is _also_ likely to have lots and lots of copies of the same executable in memory at once, and could dirty lots of pages with unnecessarily scattered relocations. PIC can optimize for DRAM usage at the expense of on-disk binary size, on a system with an MMU and multiple copies of the same process. If you reply "just statically link everything", I'm going to put you in my spam filter. Someday you may realize that the definition of "general purpose tool" isn't "it does the one strange thing you want to do, and everything else is broken". (Nor is "everybody who doesn't do it my way is stupid" a useful attitude.) > > throw in the shared busybox lib and it all goes to hell ;) > > Also sounds like a very bad idea.. At present, I consider the shared busybox library useless. I hope to get standalone applet building merged in this dev cycle, but it's fifth or sixth on the todo list. Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Fri Jul 7 17:48:11 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Fri Jul 7 17:48:20 2006 Subject: [PATCH] init: Set the RUNLEVEL environment Message-ID: <7f45d9390607071748y59de6348h45fe5539a4e3891e@mail.gmail.com> Busybox's init application does not use the runlevel argument, except for the special case of single-user mode. This patch passes the runlevel argument on to the children processes in the environment variable RUNLEVEL so that they may do something with it. For example, I have an /etc/rc file that simply calls /etc/rc$RUNLEVEL. This behaviour matches that of the standard Linux System-V-like init application. Please apply. Cheers, Shaun 2006-07-07 Shaun Jackman * init/init.c (init_main): Set the RUNLEVEL environment. --- init/init.c 7c1c416e705e9cd6bb4e44a71f0f89ff81ede8cb +++ init/init.c 0cfeb638397fac566743b7f0228f532d56bc6a11 @@ -1046,6 +1046,9 @@ for(e = environment; *e; e++) putenv((char *) *e); } + if (argc > 1) + setenv("RUNLEVEL", argv[1], 1); + /* Hello world */ message(MAYBE_CONSOLE | LOG, "init started: %s", bb_msg_full_version); From dalias at aerifal.cx Fri Jul 7 19:58:19 2006 From: dalias at aerifal.cx (Rich Felker) Date: Fri Jul 7 19:45:35 2006 Subject: exporting argc/argv to applets In-Reply-To: <200607071819.18479.rob@landley.net> References: <20060702133654.GJ21958@aon.at> <200607062034.55469.vapier@gentoo.org> <20060707050803.GL24607@brightrain.aerifal.cx> <200607071819.18479.rob@landley.net> Message-ID: <20060708025819.GS24607@brightrain.aerifal.cx> On Fri, Jul 07, 2006 at 06:19:18PM -0400, Rob Landley wrote: > On Friday 07 July 2006 1:08 am, Rich Felker wrote: > > On Thu, Jul 06, 2006 at 08:34:54PM -0400, Mike Frysinger wrote: > > > On Thursday 06 July 2006 15:18, Rich Felker wrote: > > > > Global variables are not bp+offset, just fixed address. > > > > > > that depends on your build ... with a non-pic binary this is correct > > > > Yes we're talking about i386 which always has MMU (afaik anyway), so > > building with PIC would be rather stupid.. > > Go look at http://www.gentoo.org/proj/en/hardened/pic-internals.xml sections 3 I'm quite familiar with what PIC is and how it's used. > and 4, and contemplate that like standard system libraries, BusyBox is _also_ > likely to have lots and lots of copies of the same executable in memory at > once, and could dirty lots of pages with unnecessarily scattered relocations. How would there be any relocations? All addresses except calls to the libc are resolved at link time unless you use shared libbb which we seem to agree is stupid. > PIC can optimize for DRAM usage at the expense of on-disk binary size, on a > system with an MMU and multiple copies of the same process. PIC never optimizes, it just makes a costly process (runtime linking) less costly. > If you reply "just statically link everything", I'm going to put you in my > spam filter. We're talking about BB, not everything. > Someday you may realize that the definition of "general purpose > tool" isn't "it does the one strange thing you want to do, and everything > else is broken". (Nor is "everybody who doesn't do it my way is stupid" a > useful attitude.) Huh? What does this have to do with anything I said? > > > throw in the shared busybox lib and it all goes to hell ;) > > > > Also sounds like a very bad idea.. > > At present, I consider the shared busybox library useless. I hope to get > standalone applet building merged in this dev cycle, but it's fifth or sixth > on the todo list. I still wonder if PIC is worthwhile even in this case. Oh well. Not relevant now anyway. Rich From aurel at gnuage.org Sat Jul 8 08:02:42 2006 From: aurel at gnuage.org (Aurelien Jacobs) Date: Sat Jul 8 08:00:47 2006 Subject: Building additional binaries In-Reply-To: <200607061606.06353.rob@landley.net> References: <7f45d9390607041613k2305179eocf5fcb10928b63ca@mail.gmail.com> <200607061044.07970.rob@landley.net> <7f45d9390607060939t3b353b3p5be6b13510737676@mail.gmail.com> <200607061606.06353.rob@landley.net> Message-ID: <20060708170242.869e06c9.aurel@gnuage.org> On Thu, 6 Jul 2006 16:06:06 -0400 Rob Landley wrote: > On Thursday 06 July 2006 12:39 pm, Shaun Jackman wrote: > > On 7/6/06, Rob Landley wrote: > > > I'm trying to learn about git so we can have a toolset where all of us > > > can work at full speed without stomping each other so much. My initramfs > > > tutorial at OLS is sandwiched between two git tutorials, so that seems > > > like a good time to come up to speed on it. :) > > > > I really don't want to start a version-control holy war -- honest -- > > but I will mention that I've been using monotone to manage my busybox > > patches and regularly merge with the svn trunk. It's been working > > extremely well for me. > > I've been meaning to take a look at mercurial too. Indeed mercurial is very good too. It is similar to git in a lot of area, but it is IMHO far simpler to use. It seems to be more and more popular, even in the kernel development circle (let's see alsa, v4l2...). Well, that said, git is nice too. Choosing one or the other is really a matter of taste. Aurel From vda.linux at googlemail.com Sat Jul 8 09:44:18 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat Jul 8 09:44:39 2006 Subject: [PATCH] unify itoa Message-ID: <200607081844.18212.vda.linux@googlemail.com> Hi folks, Rob, Attached patch removes all instances of local itoa()-like functions, introduces common one into libbb and uses it where appropriate. The itoa which lives in ash is not converted: /* Our own itoa(). */ static int cvtnum(arith_t num) { int len; expdest = makestrspace(32, expdest); #ifdef CONFIG_ASH_MATH_SUPPORT_64 len = fmtstr(expdest, 32, "%lld", (long long) num); #else len = fmtstr(expdest, 32, "%ld", num); #endif STADJUST(len, expdest); return len; } Where fmtstr is: int fmtstr(char *outbuf, size_t length, const char *fmt, ...) { va_list ap; int ret; va_start(ap, fmt); INTOFF; ret = vsnprintf(outbuf, length, fmt, ap); va_end(ap); INTON; return ret; } If you want it converted too, I'll do it. itoa.c already has code which can handle unsigned long long conv, it is #ifdef'ed out for now. See the patch. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox_itoa.patch Type: text/x-diff Size: 8832 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060708/b7e27d7b/busybox_itoa-0001.bin From rob at landley.net Sat Jul 8 10:06:24 2006 From: rob at landley.net (Rob Landley) Date: Sat Jul 8 10:06:19 2006 Subject: [PATCH] Add support for mounting by label or UUID In-Reply-To: <78a54e1b0606161334q39fb7cd7ma0891bf8b4f59f64@mail.gmail.com> References: <78a54e1b0606081228w2bc97d81uec989fd9b655c034@mail.gmail.com> <200606131201.58074.rob@landley.net> <78a54e1b0606161334q39fb7cd7ma0891bf8b4f59f64@mail.gmail.com> Message-ID: <200607081306.24821.rob@landley.net> Slowly grinding through the "pending" heap... On Friday 16 June 2006 4:34 pm, Jason Schoon wrote: > Attached is a new patch. I decided that since findfs already existed to do > this sort of thing for ext2/3, I should call the standalone thing findfs, > and just have it support additional filesystem types. Works for me. > To this end, I have yanked the findfs function from e2fsprogs, and it is > now under system utilities along with mount. If you enable label support > for mount, it switches on findfs automatically. Woot. > I don't particularly like this still, because all of the bloated > label-handling code is still in e2fsprogs if that is enabled. I'm going through e2fsprogs and writing new versions of the things we want to keep. (Currently doing a new mke2fs.) Don't worry about that, with the possible exception of e2fsck the entire area is condemned and will be deleted. > Ideally, > someone would take that code, coalesce it with mine, and put it in a common > spot. I don't use or want to touch e2fsprogs though, so it won't be me (at > least not anytime soon). Do people actually use reiserfs with BusyBox? I've seen people use ext2, ext3, squashfs, iso9660, cramfs, minixfs, initramfs, and probably a few others. But I haven't seen reiserfs, jfs, or xfs. But I suppose once we've started adding explicit SMP support... Banging on it... Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Sat Jul 8 10:35:42 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sat Jul 8 10:35:50 2006 Subject: [PATCH] md5sum: Set optind to 1 if getopt is not called Message-ID: <7f45d9390607081035k8e3f6f0oc06477699f17bc4e@mail.gmail.com> Well, there was bound to be at least one. Please apply. Cheers, Shaun 2006-07-08 Shaun Jackman * coreutils/md5_sha1_sum.c (hash_files): Set optind to 1 if getopt is not called. --- coreutils/md5_sha1_sum.c c5a2746a35b82fb4c06299b094dd22c951bb748b +++ coreutils/md5_sha1_sum.c ea2784f5767284a648dcc5c0544a0b0eb4e22fbc @@ -98,6 +98,8 @@ if (ENABLE_FEATURE_MD5_SHA1_SUM_CHECK) flags = bb_getopt_ulflags(argc, argv, "scw"); + else + optind = 1; if (ENABLE_FEATURE_MD5_SHA1_SUM_CHECK && !(flags & FLAG_CHECK)) { if (flags & FLAG_SILENT) { -------------- next part -------------- 2006-07-08 Shaun Jackman * coreutils/md5_sha1_sum.c (hash_files): Set optind to 1 if getopt is not called. --- coreutils/md5_sha1_sum.c c5a2746a35b82fb4c06299b094dd22c951bb748b +++ coreutils/md5_sha1_sum.c ea2784f5767284a648dcc5c0544a0b0eb4e22fbc @@ -98,6 +98,8 @@ if (ENABLE_FEATURE_MD5_SHA1_SUM_CHECK) flags = bb_getopt_ulflags(argc, argv, "scw"); + else + optind = 1; if (ENABLE_FEATURE_MD5_SHA1_SUM_CHECK && !(flags & FLAG_CHECK)) { if (flags & FLAG_SILENT) { From rob at landley.net Sat Jul 8 10:45:50 2006 From: rob at landley.net (Rob Landley) Date: Sat Jul 8 10:45:46 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607081844.18212.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> Message-ID: <200607081345.50932.rob@landley.net> On Saturday 08 July 2006 12:44 pm, Denis Vlasenko wrote: > Hi folks, Rob, > > Attached patch removes all instances of local itoa()-like > functions, introduces common one into libbb and uses > it where appropriate. Is "sprintf" really that bad? (Or xasprintf() out of our library when you need it to malloc?) Especially if the darn compiler actually starts doing intelligent string merging, which it's inching towards... You have a large quantity of code under #ifdef NOT_NEEDED_YET that by itself would make me reject this patch. (What's max_unsigned_power10() doing, anyway, and is that really a sane way to do whatever it is?) > If you want it converted too, I'll do it. itoa.c > already has code which can handle unsigned long long conv, > it is #ifdef'ed out for now. See the patch. It can handle int, and long long, but not long. On 64 bit platforms (we already support x86-64, and this sort of thing will only get more common to the point it may be a noticeable chunk of the embedded space in 3-5 years), these are three different sizes. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Sat Jul 8 10:51:57 2006 From: rob at landley.net (Rob Landley) Date: Sat Jul 8 10:51:51 2006 Subject: [PATCH] init: Set the RUNLEVEL environment In-Reply-To: <7f45d9390607071748y59de6348h45fe5539a4e3891e@mail.gmail.com> References: <7f45d9390607071748y59de6348h45fe5539a4e3891e@mail.gmail.com> Message-ID: <200607081351.58041.rob@landley.net> On Friday 07 July 2006 8:48 pm, Shaun Jackman wrote: > Busybox's init application does not use the runlevel argument, except > for the special case of single-user mode. This patch passes the > runlevel argument on to the children processes in the environment > variable RUNLEVEL so that they may do something with it. For example, > I have an /etc/rc file that simply calls /etc/rc$RUNLEVEL. This > behaviour matches that of the standard Linux System-V-like init > application. Please apply. Busybox init doesn't support runlevels. Busybox init has never supported runlevels. Our inittab doesn't do runlevels. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Sat Jul 8 10:55:59 2006 From: rob at landley.net (Rob Landley) Date: Sat Jul 8 10:56:22 2006 Subject: exporting argc/argv to applets In-Reply-To: <20060708025819.GS24607@brightrain.aerifal.cx> References: <20060702133654.GJ21958@aon.at> <200607071819.18479.rob@landley.net> <20060708025819.GS24607@brightrain.aerifal.cx> Message-ID: <200607081355.59543.rob@landley.net> On Friday 07 July 2006 10:58 pm, Rich Felker wrote: > > Go look at http://www.gentoo.org/proj/en/hardened/pic-internals.xml > > sections 3 > > I'm quite familiar with what PIC is and how it's used. And yet you miss the underlying concepts. > > and 4, and contemplate that like standard system libraries, BusyBox is > > _also_ likely to have lots and lots of copies of the same executable in > > memory at once, and could dirty lots of pages with unnecessarily > > scattered relocations. > > How would there be any relocations? All addresses except calls to the > libc are resolved at link time unless you use shared libbb which we > seem to agree is stupid. How about dynamically linking busybox against the C library? In which case, all the calls busybox makes to the C library have to be resolved by /lib/ld-linux.so or /lib/ld-uClibc.so by patching the executable as it's loaded. > > PIC can optimize for DRAM usage at the expense of on-disk binary size, on > > a system with an MMU and multiple copies of the same process. > > PIC never optimizes, it just makes a costly process (runtime linking) > less costly. And yet runtime linking is something people want to do. It is common practice outside of the ivory towers of academia. > > If you reply "just statically link everything", I'm going to put you in > > my spam filter. > > We're talking about BB, not everything. *plonk* Rob -- Never bet against the cheap plastic solution. From floydpink at gmail.com Sat Jul 8 10:51:08 2006 From: floydpink at gmail.com (Jason Schoon) Date: Sat Jul 8 10:57:53 2006 Subject: [PATCH] Add support for mounting by label or UUID In-Reply-To: <200607081306.24821.rob@landley.net> References: <78a54e1b0606081228w2bc97d81uec989fd9b655c034@mail.gmail.com> <200606131201.58074.rob@landley.net> <78a54e1b0606161334q39fb7cd7ma0891bf8b4f59f64@mail.gmail.com> <200607081306.24821.rob@landley.net> Message-ID: <78a54e1b0607081051s546c5a42u7c52316b9758a6c@mail.gmail.com> On 7/8/06, Rob Landley wrote: > Slowly grinding through the "pending" heap... > > On Friday 16 June 2006 4:34 pm, Jason Schoon wrote: > > Attached is a new patch. I decided that since findfs already existed to do > > this sort of thing for ext2/3, I should call the standalone thing findfs, > > and just have it support additional filesystem types. > > Works for me. > > > To this end, I have yanked the findfs function from e2fsprogs, and it is > > now under system utilities along with mount. If you enable label support > > for mount, it switches on findfs automatically. > > Woot. > > > I don't particularly like this still, because all of the bloated > > label-handling code is still in e2fsprogs if that is enabled. > > I'm going through e2fsprogs and writing new versions of the things we want to > keep. (Currently doing a new mke2fs.) Don't worry about that, with the > possible exception of e2fsck the entire area is condemned and will be > deleted. > > > Ideally, > > someone would take that code, coalesce it with mine, and put it in a common > > spot. I don't use or want to touch e2fsprogs though, so it won't be me (at > > least not anytime soon). > > Do people actually use reiserfs with BusyBox? I've seen people use ext2, > ext3, squashfs, iso9660, cramfs, minixfs, initramfs, and probably a few > others. But I haven't seen reiserfs, jfs, or xfs. But I suppose once we've > started adding explicit SMP support... > > Banging on it... > Thanks for taking a look into this. I did have an updated patch that applied cleanly on the final 1.2.0, and removed a leftover debug fprintf from findfs.c. At this point, you are probably far enough into a merge that you don't need it. RE: reiserfs, we definately use it in embedded systems. We needed journalling, weren't on a flash device to use jffs2, and didn't want to incur the larger journal overhead of ext3. Reiser has actually worked great for us. From vda.linux at googlemail.com Sat Jul 8 11:42:05 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat Jul 8 11:42:16 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607081345.50932.rob@landley.net> References: <200607081844.18212.vda.linux@googlemail.com> <200607081345.50932.rob@landley.net> Message-ID: <200607082042.05536.vda.linux@googlemail.com> On Saturday 08 July 2006 19:45, Rob Landley wrote: > On Saturday 08 July 2006 12:44 pm, Denis Vlasenko wrote: > > Hi folks, Rob, > > > > Attached patch removes all instances of local itoa()-like > > functions, introduces common one into libbb and uses > > it where appropriate. > > Is "sprintf" really that bad? (Or xasprintf() out of our library when you > need it to malloc?) Especially if the darn compiler actually starts doing > intelligent string merging, which it's inching towards... I think that some programs may print so much numerical output that it may be important for them to do itoa more-or-less efficiently. sprintf is a performance disaster. In any libc I've looked into, it _creates a custom struct FILE_, and then calls v_something_printf() on that, which _parses format string_ with gazzilion of possible obscure format specifiers, and _then_ it does itoa thing. > You have a large quantity of code under #ifdef NOT_NEEDED_YET that by itself > would make me reject this patch. I wrote that just in case you'll want me to convert ash too. See below. > (What's max_unsigned_power10() doing, > anyway, and is that really a sane way to do whatever it is?) It calculates maximum power-of-10 which fits in unsigned int. It does that at compile time, portably. That's why it looks funny. gcc optimizes it out to simple 1000000000 constant (if sizeof(unsigned)==4, that is). > > If you want it converted too, I'll do it. itoa.c > > already has code which can handle unsigned long long conv, > > it is #ifdef'ed out for now. See the patch. > > It can handle int, and long long, but not long. On 64 bit platforms (we > already support x86-64, and this sort of thing will only get more common to > the point it may be a noticeable chunk of the embedded space in 3-5 years), > these are three different sizes. long long currently is needed for ash only, everybody else wants itoa([unsigned] int). There are no ltoa users today. ltoa is of course a piece of cake, can do when someone will need it. So, do you want me to a) remove #ifdef NOT_NEEDED_YET part or b) enable it and use it in ash? -- vda From sjackman at gmail.com Sat Jul 8 12:17:57 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sat Jul 8 12:18:05 2006 Subject: [PATCH] init: Set the RUNLEVEL environment In-Reply-To: <200607081351.58041.rob@landley.net> References: <7f45d9390607071748y59de6348h45fe5539a4e3891e@mail.gmail.com> <200607081351.58041.rob@landley.net> Message-ID: <7f45d9390607081217l2afbbe4cr468ac7968a6537c7@mail.gmail.com> On 7/8/06, Rob Landley wrote: > On Friday 07 July 2006 8:48 pm, Shaun Jackman wrote: > > Busybox's init application does not use the runlevel argument, except > > for the special case of single-user mode. This patch passes the > > runlevel argument on to the children processes in the environment > > variable RUNLEVEL so that they may do something with it. For example, > > I have an /etc/rc file that simply calls /etc/rc$RUNLEVEL. This > > behaviour matches that of the standard Linux System-V-like init > > application. Please apply. > > Busybox init doesn't support runlevels. Busybox init has never supported > runlevels. Our inittab doesn't do runlevels. Exactly. Since init doesn't handle runlevels, this two-line patch allows /etc/rc (or kin) to handle runlevels by passing the environment variable on to the child process. If we're not going to do this work in init -- which is a fine design choice, since it simplifies init greatly -- we should at least give the next level the opportunity to handle the runlevel. For example... $ cat /etc/rc exec /etc/rc$RUNLEVEL Cheers, Shaun From mszick at morethan.org Sat Jul 8 12:40:14 2006 From: mszick at morethan.org (Michael S. Zick) Date: Sat Jul 8 12:40:23 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607082042.05536.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607081345.50932.rob@landley.net> <200607082042.05536.vda.linux@googlemail.com> Message-ID: <200607081440.14202.mszick@morethan.org> On Sat July 8 2006 13:42, Denis Vlasenko wrote: > On Saturday 08 July 2006 19:45, Rob Landley wrote: > > On Saturday 08 July 2006 12:44 pm, Denis Vlasenko wrote: > > > (What's max_unsigned_power10() doing, > > anyway, and is that really a sane way to do whatever it is?) > > It calculates maximum power-of-10 which fits in unsigned int. > It does that at compile time, portably. That's why it looks funny. > > gcc optimizes it out to simple 1000000000 constant > (if sizeof(unsigned)==4, that is). > Unless you are supporting multiple brands of compilers, it optimizes out to a simple constant before you write the code. Mike From vda.linux at googlemail.com Sat Jul 8 12:59:03 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat Jul 8 12:59:24 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607081440.14202.mszick@morethan.org> References: <200607081844.18212.vda.linux@googlemail.com> <200607082042.05536.vda.linux@googlemail.com> <200607081440.14202.mszick@morethan.org> Message-ID: <200607082159.03633.vda.linux@googlemail.com> On Saturday 08 July 2006 21:40, Michael S. Zick wrote: > > It calculates maximum power-of-10 which fits in unsigned int. > > It does that at compile time, portably. That's why it looks funny. > > > > gcc optimizes it out to simple 1000000000 constant > > (if sizeof(unsigned)==4, that is). > > Unless you are supporting multiple brands of compilers, it > optimizes out to a simple constant before you write the code. The whole world is not a x86[-64]. Please show me the simple constant which is a biggest power of 10 which fits into variable of type "int" on platforms with 16-bit, 32-bit, 64-bit and 128-bit ints? -- vda From vda.linux at googlemail.com Sat Jul 8 13:04:57 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sat Jul 8 13:05:08 2006 Subject: login and /dev/vcs[a]NNN devices. Message-ID: <200607082204.57473.vda.linux@googlemail.com> Hi people, I'm using busybox login. When I log in as non-root, I can use /dev/ttyNN device I am logged on (of course), but cannot use /dev/vcs[a]NN devices which hold screen buffer data. I need to be able to do it. util-linux's login chown+chmod's those devices for me. Is there any solution for busybox login? -- vda From mszick at morethan.org Sat Jul 8 13:45:35 2006 From: mszick at morethan.org (Michael S. Zick) Date: Sat Jul 8 13:45:43 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607082159.03633.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607081440.14202.mszick@morethan.org> <200607082159.03633.vda.linux@googlemail.com> Message-ID: <200607081545.35654.mszick@morethan.org> On Sat July 8 2006 14:59, Denis Vlasenko wrote: > On Saturday 08 July 2006 21:40, Michael S. Zick wrote: > > > It calculates maximum power-of-10 which fits in unsigned int. > > > It does that at compile time, portably. That's why it looks funny. > > > > > > gcc optimizes it out to simple 1000000000 constant > > > (if sizeof(unsigned)==4, that is). > > > > Unless you are supporting multiple brands of compilers, it > > optimizes out to a simple constant before you write the code. > > The whole world is not a x86[-64]. > > Please show me the simple constant which is a biggest > power of 10 which fits into variable of type "int" on > platforms with 16-bit, 32-bit, 64-bit and 128-bit ints? I believe you have in mind 'long int' which is usually the native register size. The compiler chosen sets the size of 'int' What compiler are you using? Turbo C? MixC? > -- > vda > > Mike From yh at bizmail.com.au Sat Jul 8 17:57:56 2006 From: yh at bizmail.com.au (Jim) Date: Sat Jul 8 17:57:35 2006 Subject: insmod module.ko In-Reply-To: <200607062031.54698.vapier@gentoo.org> References: <44ACE8A4.90106@bizmail.com.au> <20060706115503.GC9309@aon.at> <4498.203.217.29.133.1152227196.squirrel@203.217.29.133> <200607062031.54698.vapier@gentoo.org> Message-ID: <44B05494.9070105@bizmail.com.au> Thanks Mike and all responses. The loading module works now after adding a full path to the insmod. Now there is another issue. My module.ko contains an i2c function i2c_add_driver() and other i2c functions. The i2c has been built in kernel, but loading module.ko was crashed at i2c_add_driver() in an exception of null address. The i2c functions were not linked in module.ko. I am not clear whether the unresolved symbols should be resolved in kernel module building process or in insmod loading process. Could you clarify please? Does the insmod loading process search unresolved symbols in kernel binary As I mentioned that the module.o was running fine in kernel 2.4. In kernel 2.4, I did not even specify the full path to the insmod, it was called just "insmod module.o". In kernel 2.6, I have to call "insmod /usr/lib/2.6.8/kernel/module.ko" to make it works. I am not sure if I was still missing something in kernel 2.6 loading process? Thank you. Jim Mike Frysinger wrote: > On Thursday 06 July 2006 19:06, yh@bizmail.com.au wrote: > >>Thanks Bernhard. I enabled kernel 2.6, but could not build it, please see >>following errors from applets.a. Will a "make clean" fix it? > > > yes, after changing .config you always need to run `make clean` first > -mike From dalias at aerifal.cx Sat Jul 8 22:05:21 2006 From: dalias at aerifal.cx (Rich Felker) Date: Sat Jul 8 21:52:25 2006 Subject: exporting argc/argv to applets In-Reply-To: <200607081355.59543.rob@landley.net> References: <20060702133654.GJ21958@aon.at> <200607071819.18479.rob@landley.net> <20060708025819.GS24607@brightrain.aerifal.cx> <200607081355.59543.rob@landley.net> Message-ID: <20060709050521.GU24607@brightrain.aerifal.cx> On Sat, Jul 08, 2006 at 01:55:59PM -0400, Rob Landley wrote: > On Friday 07 July 2006 10:58 pm, Rich Felker wrote: > > > Go look at http://www.gentoo.org/proj/en/hardened/pic-internals.xml > > > sections 3 > > > > I'm quite familiar with what PIC is and how it's used. > > And yet you miss the underlying concepts. You can continue with the personal insults but I assure you I understand everything related to PIC. Unfortunately I've had to.. > > > and 4, and contemplate that like standard system libraries, BusyBox is > > > _also_ likely to have lots and lots of copies of the same executable in > > > memory at once, and could dirty lots of pages with unnecessarily > > > scattered relocations. > > > > How would there be any relocations? All addresses except calls to the > > libc are resolved at link time unless you use shared libbb which we > > seem to agree is stupid. > > How about dynamically linking busybox against the C library? In which case, > all the calls busybox makes to the C library have to be resolved > by /lib/ld-linux.so or /lib/ld-uClibc.so by patching the executable as it's > loaded. No, a PLT is used even without PIC in the BB objects, and copy relocations (evil) are used for external variables imported from the C library. Using PIC for the BB binary is in no way needed for shared libs. If it's used, the purpose is almost surely address randomization or other "security" measures. > > > PIC can optimize for DRAM usage at the expense of on-disk binary size, on > > > a system with an MMU and multiple copies of the same process. > > > > PIC never optimizes, it just makes a costly process (runtime linking) > > less costly. > > And yet runtime linking is something people want to do. It is common practice > outside of the ivory towers of academia. You can use this insult all you want too, but I find it's the ivory towers that love bloat like dynamic linking. Anyway I was very deliberate in saying "runtime linking" instead of "shared libraries". I very much like and want shared libraries. What I don't like is deferring a very slow (both practically and big-O-wise) computation that has the same results every time to the moment the program starts and using dirty pages to store constant data. Performing the linking only when needed and reusing the results until something changes is much more efficient and practical and there are in fact ways to make shared libraries that work this way. > > > If you reply "just statically link everything", I'm going to put you in > > > my spam filter. > > > > We're talking about BB, not everything. > > *plonk* ..... Rich From dalias at aerifal.cx Sat Jul 8 22:07:38 2006 From: dalias at aerifal.cx (Rich Felker) Date: Sat Jul 8 21:54:35 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607081345.50932.rob@landley.net> References: <200607081844.18212.vda.linux@googlemail.com> <200607081345.50932.rob@landley.net> Message-ID: <20060709050738.GV24607@brightrain.aerifal.cx> On Sat, Jul 08, 2006 at 01:45:50PM -0400, Rob Landley wrote: > On Saturday 08 July 2006 12:44 pm, Denis Vlasenko wrote: > > Hi folks, Rob, > > > > Attached patch removes all instances of local itoa()-like > > functions, introduces common one into libbb and uses > > it where appropriate. > > Is "sprintf" really that bad? (Or xasprintf() out of our library when you > need it to malloc?) Especially if the darn compiler actually starts doing > intelligent string merging, which it's inching towards... > > You have a large quantity of code under #ifdef NOT_NEEDED_YET that by itself > would make me reject this patch. (What's max_unsigned_power10() doing, > anyway, and is that really a sane way to do whatever it is?) Agree, this code is INSANELY bloated. Use snprintf! Rich From dalias at aerifal.cx Sat Jul 8 22:11:02 2006 From: dalias at aerifal.cx (Rich Felker) Date: Sat Jul 8 21:58:01 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607082042.05536.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607081345.50932.rob@landley.net> <200607082042.05536.vda.linux@googlemail.com> Message-ID: <20060709051102.GW24607@brightrain.aerifal.cx> On Sat, Jul 08, 2006 at 08:42:05PM +0200, Denis Vlasenko wrote: > On Saturday 08 July 2006 19:45, Rob Landley wrote: > > On Saturday 08 July 2006 12:44 pm, Denis Vlasenko wrote: > > > Hi folks, Rob, > > > > > > Attached patch removes all instances of local itoa()-like > > > functions, introduces common one into libbb and uses > > > it where appropriate. > > > > Is "sprintf" really that bad? (Or xasprintf() out of our library when you > > need it to malloc?) Especially if the darn compiler actually starts doing > > intelligent string merging, which it's inching towards... > > I think that some programs may print so much numerical output > that it may be important for them to do itoa more-or-less > efficiently. Perhaps, but BB is always about optimizing for size, not speed, unless a very large speed gain can be achieved with a relatively small amount of code.. > sprintf is a performance disaster. In any libc I've looked into, > it _creates a custom struct FILE_, and then calls v_something_printf() > on that, which _parses format string_ with gazzilion of possible > obscure format specifiers, and _then_ it does itoa thing. Then your libc sucks. Get a good one. BB does not write huge bloated replacements for the libc functions; it uses them as-is, and thus will perform well on a well-implemented system and poorly on a poorly-implemented system. > > (What's max_unsigned_power10() doing, > > anyway, and is that really a sane way to do whatever it is?) > > It calculates maximum power-of-10 which fits in unsigned int. > It does that at compile time, portably. That's why it looks funny. LOL.. *crying* why does itoa need to know such a thing?! Rich From dalias at aerifal.cx Sat Jul 8 22:12:03 2006 From: dalias at aerifal.cx (Rich Felker) Date: Sat Jul 8 21:59:00 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607082159.03633.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607082042.05536.vda.linux@googlemail.com> <200607081440.14202.mszick@morethan.org> <200607082159.03633.vda.linux@googlemail.com> Message-ID: <20060709051203.GX24607@brightrain.aerifal.cx> On Sat, Jul 08, 2006 at 09:59:03PM +0200, Denis Vlasenko wrote: > On Saturday 08 July 2006 21:40, Michael S. Zick wrote: > > > It calculates maximum power-of-10 which fits in unsigned int. > > > It does that at compile time, portably. That's why it looks funny. > > > > > > gcc optimizes it out to simple 1000000000 constant > > > (if sizeof(unsigned)==4, that is). > > > > Unless you are supporting multiple brands of compilers, it > > optimizes out to a simple constant before you write the code. > > The whole world is not a x86[-64]. > > Please show me the simple constant which is a biggest > power of 10 which fits into variable of type "int" on > platforms with 16-bit, 32-bit, 64-bit and 128-bit ints? There are no such things at present, only 32-bit ints. Rich From farmatito at tiscali.it Sun Jul 9 06:51:53 2006 From: farmatito at tiscali.it (Tito) Date: Sun Jul 9 06:52:19 2006 Subject: [PATCH] su code clean up, minor size reduction and new config option Message-ID: <200607091551.53277.farmatito@tiscali.it> Hi, this patch: 1) removes an a lot of #ifdef's from su.c 2) adds a new config option to enable/disable syslogging in su (it now loggs successes and failures!!!) 3) reduces the size a little bit. With syslogging enabled: root@localhost:/dev/pts/2:/root/Desktop/busybox# make bloatcheck CC loginutils/su.o AR cru loginutils/loginutils.a LINK busybox_unstripped function old new delta su_main 485 483 -2 .rodata 1879 1875 -4 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-6) Total: -6 bytes With syslogging disabled: root@localhost:/dev/pts/2:/root/Desktop/busybox# make bloatcheck function old new delta .rodata 1879 1847 -32 su_main 485 357 -128 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-160) Total: -160 bytes The patch is tested and works fine for me. Please apply if you like it. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: su.patch Type: text/x-diff Size: 5076 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060709/bc12772f/su-0001.bin From rob at landley.net Sun Jul 9 08:47:10 2006 From: rob at landley.net (Rob Landley) Date: Sun Jul 9 08:47:03 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607082042.05536.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607081345.50932.rob@landley.net> <200607082042.05536.vda.linux@googlemail.com> Message-ID: <200607091147.11082.rob@landley.net> On Saturday 08 July 2006 2:42 pm, Denis Vlasenko wrote: > On Saturday 08 July 2006 19:45, Rob Landley wrote: > > On Saturday 08 July 2006 12:44 pm, Denis Vlasenko wrote: > > > Hi folks, Rob, > > > > > > Attached patch removes all instances of local itoa()-like > > > functions, introduces common one into libbb and uses > > > it where appropriate. > > > > Is "sprintf" really that bad? (Or xasprintf() out of our library when > > you need it to malloc?) Especially if the darn compiler actually starts > > doing intelligent string merging, which it's inching towards... > > I think that some programs may print so much numerical output > that it may be important for them to do itoa more-or-less > efficiently. Could you give me an example? (Your patch didn't actually convert many users, that I saw.) > sprintf is a performance disaster. In any libc I've looked into, > it _creates a custom struct FILE_, and then calls v_something_printf() > on that, which _parses format string_ with gazzilion of possible > obscure format specifiers, and _then_ it does itoa thing. That would be a yes, then. :) > > You have a large quantity of code under #ifdef NOT_NEEDED_YET that by > > itself would make me reject this patch. > > I wrote that just in case you'll want me to convert ash too. > See below. I'm far more interested in replacing ash than fixing it, and am working towards that end here (albeit by clearing a couple other low hanging fruit off my todo list first so I can focus on bbsh with fewer interruptions). > > (What's max_unsigned_power10() doing, > > anyway, and is that really a sane way to do whatever it is?) > > It calculates maximum power-of-10 which fits in unsigned int. > It does that at compile time, portably. That's why it looks funny. > > gcc optimizes it out to simple 1000000000 constant > (if sizeof(unsigned)==4, that is). When is sizeof(unsigned) not going to be 4 on any Linux platform? We use the lp64 model (as do all modern Unix variants, including MacOS X), where only long and pointer are 64 bit. http://www.unix.org/whitepapers/64bit.html This even works for Windows, which uses llp64 because they decided to make 64 bit programming really inconvenient in the name of backwards compatability, and still managed to to screw it up: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Not that I care about that part. :) > > > If you want it converted too, I'll do it. itoa.c > > > already has code which can handle unsigned long long conv, > > > it is #ifdef'ed out for now. See the patch. > > > > It can handle int, and long long, but not long. On 64 bit platforms (we > > already support x86-64, and this sort of thing will only get more common > > to the point it may be a noticeable chunk of the embedded space in 3-5 > > years), these are three different sizes. > > long long currently is needed for ash only, everybody else wants > itoa([unsigned] int). There are no ltoa users today. > ltoa is of course a piece of cake, can do when someone will need it. > > So, do you want me to > > a) remove #ifdef NOT_NEEDED_YET part > or > b) enable it and use it in ash? The first, please. A general rule of thumb: we can always add code to the tree later. (And if we remove it, we can always add it _back_ later.) Thanks, Rob -- Never bet against the cheap plastic solution. From vda.linux at googlemail.com Sun Jul 9 09:53:25 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun Jul 9 09:53:42 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607091147.11082.rob@landley.net> References: <200607081844.18212.vda.linux@googlemail.com> <200607082042.05536.vda.linux@googlemail.com> <200607091147.11082.rob@landley.net> Message-ID: <200607091853.25263.vda.linux@googlemail.com> On Sunday 09 July 2006 17:47, Rob Landley wrote: > > I think that some programs may print so much numerical output > > that it may be important for them to do itoa more-or-less > > efficiently. > > Could you give me an example? (Your patch didn't actually convert many users, > that I saw.) Examples of things which should care about it (I do not claim that current code cares): od, seq, uniq -c, tcpdump, hexdump... > > gcc optimizes it out to simple 1000000000 constant > > (if sizeof(unsigned)==4, that is). > > When is sizeof(unsigned) not going to be 4 on any Linux platform? We use the > lp64 model (as do all modern Unix variants, including MacOS X), where only > long and pointer are 64 bit. > > http://www.unix.org/whitepapers/64bit.html What about Alpha? I heard that it has (had?) sizeof(int)==8. BTW, I could do this instead: static inline unsigned max_unsigned_power10(void) { if (sizeof(unsigned) == 4) return 1000000000; if (sizeof(unsigned) == 8) // gcc warns a lot here, shut it up return (unsigned)(10ULL*1000000000*1000000000); return BUG_unsupported_architecture(); } but since you don't want to handle long long, it's irrelevant for now. > > So, do you want me to > > > > a) remove #ifdef NOT_NEEDED_YET part > > or > > b) enable it and use it in ash? > > The first, please. > > A general rule of thumb: we can always add code to the tree later. (And if we > remove it, we can always add it _back_ later.) See attached patch. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox_itoa_v3.patch Type: text/x-diff Size: 5808 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060709/00d19121/busybox_itoa_v3.bin From rob at landley.net Sun Jul 9 10:11:41 2006 From: rob at landley.net (Rob Landley) Date: Sun Jul 9 10:11:33 2006 Subject: [PATCH]: lash: Bug fix. Avoid trying to open a NULL path. In-Reply-To: <7f45d9390607071503w2b5daae9j5478fb331aa0b027@mail.gmail.com> References: <7f45d9390607071503w2b5daae9j5478fb331aa0b027@mail.gmail.com> Message-ID: <200607091311.41378.rob@landley.net> On Friday 07 July 2006 6:03 pm, Shaun Jackman wrote: > If lash starts up in non-interactive mode, it refuses to read its > input from standard input. Instead it will attempt to open > argv[optind], which may be NULL. Applied. For future reference, could you give me a reproduction sequence for bugs when it's only one or two lines? Saves me going through the code going "ok, can this bug actually be hit?" Thanks, Rob -- Never bet against the cheap plastic solution. From farmatito at tiscali.it Sun Jul 9 10:28:49 2006 From: farmatito at tiscali.it (Tito) Date: Sun Jul 9 10:29:02 2006 Subject: [PATCH] su code clean up and new config option V.2 In-Reply-To: <200607091551.53277.farmatito@tiscali.it> References: <200607091551.53277.farmatito@tiscali.it> Message-ID: <200607091928.49369.farmatito@tiscali.it> On Sunday 9 July 2006 15:51, Tito wrote: Hi, this is an improved version of the previous patch: >1) removes an a lot of #ifdef's from su.c >2) adds a new config option to enable/disable syslogging in su > (it now loggs successes and failures!!!) 3) size is about the same as before with syslogging enabled. 4) fixes a potential issue with struct passwd *pw making old_user = opt_username (new_user) With syslogging enabled: function old new delta su_main 485 493 +8 .rodata 1879 1875 -4 > With syslogging disabled: > root@localhost:/dev/pts/2:/root/Desktop/busybox# make bloatcheck > function old new delta > .rodata 1879 1847 -32 > su_main 485 357 -128 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-160) Total: -160 bytes The patch is tested and works fine for me. Please apply if you like it. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: su_v2.patch Type: text/x-diff Size: 5124 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060709/00bcf060/su_v2.bin From vda.linux at googlemail.com Sun Jul 9 11:05:48 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun Jul 9 11:06:23 2006 Subject: [PATCH] Allow per-user setup script be run by login In-Reply-To: <200607082204.57473.vda.linux@googlemail.com> References: <200607082204.57473.vda.linux@googlemail.com> Message-ID: <200607092005.48703.vda.linux@googlemail.com> On Saturday 08 July 2006 22:04, Denis Vlasenko wrote: > Hi people, > > I'm using busybox login. When I log in as non-root, > I can use /dev/ttyNN device I am logged on (of course), > but cannot use /dev/vcs[a]NN devices which hold screen > buffer data. I need to be able to do it. > util-linux's login chown+chmod's those devices for me. > > Is there any solution for busybox login? Okay, maybe this patch will be deemed insufficiently ugly to reject. (/me crosses fingers...) With this patch I can point LOGIN_PRE_SUID_SCRIPT to the script like this: #!/bin/sh ttyname=`ttyname` ttybase=`echo "$ttyname" | sed 's/[0-9]*$//'` ttytail=${ttyname:${#ttybase}} if test "$ttybase" = "/dev/tty"; then chown "$LOGIN_USER": "/dev/vcs$ttytail" "/dev/vcsa$ttytail" chmod 0600 "/dev/vcs$ttytail" "/dev/vcsa$ttytail" fi This will achieve what I want, and is generic enough when compared to adding /dev/vcs[a] support into the login itself. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox_login.patch Type: text/x-diff Size: 1305 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060709/cefbc3a3/busybox_login-0001.bin From vda.linux at googlemail.com Sun Jul 9 10:41:52 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun Jul 9 11:06:26 2006 Subject: Any objections to smarden.org tools added to bbox? Message-ID: <200607091941.52238.vda.linux@googlemail.com> Hi Rob, I use the djb's daemontools and ucspi-tcp a lot. However, they are not GPL'ed, but there are very similar replacements, which are: http://smarden.org/runit/ http://smarden.org/socklog2/ http://smarden.org/ipsvd/ I'd like to add these to bbox. Is there a chance that they will be accepted? -- vda From bock at blacknet.de Sun Jul 9 11:17:47 2006 From: bock at blacknet.de (Goetz Bock) Date: Sun Jul 9 11:53:50 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <200607091941.52238.vda.linux@googlemail.com> References: <200607091941.52238.vda.linux@googlemail.com> Message-ID: <20060709181746.GJ10146@shell.blacknet.de> On Sun, Jul 09 '06 at 19:41, Denis Vlasenko wrote: > I use the djb's daemontools and ucspi-tcp a lot. > However, they are not GPL'ed, but there are very similar > replacements, which are: > > http://smarden.org/runit/ > http://smarden.org/socklog2/ > http://smarden.org/ipsvd/ > > I'd like to add these to bbox. Is there a chance that they > will be accepted? If they are small, and GPL I'm sure they will be accepted, but instead of runit there is (was?) an minit port to BB, and minit is IMHO a sane way to do what runit tries ;-) -- /"\ 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 won_fang at yahoo.com.au Sun Jul 9 14:11:51 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Sun Jul 9 14:12:13 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <20060709181746.GJ10146@shell.blacknet.de> References: <200607091941.52238.vda.linux@googlemail.com> <20060709181746.GJ10146@shell.blacknet.de> Message-ID: <20060710071151.6c77df8a@cluster.meeting.humbug.org.au> On Sun, 9 Jul 2006 20:17:47 +0200 Goetz Bock wrote: > > On Sun, Jul 09 '06 at 19:41, Denis Vlasenko wrote: > > I use the djb's daemontools and ucspi-tcp a lot. > > However, they are not GPL'ed, but there are very similar > > replacements, which are: > > > > http://smarden.org/runit/ > > http://smarden.org/socklog2/ > > http://smarden.org/ipsvd/ > > > > I'd like to add these to bbox. Is there a chance that they > > will be accepted? > If they are small, and GPL I'm sure they will be accepted, but instead > of runit there is (was?) an minit port to BB, and minit is IMHO a sane > way to do what runit tries ;-) Probably time to mention urunlevel at sourceforge again, if only for the sake of combpleteness. B-) -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060710/96ac3279/signature.pgp From sjackman at gmail.com Sun Jul 9 15:30:43 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sun Jul 9 15:30:48 2006 Subject: [PATCH]: lash: Bug fix. Avoid trying to open a NULL path. In-Reply-To: <200607091311.41378.rob@landley.net> References: <7f45d9390607071503w2b5daae9j5478fb331aa0b027@mail.gmail.com> <200607091311.41378.rob@landley.net> Message-ID: <7f45d9390607091530gda88c72rf6e3132722a4e128@mail.gmail.com> On 7/9/06, Rob Landley wrote: > On Friday 07 July 2006 6:03 pm, Shaun Jackman wrote: > > If lash starts up in non-interactive mode, it refuses to read its > > input from standard input. Instead it will attempt to open > > argv[optind], which may be NULL. > > Applied. Thanks. > For future reference, could you give me a reproduction sequence for bugs when > it's only one or two lines? Saves me going through the code going "ok, can > this bug actually be hit?" Will do. Cheers, Shaun From floydpink at gmail.com Sun Jul 9 15:36:19 2006 From: floydpink at gmail.com (Jason Schoon) Date: Sun Jul 9 15:36:23 2006 Subject: [PATCH] Allow per-user setup script be run by login In-Reply-To: <200607092005.48703.vda.linux@googlemail.com> References: <200607082204.57473.vda.linux@googlemail.com> <200607092005.48703.vda.linux@googlemail.com> Message-ID: <78a54e1b0607091536p63ca82a7l68d2afce99d9bcb7@mail.gmail.com> On 7/9/06, Denis Vlasenko wrote: > > On Saturday 08 July 2006 22:04, Denis Vlasenko wrote: > > Hi people, > > > > I'm using busybox login. When I log in as non-root, > > I can use /dev/ttyNN device I am logged on (of course), > > but cannot use /dev/vcs[a]NN devices which hold screen > > buffer data. I need to be able to do it. > > util-linux's login chown+chmod's those devices for me. > > > > Is there any solution for busybox login? > > Okay, maybe this patch will be deemed insufficiently ugly > to reject. (/me crosses fingers...) > > With this patch I can point LOGIN_PRE_SUID_SCRIPT to > the script like this: > > #!/bin/sh > ttyname=`ttyname` > ttybase=`echo "$ttyname" | sed 's/[0-9]*$//'` > ttytail=${ttyname:${#ttybase}} > if test "$ttybase" = "/dev/tty"; then > chown "$LOGIN_USER": "/dev/vcs$ttytail" "/dev/vcsa$ttytail" > chmod 0600 "/dev/vcs$ttytail" "/dev/vcsa$ttytail" > fi > > This will achieve what I want, and is generic enough > when compared to adding /dev/vcs[a] support into the login itself. > -- > vda I'm a bit confused, and not near the code right now. Is this something that happens before you would have a chance to call something like a .profile for the user to fix this up? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060709/f05c4098/attachment.html From dalias at aerifal.cx Sun Jul 9 17:13:05 2006 From: dalias at aerifal.cx (Rich Felker) Date: Sun Jul 9 16:59:58 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607091853.25263.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607082042.05536.vda.linux@googlemail.com> <200607091147.11082.rob@landley.net> <200607091853.25263.vda.linux@googlemail.com> Message-ID: <20060710001305.GZ24607@brightrain.aerifal.cx> On Sun, Jul 09, 2006 at 06:53:25PM +0200, Denis Vlasenko wrote: > On Sunday 09 July 2006 17:47, Rob Landley wrote: > > > I think that some programs may print so much numerical output > > > that it may be important for them to do itoa more-or-less > > > efficiently. > > > > Could you give me an example? (Your patch didn't actually convert many users, > > that I saw.) > > Examples of things which should care about it > (I do not claim that current code cares): > od, seq, uniq -c, tcpdump, hexdump... Of these od/hexdump are the only ones that sound very interesting to optimize for performance, and the 'itoa' code in question is decimal-only anyway making them irrelevant. Anyway if snprintf is too slow then what needs to be fixed is snprintf, not the applications that use it. The C library exists for a reason. As soon as you decide you can't rely on it to do what it's supposed to do and do it at an acceptable level of efficiency, you end up with the bloat that is Mozilla (NSPR), GNOME (glib), or coreutils (gnulib, i.e. half of glibc copied into the coreutils source tree...). > > > gcc optimizes it out to simple 1000000000 constant > > > (if sizeof(unsigned)==4, that is). > > > > When is sizeof(unsigned) not going to be 4 on any Linux platform? We use the > > lp64 model (as do all modern Unix variants, including MacOS X), where only > > long and pointer are 64 bit. > > > > http://www.unix.org/whitepapers/64bit.html > > What about Alpha? I heard that it has (had?) sizeof(int)==8. gcc does not support sizeof(int)!=4, so no, it does not have 8. You're thinking of long. In fact any C compiler with sizeof(int)!=4 is virtually unusable for multimedia apps because it means you lack at least one of the sizes 8, 16, or 32, all of which are needed in order to have any hope of efficient audio and video processing. Rich From rob at landley.net Sun Jul 9 20:06:12 2006 From: rob at landley.net (Rob Landley) Date: Sun Jul 9 20:07:05 2006 Subject: [PATCH] su code clean up and new config option V.2 In-Reply-To: <200607091928.49369.farmatito@tiscali.it> References: <200607091551.53277.farmatito@tiscali.it> <200607091928.49369.farmatito@tiscali.it> Message-ID: <200607092306.13164.rob@landley.net> On Sunday 09 July 2006 1:28 pm, Tito wrote: > On Sunday 9 July 2006 15:51, Tito wrote: > Hi, > > this is an improved version of the previous patch: > >1) removes an a lot of #ifdef's from su.c > >2) adds a new config option to enable/disable syslogging in su > > (it now loggs successes and failures!!!) > > 3) size is about the same as before with syslogging enabled. > 4) fixes a potential issue with struct passwd *pw making old_user = > opt_username (new_user) Applied, with further cleanups. What's the issue with #4? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Sun Jul 9 20:08:59 2006 From: rob at landley.net (Rob Landley) Date: Sun Jul 9 20:09:07 2006 Subject: [PATCH] init: Set the RUNLEVEL environment In-Reply-To: <7f45d9390607081217l2afbbe4cr468ac7968a6537c7@mail.gmail.com> References: <7f45d9390607071748y59de6348h45fe5539a4e3891e@mail.gmail.com> <200607081351.58041.rob@landley.net> <7f45d9390607081217l2afbbe4cr468ac7968a6537c7@mail.gmail.com> Message-ID: <200607092308.59986.rob@landley.net> On Saturday 08 July 2006 3:17 pm, Shaun Jackman wrote: > > Busybox init doesn't support runlevels. Busybox init has never supported > > runlevels. Our inittab doesn't do runlevels. > > Exactly. Since init doesn't handle runlevels, this two-line patch > allows /etc/rc (or kin) to handle runlevels by passing the environment > variable on to the child process. *shrug* Applied earlier today. (Might already have said this, don't remember...) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Sun Jul 9 20:13:19 2006 From: rob at landley.net (Rob Landley) Date: Sun Jul 9 20:13:59 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <20060709181746.GJ10146@shell.blacknet.de> References: <200607091941.52238.vda.linux@googlemail.com> <20060709181746.GJ10146@shell.blacknet.de> Message-ID: <200607092313.20133.rob@landley.net> On Sunday 09 July 2006 2:17 pm, Goetz Bock wrote: > On Sun, Jul 09 '06 at 19:41, Denis Vlasenko wrote: > > I use the djb's daemontools and ucspi-tcp a lot. > > However, they are not GPL'ed, but there are very similar > > replacements, which are: > > > > http://smarden.org/runit/ > > http://smarden.org/socklog2/ > > http://smarden.org/ipsvd/ > > > > I'd like to add these to bbox. Is there a chance that they > > will be accepted? > > If they are small, and GPL I'm sure they will be accepted, but instead > of runit there is (was?) an minit port to BB, and minit is IMHO a sane > way to do what runit tries ;-) I have a toy called oneit that I've meant to add to busybox for a while now, but I keep thinking about it during feature freezes. http://blog.gmane.org/gmane.linux.uml.user/day=20051213 Is this anything like what runit does? Haven't had a chance to look yet... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Sun Jul 9 20:15:34 2006 From: rob at landley.net (Rob Landley) Date: Sun Jul 9 20:15:38 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <20060710071151.6c77df8a@cluster.meeting.humbug.org.au> References: <200607091941.52238.vda.linux@googlemail.com> <20060709181746.GJ10146@shell.blacknet.de> <20060710071151.6c77df8a@cluster.meeting.humbug.org.au> Message-ID: <200607092315.34605.rob@landley.net> On Sunday 09 July 2006 5:11 pm, David Seikel wrote: > On Sun, 9 Jul 2006 20:17:47 +0200 Goetz Bock wrote: > > On Sun, Jul 09 '06 at 19:41, Denis Vlasenko wrote: > > > I use the djb's daemontools and ucspi-tcp a lot. > > > However, they are not GPL'ed, but there are very similar > > > replacements, which are: > > > > > > http://smarden.org/runit/ > > > http://smarden.org/socklog2/ > > > http://smarden.org/ipsvd/ > > > > > > I'd like to add these to bbox. Is there a chance that they > > > will be accepted? > > > > If they are small, and GPL I'm sure they will be accepted, but instead > > of runit there is (was?) an minit port to BB, and minit is IMHO a sane > > way to do what runit tries ;-) > > Probably time to mention urunlevel at sourceforge again, if only for > the sake of combpleteness. B-) Ok, you mentioned it, I have no idea what it is or what it does, and I have way too much else to do to go hunt it down myself. Since you didn't supply the slightest clue as to what it actually is or why I should care, we move on... Rob -- Never bet against the cheap plastic solution. From farmatito at tiscali.it Mon Jul 10 00:08:55 2006 From: farmatito at tiscali.it (Tito) Date: Mon Jul 10 00:09:09 2006 Subject: [PATCH] su code clean up and new config option V.2 In-Reply-To: <200607092306.13164.rob@landley.net> References: <200607091551.53277.farmatito@tiscali.it> <200607091928.49369.farmatito@tiscali.it> <200607092306.13164.rob@landley.net> Message-ID: <200607100908.55726.farmatito@tiscali.it> On Monday 10 July 2006 05:06, Rob Landley wrote: > On Sunday 09 July 2006 1:28 pm, Tito wrote: > > On Sunday 9 July 2006 15:51, Tito wrote: > > Hi, > > > > this is an improved version of the previous patch: > > >1) removes an a lot of #ifdef's from su.c > > >2) adds a new config option to enable/disable syslogging in su > > > (it now loggs successes and failures!!!) > > > > 3) size is about the same as before with syslogging enabled. > > 4) fixes a potential issue with struct passwd *pw making old_user = > > opt_username (new_user) > > Applied, with further cleanups. > > What's the issue with #4? If getlogin fails we use getpwuid to initialise old_user old_user = getlogin ( ); if ( !old_user ) { pw = getpwuid ( cur_uid ); old_user = ( pw ? pw->pw_name : "" ); } later we reuse pw pw = getpwnam ( opt_username ); so in the end we have old_user = pw->pw_name; opt_username == pw->pw_name; as the man page says (GETPWNAM(3) ): The return value may point to static area, and may be overwritten by subsequent calls to getpwent(), getpwnam(), or getpwuid(). so potentially we could have: old_user == opt_username this would mess up the logs. That is why I strdup the first pw->pw_name. BTW, I was not able to trigger this on my system.... so it is just to be sure. Ciao, Tito > Rob From vda.linux at googlemail.com Mon Jul 10 00:31:59 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Mon Jul 10 00:32:23 2006 Subject: [PATCH] Add support for mounting by label or UUID In-Reply-To: <200607081306.24821.rob@landley.net> References: <78a54e1b0606081228w2bc97d81uec989fd9b655c034@mail.gmail.com> <78a54e1b0606161334q39fb7cd7ma0891bf8b4f59f64@mail.gmail.com> <200607081306.24821.rob@landley.net> Message-ID: <200607100931.59416.vda.linux@googlemail.com> On Saturday 08 July 2006 19:06, Rob Landley wrote: > > Ideally, > > someone would take that code, coalesce it with mine, and put it in a common > > spot. I don't use or want to touch e2fsprogs though, so it won't be me (at > > least not anytime soon). > > Do people actually use reiserfs with BusyBox? I've seen people use ext2, > ext3, squashfs, iso9660, cramfs, minixfs, initramfs, and probably a few > others. But I haven't seen reiserfs, jfs, or xfs. But I suppose once we've > started adding explicit SMP support... Well, I do. On my desktop machines I have bbox and reiserfs. Actually, I think that bbox and "small is beautiful" idiom in general is "the Right Thing" (if not taken to the extreme), and should be promoted not only in small/embedded devices world (I think we won there already), but on the desktop too. It can be done only if we will actually use it on the desktops. That's why I use bbox on my desktop. I've been lazy and do install "bloated" stuff (coreutils, awk, etc...) whenever I hit incompatibility or lack of feature in bbox, but I should not ;) Not sure whether we should ever include *fsprogs tools into bbox. After all, that's _specialized_ tools which are also critical. Would you like to see "buggy bbox e2fsck ate my data!!!" bug reports? My 0.02 in some currency. -- vda From mingching.tiew at redtone.com Mon Jul 10 00:37:17 2006 From: mingching.tiew at redtone.com (Ming-Ching Tiew) Date: Mon Jul 10 00:38:14 2006 Subject: df does not report my root file system Message-ID: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> This is the output of these commands :- # ls -al /dev/ram0 /dev/root brw-rw---- 1 root root 1, 0 July 10 15:30 /dev/ram0 lrwxrwxrwx 1 root root 9 July 10 15:30 /dev/root -> /dev/ram0 # cat /proc/mounts rootfs / rootfs rw 0 0 /proc /proc proc rw 0 0 # df Filesystem 1k-blocks Used Available (blank output except for the header ) This is executed in initramfs. Now my problem is that 'df' does not report the root filesystem. What do I have to do to make it report the root files system ? Regards. From rob at landley.net Mon Jul 10 00:43:56 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 10 00:44:02 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607091853.25263.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607091147.11082.rob@landley.net> <200607091853.25263.vda.linux@googlemail.com> Message-ID: <200607100343.56443.rob@landley.net> On Sunday 09 July 2006 12:53 pm, Denis Vlasenko wrote: > On Sunday 09 July 2006 17:47, Rob Landley wrote: > > > I think that some programs may print so much numerical output > > > that it may be important for them to do itoa more-or-less > > > efficiently. > > > > Could you give me an example? (Your patch didn't actually convert many > > users, that I saw.) > > Examples of things which should care about it > (I do not claim that current code cares): > od, seq, uniq -c, tcpdump, hexdump... How many of these users actually need a malloc, and how many is it essentially a better sprintf? > > > gcc optimizes it out to simple 1000000000 constant > > > (if sizeof(unsigned)==4, that is). > > > > When is sizeof(unsigned) not going to be 4 on any Linux platform? We use > > the lp64 model (as do all modern Unix variants, including MacOS X), where > > only long and pointer are 64 bit. > > > > http://www.unix.org/whitepapers/64bit.html > > What about Alpha? I heard that it has (had?) sizeof(int)==8. A) Not on Linux. Linux standardized on LP64. B) If it's that broken, I don't care. > BTW, I could do this instead: > > static inline unsigned max_unsigned_power10(void) > { > if (sizeof(unsigned) == 4) return 1000000000; > if (sizeof(unsigned) == 8) // gcc warns a lot here, shut it up > return (unsigned)(10ULL*1000000000*1000000000); > return BUG_unsupported_architecture(); > } > > but since you don't want to handle long long, it's irrelevant for now. I'd rather wait until users of long long show up before adding support. Also, "long long" isn't a specific type: on a 32 bit platform long is 32 bits and long long is 64 bits. On a 64 bit platform, long is 64 bits and long long is 128 bits. That's why they invented uint64_t and friends. :) > > > So, do you want me to > > > > > > a) remove #ifdef NOT_NEEDED_YET part > > > or > > > b) enable it and use it in ash? > > > > The first, please. > > > > A general rule of thumb: we can always add code to the tree later. (And > > if we remove it, we can always add it _back_ later.) > > See attached patch. Well, it's definitely an improvement. However, it would be nice if you could call itoa on a buffer and have it actually fill in that buffer from the start, so you could use it like you could sprintf or strcpy, and not potentially have to track two pointers to your own buffer. I did a quick stab at that and checked it into xfuncs.c, and now I'm about to pass out. Could you tell me if that's useful, or if not what did I screw up? I have to go fall over and pass out now, it's 4 am and I have work in the morning... Rob -- Never bet against the cheap plastic solution. From vda.linux at googlemail.com Mon Jul 10 00:45:45 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Mon Jul 10 00:52:04 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <200607092315.34605.rob@landley.net> References: <200607091941.52238.vda.linux@googlemail.com> <20060710071151.6c77df8a@cluster.meeting.humbug.org.au> <200607092315.34605.rob@landley.net> Message-ID: <200607100945.45871.vda.linux@googlemail.com> On Monday 10 July 2006 05:15, Rob Landley wrote: > On Sunday 09 July 2006 5:11 pm, David Seikel wrote: > > On Sun, 9 Jul 2006 20:17:47 +0200 Goetz Bock wrote: > > > On Sun, Jul 09 '06 at 19:41, Denis Vlasenko wrote: > > > > I use the djb's daemontools and ucspi-tcp a lot. > > > > However, they are not GPL'ed, but there are very similar > > > > replacements, which are: > > > > > > > > http://smarden.org/runit/ > > > > http://smarden.org/socklog2/ > > > > http://smarden.org/ipsvd/ > > > > > > > > I'd like to add these to bbox. Is there a chance that they > > > > will be accepted? > > > > > > If they are small, and GPL I'm sure they will be accepted, but instead > > > of runit there is (was?) an minit port to BB, and minit is IMHO a sane > > > way to do what runit tries ;-) > > > > Probably time to mention urunlevel at sourceforge again, if only for > > the sake of combpleteness. B-) > > Ok, you mentioned it, I have no idea what it is or what it does, and I have > way too much else to do to go hunt it down myself. Since you didn't supply > the slightest clue as to what it actually is or why I should care, we move > on... runit is none of those things. Well, one tool from that package is an init replacement, but I'm not interested in that. My init is just a shell script and I don't need anything more complicated. The main part of the runit are daemon-controlling tools runsv, runsvdir, svlog. If you ever used or read about djb's daemontools, then I can simply say that those are GPLed replacements of svscan, supervise, multilog. (And if you never used those: this is how the setup looks like in my current machine: 613 ? S 0:00 svscan /var/service 627 ? S 0:00 supervise fw 628 ? S 0:00 supervise gpm 629 ? S 0:01 gpm -D -2 -m /dev/psaux -t ps2 630 ? S 0:00 supervise ntp 681 ? SL 0:01 ntpd -c conf -f drift -s stat -l /proc/self/fd/2 -p /dev/null -k /dev/null -g -d -n 631 ? S 0:00 supervise log 632 ? S 0:00 multilog t n5 /var/log/service/ntp 634 ? S 0:00 supervise top 635 ? S 58:48 top c s TERM=linux 638 ? S 0:00 supervise klog 639 ? S 0:00 socklog ucspi 640 ? S 0:00 supervise log 641 ? S 0:00 svlogd -tt /var/log/service/klog 658 ? S 0:00 supervise once 682 ? S 0:00 supervise sshd 3063 ? S 0:01 /usr/bin/sshd -D -e -p22 -u0 21992 ? S 0:10 sshd: root@pts/0 R 22001 pts/0 S 0:00 -bash USER=root LOGNAME=root HOME=/root PATH=/bin:/usr/bin MAIL=/var/mail/root SHELL=/bin/bash SSH_$ ) Code size (compiled against dietlibc): # top b n1 | grep -e svscan -e supervise -e multilog -e PID PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 613 root 16 0 132 24 8 S 0,0 0,0 0:00 0 svscan 627 root 16 0 100 16 8 S 0,0 0,0 0:00 0 supervise 628 root 16 0 104 20 8 S 0,0 0,0 0:00 0 supervise 630 root 16 0 100 16 8 S 0,0 0,0 0:00 0 supervise 631 root 16 0 100 16 8 S 0,0 0,0 0:00 0 supervise 633 root 16 0 100 20 8 S 0,0 0,0 0:00 0 supervise 634 root 16 0 104 20 8 S 0,0 0,0 0:00 0 supervise 632 daemon 18 0 108 32 16 S 0,0 0,0 0:00 0 multilog 638 root 16 0 104 20 8 S 0,0 0,0 0:00 0 supervise 640 root 16 0 100 16 8 S 0,0 0,0 0:00 0 supervise 658 root 16 0 100 16 8 S 0,0 0,0 0:00 0 supervise 682 root 16 0 100 16 8 S 0,0 0,0 0:00 0 supervise 683 root 16 0 100 16 8 S 0,0 0,0 0:00 0 supervise 704 daemon 18 0 108 28 16 S 0,0 0,0 0:00 0 multilog ... -- vda From ps.m at gmx.net Mon Jul 10 01:50:00 2006 From: ps.m at gmx.net (Peter S. Mazinger) Date: Mon Jul 10 01:50:26 2006 Subject: Where in make menuconfig enables PRINTK In-Reply-To: <20060707103632.20301ae8.tonyb@sysdev.org> Message-ID: On Fri, 7 Jul 2006, Hufnus wrote: > I cant find where to CONFIG PRINTK Y with kernel > 2.4.33-rc2 menuconfig, so that busybox dmesg starts working... > > Any one knows under what menu that is located? it's a 2.6 kernel option Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From vda.linux at googlemail.com Mon Jul 10 00:51:55 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Mon Jul 10 02:47:04 2006 Subject: [PATCH] Allow per-user setup script be run by login In-Reply-To: <78a54e1b0607091536p63ca82a7l68d2afce99d9bcb7@mail.gmail.com> References: <200607082204.57473.vda.linux@googlemail.com> <200607092005.48703.vda.linux@googlemail.com> <78a54e1b0607091536p63ca82a7l68d2afce99d9bcb7@mail.gmail.com> Message-ID: <200607100951.56093.vda.linux@googlemail.com> On Monday 10 July 2006 00:36, Jason Schoon wrote: > > > I'm using busybox login. When I log in as non-root, > > > I can use /dev/ttyNN device I am logged on (of course), > > > but cannot use /dev/vcs[a]NN devices which hold screen > > > buffer data. I need to be able to do it. > > > util-linux's login chown+chmod's those devices for me. > > > > > > Is there any solution for busybox login? > > > > Okay, maybe this patch will be deemed insufficiently ugly > > to reject. (/me crosses fingers...) > > > > With this patch I can point LOGIN_PRE_SUID_SCRIPT to > > the script like this: > > > > #!/bin/sh > > ttyname=`ttyname` > > ttybase=`echo "$ttyname" | sed 's/[0-9]*$//'` > > ttytail=${ttyname:${#ttybase}} > > if test "$ttybase" = "/dev/tty"; then > > chown "$LOGIN_USER": "/dev/vcs$ttytail" "/dev/vcsa$ttytail" > > chmod 0600 "/dev/vcs$ttytail" "/dev/vcsa$ttytail" > > fi > > > > This will achieve what I want, and is generic enough > > when compared to adding /dev/vcs[a] support into the login itself. > > I'm a bit confused, and not near the code right now. Is this something that > happens before you would have a chance to call something like a .profile for > the user to fix this up? This allows admin to instruct login to run and wait for a child (typically shell script) after login authenticated the user (read: we know username, homedir, shell, etc) but before login actually setuid()s to $UID. IOW: script is run with root privileges. It allows me to do a chown/chmod on /dev/something. /etc/profile and/or .profile are run as user -> I cannot chown/chmod /dev/something. -- vda From vda.linux at googlemail.com Mon Jul 10 02:46:46 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Mon Jul 10 02:47:10 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607100343.56443.rob@landley.net> References: <200607081844.18212.vda.linux@googlemail.com> <200607091853.25263.vda.linux@googlemail.com> <200607100343.56443.rob@landley.net> Message-ID: <200607101146.46903.vda.linux@googlemail.com> On Monday 10 July 2006 09:43, Rob Landley wrote: > > Examples of things which should care about it > > (I do not claim that current code cares): > > od, seq, uniq -c, tcpdump, hexdump... > > How many of these users actually need a malloc, and how many is it essentially > a better sprintf? The attached test program shows that snprintf is 2.5 times slower than utoa. Operations done per second: sprintf='12345678' count=27346 utoa_to_buf='12345678' count=69880 utoa='12345678' count=65934 A few days ago I ran "hexdump | grep" over entire hard drive. Took a long time. I wish hexdump was optimized a bit better... > > > > gcc optimizes it out to simple 1000000000 constant > > > > (if sizeof(unsigned)==4, that is). > > > > > > When is sizeof(unsigned) not going to be 4 on any Linux platform? We use > > > the lp64 model (as do all modern Unix variants, including MacOS X), where > > > only long and pointer are 64 bit. > > > > > > http://www.unix.org/whitepapers/64bit.html > > > > What about Alpha? I heard that it has (had?) sizeof(int)==8. > > A) Not on Linux. Linux standardized on LP64. I am not sure. It looks like you are not sure too. > B) If it's that broken, I don't care. What's broken about it? If the CPU is _designed_ to handle mostly 64-bit operands, then it's only natural to make "int" type 64-bit. For AMD64, instructions are 32-bit (with auto sign extend to 64 bit) unless you add a "I want 64bit op" prefix. IOW: AMD64 CPU most of the time works with 32bit operands. That's why for AMD64, natural size of "int" is 32 bits. Cool, AMD got best things from both worlds. IIRC Alpha took a simpler "we are a fully 64 animal" route. Sane C ABI on such CPU should use 64-bit ints, or else you will drown in zillions of "n &= 0x00000000fffffffff" type instructions which will enforce 32-bitness on 64-bit CPU. I think I'm starting to waste your (and my) time. Alpha is almost history now... > > > > So, do you want me to > > > > > > > > a) remove #ifdef NOT_NEEDED_YET part > > > > or > > > > b) enable it and use it in ash? > > > > > > The first, please. > > > > > > A general rule of thumb: we can always add code to the tree later. (And > > > if we remove it, we can always add it _back_ later.) > > > > See attached patch. > > Well, it's definitely an improvement. However, it would be nice if you could > call itoa on a buffer and have it actually fill in that buffer from the > start, so you could use it like you could sprintf or strcpy, and not > potentially have to track two pointers to your own buffer. That will need either a clever method to determine how much digits are there _before_ we do the conversion, or copying the result. I hope that in most cases you can just do_something(utoa_to_buf(n, buf, sizeof(buf)); (Actually, im most cases people will just use do_something(utoa(n)); ...) > I did a quick stab at that and checked it into xfuncs.c, and now I'm about to > pass out. Could you tell me if that's useful, or if not what did I screw up? > I have to go fall over and pass out now, it's 4 am and I have work in the > morning... Aha! So you DO have a clever method! :) Thanks! Hmmm.... (/me takes a look) I think I can improve on that. Please see (and run) attached program. utoa_to_buf_rob is your version copied from xfuncs.c. Two problems: it's almost as slow as sprintf and it doesn't check for buflen. utoa_to_buf_rob2 is a speed improved version and utoa_to_buf_rob2_with_check adds compile-time check that unsigned is really 32-bit and also correctly handles buflen. There is a correctness tests for utoa_to_buf_rob2_with_check. Seems to work right. Please put utoa_to_buf_rob2_with_check code into xfuncs (unless you find more way to make it better). -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: itoa_bench.c Type: text/x-csrc Size: 3950 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060710/9aebbade/itoa_bench.c From bock at blacknet.de Mon Jul 10 02:35:17 2006 From: bock at blacknet.de (Goetz Bock) Date: Mon Jul 10 02:53:29 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <200607100945.45871.vda.linux@googlemail.com> References: <200607091941.52238.vda.linux@googlemail.com> <20060710071151.6c77df8a@cluster.meeting.humbug.org.au> <200607092315.34605.rob@landley.net> <200607100945.45871.vda.linux@googlemail.com> Message-ID: <20060710093516.GK10146@shell.blacknet.de> On Mon, Jul 10 '06 at 09:45, Denis Vlasenko wrote: > > > > > I use the djb's daemontools and ucspi-tcp a lot. > > > > > However, they are not GPL'ed, but there are very similar > > > > > replacements, which are: > > > > > > > > > > http://smarden.org/runit/ > > > > > > > > [ ... ] instead of runit there is (was?) an minit port to BB, > > > > and minit is IMHO a sane way to do what runit tries ;-) > > runit is none of those things. [ ... ] > The main part of the runit are daemon-controlling tools runsv, > runsvdir, svlog. [ ... ] > 613 ? S 0:00 svscan /var/service > 627 ? S 0:00 supervise fw > 628 ? S 0:00 supervise gpm > 629 ? S 0:01 gpm -D -2 -m /dev/psaux -t ps2 Why should I want to start an deamon (that better should never die) to scan a service directory (svscan) which forks other daemons (supervice) which in turn start the real service but need an additional log daemon when I can have all that in one package: minit. minit scans one directory (normaly /etc/minit) for a list of service to start, starts them and restarts them if they die. It also supports logging. So you get one daemon which does all what you need 1 (svscan) + n (supervice) + n (optional multilog) daemons for. And minit can be used as an init to, so you save one additional process and the kernel knows what to do if init should die ;-) -- /"\ 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 bock at blacknet.de Mon Jul 10 02:42:45 2006 From: bock at blacknet.de (Goetz Bock) Date: Mon Jul 10 03:01:00 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <200607092313.20133.rob@landley.net> References: <200607091941.52238.vda.linux@googlemail.com> <20060709181746.GJ10146@shell.blacknet.de> <200607092313.20133.rob@landley.net> Message-ID: <20060710094244.GL10146@shell.blacknet.de> On Sun, Jul 09 '06 at 23:13, Rob Landley wrote: > I have a toy called oneit that I've meant to add to busybox for a while now, > but I keep thinking about it during feature freezes. > > http://blog.gmane.org/gmane.linux.uml.user/day=20051213 > > Is this anything like what runit does? Haven't had a chance to look yet... Not at all, but your oneit sounds like a nice addon to bb. My main reason to use /bin/sh as init it to later on be able to exec /sbin/init this won't work with noeit, but there where some special cases where oneit would save the day posted to the list that i vaugely remember. -- /"\ 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 vda.linux at googlemail.com Mon Jul 10 03:26:56 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Mon Jul 10 03:27:06 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <20060710093516.GK10146@shell.blacknet.de> References: <200607091941.52238.vda.linux@googlemail.com> <200607100945.45871.vda.linux@googlemail.com> <20060710093516.GK10146@shell.blacknet.de> Message-ID: <200607101226.56594.vda.linux@googlemail.com> On Monday 10 July 2006 11:35, Goetz Bock wrote: > > On Mon, Jul 10 '06 at 09:45, Denis Vlasenko wrote: > > > > > > I use the djb's daemontools and ucspi-tcp a lot. > > > > > > However, they are not GPL'ed, but there are very similar > > > > > > replacements, which are: > > > > > > > > > > > > http://smarden.org/runit/ > > > > > > > > > > [ ... ] instead of runit there is (was?) an minit port to BB, > > > > > and minit is IMHO a sane way to do what runit tries ;-) > > > > runit is none of those things. [ ... ] > > The main part of the runit are daemon-controlling tools runsv, > > runsvdir, svlog. [ ... ] > > > 613 ? S 0:00 svscan /var/service > > 627 ? S 0:00 supervise fw > > 628 ? S 0:00 supervise gpm > > 629 ? S 0:01 gpm -D -2 -m /dev/psaux -t ps2 > > Why should I want to start an deamon (that better should never die) to > scan a service directory (svscan) which forks other daemons (supervice) > which in turn start the real service but need an additional log daemon > when I can have all that in one package: minit. > > minit scans one directory (normaly /etc/minit) for a list of service to > start, starts them and restarts them if they die. It also supports > logging. So you get one daemon which does all what you need > 1 (svscan) + n (supervice) + n (optional multilog) daemons for. And > minit can be used as an init to, so you save one additional process and > the kernel knows what to do if init should die ;-) Sounds interesting, I need to look into minit. Answer to "why supervise?" question: supervise do not simply restart processes when they die. It provides means of _controlling_ them (using svc): stop/restrart a service: svc -du /var/service/some_dir run service once (I use this a lot): svc -o /var/service/some_dir This provides both a convenient tool for manual control and also for cross-service interactions. Example: "dhcp" service starts firewall "service" (with svc -u) when IP addr is (re)obtained. "firewall" service makes itself "one-shot" (via svc -o), configures ip addr/routing/firewall and dies. Imagine the mess of doing it without supervise... Maybe svscan + supervise*n can be merged into one process. But maybe djb wanted system to stay modular even on this level too. -- vda From Kim.Heino at bluegiga.com Mon Jul 10 03:31:45 2006 From: Kim.Heino at bluegiga.com (Kim B. Heino) Date: Mon Jul 10 04:00:56 2006 Subject: svn 15217 breaks dpkg Message-ID: <44B22C91.8040409@bluegiga.com> Hello, SVN 15217 breaks dpkg. It has: info_prefix = bb_xasprintf("/var/lib/dpkg/info/%s.", package_name); ...but later on the same function (unpack_package): strcat(info_prefix, "list"); Old version was ok: info_prefix = (char *) xmalloc(strlen(package_name) + 20 + 4 + 2); sprintf(info_prefix, "/var/lib/dpkg/info/%s.", package_name); From Kim.Heino at bluegiga.com Mon Jul 10 04:16:23 2006 From: Kim.Heino at bluegiga.com (Kim B. Heino) Date: Mon Jul 10 04:16:17 2006 Subject: svn 15217 breaks dpkg In-Reply-To: <44B22C91.8040409@bluegiga.com> References: <44B22C91.8040409@bluegiga.com> Message-ID: <44B23707.9030803@bluegiga.com> > SVN 15217 breaks dpkg. It has: There's also another bug in dpkg: If I update from foo-42-1.deb to foo-42-2.deb, dpkg accesses free'd memory. Attached is a patch to both bugs. Submitted to bug tracking system as id 939. -------------- next part -------------- A non-text attachment was scrubbed... Name: dpkg.patch Type: text/x-patch Size: 1116 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060710/27a2a40d/dpkg.bin From rpjday at mindspring.com Mon Jul 10 04:20:12 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 10 04:21:49 2006 Subject: should all BB code be GPL? Message-ID: i was just about to write a perl script to go through the source files and replace any GPL-related verbosity with the single-line boilerplate for brevity until i read this in libbb/change_identity.c (sorry about the ugly re-formatting, you can blame pine): =================================== /* * Copyright 1989 - 1991, Julianne Frances Haugh * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Neither the name of Julianne F. Haugh nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY JULIE HAUGH AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL JULIE HAUGH OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ ======================================= i don't see any reference to the GPL here. what should i assume? rday From rpjday at mindspring.com Mon Jul 10 04:41:21 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 10 04:43:00 2006 Subject: Update to standard GPL boilerplate in libbb source files. Message-ID: for at least those files that were obviously under the GPL, i replaced the earlier verbose GPL stuff with the one-line boilerplate. however, there are still numerous files in the libbb directory that had no reference to the GPL so i didn't touch those. rday From farmatito at tiscali.it Mon Jul 10 04:56:06 2006 From: farmatito at tiscali.it (Tito) Date: Mon Jul 10 04:57:24 2006 Subject: should all BB code be GPL? In-Reply-To: References: Message-ID: <200607101356.06287.farmatito@tiscali.it> On Monday 10 July 2006 13:20, Robert P. J. Day wrote: > > i was just about to write a perl script to go through the source > files and replace any GPL-related verbosity with the single-line > boilerplate for brevity until i read this in libbb/change_identity.c > (sorry about the ugly re-formatting, you can blame pine): > > =================================== > /* > * Copyright 1989 - 1991, Julianne Frances Haugh > > * All rights reserved. > * snip > OF > * SUCH DAMAGE. > */ > ======================================= > > i don't see any reference to the GPL here. what should i assume? > > rday You will find the same header also in: file:///root/Desktop/busybox.orig/libbb/correct_password.c (rewritten: patch pending, and a new one I'm working on now but not ready yet) file:///root/Desktop/busybox.orig/libbb/pwd2spwd.c (to be removed: patch pending) file:///root/Desktop/busybox.orig/libbb/restricted_shell.c file:///root/Desktop/busybox.orig/libbb/run_shell.c file:///root/Desktop/busybox.orig/libbb/setup_environment.c it was also in: file:///root/Desktop/busybox.orig/libbb/obscure.c but this one was already rewritten and is now GPL. Ciao, Tito From rpjday at mindspring.com Mon Jul 10 05:05:03 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Jul 10 05:06:40 2006 Subject: should all BB code be GPL? In-Reply-To: <200607101356.06287.farmatito@tiscali.it> References: <200607101356.06287.farmatito@tiscali.it> Message-ID: On Mon, 10 Jul 2006, Tito wrote: > On Monday 10 July 2006 13:20, Robert P. J. Day wrote: > > > > i was just about to write a perl script to go through the source > > files and replace any GPL-related verbosity with the single-line > > boilerplate for brevity until i read this in libbb/change_identity.c > > (sorry about the ugly re-formatting, you can blame pine): > > > > =================================== > > /* > > * Copyright 1989 - 1991, Julianne Frances Haugh > > > > * All rights reserved. > > * > > snip > > > OF > > * SUCH DAMAGE. > > */ > > ======================================= > > > > i don't see any reference to the GPL here. what should i assume? > > > > rday > > You will find the same header also in: ... several other files listed ... but the more general question is, what is the status of the BB source files that don't mention anything about the GPL? rday From mszick at morethan.org Mon Jul 10 07:13:56 2006 From: mszick at morethan.org (Michael S. Zick) Date: Mon Jul 10 07:14:09 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607101146.46903.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607100343.56443.rob@landley.net> <200607101146.46903.vda.linux@googlemail.com> Message-ID: <200607100913.56567.mszick@morethan.org> On Mon July 10 2006 04:46, Denis Vlasenko wrote: > > > I think I'm starting to waste your (and my) time. > Alpha is almost history now... > Almost for some, (HP) Vax and MicroVax - no new machines, remarket only (HP) Alpha Servers - new orders only until Oct. 2006 (HP) PA-RISC, 64-bit - alive and well - no 64-bit userland under Linux - 64-bit Linux kernel alive and well. Two on-going efforts to keep in mind... Giving parisc-Linux a 64-bit userland is on-going, but you will not see these in an embedded system. If an adaption of BB gets shoved into the kernel as some propose - then handling 64-bit & 128-bit types may come up again. - - - - But still, sizeof(unsigned int) is set by choosing the compiler to use for the code. There are only two widely used compilers for pa-risc - HP and GCC - those are 32-bit unsigned int for both compilers, both 32-bit and 64-bit machines. (The hardware handles the masking and sign extension.) Now if you wanted to know about the sizeof(long double)... Thank goodness, you don't. Mike From sjackman at gmail.com Mon Jul 10 07:28:02 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Mon Jul 10 07:28:15 2006 Subject: [PATCH] init: Set the RUNLEVEL environment In-Reply-To: <200607092308.59986.rob@landley.net> References: <7f45d9390607071748y59de6348h45fe5539a4e3891e@mail.gmail.com> <200607081351.58041.rob@landley.net> <7f45d9390607081217l2afbbe4cr468ac7968a6537c7@mail.gmail.com> <200607092308.59986.rob@landley.net> Message-ID: <7f45d9390607100728s70e0ec72uf3a51e175127ca6a@mail.gmail.com> On 7/9/06, Rob Landley wrote: > On Saturday 08 July 2006 3:17 pm, Shaun Jackman wrote: > > > Busybox init doesn't support runlevels. Busybox init has never supported > > > runlevels. Our inittab doesn't do runlevels. > > > > Exactly. Since init doesn't handle runlevels, this two-line patch > > allows /etc/rc (or kin) to handle runlevels by passing the environment > > variable on to the child process. > > *shrug* > > Applied earlier today. (Might already have said this, don't remember...) Thanks, Rob. -- sdj From dalias at aerifal.cx Mon Jul 10 07:54:07 2006 From: dalias at aerifal.cx (Rich Felker) Date: Mon Jul 10 07:40:48 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607101146.46903.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607091853.25263.vda.linux@googlemail.com> <200607100343.56443.rob@landley.net> <200607101146.46903.vda.linux@googlemail.com> Message-ID: <20060710145407.GE24607@brightrain.aerifal.cx> On Mon, Jul 10, 2006 at 11:46:46AM +0200, Denis Vlasenko wrote: > On Monday 10 July 2006 09:43, Rob Landley wrote: > > > Examples of things which should care about it > > > (I do not claim that current code cares): > > > od, seq, uniq -c, tcpdump, hexdump... > > > > How many of these users actually need a malloc, and how many is it essentially > > a better sprintf? > > The attached test program shows that snprintf is 2.5 times slower > than utoa. Operations done per second: Which snprintf? glibc? uClibc? Anyway I ran the rest (after sanitizing it; your benchmarking method is not valid due to multitasking) and obtained much more extreme results. Still your code is huge massive bloat to do something very simple... It's like these 10k memcpy implementations... > > > > http://www.unix.org/whitepapers/64bit.html > > > > > > What about Alpha? I heard that it has (had?) sizeof(int)==8. > > > > A) Not on Linux. Linux standardized on LP64. > > I am not sure. It looks like you are not sure too. > > > B) If it's that broken, I don't care. > > What's broken about it? If the CPU is _designed_ to handle > mostly 64-bit operands, then it's only natural to make > "int" type 64-bit. And this cpu won't be able to handle lots of real-world tasks in C code. Lovely. The conclusion: the cpu sucks. > For AMD64, instructions are 32-bit (with auto sign extend > to 64 bit) unless you add a "I want 64bit op" prefix. > IOW: AMD64 CPU most of the time works with 32bit operands. > That's why for AMD64, natural size of "int" is 32 bits. > Cool, AMD got best things from both worlds. Actually I think the prefix is needed for 32bit when running 64bit code, but it makes little difference to performance. > IIRC Alpha took a simpler "we are a fully 64 animal" > route. No, it took the "we are an idiotic risc arch" approach of not having opcodes to manipulate all integer sizes up to and including the system word size. > Sane C ABI on such CPU should use 64-bit ints, gcc is not sane then. :) > or else you will drown in zillions of "n &= 0x00000000fffffffff" > type instructions which will enforce 32-bitness > on 64-bit CPU. I suspect it's easier than this. Still ugly, and still alpha's fault. > Please put utoa_to_buf_rob2_with_check code into xfuncs > (unless you find more way to make it better). Calling sprintf makes it better by adding less size to BB... At the very least this should be a build option. Rich From wharms at bfs.de Mon Jul 10 09:36:57 2006 From: wharms at bfs.de (walter harms) Date: Mon Jul 10 09:37:14 2006 Subject: df does not report my root file system In-Reply-To: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> Message-ID: <44B28229.4080707@bfs.de> please, what version fo bb you are using ? what processor ? my bb works fine: $ busybox BusyBox v1.1.0 (2006.06.26-17:06+0000) multi-call binary $df Filesystem 1k-blocks Used Available Use% Mounted on /dev/flash3 9032 9032 0 100% / /dev/flash2 4736 1064 3672 22% /mnt/flash tmpfs 10240 400 9840 4% /var i will be away the next few days. please provide the needed information on the list. re, walter Ming-Ching Tiew wrote: > This is the output of these commands :- > > # ls -al /dev/ram0 /dev/root > brw-rw---- 1 root root 1, 0 July 10 15:30 /dev/ram0 > lrwxrwxrwx 1 root root 9 July 10 15:30 /dev/root -> /dev/ram0 > # cat /proc/mounts > rootfs / rootfs rw 0 0 > /proc /proc proc rw 0 0 > # df > Filesystem 1k-blocks Used Available > (blank output except for the header ) > > This is executed in initramfs. > > Now my problem is that 'df' does not report the root filesystem. > What do I have to do to make it report the root files system ? > > Regards. > > > > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > From sjackman at gmail.com Mon Jul 10 10:17:03 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Mon Jul 10 10:17:18 2006 Subject: [PATCH] .config.mak and CROSS_COMPILE fails with check_cc Message-ID: <7f45d9390607101017w6a05e0dbs86be6f9d744ee4b7@mail.gmail.com> .config.mak is included after the check_cc macros run. The check_cc macro requires that CROSS_COMPILE be defined. The best solution I have is to move the inclusion of .config.mak up before the check_cc macro. Please apply or suggest an alternative solution. I only started seeing this error after I tried an out-of-source-tree build -- aka make O=_build. I don't know why this bug doesn't seem to affect in-source-tree builds. Cheers, Shaun 2006-07-10 Shaun Jackman * Rules.mak: Include .config.mak before check_cc. --- Rules.mak a9b58db97585dfa13f1bb0ffd07cfb7e700c4ee9 +++ Rules.mak b3ed0397b2fcc836626854adfdb170e9f67dda55 @@ -56,6 +56,9 @@ CFLAGS+=$(CHECKED_CFLAGS) ARFLAGS=cru +# Include the user-supplied flags. +-include $(top_builddir)/.config.mak + # gcc centric. Perhaps fiddle with findstring gcc,$(CC) for the rest # get the CC MAJOR/MINOR version CC_MAJOR:=$(shell printf "%02d" $(shell echo __GNUC__ | $(CC) -E -xc - | tail -n 1)) @@ -320,10 +323,6 @@ CFLAGS += -DINIT_SCRIPT='"$(BB_INIT_SCRIPT)"' endif -# Put user-supplied flags at the end, where they -# have a chance of winning. --include $(top_builddir)/.config.mak - #------------------------------------------------------------ # Installation options ifeq ($(strip $(CONFIG_INSTALL_APPLET_HARDLINKS)),y) -------------- next part -------------- 2006-07-10 Shaun Jackman * Rules.mak: Include .config.mak before check_cc. --- Rules.mak a9b58db97585dfa13f1bb0ffd07cfb7e700c4ee9 +++ Rules.mak b3ed0397b2fcc836626854adfdb170e9f67dda55 @@ -56,6 +56,9 @@ CFLAGS+=$(CHECKED_CFLAGS) ARFLAGS=cru +# Include the user-supplied flags. +-include $(top_builddir)/.config.mak + # gcc centric. Perhaps fiddle with findstring gcc,$(CC) for the rest # get the CC MAJOR/MINOR version CC_MAJOR:=$(shell printf "%02d" $(shell echo __GNUC__ | $(CC) -E -xc - | tail -n 1)) @@ -320,10 +323,6 @@ CFLAGS += -DINIT_SCRIPT='"$(BB_INIT_SCRIPT)"' endif -# Put user-supplied flags at the end, where they -# have a chance of winning. --include $(top_builddir)/.config.mak - #------------------------------------------------------------ # Installation options ifeq ($(strip $(CONFIG_INSTALL_APPLET_HARDLINKS)),y) From sjackman at gmail.com Mon Jul 10 10:48:12 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Mon Jul 10 10:48:19 2006 Subject: [PATCH] Use local.h for local configuration Message-ID: <7f45d9390607101048h77a8c167rfeb95b454adc7550@mail.gmail.com> This patch adds an empty include file, local.h, to be included by platform.h. When building outside of the source tree, the user can add a $top_builddir/include/local.h file to include any system-specific header files or definitions. This mechanism is terribly useful for questionable but necessary definitions such as `#define fork() vfork()'. Cheers, Shaun 2006-07-10 Shaun Jackman * include/platform.h: Include local.h. * include/local.h: New file. --- include/platform.h 72d6a6d6f899f71f0335ce09088b3e9535f7a964 +++ include/platform.h 0964d97f2c73061941f9db3d768505b7c82d2126 @@ -230,4 +230,7 @@ #endif #endif +/* Include any user-supplied configuartion. */ +#include "local.h" + #endif /* platform.h */ # # old_revision [8b518c57c2a1662f8e6c57bc2386b1ed8cfae39e] # # add_file "include/local.h" # content [e868d2b601e285556b0fb9d4c888c5a647c9f166] # ============================================================ --- include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 +++ include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 @@ -0,0 +1,8 @@ +#ifndef LOCAL_H +#define LOCAL_H + +/* Any local configuration may be put here. If building outside of + * the source tree, the file $top_builddir/include/local.h may be + * used instead if preferred. */ + +#endif -------------- next part -------------- 2006-07-10 Shaun Jackman * include/platform.h: Include local.h. * include/local.h: New file. --- include/platform.h 72d6a6d6f899f71f0335ce09088b3e9535f7a964 +++ include/platform.h 0964d97f2c73061941f9db3d768505b7c82d2126 @@ -230,4 +230,7 @@ #endif #endif +/* Include any user-supplied configuartion. */ +#include "local.h" + #endif /* platform.h */ # # old_revision [8b518c57c2a1662f8e6c57bc2386b1ed8cfae39e] # # add_file "include/local.h" # content [e868d2b601e285556b0fb9d4c888c5a647c9f166] # ============================================================ --- include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 +++ include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 @@ -0,0 +1,8 @@ +#ifndef LOCAL_H +#define LOCAL_H + +/* Any local configuration may be put here. If building outside of + * the source tree, the file $top_builddir/include/local.h may be + * used instead if preferred. */ + +#endif From sjackman at gmail.com Mon Jul 10 13:36:10 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Mon Jul 10 13:36:18 2006 Subject: [PATCH] Use local.h for local configuration In-Reply-To: <7f45d9390607101048h77a8c167rfeb95b454adc7550@mail.gmail.com> References: <7f45d9390607101048h77a8c167rfeb95b454adc7550@mail.gmail.com> Message-ID: <7f45d9390607101336w51cfce1fp5559d50a20ba5bd2@mail.gmail.com> On 7/10/06, Shaun Jackman wrote: > This patch adds an empty include file, local.h, to be included by > platform.h. When building outside of the source tree, the user ... A small bug existed in my previous patch. The #include "local.h" directive should have been #include to force searching the build tree for _build/include/local.h before searching the source tree. An updated patch follows. Cheers, Shaun 2006-07-10 Shaun Jackman * include/platform.h: Include local.h. * include/local.h: New file. --- include/platform.h 72d6a6d6f899f71f0335ce09088b3e9535f7a964 +++ include/platform.h 0964d97f2c73061941f9db3d768505b7c82d2126 @@ -230,4 +230,7 @@ #endif #endif +/* Include any user-supplied configuration. */ +#include + #endif /* platform.h */ --- include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 +++ include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 @@ -0,0 +1,8 @@ +#ifndef LOCAL_H +#define LOCAL_H + +/* Any local configuration may be put here. If building outside of + * the source tree, the file $top_builddir/include/local.h may be + * used instead if preferred. */ + +#endif -------------- next part -------------- 2006-07-10 Shaun Jackman * include/platform.h: Include local.h. * include/local.h: New file. --- include/platform.h 72d6a6d6f899f71f0335ce09088b3e9535f7a964 +++ include/platform.h 0964d97f2c73061941f9db3d768505b7c82d2126 @@ -230,4 +230,7 @@ #endif #endif +/* Include any user-supplied configuartion. */ +#include + #endif /* platform.h */ # # old_revision [8b518c57c2a1662f8e6c57bc2386b1ed8cfae39e] # # add_file "include/local.h" # content [e868d2b601e285556b0fb9d4c888c5a647c9f166] # ============================================================ --- include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 +++ include/local.h e868d2b601e285556b0fb9d4c888c5a647c9f166 @@ -0,0 +1,8 @@ +#ifndef LOCAL_H +#define LOCAL_H + +/* Any local configuration may be put here. If building outside of + * the source tree, the file $top_builddir/include/local.h may be + * used instead if preferred. */ + +#endif From yann.morin.1998 at anciens.enib.fr Mon Jul 10 14:12:10 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Mon Jul 10 14:12:20 2006 Subject: [SVN] maintenance branch for 1.2.x Message-ID: <200607102312.10673.yann.morin.1998@anciens.enib.fr> Hello all, Rob, I was looking at the subversion tree and saw no branch for the 1.2.x series. Having such a branch would allow: - to apply bug fixes, new features and enhancements to trunk, and to trunk _only_, - back-port relevant fixes, and fixes _only_, to the maintenance branch, - the pending patches for directory to go away as they would be available directly from the repository. Well at least, that's the way I'm used to work: once a release has been cut out of the trunk, then create a branch for it to be maintained, name a maintainer for that branch, and enjoy the fun work on the trunk, while still keeping an eye on what's goin' on there. The linux kernel folks do it that way (not that they have the absolute knowledge of what is best :-) ), and it seems to work quite well. I know maintaining is not real fun, 'cause interesting things only happen in the trunk, and maybe you don't want to spend too much time on this, which I honestly understand for having the exact same problem at work. That's why I think that you could have a little help from someone you appointed to specially handle maintaining a revision (not that you are doing a bad work at all, I do really appreciate the time and efforts you, and others, devote to this project). Then, less time maintaining a series means more time for you to handle your more important projects you've been having pending for ages... If you decide that you want such a maintainer for the 1.2.x series, then I offer my services. I'm not a heavy nor an active contributor, but I have a bit of time I can devote daily (well nightly I'd say), and helping in that way would be my little stone to BusyBox. Of course, should someone else be more suited for the work, or willing to do the job, please speak up! :-) Regards, and long live BusyBox! Yann E. MORIN. PS. Sorry for the long mail, and all the blahblah in there, but I'm tired, and when I'm tired I tend to be a little verbose and not go to the point. And don't forget English is not my mother tongue and I have a rather limited vocabulary... Oh shit I'm doing it again. Bed time. YEM. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? From rob at landley.net Mon Jul 10 14:32:09 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 10 14:32:19 2006 Subject: [PATCH] Add support for mounting by label or UUID In-Reply-To: <200607100931.59416.vda.linux@googlemail.com> References: <78a54e1b0606081228w2bc97d81uec989fd9b655c034@mail.gmail.com> <200607081306.24821.rob@landley.net> <200607100931.59416.vda.linux@googlemail.com> Message-ID: <200607101732.09546.rob@landley.net> On Monday 10 July 2006 3:31 am, Denis Vlasenko wrote: > On Saturday 08 July 2006 19:06, Rob Landley wrote: > > > Ideally, > > > someone would take that code, coalesce it with mine, and put it in a > > > common spot. I don't use or want to touch e2fsprogs though, so it > > > won't be me (at least not anytime soon). > > > > Do people actually use reiserfs with BusyBox? I've seen people use ext2, > > ext3, squashfs, iso9660, cramfs, minixfs, initramfs, and probably a few > > others. But I haven't seen reiserfs, jfs, or xfs. But I suppose once > > we've started adding explicit SMP support... > > Well, I do. On my desktop machines I have bbox and reiserfs. > > Actually, I think that bbox and "small is beautiful" idiom in general > is "the Right Thing" (if not taken to the extreme), and should be promoted > not only in small/embedded devices world (I think we won there already), > but on the desktop too. It can be done only if we will actually use it > on the desktops. I'm entirely in favor of this as well. What I was really thinking about was whether reiserfs support should have a CONFIG entry or not. Wasn't quite big enough, and a global resiserfs support option only has one other place (stat.c) that's also tiny, so I didn't bother... > That's why I use bbox on my desktop. I've been lazy and do install > "bloated" stuff (coreutils, awk, etc...) whenever I hit incompatibility > or lack of feature in bbox, but I should not ;) I need to restart my firmware linux project, and/or modify buildroot to use busybox in the build environment instead of coreutils and friends, or add such a mode to gentoo... But my day job wants me to spend at least half my time on non-busybox stuff. > Not sure whether we should ever include *fsprogs tools into bbox. > After all, that's _specialized_ tools which are also critical. > Would you like to see "buggy bbox e2fsck ate my data!!!" bug reports? You mean like the e2fsck that Mike Frysinger dumped into BusyBox along with the rest of the e2fscrap directory? > My 0.02 in some currency. > -- > vda Rob -- Never bet against the cheap plastic solution. From adamh at adpro.com.au Mon Jul 10 16:17:23 2006 From: adamh at adpro.com.au (Adam Hawes) Date: Mon Jul 10 16:25:53 2006 Subject: should all BB code be GPL? In-Reply-To: Message-ID: <21E1E750F7A66649A99576799021BBD8628FBB@zulu.adpro.com.au> > but the more general question is, what is the status of the BB source > files that don't mention anything about the GPL? If they are intended solely for linking against a GPL application then shouldn't the GPL apply to them as they are a derived work? From mingching.tiew at redtone.com Mon Jul 10 16:46:27 2006 From: mingching.tiew at redtone.com (Ming-Ching Tiew) Date: Mon Jul 10 16:46:44 2006 Subject: df does not report my root file system References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> <44B28229.4080707@bfs.de> Message-ID: <005901c6a47b$13f93670$02bca8c0@freelance> I have tried with bb 1.0 and bb 1.2.0. And I think it is almost independent of bb version. Please note that your case is different from what I am reporting. I have no doubt that df will work under your scenario. But I issued the command 'df' inside the initramfs, I have no other block devices mounted under the root, ie initramfs is my root file system. Regards. ----- Original Message ----- From: "walter harms" To: "Ming-Ching Tiew" Cc: Sent: Tuesday, July 11, 2006 12:36 AM Subject: Re: df does not report my root file system > please, > what version fo bb you are using ? > what processor ? > my bb works fine: > $ busybox > BusyBox v1.1.0 (2006.06.26-17:06+0000) multi-call binary > > > $df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/flash3 9032 9032 0 100% / > /dev/flash2 4736 1064 3672 22% /mnt/flash > tmpfs 10240 400 9840 4% /var > > i will be away the next few days. please provide the needed information > on the list. > > re, > walter > > > Ming-Ching Tiew wrote: > > This is the output of these commands :- > > > > # ls -al /dev/ram0 /dev/root > > brw-rw---- 1 root root 1, 0 July 10 15:30 /dev/ram0 > > lrwxrwxrwx 1 root root 9 July 10 15:30 /dev/root -> /dev/ram0 > > # cat /proc/mounts > > rootfs / rootfs rw 0 0 > > /proc /proc proc rw 0 0 > > # df > > Filesystem 1k-blocks Used Available > > (blank output except for the header ) > > > > This is executed in initramfs. > > > > Now my problem is that 'df' does not report the root filesystem. > > What do I have to do to make it report the root files system ? > > > > Regards. > > > > > > > > > > > > _______________________________________________ > > busybox mailing list > > busybox@busybox.net > > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > > > > > From dalias at aerifal.cx Mon Jul 10 17:44:24 2006 From: dalias at aerifal.cx (Rich Felker) Date: Mon Jul 10 17:31:00 2006 Subject: [PATCH] Add support for mounting by label or UUID In-Reply-To: <200607101732.09546.rob@landley.net> References: <78a54e1b0606081228w2bc97d81uec989fd9b655c034@mail.gmail.com> <200607081306.24821.rob@landley.net> <200607100931.59416.vda.linux@googlemail.com> <200607101732.09546.rob@landley.net> Message-ID: <20060711004423.GK24607@brightrain.aerifal.cx> On Mon, Jul 10, 2006 at 05:32:09PM -0400, Rob Landley wrote: > On Monday 10 July 2006 3:31 am, Denis Vlasenko wrote: > > On Saturday 08 July 2006 19:06, Rob Landley wrote: > > > > Ideally, > > > > someone would take that code, coalesce it with mine, and put it in a > > > > common spot. I don't use or want to touch e2fsprogs though, so it > > > > won't be me (at least not anytime soon). > > > > > > Do people actually use reiserfs with BusyBox? I've seen people use ext2, > > > ext3, squashfs, iso9660, cramfs, minixfs, initramfs, and probably a few > > > others. But I haven't seen reiserfs, jfs, or xfs. But I suppose once > > > we've started adding explicit SMP support... > > > > Well, I do. On my desktop machines I have bbox and reiserfs. > > > > Actually, I think that bbox and "small is beautiful" idiom in general > > is "the Right Thing" (if not taken to the extreme), and should be promoted > > not only in small/embedded devices world (I think we won there already), > > but on the desktop too. It can be done only if we will actually use it > > on the desktops. > > I'm entirely in favor of this as well. Me too. I'm intending to use BB on my production workstation/server machine very soon, and I'll continue to submit patches to fix bugs I find or to make improvements where standards-required functionality is missing, especially UTF-8-locale related issues. > > Not sure whether we should ever include *fsprogs tools into bbox. > > After all, that's _specialized_ tools which are also critical. > > Would you like to see "buggy bbox e2fsck ate my data!!!" bug reports? > > You mean like the e2fsck that Mike Frysinger dumped into BusyBox along with > the rest of the e2fscrap directory? You could rename it to "e2fuck" and then people have no business complaining when it ruins their data.. :) Rich From rob at landley.net Mon Jul 10 17:47:14 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 10 17:47:31 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607101146.46903.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607100343.56443.rob@landley.net> <200607101146.46903.vda.linux@googlemail.com> Message-ID: <200607102047.14896.rob@landley.net> On Monday 10 July 2006 5:46 am, Denis Vlasenko wrote: > On Monday 10 July 2006 09:43, Rob Landley wrote: > > > Examples of things which should care about it > > > (I do not claim that current code cares): > > > od, seq, uniq -c, tcpdump, hexdump... > > > > How many of these users actually need a malloc, and how many is it > > essentially a better sprintf? > > The attached test program shows that snprintf is 2.5 times slower > than utoa. Operations done per second: > sprintf='12345678' count=27346 > utoa_to_buf='12345678' count=69880 > utoa='12345678' count=65934 > > A few days ago I ran "hexdump | grep" over entire hard drive. > Took a long time. I wish hexdump was optimized a bit better... I haven't really looked closely at hexdump, but what does a base 10 utoa have to do with a base 16 hexdump? > > > > > gcc optimizes it out to simple 1000000000 constant > > > > > (if sizeof(unsigned)==4, that is). > > > > > > > > When is sizeof(unsigned) not going to be 4 on any Linux platform? We > > > > use the lp64 model (as do all modern Unix variants, including MacOS > > > > X), where only long and pointer are 64 bit. > > > > > > > > http://www.unix.org/whitepapers/64bit.html > > > > > > What about Alpha? I heard that it has (had?) sizeof(int)==8. > > > > A) Not on Linux. Linux standardized on LP64. > > I am not sure. It looks like you are not sure too. Apparently I didn't make myself clear. Linux standardized on LP64, following the official Open Group recommendations for all Unix platforms. I am sure of this, and there were good reasons for it. The research behind the decision is stated here: http://www.unix.org/version2/whatsnew/lp64_wp.html I believe all 64-bit Linux platforms are x86-64. x86-64 is LP64. PPC 64 is LP64. Even Itanic is LP64. Because there's a _spec_ that says LP64 and the Linux developers have announced support for that spec. It seems highly unlikely for the Alpha port to not be LP64, but it's hard looking up information on the alpha because the platform's so obsolete. (The Alpha Linux FAQ was last updated six years ago.) However, google for "linux alpha sizeof int" and the first hit is the Wine developers talking about it (three years ago), where they point out that sizeof(int) != sizeof(void *), because Alpha Linux is LP64. Here's explicitly running a program on Alpha to print out sizeof(int) and sizeof(long): http://www.alphalinux.org/archives/axp-list/January2001/0072.shtml > > B) If it's that broken, I don't care. > > What's broken about it? If the CPU is _designed_ to handle > mostly 64-bit operands, then it's only natural to make > "int" type 64-bit. No, it's natural to make "long" 64 bit, "int" 32 bit, "short" 16 bit, and "char" 8 bit. If Alpha was broken that way, I would just document that BusyBox does not support it. I see no reason to add support for something that's _both_ stupid and obsolete. > IIRC Alpha took a simpler "we are a fully 64 animal" > route. I.E. we don't handle 32, 16, or 8 bit data types well. > Sane C ABI on such CPU should use 64-bit ints, > or else you will drown in zillions of "n &= 0x00000000fffffffff" > type instructions which will enforce 32-bitness > on 64-bit CPU. This is sad, but the deficiencies of Alpha's instruction set really are not BusyBox's problem. Should we have a 64 bit char type for similar reasons? > I think I'm starting to waste your (and my) time. > Alpha is almost history now... Bernhard's still adding Tru64 support. It's his pet platform... > > > > > So, do you want me to > > > > > > > > > > a) remove #ifdef NOT_NEEDED_YET part > > > > > or > > > > > b) enable it and use it in ash? > > > > > > > > The first, please. > > > > > > > > A general rule of thumb: we can always add code to the tree later. > > > > (And if we remove it, we can always add it _back_ later.) > > > > > > See attached patch. > > > > Well, it's definitely an improvement. However, it would be nice if you > > could call itoa on a buffer and have it actually fill in that buffer from > > the start, so you could use it like you could sprintf or strcpy, and not > > potentially have to track two pointers to your own buffer. > > That will need either a clever method to determine how much digits are > there _before_ we do the conversion, or copying the result. Nope. See the checkin I did for libbb/xfuncs.c. Yes, it potentially does a few extra divides, but it still does 1.4 million utoa_to_buf() per second on my laptop. > I hope that in most cases you can just > > do_something(utoa_to_buf(n, buf, sizeof(buf)); > > (Actually, im most cases people will just use do_something(utoa(n)); ...) Yup. It's not returning the buf from utoa_to_buf(). It can if there's a pressing need, but utoa() and itoa() both return it and that's probably the common case for inline use. > > I did a quick stab at that and checked it into xfuncs.c, and now I'm > > about to pass out. Could you tell me if that's useful, or if not what > > did I screw up? I have to go fall over and pass out now, it's 4 am and I > > have work in the morning... > > Aha! So you DO have a clever method! :) Thanks! > > Hmmm.... (/me takes a look) I think I can improve on that. Glances at attachment... You spotted my lack of bounds checking, which is definitely a big oversight on my part. :) > Please see (and run) attached program. utoa_to_buf_rob is your version > copied from xfuncs.c. Two problems: it's almost as slow as sprintf > and it doesn't check for buflen. utoa_to_buf_rob2 is a speed improved > version and utoa_to_buf_rob2_with_check adds compile-time check > that unsigned is really 32-bit and also correctly handles buflen. On even the 64-bit platforms BusyBox targets, unsigned is 32 bit. I'm pretty sure of this one. The lookup table is a classic size/speed tradeoff, something BusyBox has traditionally come down on the "size" side of. Doing a write() on the result is going to be way slower than the actual conversion anyway. What actual bottleneck are you seeing? I definitely agree the bounds checking needs to be added, though. I'll do that now... Rob -- Never bet against the cheap plastic solution. From mingching.tiew at redtone.com Mon Jul 10 18:18:16 2006 From: mingching.tiew at redtone.com (Ming-Ching Tiew) Date: Mon Jul 10 18:18:52 2006 Subject: df does not report my root file system References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> <44B28229.4080707@bfs.de> Message-ID: <00a301c6a487$e3747c00$0100a8c0@newlife> I have tried with bb 1.0 and bb 1.2.0. And I think it is almost independent of bb version. Please note that your case is different from what I am reporting. I have no doubt that df will work under your scenario. But I issued the command 'df' inside the initramfs, I have no other block devices mounted under the root, ie initramfs is my root file system. Regards. ----- Original Message ----- From: "walter harms" To: "Ming-Ching Tiew" Cc: Sent: Tuesday, July 11, 2006 12:36 AM Subject: Re: df does not report my root file system > please, > what version fo bb you are using ? > what processor ? > my bb works fine: > $ busybox > BusyBox v1.1.0 (2006.06.26-17:06+0000) multi-call binary > > > $df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/flash3 9032 9032 0 100% / > /dev/flash2 4736 1064 3672 22% /mnt/flash > tmpfs 10240 400 9840 4% /var > > i will be away the next few days. please provide the needed information > on the list. > > re, > walter > > > Ming-Ching Tiew wrote: > > This is the output of these commands :- > > > > # ls -al /dev/ram0 /dev/root > > brw-rw---- 1 root root 1, 0 July 10 15:30 /dev/ram0 > > lrwxrwxrwx 1 root root 9 July 10 15:30 /dev/root -> /dev/ram0 > > # cat /proc/mounts > > rootfs / rootfs rw 0 0 > > /proc /proc proc rw 0 0 > > # df > > Filesystem 1k-blocks Used Available > > (blank output except for the header ) > > > > This is executed in initramfs. > > > > Now my problem is that 'df' does not report the root filesystem. > > What do I have to do to make it report the root files system ? > > > > Regards. > > > > From rob at landley.net Mon Jul 10 18:20:28 2006 From: rob at landley.net (Rob Landley) Date: Mon Jul 10 18:20:44 2006 Subject: [SVN] maintenance branch for 1.2.x In-Reply-To: <200607102312.10673.yann.morin.1998@anciens.enib.fr> References: <200607102312.10673.yann.morin.1998@anciens.enib.fr> Message-ID: <200607102120.29020.rob@landley.net> On Monday 10 July 2006 5:12 pm, Yann E. MORIN wrote: > Hello all, > Rob, > > I was looking at the subversion tree and saw no branch for the 1.2.x > series. > > Having such a branch would allow: > - to apply bug fixes, new features and enhancements to trunk, and to trunk > _only_, Everything that gets applied to trunk is to the new branch only. Fixes are cherry-picked out of that. (With a few exceptions, it's just a bunch of files from http://busybox.net/downloads/patches concatenated together.) > - back-port relevant fixes, and fixes _only_, to the maintenance branch, http://busybox.net/downloads/busybox-1.2.0.fixes.patch After being applied to the 1.2.0 release tarball to create 1.2.1, that file will become the file "changelog" in the 1.2.1 tarball. > - the pending patches for directory to go away as they > would be available directly from the repository. What pending patches directory? > Well at least, that's the way I'm used to work: once a release has been cut > out of the trunk, then create a branch for it to be maintained, name a > maintainer for that branch, and enjoy the fun work on the trunk, while > still keeping an eye on what's goin' on there. The linux kernel folks do it > that way (not that they have the absolute knowledge of what is best :-) ), > and it seems to work quite well. The bugfix only releases are exactly that: bugfixes only. Nothing goes into them that isn't a fix to a bug we've already fixed in svn, so we never have to forward port anything. > I know maintaining is not real fun, 'cause interesting things only happen > in the trunk, and maybe you don't want to spend too much time on this, > which I honestly understand for having the exact same problem at work. > That's why I think that you could have a little help from someone you > appointed to specially handle maintaining a revision (not that you are > doing a bad work at all, I do really appreciate the time and efforts you, > and others, devote to this project). Then, less time maintaining a series > means more time for you to handle your more important projects you've been > having pending for ages... I don't want to miss bugfixes that go into the old version but aren't fixed in what will be the next release. I want to avoid that coming up in the first place. > If you decide that you want such a maintainer for the 1.2.x series, then I > offer my services. I'm not a heavy nor an active contributor, but I have a > bit of time I can devote daily (well nightly I'd say), and helping in that > way would be my little stone to BusyBox. So far my -stable policy has consisted of cherry picked patches from -devel. I can see minimally tweaking them to get them to apply, but haven't had to yet. (I did squash one big set of changes into a single patch to just bring an applet up to -devel's level as the only sane way to fix the bug.) That way, there's not a whole lot to maintaining -stable other than pointing at patches in -svn that need backporting. I tried it the other way (1.01) and it was a nightmare trying to reconcile that with 1.1.0 to see what needed forward-porting... > Of course, should someone else be more suited for the work, or willing to > do the job, please speak up! :-) > > Regards, and long live BusyBox! > Yann E. MORIN. > > PS. Sorry for the long mail, and all the blahblah in there, but I'm tired, > and when I'm tired I tend to be a little verbose and not go to the point. Join the club. > And don't forget English is not my mother tongue and I have a rather > limited vocabulary... Oh shit I'm doing it again. Bed time. > YEM. Blaise Pascal once had a P.S. apologizing for writing a long letter because he didn't have time to write a short one. Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Tue Jul 11 00:24:03 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jul 11 00:24:18 2006 Subject: df does not report my root file system In-Reply-To: <00a301c6a487$e3747c00$0100a8c0@newlife> References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> <44B28229.4080707@bfs.de> <00a301c6a487$e3747c00$0100a8c0@newlife> Message-ID: <20060711072403.GA28858@aon.at> On Tue, Jul 11, 2006 at 09:18:16AM +0800, Ming-Ching Tiew wrote: > >I have tried with bb 1.0 and bb 1.2.0. > >And I think it is almost independent of bb version. This is correct. See http://bugs.uclibc.org/view.php?id=145 http://bugs.uclibc.org/view.php?id=894 > >Please note that your case is different from what I >am reporting. I have no doubt that df will work under >your scenario. But I issued the command 'df' inside >the initramfs, I have no other block devices mounted >under the root, ie initramfs is my root file system. > >Regards. > >----- Original Message ----- >From: "walter harms" >To: "Ming-Ching Tiew" >Cc: >Sent: Tuesday, July 11, 2006 12:36 AM >Subject: Re: df does not report my root file system > > >> please, >> what version fo bb you are using ? >> what processor ? >> my bb works fine: >> $ busybox >> BusyBox v1.1.0 (2006.06.26-17:06+0000) multi-call binary >> >> >> $df >> Filesystem 1k-blocks Used Available Use% Mounted on >> /dev/flash3 9032 9032 0 100% / >> /dev/flash2 4736 1064 3672 22% /mnt/flash >> tmpfs 10240 400 9840 4% /var >> >> i will be away the next few days. please provide the needed information >> on the list. >> >> re, >> walter >> >> >> Ming-Ching Tiew wrote: >> > This is the output of these commands :- >> > >> > # ls -al /dev/ram0 /dev/root >> > brw-rw---- 1 root root 1, 0 July 10 15:30 /dev/ram0 >> > lrwxrwxrwx 1 root root 9 July 10 15:30 /dev/root -> /dev/ram0 >> > # cat /proc/mounts >> > rootfs / rootfs rw 0 0 >> > /proc /proc proc rw 0 0 >> > # df >> > Filesystem 1k-blocks Used Available >> > (blank output except for the header ) >> > >> > This is executed in initramfs. >> > >> > Now my problem is that 'df' does not report the root filesystem. >> > What do I have to do to make it report the root files system ? >> > >> > Regards. >> > >> > > > > > >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox > From rep.nop at aon.at Tue Jul 11 00:32:45 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jul 11 00:32:50 2006 Subject: insmod module.ko In-Reply-To: <44B05494.9070105@bizmail.com.au> References: <44ACE8A4.90106@bizmail.com.au> <20060706115503.GC9309@aon.at> <4498.203.217.29.133.1152227196.squirrel@203.217.29.133> <200607062031.54698.vapier@gentoo.org> <44B05494.9070105@bizmail.com.au> Message-ID: <20060711073245.GB28858@aon.at> On Sun, Jul 09, 2006 at 10:57:56AM +1000, Jim wrote: >Thanks Mike and all responses. The loading module works now after adding >a full path to the insmod. Now there is another issue. My module.ko >contains an i2c function i2c_add_driver() and other i2c functions. The >i2c has been built in kernel, but loading module.ko was crashed at >i2c_add_driver() in an exception of null address. The i2c functions were >not linked in module.ko. I am not clear whether the unresolved symbols >should be resolved in kernel module building process or in insmod >loading process. Could you clarify please? Does the insmod loading >process search unresolved symbols in kernel binary > >As I mentioned that the module.o was running fine in kernel 2.4. In >kernel 2.4, I did not even specify the full path to the insmod, it was >called just "insmod module.o". In kernel 2.6, I have to call "insmod >/usr/lib/2.6.8/kernel/module.ko" to make it works. I am not sure if I >was still missing something in kernel 2.6 loading process? Sounds like you're missing modprobe.. The sequence would be 1) create a dependency file for your modules (see depmod.pl resp. depmod on your host, eventually) 2) modprobe module; where module is without extension (guessed by modprobe which also should load the prerequisites of 'module') This is not busybox specific, there should be excentive documentation out there which covers module loading. HTH. From mingching.tiew at redtone.com Tue Jul 11 01:00:54 2006 From: mingching.tiew at redtone.com (Ming-Ching Tiew) Date: Tue Jul 11 01:03:31 2006 Subject: df does not report my root file system References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> <44B28229.4080707@bfs.de> <00a301c6a487$e3747c00$0100a8c0@newlife> <20060711072403.GA28858@aon.at> Message-ID: <036c01c6a4c0$22a06190$0100a8c0@newlife> From: "Bernhard Fischer" > > > >I have tried with bb 1.0 and bb 1.2.0. > > > >And I think it is almost independent of bb version. > > This is correct. > See > http://bugs.uclibc.org/view.php?id=145 > http://bugs.uclibc.org/view.php?id=894 > > > Not sure what do you mean by "This is correct". Did you mean my observation is correct or you mean bb is correct ? :-) Before I made the first post, I have already tried bug id 894 patch. It did not make any difference. Also bug id 145 patch could not be applied on bb 1.2.0. Now I am not sure why id 894 patch did not fix my problem. Maybe there is something I did not do correct on my side. Regard. From roberto.foglietta at gmail.com Tue Jul 11 01:18:29 2006 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Tue Jul 11 01:18:35 2006 Subject: timeout applet (new version) Message-ID: Hi to all, updated: http://bugs.busybox.net/view.php?id=680 Applet version 0.2.7 applies against busybox v1.1.3, changelog: a) Note: 0000600bytes less than previous applet version b) 1 bug less than previous applet version c) added regression test in testsuite [roberto@GEDX0327 busybox-1.1.3]$ size libbb/talarm.o text data bss dec hex filename 1176 20 12 1208 4b8 libbb/talarm.o [roberto@GEDX0327 busybox-1.1.3]$ size miscutils/timeout.o text data bss dec hex filename 316 24 0 340 154 miscutils/timeout.o Some options have been removed, now this applet is easier to use: [roberto@GEDX0327 busybox-1.1.3]$ busybox timeout USAGE: timeout [-s int_signal] "" [roberto@GEDX0327 busybox-1.1.3]$ busybox timeout --help BusyBox v1.1.3 (2006.07.11-08:14+0000) multi-call binary Usage: timeout [-s signal] "" Runs the "command line" within a timeout window and returns its status. Options: -s Number of signal to the command and its children when timeout expires Please spent a minute to integrate in bb, -- /roberto -------------- next part -------------- A non-text attachment was scrubbed... Name: timeout_applet-0.2.7.tar.bz2 Type: application/x-bzip2 Size: 5431 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060711/997e1d02/timeout_applet-0.2.7.tar.bin From rep.nop at aon.at Tue Jul 11 01:50:39 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jul 11 01:50:51 2006 Subject: df does not report my root file system In-Reply-To: <036c01c6a4c0$22a06190$0100a8c0@newlife> References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> <44B28229.4080707@bfs.de> <00a301c6a487$e3747c00$0100a8c0@newlife> <20060711072403.GA28858@aon.at> <036c01c6a4c0$22a06190$0100a8c0@newlife> Message-ID: <20060711085039.GC28858@aon.at> On Tue, Jul 11, 2006 at 04:00:54PM +0800, Ming-Ching Tiew wrote: >Not sure what do you mean by "This is correct". Did you mean my observation is >correct or you mean bb is correct ? :-) Your observation that it's broken since a long time is correct. > >Before I made the first post, I have already tried bug id 894 patch. It did not make >any difference. Also bug id 145 patch could not be applied on bb 1.2.0. Please try the attached updated patch from #145 and let me know if this fixes the problem you are seeing -------------- next part -------------- Index: libbb/find_mount_point.c =================================================================== --- libbb/find_mount_point.c (revision 15683) +++ libbb/find_mount_point.c (working copy) @@ -27,7 +27,7 @@ struct mntent *find_mount_point(const ch FILE *mountTable; struct mntent *mountEntry; - if (stat(name, &s) != 0) + if (stat(name, &s) != 0 && strcmp(name,"/dev/root")) return 0; if ((s.st_mode & S_IFMT) == S_IFBLK) @@ -40,14 +40,15 @@ struct mntent *find_mount_point(const ch return 0; while ((mountEntry = getmntent(mountTable)) != 0) { - - if(strcmp(name, mountEntry->mnt_dir) == 0 - || strcmp(name, mountEntry->mnt_fsname) == 0) /* String match. */ - break; - if (stat(mountEntry->mnt_fsname, &s) == 0 && s.st_rdev == mountDevice) /* Match the device. */ - break; - if (stat(mountEntry->mnt_dir, &s) == 0 && s.st_dev == mountDevice) /* Match the directory's mount point. */ - break; + if (!strcmp(mountEntry->mnt_fsname, "rootfs")) + continue; + if (strcmp(name, mountEntry->mnt_dir) == 0 + || strcmp(name, mountEntry->mnt_fsname) == 0) + break; /* String match. */ + if (stat(mountEntry->mnt_fsname, &s) == 0 && s.st_rdev == mountDevice) + break; /* Match the device. */ + if (stat(mountEntry->mnt_dir, &s) == 0 && s.st_dev == mountDevice) + break; /* Match the directory's mount point. */ } endmntent(mountTable); return mountEntry; From mingching.tiew at redtone.com Tue Jul 11 03:17:58 2006 From: mingching.tiew at redtone.com (Ming-Ching Tiew) Date: Tue Jul 11 03:19:18 2006 Subject: df does not report my root file system References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> <44B28229.4080707@bfs.de> <00a301c6a487$e3747c00$0100a8c0@newlife> <20060711072403.GA28858@aon.at> <036c01c6a4c0$22a06190$0100a8c0@newlife> <20060711085039.GC28858@aon.at> Message-ID: <042701c6a4d3$48c71860$0100a8c0@newlife> From: "Bernhard Fischer" > Please try the attached updated patch from #145 and let me know if this > fixes the problem you are seeing > It did not look good either. Basically I did some debug prints, I found that rootfs ( initramfs, device=rootfs, mount_point=/ ) reports s.f_blocks = 0 ( see df.c source ), so whatever logic inside the block has been skipped. Basically I think initramfs does not have the block file system behaviour, so statfs() is hopeless on it. Regards. From rbraun at proformatique.com Tue Jul 11 03:17:49 2006 From: rbraun at proformatique.com (Richard Braun) Date: Tue Jul 11 03:38:22 2006 Subject: Patch for BusyBox httpd Message-ID: <20060711101749.GA14378@sceen.net> Hello, Here are two patches for BusyBox httpd (stable 1.1.3 release) which respectively add support for interpreters outside of /cgi-bin/ (something very useful for lots of PHP based applications) and write the PID of the master process into /var/run/httpd.pid (I have found no way to force httpd to stay in the foreground, and no option to make it write the PID somewhere). These patches are quite small, and could easily be improved (I had no personal need for better support like an option to specify the PID file), so I just send them as is, with no other intention than sending them somewhere in case they help other people, and the best location seemed to be the mailing list :-). -- Richard Braun Proformatique - 67 rue Voltaire - 92800 Puteaux Tel. : 01 41 38 99 60 - Fax. : 01 41 38 99 70 Email : rbraun@proformatique.com - http://proformatique.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://busybox.net/lists/busybox/attachments/20060711/7db12f3e/attachment.pgp From rbraun at proformatique.com Tue Jul 11 03:19:43 2006 From: rbraun at proformatique.com (Richard Braun) Date: Tue Jul 11 03:38:35 2006 Subject: Patch for BusyBox httpd Message-ID: <20060711101943.GA14493@sceen.net> Hello, Here are two patches for BusyBox httpd (stable 1.1.3 release) which respectively add support for interpreters outside of /cgi-bin/ (something very useful for lots of PHP based applications) and write the PID of the master process into /var/run/httpd.pid (I have found no way to force httpd to stay in the foreground, and no option to make it write the PID somewhere). These patches are quite small, and could easily be improved (I had no personal need for better support like an option to specify the PID file), so I just send them as is, with no other intention than sending them somewhere in case they help other people, and the best location seemed to be the mailing list :-). -- Richard Braun Proformatique - 67 rue Voltaire - 92800 Puteaux Tel. : 01 41 38 99 60 - Fax. : 01 41 38 99 70 Email : rbraun@proformatique.com - http://proformatique.com/ As usual, I forgot the patches ... :-) diff -Nurp busybox-1.1.3.orig/networking/httpd.c busybox-1.1.3/networking/httpd.c --- busybox-1.1.3.orig/networking/httpd.c 2006-03-22 22:16:19.000000000 +0100 +++ busybox-1.1.3/networking/httpd.c 2006-07-10 18:47:24.000000000 +0200 @@ -1815,9 +1815,27 @@ FORBIDDEN: /* protect listing /cgi- goto FORBIDDEN; // protect listing cgi-bin/ sendCgi(url, prequest, length, cookie, content_type); } else { - if (prequest != request_GET) +#ifdef CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR + char *suffix = strrchr(url, '.'); + int interpr_cgi = 0; + + if(suffix) { + Htaccess * cur; + size_t suffix_len = strlen(suffix); + for (cur = config->script_i; cur; cur = cur->next) + if(strncmp(cur->before_colon + 1, suffix, suffix_len) == 0) { + interpr_cgi = 1; + break; + } + } + + if (interpr_cgi) { + sendCgi(url, prequest, length, cookie, content_type); + } else { +#endif /* CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR */ + if (prequest != request_GET) sendHeaders(HTTP_NOT_IMPLEMENTED); - else { + else { #endif /* CONFIG_FEATURE_HTTPD_CGI */ if(purl[-1] == '/') strcpy(purl, "index.html"); @@ -1832,9 +1850,12 @@ FORBIDDEN: /* protect listing /cgi- #endif #ifdef CONFIG_FEATURE_HTTPD_CGI + } +#ifdef CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR } +#endif /* CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR */ } -#endif +#endif /* CONFIG_FEATURE_HTTPD_CGI */ } while (0); diff -Nurp busybox-1.1.3.orig/networking/httpd.c busybox-1.1.3/networking/httpd.c --- busybox-1.1.3.orig/networking/httpd.c 2006-07-11 11:49:57.000000000 +0200 +++ busybox-1.1.3/networking/httpd.c 2006-07-11 11:50:25.000000000 +0200 @@ -2153,6 +2153,15 @@ int httpd_main(int argc, char *argv[]) # if !DEBUG if (daemon(1, 0) < 0) /* don`t change curent directory */ bb_perror_msg_and_die("daemon"); + + char *pidfilename = "/var/run/httpd.pid"; + FILE *pidfile = fopen(pidfilename, "w"); + + if (pidfile == NULL) + bb_perror_msg_and_die("can't open %s", pidfilename); + + fprintf(pidfile, "%d\n", getpid()); + fclose(pidfile); # endif return miniHttpd(server); #else -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://busybox.net/lists/busybox/attachments/20060711/d018515a/attachment.pgp From rpjday at mindspring.com Tue Jul 11 04:18:33 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Tue Jul 11 04:21:04 2006 Subject: should all BB code be GPL? In-Reply-To: <200607101356.06287.farmatito@tiscali.it> References: <200607101356.06287.farmatito@tiscali.it> Message-ID: On Mon, 10 Jul 2006, Tito wrote: ... > You will find the same header also in: > > file:///root/Desktop/busybox.orig/libbb/correct_password.c (rewritten: patch pending, and a new one I'm working on now but not ready yet) > file:///root/Desktop/busybox.orig/libbb/pwd2spwd.c (to be removed: patch pending) > file:///root/Desktop/busybox.orig/libbb/restricted_shell.c > file:///root/Desktop/busybox.orig/libbb/run_shell.c > file:///root/Desktop/busybox.orig/libbb/setup_environment.c > > it was also in: > > file:///root/Desktop/busybox.orig/libbb/obscure.c > but this one was already rewritten and is now GPL. ok, but i'm still unclear -- should all code in BB be GPL? including examples such as libbb/correct_password.c that make no mention of GPL but, rather, show a copyright plus "All rights reserved." rday From rpjday at mindspring.com Tue Jul 11 04:19:51 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Tue Jul 11 04:21:52 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711101943.GA14493@sceen.net> References: <20060711101943.GA14493@sceen.net> Message-ID: On Tue, 11 Jul 2006, Richard Braun wrote: > Hello, > > Here are two patches for BusyBox httpd (stable 1.1.3 release) which > respectively add support for interpreters outside of /cgi-bin/ > (something very useful for lots of PHP based applications) and write > the PID of the master process into /var/run/httpd.pid ... snip ... i can apply those patches if no one objects. what's the protocol for applying someone else's patches? rday From rep.nop at aon.at Tue Jul 11 05:00:07 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jul 11 05:00:15 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711101943.GA14493@sceen.net> References: <20060711101943.GA14493@sceen.net> Message-ID: <20060711120006.GA862@aon.at> On Tue, Jul 11, 2006 at 12:19:43PM +0200, Richard Braun wrote: >Hello, > >Here are two patches for BusyBox httpd (stable 1.1.3 release) which >respectively add support for interpreters outside of /cgi-bin/ >(something very useful for lots of PHP based applications) and >write the PID of the master process into /var/run/httpd.pid >(I have found no way to force httpd to stay in the foreground, >and no option to make it write the PID somewhere). These patches I believe that you should use start-stop-daemon -m /var/run/httpd.pid -x ..... to create pidfiles. To me, it doesn't make sense to equip the individual daemons with redundant functionality (introducing x{read,write}_pidfile and using that also sounds like a bad idea to me). Put short: NAK for the pidfile thing and shrug for the interpreters, in my POV >are quite small, and could easily be improved (I had no personal >need for better support like an option to specify the PID file), >so I just send them as is, with no other intention than sending >them somewhere in case they help other people, and the best location >seemed to be the mailing list :-). From rbraun at proformatique.com Tue Jul 11 05:14:33 2006 From: rbraun at proformatique.com (Richard Braun) Date: Tue Jul 11 05:14:50 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711120006.GA862@aon.at> References: <20060711101943.GA14493@sceen.net> <20060711120006.GA862@aon.at> Message-ID: <20060711121433.GA16264@sceen.net> On Tue, Jul 11, 2006 at 02:00:07PM +0200, Bernhard Fischer wrote: > I believe that you should use start-stop-daemon -m /var/run/httpd.pid -x > ..... to create pidfiles. To me, it doesn't make sense to equip the > individual daemons with redundant functionality (introducing > x{read,write}_pidfile and using that also sounds like a bad idea to me). The problem with start-stop-daemon is that it relies on the daemon to create its PID file. When the daemon doesn't, it usually provides an option to force running in the foreground, so that you can use start-stop-daemon with --background and --make-pidfile. The problem with busybox httpd is that it doesn't provide such an option. So when using start-stop-daemon, you never get the right PID, only the PID of the parent httpd process, before daemon() is called... -- Richard Braun -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://busybox.net/lists/busybox/attachments/20060711/813e2b23/attachment.pgp From farmatito at tiscali.it Tue Jul 11 05:43:26 2006 From: farmatito at tiscali.it (Tito) Date: Tue Jul 11 05:43:54 2006 Subject: [PATCH] pwd2spwd.c removal Message-ID: <200607111443.26417.farmatito@tiscali.it> Hi, this patch removes pwd2spwd.c from libbb as it is used only in one place (passwd.c) and in a silly way. function old new delta passwd_main 2335 2316 -19 static.sp 36 - -36 pwd_to_spwd 108 - -108 ------------------------------------------------------------------------------ (add/remove: 0/2 grow/shrink: 0/1 up/down: 0/-163) Total: -163 bytes The patch is tested and works for me. Please apply. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: pwd2spwd_removal.patch Type: text/x-diff Size: 4498 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060711/79abeb3e/pwd2spwd_removal.bin From farmatito at tiscali.it Tue Jul 11 05:54:33 2006 From: farmatito at tiscali.it (Tito) Date: Tue Jul 11 05:54:41 2006 Subject: [PATCH] fix minor bug in obscure.c Message-ID: <200607111454.33603.farmatito@tiscali.it> Hi, this patch fixes a minor bug in obscure.c. If the gecos field of an user is empty obscure reports a false "similar to gecos" error. The patch is trivial and tested, please apply. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: obscure.patch Type: text/x-diff Size: 459 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060711/61042301/obscure-0001.bin From stephane.billiart at gmail.com Tue Jul 11 06:00:27 2006 From: stephane.billiart at gmail.com (Stephane Billiart) Date: Tue Jul 11 06:05:52 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711121433.GA16264@sceen.net> References: <20060711101943.GA14493@sceen.net> <20060711120006.GA862@aon.at> <20060711121433.GA16264@sceen.net> Message-ID: <20060711130027.GA2465@localhost.localdomain> On 11/07/06 ? ? 14:14, Richard Braun wrote: > On Tue, Jul 11, 2006 at 02:00:07PM +0200, Bernhard Fischer wrote: > > I believe that you should use start-stop-daemon -m /var/run/httpd.pid -x > > ..... to create pidfiles. To me, it doesn't make sense to equip the > > individual daemons with redundant functionality (introducing > > x{read,write}_pidfile and using that also sounds like a bad idea to me). > > The problem with start-stop-daemon is that it relies on the daemon to > create its PID file. When the daemon doesn't, it usually provides an > option to force running in the foreground, so that you can use > start-stop-daemon with --background and --make-pidfile. The problem with > busybox httpd is that it doesn't provide such an option. So when > using start-stop-daemon, you never get the right PID, only the PID of > the parent httpd process, before daemon() is called... > > -- > Richard Braun As an alternative, here is a patch I personnally use and tried to submit to the list a while back that creates a writepidfile function in libbb to write PID files, remove redundancy where applicable (fakeidentd, inetd) and add the pidfile feature to crond and syslogd. To me, it makes sense to have library function for writing pidfiles. The patch applies to 1.1.3 but also works with the SVN head. -- St?phane Billiart http://perso.orange.fr/billiart/ -------------- next part -------------- diff -ruN busybox-1.1.3/include/libbb.h busybox-1.1.3.new/include/libbb.h --- busybox-1.1.3/include/libbb.h 2006-05-17 20:51:46.000000000 +0200 +++ busybox-1.1.3.new/include/libbb.h 2006-05-20 21:37:39.000000000 +0200 @@ -59,6 +59,8 @@ #define MAX(a,b) (((a)>(b))?(a):(b)) #endif +extern int bb_writepidfile(const char *path); +#define bb_removepidfile(f) remove_file(f, FILEUTILS_FORCE) extern void bb_show_usage(void) ATTRIBUTE_NORETURN ATTRIBUTE_EXTERNALLY_VISIBLE; extern void bb_error_msg(const char *s, ...) __attribute__ ((format (printf, 1, 2))); extern void bb_error_msg_and_die(const char *s, ...) __attribute__ ((noreturn, format (printf, 1, 2))); diff -ruN busybox-1.1.3/libbb/Makefile.in busybox-1.1.3.new/libbb/Makefile.in --- busybox-1.1.3/libbb/Makefile.in 2006-04-10 21:45:46.000000000 +0200 +++ busybox-1.1.3.new/libbb/Makefile.in 2006-05-20 21:27:16.000000000 +0200 @@ -22,7 +22,7 @@ kernel_version.c last_char_is.c login.c \ make_directory.c md5.c mode_string.c mtab_file.c \ obscure.c parse_mode.c parse_number.c perror_msg.c \ - perror_msg_and_die.c print_file.c get_console.c \ + perror_msg_and_die.c pidfile.c print_file.c get_console.c \ process_escape_sequence.c procps.c qmodule.c \ read_package_field.c recursive_action.c remove_file.c \ restricted_shell.c run_parts.c run_shell.c safe_read.c safe_write.c \ diff -ruN busybox-1.1.3/libbb/pidfile.c busybox-1.1.3.new/libbb/pidfile.c --- busybox-1.1.3/libbb/pidfile.c 1970-01-01 01:00:00.000000000 +0100 +++ busybox-1.1.3.new/libbb/pidfile.c 2006-05-20 21:38:18.000000000 +0200 @@ -0,0 +1,45 @@ +/* vi: set sw=4 ts=4: */ +/* + * Utility routines. + * + * Copyright (C) 1999-2004 by Erik Andersen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include "libbb.h" + +extern int bb_writepidfile(const char *path) +{ + FILE *pidf; + + if ((pidf = bb_wfopen(path, "w")) != NULL) { + fprintf(pidf, "%u\n", getpid()); + fclose(pidf); + return 0; + } + return 1; +} + +/* END CODE */ +/* +Local Variables: +c-file-style: "linux" +c-basic-offset: 4 +tab-width: 4 +End: +*/ diff -ruN busybox-1.1.3/miscutils/crond.c busybox-1.1.3.new/miscutils/crond.c --- busybox-1.1.3/miscutils/crond.c 2006-03-22 22:16:24.000000000 +0100 +++ busybox-1.1.3.new/miscutils/crond.c 2006-05-20 21:28:43.000000000 +0200 @@ -238,6 +238,7 @@ int rescan = 60; short sleep_time = 60; + bb_writepidfile("/var/run/crond.pid"); for (;;) { sleep((sleep_time + 1) - (short) (time(NULL) % sleep_time)); diff -ruN busybox-1.1.3/networking/fakeidentd.c busybox-1.1.3.new/networking/fakeidentd.c --- busybox-1.1.3/networking/fakeidentd.c 2006-03-22 22:16:19.000000000 +0100 +++ busybox-1.1.3.new/networking/fakeidentd.c 2006-05-20 21:33:20.000000000 +0200 @@ -138,31 +138,10 @@ static void handlexitsigs(int signum) { - if (unlink(PIDFILE) < 0) - close(open(PIDFILE, O_WRONLY|O_CREAT|O_TRUNC, 0644)); + bb_removepidfile(PIDFILE); exit(0); } -/* May succeed. If not, won't care. */ -static inline void writepid(uid_t nobody, uid_t nogrp) -{ - char buf[24]; - int fd = open(PIDFILE, O_WRONLY|O_CREAT|O_TRUNC, 0664); - - if (fd < 0) - return; - - snprintf(buf, 23, "%d\n", getpid()); - write(fd, buf, strlen(buf)); - fchown(fd, nobody, nogrp); - close(fd); - - /* should this handle ILL, ... (see signal(7)) */ - signal(SIGTERM, handlexitsigs); - signal(SIGINT, handlexitsigs); - signal(SIGQUIT, handlexitsigs); -} - /* return 0 as parent, 1 as child */ static int godaemon(void) { @@ -179,7 +158,11 @@ bb_error_msg_and_die("Cannot find uid/gid of user '%s'", nobodystr); nobody = pw->pw_uid; nogrp = pw->pw_gid; - writepid(nobody, nogrp); + bb_writepidfile(PIDFILE); + /* should this handle KILL, ... (see signal(7)) */ + signal(SIGTERM, handlexitsigs); + signal(SIGINT, handlexitsigs); + signal(SIGQUIT, handlexitsigs); close(0); inetbind(); diff -ruN busybox-1.1.3/networking/inetd.c busybox-1.1.3.new/networking/inetd.c --- busybox-1.1.3/networking/inetd.c 2006-03-22 22:16:19.000000000 +0100 +++ busybox-1.1.3.new/networking/inetd.c 2006-05-20 21:34:33.000000000 +0200 @@ -1224,7 +1224,7 @@ } (void) close (sep->se_fd); } - (void) unlink (_PATH_INETDPID); + bb_removepidfile (_PATH_INETDPID); exit (0); } @@ -1327,14 +1327,7 @@ setgroups (1, &gid); } - { - FILE *fp; - - if ((fp = fopen (_PATH_INETDPID, "w")) != NULL) { - fprintf (fp, "%u\n", getpid ()); - (void) fclose (fp); - } - } + bb_writepidfile (_PATH_INETDPID); if (getrlimit (RLIMIT_NOFILE, &rlim_ofile) < 0) { syslog (LOG_ERR, "getrlimit: %m"); diff -ruN busybox-1.1.3/sysklogd/syslogd.c busybox-1.1.3.new/sysklogd/syslogd.c --- busybox-1.1.3/sysklogd/syslogd.c 2006-03-22 22:16:20.000000000 +0100 +++ busybox-1.1.3.new/sysklogd/syslogd.c 2006-05-20 21:30:32.000000000 +0200 @@ -459,6 +459,7 @@ #ifdef CONFIG_FEATURE_IPC_SYSLOG ipcsyslog_cleanup(); #endif + bb_removepidfile("/var/run/syslogd.pid"); exit(TRUE); } @@ -686,6 +687,7 @@ bb_perror_msg_and_die("daemon"); #endif /* __uClinux__ */ } + bb_writepidfile("/var/run/syslogd.pid"); doSyslogd(); return EXIT_SUCCESS; From floydpink at gmail.com Tue Jul 11 07:38:11 2006 From: floydpink at gmail.com (Jason Schoon) Date: Tue Jul 11 07:38:21 2006 Subject: should all BB code be GPL? In-Reply-To: References: <200607101356.06287.farmatito@tiscali.it> Message-ID: <78a54e1b0607110738i2fec8980t17cff78af24797be@mail.gmail.com> On 7/11/06, Robert P. J. Day wrote: > > On Mon, 10 Jul 2006, Tito wrote: > ... > > You will find the same header also in: > > > > file:///root/Desktop/busybox.orig/libbb/correct_password.c (rewritten: > patch pending, and a new one I'm working on now but not ready yet) > > file:///root/Desktop/busybox.orig/libbb/pwd2spwd.c (to be removed: patch > pending) > > file:///root/Desktop/busybox.orig/libbb/restricted_shell.c > > file:///root/Desktop/busybox.orig/libbb/run_shell.c > > file:///root/Desktop/busybox.orig/libbb/setup_environment.c > > > > it was also in: > > > > file:///root/Desktop/busybox.orig/libbb/obscure.c > > but this one was already rewritten and is now GPL. > > ok, but i'm still unclear -- should all code in BB be GPL? including > examples such as libbb/correct_password.c that make no mention of GPL > but, rather, show a copyright plus "All rights reserved." > > Well, when you are talking about existing code, I think Adam's point was that by definition it is now GPL, because it is included and linked into a GPL application. Thus, any existing code is GPL. That does not necessarily mean there aren't still other license terms in effect though, such as requiring the original author's name in the source code and such, those would still need to be honored also. Any new code should only be accepted if it is GPL, is compatible with GPL (BSD), or the author gives permission to relicense it as GPL. (This is all just my take on the situation.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060711/d7371fab/attachment.html From vda.linux at googlemail.com Tue Jul 11 07:44:48 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Tue Jul 11 07:45:00 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607102047.14896.rob@landley.net> References: <200607081844.18212.vda.linux@googlemail.com> <200607101146.46903.vda.linux@googlemail.com> <200607102047.14896.rob@landley.net> Message-ID: <200607111644.48224.vda.linux@googlemail.com> On Tuesday 11 July 2006 02:47, Rob Landley wrote: > > The attached test program shows that snprintf is 2.5 times slower > > than utoa. Operations done per second: > > sprintf='12345678' count=27346 > > utoa_to_buf='12345678' count=69880 > > utoa='12345678' count=65934 > > > > A few days ago I ran "hexdump | grep" over entire hard drive. > > Took a long time. I wish hexdump was optimized a bit better... > > I haven't really looked closely at hexdump, but what does a base 10 utoa have > to do with a base 16 hexdump? This is a real-life example of a program which does a lot of int -> string conversions, so that it actually mattered for me recently. hexdump is of course using base 16 conversion. tcpdump could be an example of a proc which does base 10 conversions, but I didn't use it lately. > The lookup table is a classic size/speed tradeoff, something BusyBox has > traditionally come down on the "size" side of. Doing a write() on the result > is going to be way slower than the actual conversion anyway. What actual > bottleneck are you seeing? > > I definitely agree the bounds checking needs to be added, though. I'll do > that now... The version in current svn produces _most significant_ digits if buffer is too small. IOW: utoa_to_buf_rob(100223,buf,3)=="10". The usual practuce is to produce "23". How about this modified version? // 0x63 bytes void utoa_to_buf_rob(unsigned n, char *buf, int buflen) { unsigned i, out; if (buflen) { buflen -= 11; out = 0; for (i=1000000000; i; i/=10) { unsigned res = n / i; n %= i; // gcc reuses remainder produced in division if (res || out || i == 1) { out++; if (buflen >= 0) *buf++ = '0' + res; } buflen++; } *buf = 0; } } It's even a bit smaller. gcc is smart enough to know div instruction produces the remainder also, and we get n %= i for free. I still dislike the speed, i/=10 eats too much CPU... -- vda From giuseppe at telvia.it Tue Jul 11 07:55:39 2006 From: giuseppe at telvia.it (Giuseppe Ciotta) Date: Tue Jul 11 07:55:49 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711121433.GA16264@sceen.net> References: <20060711101943.GA14493@sceen.net> <20060711120006.GA862@aon.at> <20060711121433.GA16264@sceen.net> Message-ID: <20060711145539.GA1867@ummmagumma.localnet> On Tue, Jul 11, 2006 at 02:14:33PM +0200, Richard Braun wrote: > On Tue, Jul 11, 2006 at 02:00:07PM +0200, Bernhard Fischer wrote: > > I believe that you should use start-stop-daemon -m /var/run/httpd.pid -x > > ..... to create pidfiles. To me, it doesn't make sense to equip the > > individual daemons with redundant functionality (introducing > > x{read,write}_pidfile and using that also sounds like a bad idea to me). > > The problem with start-stop-daemon is that it relies on the daemon to > create its PID file. When the daemon doesn't, it usually provides an > option to force running in the foreground, so that you can use > start-stop-daemon with --background and --make-pidfile. The problem with > busybox httpd is that it doesn't provide such an option. What about adding the option to go in foreground and leave the pid writing task to start-stop-daemon then? -- From rob at landley.net Tue Jul 11 07:56:25 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 08:03:05 2006 Subject: df does not report my root file system In-Reply-To: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> References: <01c201c6a3f3$ab3f2360$0100a8c0@newlife> Message-ID: <200607111056.27154.rob@landley.net> On Monday 10 July 2006 3:37 am, Ming-Ching Tiew wrote: > This is the output of these commands :- > > # ls -al /dev/ram0 /dev/root > brw-rw---- 1 root root 1, 0 July 10 15:30 /dev/ram0 > lrwxrwxrwx 1 root root 9 July 10 15:30 /dev/root -> /dev/ram0 > # cat /proc/mounts > rootfs / rootfs rw 0 0 > /proc /proc proc rw 0 0 > # df > Filesystem 1k-blocks Used Available > (blank output except for the header ) > > This is executed in initramfs. > > Now my problem is that 'df' does not report the root filesystem. > What do I have to do to make it report the root files system ? > > Regards. Yeah, df is broken. I need to upgrade it. I have a todo item to make df sort the mount points and show the most recent of each. The problem is that rootfs is always mounted even when you're not using initramfs (or after you've pivoted off of it). In most systems another partition gets mounted over it during normal use, and so we needed to add extra logic to avoid df showing a partition you can't access. The _correct_ fix would have been to accumulate a list of mount points and kill duplicates, showing only the latest of each. What we did is special case the root mount so we never show rootfs, which is wrong and broken and doesn't give the right result if something _else_ is overmounted. (Which isn't a common case, but is easily possible with bind mounts or ubuntu 6.06's broken init scripts that mount /var/run and /var/lock _twice_ (it's tmpfs, they stack)...) I'll fix it. Rob -- Never bet against the cheap plastic solution. From rbraun at proformatique.com Tue Jul 11 08:05:19 2006 From: rbraun at proformatique.com (Richard Braun) Date: Tue Jul 11 08:05:31 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711145539.GA1867@ummmagumma.localnet> References: <20060711101943.GA14493@sceen.net> <20060711120006.GA862@aon.at> <20060711121433.GA16264@sceen.net> <20060711145539.GA1867@ummmagumma.localnet> Message-ID: <20060711150519.GA21532@sceen.net> On Tue, Jul 11, 2006 at 04:55:39PM +0200, Giuseppe Ciotta wrote: > > The problem with start-stop-daemon is that it relies on the daemon to > > create its PID file. When the daemon doesn't, it usually provides an > > option to force running in the foreground, so that you can use > > start-stop-daemon with --background and --make-pidfile. The problem with > > busybox httpd is that it doesn't provide such an option. > > What about adding the option to go in foreground and leave the pid > writing task to start-stop-daemon then? It's one solution, but usually, a daemon is designed to run in the background, so using an option to run in the foreground for a daemon designed to run in the background is not really logic. The usual way, again, is that the daemon has an option to write his PID file. The best implementation has both : it can write the PID file, and it can run in the foreground, depending on the user options. -- Richard Braun Proformatique - 67 rue Voltaire - 92800 Puteaux Tel. : 01 41 38 99 60 - Fax. : 01 41 38 99 70 Email : rbraun@proformatique.com - http://proformatique.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://busybox.net/lists/busybox/attachments/20060711/edcd9808/attachment.pgp From rob at landley.net Tue Jul 11 08:07:50 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 08:08:00 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: <200607101226.56594.vda.linux@googlemail.com> References: <200607091941.52238.vda.linux@googlemail.com> <20060710093516.GK10146@shell.blacknet.de> <200607101226.56594.vda.linux@googlemail.com> Message-ID: <200607111107.50480.rob@landley.net> On Monday 10 July 2006 6:26 am, Denis Vlasenko wrote: > Answer to "why supervise?" question: > supervise do not simply restart processes when they die. It provides > means of _controlling_ them (using svc): I'm not really enthused about this so far. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 11 08:17:33 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 08:17:41 2006 Subject: should all BB code be GPL? In-Reply-To: References: Message-ID: <200607111117.33296.rob@landley.net> On Monday 10 July 2006 7:20 am, Robert P. J. Day wrote: > i was just about to write a perl script to go through the source > files and replace any GPL-related verbosity with the single-line > boilerplate for brevity until i read this in libbb/change_identity.c > (sorry about the ugly re-formatting, you can blame pine): All busybox code _is_ GPL. If it isn't, we can't ship it in a GPL project. Some of it is dual licensed, although I'm pretty happy to rip out the notice of the other license since the original authors can make it available elsewhere under whatever license they like. The _busybox_ version is GPL. > =================================== > /* > * Copyright 1989 - 1991, Julianne Frances Haugh > > * All rights reserved. Yeah, I met him once at an Austin LUG meeting. Remember my big passwd rewrite that got buried in other todo items? Licensing issues are about 20% of my motivation there. About 80% of it is that I can throw away huge quantities of crappy code and replace it with a much smaller amount of less crappy code. > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: This is a long form of the BSD license. > i don't see any reference to the GPL here. what should i assume? That somebody nailed BSD licensed code into BusyBox and assumed it could be trivially relicensed to GPL due to the University of California's statement defanging the advertising clause, without noticing that this code was not copyright the Regants of the University of California but some individual guy? I consider "code must include this notice" to be incompatible with the GPL, but most people don't seem to interpret it that strictly... > rday Rob -- Never bet against the cheap plastic solution. From dalias at aerifal.cx Tue Jul 11 08:39:14 2006 From: dalias at aerifal.cx (Rich Felker) Date: Tue Jul 11 08:25:43 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711150519.GA21532@sceen.net> References: <20060711101943.GA14493@sceen.net> <20060711120006.GA862@aon.at> <20060711121433.GA16264@sceen.net> <20060711145539.GA1867@ummmagumma.localnet> <20060711150519.GA21532@sceen.net> Message-ID: <20060711153914.GA14376@brightrain.aerifal.cx> On Tue, Jul 11, 2006 at 05:05:19PM +0200, Richard Braun wrote: > On Tue, Jul 11, 2006 at 04:55:39PM +0200, Giuseppe Ciotta wrote: > > > The problem with start-stop-daemon is that it relies on the daemon to > > > create its PID file. When the daemon doesn't, it usually provides an > > > option to force running in the foreground, so that you can use > > > start-stop-daemon with --background and --make-pidfile. The problem with > > > busybox httpd is that it doesn't provide such an option. > > > > What about adding the option to go in foreground and leave the pid > > writing task to start-stop-daemon then? > > It's one solution, but usually, a daemon is designed to run in the > background, so using an option to run in the foreground for a daemon > designed to run in the background is not really logic. The usual way, > again, is that the daemon has an option to write his PID file. The > best implementation has both : it can write the PID file, and it > can run in the foreground, depending on the user options. I agree, this is a much more sane approach. I never understood the obsession with start-stop-daemon. Rich From rob at landley.net Tue Jul 11 08:36:44 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 08:36:54 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607100913.56567.mszick@morethan.org> References: <200607081844.18212.vda.linux@googlemail.com> <200607101146.46903.vda.linux@googlemail.com> <200607100913.56567.mszick@morethan.org> Message-ID: <200607111136.44715.rob@landley.net> On Monday 10 July 2006 10:13 am, Michael S. Zick wrote: > On Mon July 10 2006 04:46, Denis Vlasenko wrote: > > I think I'm starting to waste your (and my) time. > > Alpha is almost history now... > > Almost for some, > > (HP) Vax and MicroVax - no new machines, remarket only > (HP) Alpha Servers - new orders only until Oct. 2006 > (HP) PA-RISC, 64-bit - alive and well - no 64-bit userland > under Linux - 64-bit Linux kernel alive and well. I always assumed that PA-RISC used HP-PA processors. (Which I vaguely recall Linux being ported to by The Puffin Group, years ago...) > Two on-going efforts to keep in mind... > > Giving parisc-Linux a 64-bit userland is on-going, but you > will not see these in an embedded system. I still think PA-RISC is an architecture from HP. And the parisc-linux website would appear to agree with me: http://www.parisc-linux.org/ > If an adaption of BB gets shoved into the kernel as some > propose - then handling 64-bit & 128-bit types may come up again. *blink* *blink* No. And I'm not against handling 64 bit and 128 bit types, I'm just saying that "int" is 32 bit (not 64 or 128 bit) on any platform we care to support. Long is 64 bits on some platforms of interest to us, and long long is 128 bit on some, 64 bit on others. > But still, sizeof(unsigned int) is set by choosing the compiler > to use for the code. There are only two widely used compilers > for pa-risc - HP and GCC - those are 32-bit unsigned int for > both compilers, both 32-bit and 64-bit machines. > (The hardware handles the masking and sign extension.) > > Now if you wanted to know about the sizeof(long double)... > Thank goodness, you don't. We largely avoid floating point. Where we use it, we usually have a CONFIG option, ala SORT. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 11 08:45:20 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 08:45:25 2006 Subject: [PATCH] .config.mak and CROSS_COMPILE fails with check_cc In-Reply-To: <7f45d9390607101017w6a05e0dbs86be6f9d744ee4b7@mail.gmail.com> References: <7f45d9390607101017w6a05e0dbs86be6f9d744ee4b7@mail.gmail.com> Message-ID: <200607111145.20473.rob@landley.net> On Monday 10 July 2006 1:17 pm, Shaun Jackman wrote: > .config.mak is included after the check_cc macros run. The check_cc > macro requires that CROSS_COMPILE be defined. The best solution I have > is to move the inclusion of .config.mak up before the check_cc macro. > Please apply or suggest an alternative solution. I have another todo item here, which is cacheing the output of check_cc because it's really slow now that we're running dozens of them, and it runs even when you do "make help". The check_cc or check_ld macros are used to set the following variables: HOSTFLAGS CHECKED_LDFLAGS CHECKED_CFLAGS OPTIMIZATION LIB_LDFLAGS STRIPCMD CFLAGS_PIC And here's what actually happens when it runs: landley@driftwood:~/busybox/busybox$ make menuconfig BUILD_VERBOSE=2 CC="gcc" check_cc -Wall CC="gcc" check_cc -Wstrict-prototypes CC="gcc" check_cc -O2 CC="gcc" check_cc -fomit-frame-pointer LD="ld" check_ld --warn-common CC="gcc" check_cc -Wall CC="gcc" check_cc -Wstrict-prototypes CC="gcc" check_cc -Wshadow CC="gcc" check_cc -funsigned-char CC="gcc" check_cc -mmax-stack-frame=256 CC="gcc" check_cc -fno-builtin-strlen CC="gcc" check_cc -finline-limit=0 CC="gcc" check_cc -Os LD="ld" check_ld --enable-new-dtags CC="gcc" check_cc -march=i386 CC="gcc" check_cc -mpreferred-stack-boundary=2 CC="gcc" check_cc -falign-functions=1 -falign-jumps=1 -falign-loops=1 CC="gcc" check_cc -fomit-frame-pointer CC="gcc" check_cc -ffunction-sections -fdata-sections LD="ld" check_ld --sort-common LD="--gc-sections" check_ld STRIPCMD="strip" check_strip -s --remove-section=.note --remove-section=.comment CC="gcc" check_cc -shared make -C /home/landley/busybox/busybox \ top_srcdir=/home/landley/busybox/busybox \ top_builddir=/home/landley/busybox/busybox \ BUILD_SRC=/home/landley/busybox/busybox \ -f /home/landley/busybox/busybox/Makefile menuconfig CC="gcc" check_cc -Wall CC="gcc" check_cc -Wstrict-prototypes CC="gcc" check_cc -O2 CC="gcc" check_cc -fomit-frame-pointer LD="ld" check_ld --warn-common CC="gcc" check_cc -Wall CC="gcc" check_cc -Wstrict-prototypes CC="gcc" check_cc -Wshadow CC="gcc" check_cc -funsigned-char CC="gcc" check_cc -mmax-stack-frame=256 CC="gcc" check_cc -fno-builtin-strlen CC="gcc" check_cc -finline-limit=0 CC="gcc" check_cc -Os LD="ld" check_ld --enable-new-dtags CC="gcc" check_cc -march=i386 CC="gcc" check_cc -mpreferred-stack-boundary=2 CC="gcc" check_cc -falign-functions=1 -falign-jumps=1 -falign-loops=1 CC="gcc" check_cc -fomit-frame-pointer CC="gcc" check_cc -ffunction-sections -fdata-sections LD="ld" check_ld --sort-common LD="--gc-sections" check_ld STRIPCMD="strip" check_strip -s --remove-section=.note --remove-section=.comment CC="gcc" check_cc -shared make -C scripts/config ncurses conf mconf CC="gcc" check_cc -Wall CC="gcc" check_cc -Wstrict-prototypes CC="gcc" check_cc -O2 CC="gcc" check_cc -fomit-frame-pointer LD="ld" check_ld --warn-common CC="gcc" check_cc -Wall CC="gcc" check_cc -Wstrict-prototypes CC="gcc" check_cc -Wshadow CC="gcc" check_cc -funsigned-char CC="gcc" check_cc -mmax-stack-frame=256 CC="gcc" check_cc -fno-builtin-strlen CC="gcc" check_cc -finline-limit=0 CC="gcc" check_cc -Os LD="ld" check_ld --enable-new-dtags CC="gcc" check_cc -march=i386 CC="gcc" check_cc -mpreferred-stack-boundary=2 CC="gcc" check_cc -falign-functions=1 -falign-jumps=1 -falign-loops=1 CC="gcc" check_cc -fomit-frame-pointer CC="gcc" check_cc -ffunction-sections -fdata-sections LD="ld" check_ld --sort-common LD="--gc-sections" check_ld STRIPCMD="strip" check_strip -s --remove-section=.note --remove-section=.comment CC="gcc" check_cc -shared Sad, isn't it? Rob -- Never bet against the cheap plastic solution. From vda.linux at googlemail.com Tue Jul 11 09:14:09 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Tue Jul 11 09:14:21 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607111644.48224.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607102047.14896.rob@landley.net> <200607111644.48224.vda.linux@googlemail.com> Message-ID: <200607111814.09133.vda.linux@googlemail.com> On Tuesday 11 July 2006 16:44, Denis Vlasenko wrote: > It's even a bit smaller. gcc is smart enough to know div instruction > produces the remainder also, and we get n %= i for free. > > I still dislike the speed, i/=10 eats too much CPU... This patch converts division into mul + shift. It's smaller and faster. i = (i*429496730ULL)>>32 /* divide by 10, fast */ Speed is ok, correctness check ok: sprintf='12345678' count=27599 utoa_to_buf='12345678' count=62667 utoa='12345678' count=59227 utoa_to_buf_test='12345678' count=41303 utoa_to_buf_test(0)='0' utoa_to_buf_test(123)='123' utoa_to_buf_test(100223)='100223' utoa_to_buf_test(100223,3)='23' utoa_to_buf_test(100223,2)='3' utoa_to_buf_test(100223,1)='' Please apply. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: itoa.diff Type: text/x-diff Size: 930 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060711/863e5e7d/itoa.bin From rob at landley.net Tue Jul 11 09:19:42 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 09:19:49 2006 Subject: [PATCH] pwd2spwd.c removal In-Reply-To: <200607111443.26417.farmatito@tiscali.it> References: <200607111443.26417.farmatito@tiscali.it> Message-ID: <200607111219.43010.rob@landley.net> On Tuesday 11 July 2006 8:43 am, Tito wrote: > Hi, > this patch removes pwd2spwd.c from libbb > as it is used only in one place (passwd.c) and in a silly > way. > > function old new delta > passwd_main 2335 2316 -19 > static.sp 36 - > -36 pwd_to_spwd 108 - -108 > --------------------------------------------------------------------------- >--- (add/remove: 0/2 grow/shrink: 0/1 up/down: 0/-163) Total: -163 > bytes > > The patch is tested and works for me. > Please apply. Applied. Rob -- Never bet against the cheap plastic solution. From giuseppe at telvia.it Tue Jul 11 10:26:21 2006 From: giuseppe at telvia.it (Giuseppe Ciotta) Date: Tue Jul 11 10:26:30 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711153914.GA14376@brightrain.aerifal.cx> References: <20060711101943.GA14493@sceen.net> <20060711120006.GA862@aon.at> <20060711121433.GA16264@sceen.net> <20060711145539.GA1867@ummmagumma.localnet> <20060711150519.GA21532@sceen.net> <20060711153914.GA14376@brightrain.aerifal.cx> Message-ID: <20060711172621.GA1662@ummmagumma.localnet> On Tue, Jul 11, 2006 at 11:39:14AM -0400, Rich Felker wrote: > On Tue, Jul 11, 2006 at 05:05:19PM +0200, Richard Braun wrote: > > On Tue, Jul 11, 2006 at 04:55:39PM +0200, Giuseppe Ciotta wrote: > > > > The problem with start-stop-daemon is that it relies on the daemon to > > > > create its PID file. When the daemon doesn't, it usually provides an > > > > option to force running in the foreground, so that you can use > > > > start-stop-daemon with --background and --make-pidfile. The problem with > > > > busybox httpd is that it doesn't provide such an option. > > > > > > What about adding the option to go in foreground and leave the pid > > > writing task to start-stop-daemon then? > > > > It's one solution, but usually, a daemon is designed to run in the > > background, so using an option to run in the foreground for a daemon > > designed to run in the background is not really logic. The usual way, > > again, is that the daemon has an option to write his PID file. The > > best implementation has both : it can write the PID file, and it > > can run in the foreground, depending on the user options. > > I agree, this is a much more sane approach. I never understood the > obsession with start-stop-daemon. > Well, it's not a matter of obsession with start-stop-daemon, actually i rarely use it and usually a plain simple daemon & echo $! > pidfile is enough for what i need to do (well, you may also need to cd to / and redirect std{in,out,err} to /dev/null in order to have the same behaviour of daemon()) I don't see why it's not logic to have a -fg option, a lot of daemons actually have options to run in foreground (apache, proftpd, sshd among others...), this gives the opportunity to easily monitor the daemon from within shell scripts, like while true; do daemon ; snmpset daemon.died.variable ; done instead of polling a pidfile and sending baroque vintage signals to processes to see if they're alive. Just suggestions... Ciao. -- From rbraun at proformatique.com Tue Jul 11 12:19:12 2006 From: rbraun at proformatique.com (Richard Braun) Date: Tue Jul 11 12:19:38 2006 Subject: Patch for BusyBox httpd In-Reply-To: <20060711172621.GA1662@ummmagumma.localnet> References: <20060711101943.GA14493@sceen.net> <20060711120006.GA862@aon.at> <20060711121433.GA16264@sceen.net> <20060711145539.GA1867@ummmagumma.localnet> <20060711150519.GA21532@sceen.net> <20060711153914.GA14376@brightrain.aerifal.cx> <20060711172621.GA1662@ummmagumma.localnet> Message-ID: <20060711191911.GA27230@sceen.net> On Tue, Jul 11, 2006 at 07:26:21PM +0200, Giuseppe Ciotta wrote: > I don't see why it's not logic to have a -fg option, a lot of daemons > actually have options to run in foreground (apache, proftpd, sshd > among others...), this gives the opportunity to easily monitor the > daemon from within shell scripts, like > > while true; do daemon ; snmpset daemon.died.variable ; done > > instead of polling a pidfile and sending baroque vintage signals to > processes to see if they're alive. Read again please. I said it's not logic to have a daemon started with an option to force it to run in the foreground when start-stop-daemon, used with the --background and --make-pidfile options, will actually run this daemon in the background... In addition, I also said the best implementation includes an option to run in the foreground. But running in the foreground is mainly used for debugging, or for the use-case you gave. -- Richard Braun Proformatique - 67 rue Voltaire - 92800 Puteaux Tel. : 01 41 38 99 60 - Fax. : 01 41 38 99 70 Email : rbraun@proformatique.com - http://proformatique.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://busybox.net/lists/busybox/attachments/20060711/d0dfdefa/attachment.pgp From pgf at brightstareng.com Tue Jul 11 12:39:13 2006 From: pgf at brightstareng.com (Paul Fox) Date: Tue Jul 11 12:39:19 2006 Subject: Any objections to smarden.org tools added to bbox? In-Reply-To: rob's message of Tue, 11 Jul 2006 11:07:50 -0400. <200607111107.50480.rob@landley.net> Message-ID: <3197.1152646753@brightstareng.com> rob wrote: > On Monday 10 July 2006 6:26 am, Denis Vlasenko wrote: > > Answer to "why supervise?" question: > > supervise do not simply restart processes when they die. It provides > > means of _controlling_ them (using svc): > > I'm not really enthused about this so far. neither am i, though perhaps for different reasons. the solutions discussed in this thread (svc, minit, runit) are all tiny _already_. there's no need to take something that already meets all of the busybox criteria for small/light/fast and cram it in place as yet another applet. paul =--------------------- paul fox, pgf@brightstareng.com From rob at landley.net Tue Jul 11 12:41:17 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 12:41:26 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607111814.09133.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607111644.48224.vda.linux@googlemail.com> <200607111814.09133.vda.linux@googlemail.com> Message-ID: <200607111541.17883.rob@landley.net> On Tuesday 11 July 2006 12:14 pm, Denis Vlasenko wrote: > On Tuesday 11 July 2006 16:44, Denis Vlasenko wrote: > > It's even a bit smaller. gcc is smart enough to know div instruction > > produces the remainder also, and we get n %= i for free. > > > > I still dislike the speed, i/=10 eats too much CPU... > > This patch converts division into mul + shift. > It's smaller and faster. > > i = (i*429496730ULL)>>32 /* divide by 10, fast */ A) That's too ugly for words. B) On what platform are you having a speed problem, and on what platform is this an improvement? On 32 bit platforms (which are what most of busybox is deployed on these days, and where most of it will _continue_ to be deployed on for years to come if not the foreseeable future) gcc produces absolutely _horrible_ code for long long multiplies, and it triggers the gcc_s shared library problem with some toolchains. C) On a lot of 64 bit platforms (I don't know if it's all), long long is a 128 bit number, so this is a big pessimization. > Speed is ok, correctness check ok: > > sprintf='12345678' count=27599 > utoa_to_buf='12345678' count=62667 > utoa='12345678' count=59227 > utoa_to_buf_test='12345678' count=41303 What are you using to produce these numbers? What hardware, what test program, and what _other_ platforms have you tried it on to see what the impact is there? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 11 12:42:38 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 12:42:45 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607111644.48224.vda.linux@googlemail.com> References: <200607081844.18212.vda.linux@googlemail.com> <200607102047.14896.rob@landley.net> <200607111644.48224.vda.linux@googlemail.com> Message-ID: <200607111542.38962.rob@landley.net> On Tuesday 11 July 2006 10:44 am, Denis Vlasenko wrote: > On Tuesday 11 July 2006 02:47, Rob Landley wrote: > > > The attached test program shows that snprintf is 2.5 times slower > > > than utoa. Operations done per second: > > > sprintf='12345678' count=27346 > > > utoa_to_buf='12345678' count=69880 > > > utoa='12345678' count=65934 > > > > > > A few days ago I ran "hexdump | grep" over entire hard drive. > > > Took a long time. I wish hexdump was optimized a bit better... > > > > I haven't really looked closely at hexdump, but what does a base 10 utoa > > have to do with a base 16 hexdump? > > This is a real-life example of a program which does a lot of > int -> string conversions, so that it actually mattered for me recently. > > hexdump is of course using base 16 conversion. tcpdump could be > an example of a proc which does base 10 conversions, but I didn't > use it lately. Understood, but if I wanted to speed up hexdump | grep I'd profile both hexdump and grep, and probably find out that our grep is dog slow (there's the pending patch to speed up get_chomped_line_from_file() in my todo heap, which is waiting for me to get back around to the sed NUL bug and make sure that they play nice together). > > The lookup table is a classic size/speed tradeoff, something BusyBox has > > traditionally come down on the "size" side of. Doing a write() on the > > result is going to be way slower than the actual conversion anyway. What > > actual bottleneck are you seeing? > > > > I definitely agree the bounds checking needs to be added, though. I'll > > do that now... > > The version in current svn produces _most significant_ digits > if buffer is too small. IOW: utoa_to_buf_rob(100223,buf,3)=="10". > The usual practuce is to produce "23". If the buffer is too small it essentially produces garbage, we just don't want it to overflow and stomp memory it doesn't own. > How about this modified version? ... > It's even a bit smaller. gcc is smart enough to know div instruction > produces the remainder also, and we get n %= i for free. Very nice. My only concern is on which platforms does division automatically produce a remainder? I expect division to be supported everywhere, and to perform fairly well. I have a vague recollection that in some cases environments modulus is overlooked and (as a result) kind of evil, but I don't remember specifics. > I still dislike the speed, i/=10 eats too much CPU... It's a tight L1 cache-hot loop. In a pipeline like hexdump | grep it's unlikely to be even 1% of the total CPU overhead. What platform have you profiled this on? I don't believe integer division has boiled down to a subtraction loop on any interesting processor for a quarter-century (I remember that multiplication could be done in something like 6 clock cycles without being _that_ clever, although this is a vague recollection from my undergraduate days circa 1993), but then I'm not entirely certain how some of the really low-transistor-budget embedded processors (like ARM) are implemented. I doubt they're _stupid_, though. Many of them have floating point units, there's no reason for them to stint on integer arithmetic operations... Could I have some benchmark numbers on the system you're worried about, please? I already mentioned I tried the following here: #include // 0x4f bytes void utoa_to_buf(unsigned n, char *buf, int buflen) { int i, out = 0; for (i=1000000000; i; i/=10) { int res = n/i; if (res || out || i == 1) { out++; n -= res*i; *buf++ = '0' + res; } } *buf = 0; } int main(int argc, char *argv[]) { int i; char blah[16]; for(i=0;i<1000000;i++) { utoa_to_buf(i, blah, 16); } } Ran that under "time", and got 0.707 seconds. 1000000/.707 is 1.4 million according to my handy dandy python interpreter (the best calculator Linux ever shipped with). Adding bounds checking didn't slow it down _that_ much. What do you get on the system you're worried about the performance of? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 11 12:44:31 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 12:44:39 2006 Subject: [PATCH] Use local.h for local configuration In-Reply-To: <7f45d9390607101048h77a8c167rfeb95b454adc7550@mail.gmail.com> References: <7f45d9390607101048h77a8c167rfeb95b454adc7550@mail.gmail.com> Message-ID: <200607111544.32115.rob@landley.net> On Monday 10 July 2006 1:48 pm, Shaun Jackman wrote: > This patch adds an empty include file, local.h, to be included by > platform.h. When building outside of the source tree, the user can add > a $top_builddir/include/local.h file to include any system-specific > header files or definitions. This mechanism is terribly useful for > questionable but necessary definitions such as `#define fork() > vfork()'. I'd really rather not... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 11 13:02:10 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 13:02:43 2006 Subject: should all BB code be GPL? In-Reply-To: References: <200607101356.06287.farmatito@tiscali.it> Message-ID: <200607111602.10816.rob@landley.net> On Tuesday 11 July 2006 7:18 am, Robert P. J. Day wrote: > ok, but i'm still unclear -- should all code in BB be GPL? including > examples such as libbb/correct_password.c that make no mention of GPL > but, rather, show a copyright plus "All rights reserved." "All rights reserved" was legal boilerplate required before US copyright law started being regulated by the Berne convention circa 1987 or so, and people still put it on out of habit (and due to international jurisdictions that may not be Berne signatories or may have futzed with it in the enabling legislation). It's a statement that copyright is being claimed on the work, which is independent of what license is being issued to grant access to the rights the copyright regulates. > rday Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jul 11 13:09:43 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 13:09:56 2006 Subject: Patch for BusyBox httpd In-Reply-To: References: <20060711101943.GA14493@sceen.net> Message-ID: <200607111609.43819.rob@landley.net> On Tuesday 11 July 2006 7:19 am, Robert P. J. Day wrote: > On Tue, 11 Jul 2006, Richard Braun wrote: > > Hello, > > > > Here are two patches for BusyBox httpd (stable 1.1.3 release) which > > respectively add support for interpreters outside of /cgi-bin/ > > (something very useful for lots of PHP based applications) and write > > the PID of the master process into /var/run/httpd.pid > > ... snip ... > > i can apply those patches if no one objects. what's the protocol for > applying someone else's patches? I actually wanted to clean them up and try to remove the #ifdefs. (I haven't touched httpd.c yet. Vladimir used to maintain it so it's a bit of a mess that's likely to take up lots of time once I get into it...) > rday Rob -- Never bet against the cheap plastic solution. From rpjday at mindspring.com Tue Jul 11 13:14:57 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Tue Jul 11 13:17:05 2006 Subject: Patch for BusyBox httpd In-Reply-To: <200607111609.43819.rob@landley.net> References: <20060711101943.GA14493@sceen.net> <200607111609.43819.rob@landley.net> Message-ID: On Tue, 11 Jul 2006, Rob Landley wrote: > I actually wanted to clean them up and try to remove the #ifdefs. > (I haven't touched httpd.c yet. Vladimir used to maintain it so > it's a bit of a mess that's likely to take up lots of time once I > get into it...) go wild. rday From dalias at aerifal.cx Tue Jul 11 13:35:08 2006 From: dalias at aerifal.cx (Rich Felker) Date: Tue Jul 11 13:36:10 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607111541.17883.rob@landley.net> References: <200607081844.18212.vda.linux@googlemail.com> <200607111644.48224.vda.linux@googlemail.com> <200607111814.09133.vda.linux@googlemail.com> <200607111541.17883.rob@landley.net> Message-ID: <20060711203508.GP24607@brightrain.aerifal.cx> On Tue, Jul 11, 2006 at 03:41:17PM -0400, Rob Landley wrote: > On Tuesday 11 July 2006 12:14 pm, Denis Vlasenko wrote: > > On Tuesday 11 July 2006 16:44, Denis Vlasenko wrote: > > > It's even a bit smaller. gcc is smart enough to know div instruction > > > produces the remainder also, and we get n %= i for free. > > > > > > I still dislike the speed, i/=10 eats too much CPU... > > > > This patch converts division into mul + shift. > > It's smaller and faster. > > > > i = (i*429496730ULL)>>32 /* divide by 10, fast */ > > A) That's too ugly for words. :) > B) On what platform are you having a speed problem, and on what platform is > this an improvement? On 32 bit platforms (which are what most of busybox is > deployed on these days, and where most of it will _continue_ to be deployed > on for years to come if not the foreseeable future) gcc produces absolutely > _horrible_ code for long long multiplies, and it triggers the gcc_s shared > library problem with some toolchains. This code should not generate a 64bit multiply since the operands both fit in 32 bits and a 32x32 multiply gives a 64bit result. Still, gcc is broken so maybe it does 64x64 multiply anyway... BTW inttypes.h has a macro to declare uint64_t constants, or you can just cast the integer constant to (uint64_t) before multiplying.. Anyway I doubt this is faster than just dividing, especially since the divide also gives you the modulo result for free without extra ops. Certainly the division should result in smaller code size. Rich From sjackman at gmail.com Tue Jul 11 13:41:43 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Tue Jul 11 13:41:51 2006 Subject: [PATCH] Use local.h for local configuration In-Reply-To: <200607111544.32115.rob@landley.net> References: <7f45d9390607101048h77a8c167rfeb95b454adc7550@mail.gmail.com> <200607111544.32115.rob@landley.net> Message-ID: <7f45d9390607111341l6037559cyd90c5864c55c35e9@mail.gmail.com> On 7/11/06, Rob Landley wrote: > On Monday 10 July 2006 1:48 pm, Shaun Jackman wrote: > > This patch adds an empty include file, local.h, to be included by > > platform.h. When building outside of the source tree, the user can add > > a $top_builddir/include/local.h file to include any system-specific > > header files or definitions. This mechanism is terribly useful for > > questionable but necessary definitions such as `#define fork() > > vfork()'. > > I'd really rather not... Fair enough. Do you have any suggestion where this sort of configuration should go? I would suggest platform.h, but the source tree is effectively read-only in the case of one source-tree and many build-trees. I thought a local.h in the build tree was a reasonable solution to the problem. Cheers, Shaun #ifndef LOCAL_H #define LOCAL_H #include #include #include ATTRIBUTE_NORETURN static inline void bb_exit(int status) { fflush(NULL); _exit(status); } #define exit(status) bb_exit(status) #define fork() vfork() #endif From sjackman at gmail.com Tue Jul 11 13:45:30 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Tue Jul 11 13:45:33 2006 Subject: [PATCH] .config.mak and CROSS_COMPILE fails with check_cc In-Reply-To: <200607111145.20473.rob@landley.net> References: <7f45d9390607101017w6a05e0dbs86be6f9d744ee4b7@mail.gmail.com> <200607111145.20473.rob@landley.net> Message-ID: <7f45d9390607111345j1121ac4cjba04b2bcb0daf684@mail.gmail.com> On 7/11/06, Rob Landley wrote: > On Monday 10 July 2006 1:17 pm, Shaun Jackman wrote: > > .config.mak is included after the check_cc macros run. The check_cc > > macro requires that CROSS_COMPILE be defined. The best solution I have > > is to move the inclusion of .config.mak up before the check_cc macro. > > Please apply or suggest an alternative solution. > > I have another todo item here, which is cacheing the output of check_cc > because it's really slow now that we're running dozens of them, and it runs > even when you do "make help". > > The check_cc or check_ld macros are used to set the following variables: > HOSTFLAGS > CHECKED_LDFLAGS > CHECKED_CFLAGS > OPTIMIZATION > LIB_LDFLAGS > STRIPCMD > CFLAGS_PIC > > And here's what actually happens when it runs: > > landley@driftwood:~/busybox/busybox$ make menuconfig BUILD_VERBOSE=2 > CC="gcc" check_cc -Wall .... > CC="gcc" check_cc -shared > > Sad, isn't it? I agree; caching the autodetected configuration would be very helpful. In the mean time, can the .config.mak related patch above be applied to save CROSS_COMPILE? Cheers, Shaun From mszick at morethan.org Tue Jul 11 13:50:53 2006 From: mszick at morethan.org (Michael S. Zick) Date: Tue Jul 11 13:51:01 2006 Subject: [PATCH] unify itoa In-Reply-To: <20060711203508.GP24607@brightrain.aerifal.cx> References: <200607081844.18212.vda.linux@googlemail.com> <200607111541.17883.rob@landley.net> <20060711203508.GP24607@brightrain.aerifal.cx> Message-ID: <200607111550.53759.mszick@morethan.org> On Tue July 11 2006 15:35, Rich Felker wrote: > > Anyway I doubt this is faster than just dividing, especially since the > divide also gives you the modulo result for free without extra ops. > Certainly the division should result in smaller code size. > You want small and fast? q1) What target processors do you wish to handle? Any processor with special instructions for BCD, it is smallest and fastest to: int -> BCD BCD -> ASCII q2) How gcc-centric is BusyBox? Any interest in a __builtin_uitoa( ... )? I just happen to have gcc's builtins.c torn apart in front of me for a different reason. > Rich Mike From dalias at aerifal.cx Tue Jul 11 13:51:02 2006 From: dalias at aerifal.cx (Rich Felker) Date: Tue Jul 11 13:52:01 2006 Subject: [PATCH] unify itoa In-Reply-To: <200607111542.38962.rob@landley.net> References: <200607081844.18212.vda.linux@googlemail.com> <200607102047.14896.rob@landley.net> <200607111644.48224.vda.linux@googlemail.com> <200607111542.38962.rob@landley.net> Message-ID: <20060711205102.GQ24607@brightrain.aerifal.cx> On Tue, Jul 11, 2006 at 03:42:38PM -0400, Rob Landley wrote: > On Tuesday 11 July 2006 10:44 am, Denis Vlasenko wrote: > > On Tuesday 11 July 2006 02:47, Rob Landley wrote: > > > > The attached test program shows that snprintf is 2.5 times slower > > > > than utoa. Operations done per second: > > > > sprintf='12345678' count=27346 > > > > utoa_to_buf='12345678' count=69880 > > > > utoa='12345678' count=65934 > > > > > > > > A few days ago I ran "hexdump | grep" over entire hard drive. > > > > Took a long time. I wish hexdump was optimized a bit better... > > > > > > I haven't really looked closely at hexdump, but what does a base 10 utoa > > > have to do with a base 16 hexdump? > > > > This is a real-life example of a program which does a lot of > > int -> string conversions, so that it actually mattered for me recently. > > > > hexdump is of course using base 16 conversion. tcpdump could be > > an example of a proc which does base 10 conversions, but I didn't > > use it lately. > > Understood, but if I wanted to speed up hexdump | grep I'd profile both > hexdump and grep, and probably find out that our grep is dog slow (there's > the pending patch to speed up get_chomped_line_from_file() in my todo heap, > which is waiting for me to get back around to the sed NUL bug and make sure > that they play nice together). Currently get_chomped_line_from_file does not support embedded NUL bytes. My patch could add support at the cost of a little performance (but still much better performance than the current version). > > How about this modified version? > ... > > It's even a bit smaller. gcc is smart enough to know div instruction > > produces the remainder also, and we get n %= i for free. > > Very nice. My only concern is on which platforms does division automatically > produce a remainder? I expect division to be supported everywhere, and to > perform fairly well. I have a vague recollection that in some cases > environments modulus is overlooked and (as a result) kind of evil, but I > don't remember specifics. All I know is that division yields both on x86. Sorry. > > I still dislike the speed, i/=10 eats too much CPU... > > It's a tight L1 cache-hot loop. In a pipeline like hexdump | grep it's > unlikely to be even 1% of the total CPU overhead. What platform have you > profiled this on? I don't believe integer division has boiled down to a > subtraction loop on any interesting processor for a quarter-century (I > remember that multiplication could be done in something like 6 clock cycles > without being _that_ clever, although this is a vague recollection from my > undergraduate days circa 1993), but then I'm not entirely certain how some of > the really low-transistor-budget embedded processors (like ARM) are Division is something like 40 cycles on old x86 (386-586). IIRC on modern x86 it's around 10-15 cycles. > implemented. I doubt they're _stupid_, though. Many of them have floating > point units, there's no reason for them to stint on integer arithmetic > operations... Sadly some modern cpus perform better at float than integer, simply because of stupidity and nonsensical goals. Obviously integer ops should perform significantly better if both are given the same attention by the engineers, but I guess winning floating point benchmarks buys you more than improving practical performance. > Ran that under "time", and got 0.707 seconds. 1000000/.707 is 1.4 million > according to my handy dandy python interpreter (the best calculator Linux > ever shipped with). Adding bounds checking didn't slow it down _that_ much. Yes, time(1) is a much more accurate benchmarking system, as it won't include the time spent by other processes interrupting your benchmark. The time(3) based benchmark is a rather bad idea.. Rich From rob at landley.net Tue Jul 11 13:58:20 2006 From: rob at landley.net (Rob Landley) Date: Tue Jul 11 13:58:33 2006 Subject: timeout applet (new version) In-Reply-To: References: Message-ID: <200607111658.20380.rob@landley.net> On Tuesday 11 July 2006 4:18 am, Roberto A. Foglietta wrote: > Hi to all, > > updated: > http://bugs.busybox.net/view.php?id=680 Feature requests really don't belong in the bug generator. (In case you haven't figured it out now, I'm pretty happy ignoring bug generator entries indefinitely, thanks to Erik adding license violations in there that could not _be_ closed out and me getting out of the habit of trying.) > Applet version 0.2.7 applies against busybox v1.1.3, changelog: > > a) Note: 0000600bytes less than previous applet version If you managed to strip 600 bytes off of it, how enormous was it to begin with? Or is this 600 octal due to the leading zeroes? > b) 1 bug less than previous applet version Since the previous version wasn't in busybox, and you didn't say what the fixed bug was, you're talking about an unknown change from an unknown starting point. This statement conveys no information. > c) added regression test in testsuite Ok, that's pretty cool. > Some options have been removed, now this applet is easier to use: > > [roberto@GEDX0327 busybox-1.1.3]$ busybox timeout > USAGE: timeout [-s int_signal] "" Seems reasonable. > [roberto@GEDX0327 busybox-1.1.3]$ busybox timeout --help > BusyBox v1.1.3 (2006.07.11-08:14+0000) multi-call binary > > Usage: timeout [-s signal] "" > > Runs the "command line" within a timeout window and returns its status. > Options: > -s Number of signal to the command and its children when timeout > expires > > > Please spent a minute to integrate in bb, Tarballs of individual files are a bit of a pain to deal with. Just attach the files if you don't want to make a patch. (And this says .bz2 but it's actually .gz.) #include/talarm.h defines lots of signal names that libbb/u_signal_names.c already handles. This entire .h file doesn't belong in #include. (What's left would go in libbb.h if it should be in libbb/*.c.) Next, libbb/talarm.c is kind of ugly. It's not busyboxified (doesn't even include busybox.h), it has gratuitous newlines like "static\nint" (and why is it defining a lot of static data anyway), you really don't need to block copy part of a freebsd web page on "what is a signal" into it as a big comment, please don't do things like #define alarm_kill and then use it exactly once, why the heck are you adding something libbb.h that's only used by one applet anyway... I'm going to stop reading it now. The applet sounds like a go