From dalias at aerifal.cx Thu Jun 1 00:34:23 2006 From: dalias at aerifal.cx (Rich Felker) Date: Thu Jun 1 00:29:54 2006 Subject: [PATCH] multiple bugs in ls.c Message-ID: <20060601073422.GA28276@brightrain.aerifal.cx> - duplicated format bit 14 forced LIST_EXEC always-on - -p option was behaving just like -F (SUSv3 says -p only shows / for dirs, not other special symbols) - tests for LIST_EXEC in color functions were nonsense (constant tests). i assume they were supposed to be (all_fmt & LIST_EXEC) however having coloring of executable files depend on -F seems undesirable. attached patch fixes the bugs, but LIST_EXEC is sort of a misnomer now. better name, anyone? rich -------------- next part -------------- Index: coreutils/ls.c =================================================================== --- coreutils/ls.c (revision 15108) +++ coreutils/ls.c (working copy) @@ -90,8 +90,6 @@ #define LIST_MASK ((LIST_EXEC << 1) - 1) /* what files will be displayed */ -/* TODO -- We may be able to make DISP_NORMAL 0 to save a bit slot. */ -#define DISP_NORMAL (1U<<14) /* show normal filenames */ #define DISP_DIRNAME (1U<<15) /* 2 or more items? label directories */ #define DISP_HIDDEN (1U<<16) /* show filenames starting with . */ #define DISP_DOT (1U<<17) /* show . and .. */ @@ -99,7 +97,7 @@ #define DISP_RECURSIVE (1U<<19) /* show directory and everything below it */ #define DISP_ROWS (1U<<20) /* print across rows */ -#define DISP_MASK (((DISP_ROWS << 1) - 1) & ~(DISP_NORMAL - 1)) +#define DISP_MASK (((DISP_ROWS << 1) - 1) & ~(DISP_DIRNAME - 1)) #ifdef CONFIG_FEATURE_LS_SORTFILES /* how will the files be sorted */ @@ -259,8 +257,7 @@ if (errno == ENOENT) { return '\037'; } - if (LIST_EXEC && S_ISREG(mode) - && (mode & (S_IXUSR | S_IXGRP | S_IXOTH))) + if (S_ISREG(mode) && (mode & (S_IXUSR | S_IXGRP | S_IXOTH))) return COLOR(0xF000); /* File is executable ... */ return COLOR(mode); } @@ -268,8 +265,7 @@ /*----------------------------------------------------------------------*/ static char bgcolor(mode_t mode) { - if (LIST_EXEC && S_ISREG(mode) - && (mode & (S_IXUSR | S_IXGRP | S_IXOTH))) + if (S_ISREG(mode) && (mode & (S_IXUSR | S_IXGRP | S_IXOTH))) return ATTR(0xF000); /* File is executable ... */ return ATTR(mode); } @@ -281,8 +277,11 @@ { if (!(all_fmt & LIST_FILETYPE)) return '\0'; - if ((all_fmt & LIST_EXEC) && S_ISREG(mode) - && (mode & (S_IXUSR | S_IXGRP | S_IXOTH))) + if (S_ISDIR(mode)) + return '/'; + if (!(all_fmt & LIST_EXEC)) + return '\0'; + if (S_ISREG(mode) && (mode & (S_IXUSR | S_IXGRP | S_IXOTH))) return '*'; return APPCHAR(mode); } @@ -947,7 +946,7 @@ char *color_opt; #endif - all_fmt = LIST_SHORT | DISP_NORMAL | STYLE_AUTO + all_fmt = LIST_SHORT | STYLE_AUTO #ifdef CONFIG_FEATURE_LS_TIMESTAMPS | TIME_MOD #endif From pgf at brightstareng.com Thu Jun 1 05:43:23 2006 From: pgf at brightstareng.com (Paul Fox) Date: Thu Jun 1 05:43:38 2006 Subject: [PATCH] Integrate dd ibs/obs patch In-Reply-To: rob's message of Wed, 31 May 2006 19:24:49 -0400. <200605311924.49972.rob@landley.net> Message-ID: <30818.1149165803@brightstareng.com> > > > Hmmm... If somebody specifies both obs= and bs= they can cause the size > > > to be something that the !twobufs_flag codepath doesn't expect. I'll > > > fix it. (And the #ifdefs are going away; The !twobufs_flag codepath > > > should be the same whether the twobufs part is enabled or not.) > > > > > > conv= should be under this config flag as well. > > > > i don't understand the last part of this change. > > > > why are the "notrunc" and "noerror" conv options conditional on > > the FEATURE_DD_IBS_OBS? > > Basically using it as a DD_BIG switch? oh. i see. yes, in that case it should be "CONFIG_FANCY_DD", or something like that. > > > i can separate them, if it's the right thing -- i have another > > conv= option i'd like to add, and it's definitely independent of > > ibs/obs, so i need to clean this up for my own use in any case. > > I'm not _against_ adding configuration granularity, but it seems like it's > about time to add a CONFIG_NITPICK switch. > > I just did so. huh? is that an ifdef we can apply to mailing list text? ;-) paul =--------------------- paul fox, pgf@brightstareng.com From mszick at morethan.org Thu Jun 1 06:05:05 2006 From: mszick at morethan.org (Michael S. Zick) Date: Thu Jun 1 06:05:12 2006 Subject: Error in creating linux single floppy In-Reply-To: References: Message-ID: <200606010805.06121.mszick@morethan.org> On Wed May 31 2006 23:20, gopi chand komma wrote: > Hai, > > I have been succesful in creating linux single floppy. Congratulations. > now i am > trying to build the same thing into a usb memory stick. An interesting idea. You probably will have to make changes to the kernel configuration. > when i am > doing this i am getting the follwing error while booting from the usb > device. > > ds : no socket drivers loaded. > kmod : filed to exec /sbinmdprobe -s -k block-major -1 error=2 > VFS : Cannot open root device "ram0" or 01:00 > please append a correct "root" boot options > kernel panic : VFS : unable to mount root fson 01:00 > > HOW TO LOAD SOCKET DRIVERS ? > The above looks like kernel boot problems, not really busybox issues. > Please kindly send me some solution to the above problems > The thing to consider here is that everything required to access the usb memory stick is built-in, into the kernel. It is the same as the requirement of having the boot filesystem built-in. The usb things are normally built as modules, since you need them to boot, you will have to re-configure them to be built-ins. You might try asking google, see if it can find some directions for bootable linux memory sticks. Mike From sjackman at gmail.com Thu Jun 1 08:48:05 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Thu Jun 1 08:48:11 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> Message-ID: <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> On 5/31/06, Robert P. J. Day wrote: > or conditionally define it to be something generically meaningless if > the OS is *not* linux? I thought of that, and initially thought, "What's the point", since KERNEL_VERSION just assembles a constant anyways. KERNEL_VERSION(2,6,0) is simply a pretty way of writing 0x20600. I didn't think mucking with a macro that only defines a constant had any benefit. There is, however, an inherent problem with get_linux_version_code. It returns the version of not only Linux, but any system that implements uname. It seems some incorrect decisions could be made if busybox were running on FreeBSD 6.1, and Busybox thought it were running on Linux 6.1.0, or possibly Linux 0.6.1. Looking at it now, it seems get_linux_version_code would simply crash -- thou shalt not follow the NULL pointer [1] -- if it were passed a version number with only two digits. My conclusion is that any branch on get_linux_version_code should probably also specify which branch to take if it's *not* running on Linux, but a generic POSIX/SUS system. Cheers, Shaun [1] 2. Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end. Clearly the holy scriptures were mis-transcribed here, as the words should have been ``null pointer'', to minimize confusion between the concept of null pointers and the macro NULL (of which more anon). Otherwise, the meaning is plain. A null pointer points to regions filled with dragons, demons, core dumps, and numberless other foul creatures, all of which delight in frolicing in thy program if thou disturb their sleep. A null pointer doth not point to a 0 of any type, despite some blasphemous old code which impiously assumes this. From rpjday at mindspring.com Thu Jun 1 08:51:11 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Thu Jun 1 08:52:11 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> Message-ID: On Thu, 1 Jun 2006, Shaun Jackman wrote: > On 5/31/06, Robert P. J. Day wrote: > > or conditionally define it to be something generically meaningless if > > the OS is *not* linux? > > I thought of that, and initially thought, "What's the point", since > KERNEL_VERSION just assembles a constant anyways. > KERNEL_VERSION(2,6,0) is simply a pretty way of writing 0x20600. I > didn't think mucking with a macro that only defines a constant had > any benefit. > > There is, however, an inherent problem with get_linux_version_code. > It returns the version of not only Linux, but any system that > implements uname. It seems some incorrect decisions could be made if > busybox were running on FreeBSD 6.1, and Busybox thought it were > running on Linux 6.1.0, or possibly Linux 0.6.1. Looking at it now, > it seems get_linux_version_code would simply crash -- thou shalt not > follow the NULL pointer [1] -- if it were passed a version number > with only two digits. > > My conclusion is that any branch on get_linux_version_code should > probably also specify which branch to take if it's *not* running on > Linux, but a generic POSIX/SUS system. > > Cheers, > Shaun i agree that that routine should be more robust. as it is, my goal when i submitted the rewrite was to make it cleaner but to leave the functionality exactly the way it was. so i'm just guessing that any fundamental weaknesses in the current method probably existed in the old method anyway. feel free to submit improved versions that are more OS-agnostic. rday From rep.nop at aon.at Thu Jun 1 10:36:54 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jun 1 10:37:05 2006 Subject: [PATCH] Implement doubly-linked list In-Reply-To: <200606010130.23943.yann.morin.1998@anciens.enib.fr> References: <200606010022.28386.yann.morin.1998@anciens.enib.fr> <200606010130.23943.yann.morin.1998@anciens.enib.fr> Message-ID: <20060601173654.GA15547@aon.at> On Thu, Jun 01, 2006 at 01:30:23AM +0200, Yann E. MORIN wrote: >On Thursday 01 June 2006 002, Yann E. MORIN wrote: >> 003-doubly_linked_lists.patch >> - adds the configuration option CONFIG_FEATURE_DLLIST: >> - prompt is visible only if building the shared library, >> - defaults to no, May i point you to xargs.c's xlist_t which wants a singly-linked list with a runlength for the data? Didn't look, but perhaps there are other users (ed has a LINE -- i'm thinking of busyboxifying ed, it's seems to be very, very bloated and doesn't even pass two dozends of the GNU ed's tests, FWIW), get_header_cpio.c: hardlinks_s has *next, *data, size stat.c: types has size, *data vi.c: esc_cmds has *data, size mt.c: mt_opcodes has *data, size hdparm.c: xfermode_entry has size, *data insmod.c: common_entry has *next, *data modprobe.c: mod_opt_t has *next, *data vconfig.c: vlan_ioctl_args should allocate it's .device1 ll_proto.c: llproto_names has size, *data llist_proto.c: arphrd_names ditto etc, etc. Maybe worth a look? From rep.nop at aon.at Thu Jun 1 10:44:48 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jun 1 10:44:55 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> Message-ID: <20060601174448.GB15547@aon.at> On Thu, Jun 01, 2006 at 11:51:11AM -0400, Robert P. J. Day wrote: >On Thu, 1 Jun 2006, Shaun Jackman wrote: > >> On 5/31/06, Robert P. J. Day wrote: >> > or conditionally define it to be something generically meaningless if >> > the OS is *not* linux? >> >> I thought of that, and initially thought, "What's the point", since >> KERNEL_VERSION just assembles a constant anyways. >> KERNEL_VERSION(2,6,0) is simply a pretty way of writing 0x20600. I >> didn't think mucking with a macro that only defines a constant had >> any benefit. >> >> There is, however, an inherent problem with get_linux_version_code. >> It returns the version of not only Linux, but any system that >> implements uname. It seems some incorrect decisions could be made if >> busybox were running on FreeBSD 6.1, and Busybox thought it were >> running on Linux 6.1.0, or possibly Linux 0.6.1. Looking at it now, >> it seems get_linux_version_code would simply crash -- thou shalt not >> follow the NULL pointer [1] -- if it were passed a version number >> with only two digits. >> >> My conclusion is that any branch on get_linux_version_code should >> probably also specify which branch to take if it's *not* running on >> Linux, but a generic POSIX/SUS system. >> >> Cheers, >> Shaun > >i agree that that routine should be more robust. as it is, my goal >when i submitted the rewrite was to make it cleaner but to leave the >functionality exactly the way it was. so i'm just guessing that any >fundamental weaknesses in the current method probably existed in the >old method anyway. > >feel free to submit improved versions that are more OS-agnostic. nitpicking.. May i point to the archives, where i wanted a #define KERNEL_VERSION(os,maj,min,patch) \ os##_kernel_version(maj,min,patch) This would IMO be the most robust solution. From rpjday at mindspring.com Thu Jun 1 10:46:04 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Thu Jun 1 10:46:59 2006 Subject: ok, what's the official take on "endianness"? Message-ID: probably a silly question, but what's the whole story on best practises for dealing with endianness? rday From rpjday at mindspring.com Thu Jun 1 10:59:00 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Thu Jun 1 10:59:53 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: <20060601174448.GB15547@aon.at> References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> <20060601174448.GB15547@aon.at> Message-ID: On Thu, 1 Jun 2006, Bernhard Fischer wrote: > On Thu, Jun 01, 2006 at 11:51:11AM -0400, Robert P. J. Day wrote: > >On Thu, 1 Jun 2006, Shaun Jackman wrote: > > > >> On 5/31/06, Robert P. J. Day wrote: > >> > or conditionally define it to be something generically meaningless if > >> > the OS is *not* linux? > >> > >> I thought of that, and initially thought, "What's the point", since > >> KERNEL_VERSION just assembles a constant anyways. > >> KERNEL_VERSION(2,6,0) is simply a pretty way of writing 0x20600. I > >> didn't think mucking with a macro that only defines a constant had > >> any benefit. > >> > >> There is, however, an inherent problem with get_linux_version_code. > >> It returns the version of not only Linux, but any system that > >> implements uname. It seems some incorrect decisions could be made if > >> busybox were running on FreeBSD 6.1, and Busybox thought it were > >> running on Linux 6.1.0, or possibly Linux 0.6.1. Looking at it now, > >> it seems get_linux_version_code would simply crash -- thou shalt not > >> follow the NULL pointer [1] -- if it were passed a version number > >> with only two digits. > >> > >> My conclusion is that any branch on get_linux_version_code should > >> probably also specify which branch to take if it's *not* running on > >> Linux, but a generic POSIX/SUS system. > >> > >> Cheers, > >> Shaun > > > >i agree that that routine should be more robust. as it is, my goal > >when i submitted the rewrite was to make it cleaner but to leave the > >functionality exactly the way it was. so i'm just guessing that any > >fundamental weaknesses in the current method probably existed in the > >old method anyway. > > > >feel free to submit improved versions that are more OS-agnostic. > > nitpicking.. > May i point to the archives, where i wanted a > #define KERNEL_VERSION(os,maj,min,patch) \ > os##_kernel_version(maj,min,patch) i do remember that. i just have a habit of wanting to commit changes one concept at a time. or, more pedantically, in two phases: 1) a cleanup that doesn't change functionality 2) additional change to the *cleaned* stuff to add that functionality if someone else wants to do part 2 WRT kernel versioning, they're certainly welcome to submit a patch. :-) rday From yann.morin.1998 at anciens.enib.fr Thu Jun 1 11:18:41 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Thu Jun 1 11:18:53 2006 Subject: [PATCH] Implement doubly-linked list In-Reply-To: <200605312308.49800.rob@landley.net> References: <200606010022.28386.yann.morin.1998@anciens.enib.fr> <200605312308.49800.rob@landley.net> Message-ID: <200606012018.41685.yann.morin.1998@anciens.enib.fr> On Thursday 01 June 2006 050, Rob Landley wrote: > On Wednesday 31 May 2006 6:22 pm, Yann E. MORIN wrote: > > Here is at last my implementation of doubly-linked lists. > What uses do you have in mind for this? Well, it seems some applets makes use of doubly-linked lists. At least modprobe and ed do. Maybe others as well. See these two messages: http://www.busybox.net/lists/busybox/2006-May/021645.html http://www.busybox.net/lists/busybox/2006-May/021661.html What annoys me is that some applets makes use of linked lists, and each has its own implementation. Gathering (singly- or doubly-) linked list management in a common place seems sensible to me, so that one does'nt have to re-invent the wheel every time. And because it is a good candidate for code size reduction as well. > It's an extra 4 bytes per node, plus the code to deal with it. Having _both_ > singly and doubly linked lists makes little sense, but having things that > only need singly linked lists be doubly linked makes little sense either... Yes I do agree. What would be the best practice? - only doubly-linked lists for all: -> a 4-byte impact at run-time per node -> a small impact in code size (35 bytes) - both types of lists: -> no run-time impact, as nodes are the strict necessary size. -> a bigger, but not huge, impact on code size. > > --- > > + USE_FEATURE_DLLIST ( [--SNIP code portion--] > > Because if I use "if (ENABLE_FEATURE_DLLIST) " then gcc barfs on the next > > line. Comments? > You gave me three patches and didn't say which one had the hunk you were > talking about. Sorry, I thought it was clear enough I was speaking of the third patch. > +extern ATTRIBUTE_ALWAYS_INLINE void *llist_get_front(llist_t **elm); > Ok, _how_? This is a declaration but not a definition. The body of the code > ain't here. The body is in a separate .c file that is compiled by itself to > make a .o file. What's supposed to inline it, the linker? (Unless nobody > outside of llist.c is ever going to call it...) I should go to bed earlier... You're absolutely right. My bad. Bahhhhh! > Besides, we should let gcc make the inlining decisions. Programmers have a > history of sucking at this, over time. I was thinking of this, but wanted to be sure. Bah... > llist_get_front() will segfault if *head is NULL. Shame on me. Note for tonight: bed time is 10PM, no later. :-] > - free(*head); > + if (ENABLE_FEATURE_CLEAN_UP) > + free(*head); > We don't know who's calling us, it could be something long-running (httpd? Or > possibly what httpd _should_ be doing?) Thus the free isn't optional. That was not my understanding of FEATURE_CLEAN_UP. I didn't understand that we should take into conideration wether the applet was blindly fast (ls) or long-running (httpd). But that makes sense. > +#ifdef CONFIG_FEATURE_DLLIST > + struct llist_s *prev; > +#endif > A) That's the sort of thing USE() macros are for. > B) When the existence of variables is #ifdefed out, the code that plays with [--SNIP--] > And yeah, I finally found the chunk you were referring to and it's a case of > the variable being #ifdefed out and the code barfing on an undeclared > variable before it gets as far as dead code elimination. The two techniques > don't mix... Yep. Sounds so blatently obvious when you explain things! :-) So what next? Regars, 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 Jun 1 06:56:54 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 1 11:30:27 2006 Subject: [PATCH] remove long options from hdparm + minor bugfixes In-Reply-To: <200606010118.37009.farmatito@tiscali.it> References: <200606010003.05528.farmatito@tiscali.it> <200605311853.21653.rob@landley.net> <200606010118.37009.farmatito@tiscali.it> Message-ID: <200606010956.54272.rob@landley.net> On Wednesday 31 May 2006 7:18 pm, Tito wrote: > On Thursday 1 June 2006 00:53, Rob Landley wrote: > > On Wednesday 31 May 2006 6:03 pm, Tito wrote: > > > Hi to all, > > > this patch: > > > 1) removes totally long option support from hdparm, > > > but the --Istdin functionality is preserved because now the program > > > reads from stdin if no device names are specified: > > > > > > cat /proc/ide/hda/identify |./busybox hdparm > > > > Hmmm... The hdparm people are used to dumps its --help when you run it > > without arguments. > > They will wonder why the program blocks... ;-P > hit Ctrl-c > do hdparm -h > and discover the truth!!! So it's horrible usability that it's possible to recover from. This is generally the case even if they have to reboot and reinstall... The sad part is that it will only block (with no message) if it's configured certain ways, and when configured other ways it'll print out a usage message. And this is a compile time behavior change, which sucks. > > Could you stick in a check for stdin isn't a TTY? > > I could, but our menuconfig system and the verbose usage describe the non > standard behaviour, so maybe it is not worth the trouble.... And of course having a man page is the perfect substitute for minimal levels of usability. We have the code to do this in gunzip already... > Ciao, > Tito Rob -- Never bet against the cheap plastic solution. From ddaney at avtrex.com Thu Jun 1 11:47:39 2006 From: ddaney at avtrex.com (David Daney) Date: Thu Jun 1 11:47:45 2006 Subject: ok, what's the official take on "endianness"? In-Reply-To: References: Message-ID: <447F364B.9080402@avtrex.com> Robert P. J. Day wrote: > probably a silly question, but what's the whole story on best > practises for dealing with endianness? > Is this a trick question? In general don't write code that has endianness dependencies. For network code use htonl(), htons(), ntohl() and ntohs(). If you are working with file systems or other things where the endianness of on-disk data structures is important, #include and be very careful. David Daney. From rpjday at mindspring.com Thu Jun 1 11:53:39 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Thu Jun 1 11:54:39 2006 Subject: ok, what's the official take on "endianness"? In-Reply-To: <447F364B.9080402@avtrex.com> References: <447F364B.9080402@avtrex.com> Message-ID: On Thu, 1 Jun 2006, David Daney wrote: > Robert P. J. Day wrote: > > probably a silly question, but what's the whole story on best > > practises for dealing with endianness? > > > > Is this a trick question? > > In general don't write code that has endianness dependencies. > > For network code use htonl(), htons(), ntohl() and ntohs(). > > If you are working with file systems or other things where the > endianness of on-disk data structures is important, #include > and be very careful. but this doesn't address what's happening in busybox at the moment, which is slightly more complicated. rday From yann.morin.1998 at anciens.enib.fr Thu Jun 1 12:00:03 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Thu Jun 1 12:00:14 2006 Subject: [PATCH] Implement doubly-linked list In-Reply-To: <20060601173654.GA15547@aon.at> References: <200606010022.28386.yann.morin.1998@anciens.enib.fr> <200606010130.23943.yann.morin.1998@anciens.enib.fr> <20060601173654.GA15547@aon.at> Message-ID: <200606012100.03896.yann.morin.1998@anciens.enib.fr> On Thursday 01 June 2006 193, Bernhard Fischer wrote: > >On Thursday 01 June 2006 002, Yann E. MORIN wrote: > >> 003-doubly_linked_lists.patch > May i point you to xargs.c's xlist_t which wants a singly-linked list > with a runlength for the data? > Didn't look, but perhaps there are other users (ed has a LINE -- i'm > thinking of busyboxifying ed, it's seems to be very, very bloated and > doesn't even pass two dozends of the GNU ed's tests, FWIW), [--SNIP--] > modprobe.c: mod_opt_t has *next, *data -> and *prev. [--SNIP--] > Maybe worth a look? Yep. As I said earlier, all these applets should have a common list management with common structure and code. As Rob and you pointed out, there is still work to do to my submission. I'll rework my copy. But I'd like to be sure to understand what is really needed and what I should do. And from Rob's message, having every thing use the same list type might, and will, consume memory more than necessary. From your list above, we seem to need these lists: - *data, *next - *data, *prev, *next - *data, size, *next - *data, size, *prev, *next - Others? Again: what next? What do you guys suggest I do? Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? From ddaney at avtrex.com Thu Jun 1 12:02:23 2006 From: ddaney at avtrex.com (David Daney) Date: Thu Jun 1 12:02:26 2006 Subject: ok, what's the official take on "endianness"? In-Reply-To: References: <447F364B.9080402@avtrex.com> Message-ID: <447F39BF.5060806@avtrex.com> Robert P. J. Day wrote: > On Thu, 1 Jun 2006, David Daney wrote: > > >>Robert P. J. Day wrote: >> >>> probably a silly question, but what's the whole story on best >>>practises for dealing with endianness? >>> >> >>Is this a trick question? >> >>In general don't write code that has endianness dependencies. >> >>For network code use htonl(), htons(), ntohl() and ntohs(). >> >>If you are working with file systems or other things where the >>endianness of on-disk data structures is important, #include >> and be very careful. > > > but this doesn't address what's happening in busybox at the moment, > which is slightly more complicated. > I have not been following the mailing list closely enough to know what the problem is. My guess is that there is code that has endianness dependencies in it. But that is only a guess. If so, see my first point. Sometimes you can play optimization tricks that break endianness neutrality. It ends up being a maintenance nightmare. David Daney From rep.nop at aon.at Thu Jun 1 12:39:42 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jun 1 12:39:55 2006 Subject: [PATCH] ed stuff #1 Message-ID: <20060601193942.GC15547@aon.at> Hi, ed is a) bloated and b) broken. The attached patchlet starts to look a tiny bit into a) Comments? Ok to checkin? text data bss dec hex filename 864338 10244 645924 1520506 17337a busybox_old 864114 10244 645924 1520282 17329a busybox_unstripped thanks, -------------- next part -------------- Index: modutils/modprobe.c =================================================================== --- modutils/modprobe.c (revision 15260) +++ modutils/modprobe.c (working copy) @@ -474,8 +474,7 @@ /* It's a dep description continuation */ p = buffer; - while ( p && *p && isblank(*p)) - p++; + p = bb_skip_blank(p); /* p points to the first dependable module; if NULL, no dependable module */ if ( p && *p ) { @@ -485,7 +484,7 @@ char *next; int ext = 0; - while ( isblank ( *end ) || ( *end == '\\' )) + while ( bb_isblank ( *end ) || ( *end == '\\' )) end--; do @@ -506,8 +505,7 @@ if ( !deps || ( deps < p )) { deps = p; - while ( isblank ( *deps )) - deps++; + deps = bb_skip_blank(deps); } else deps++; Index: coreutils/fold.c =================================================================== --- coreutils/fold.c (revision 15260) +++ coreutils/fold.c (working copy) @@ -113,7 +113,7 @@ int logical_end; for (logical_end = offset_out - 1; logical_end >= 0; logical_end--) { - if (isblank(line_out[logical_end])) { + if (bb_isblank(line_out[logical_end])) { break; } } Index: libbb/Makefile.in =================================================================== --- libbb/Makefile.in (revision 15260) +++ libbb/Makefile.in (working copy) @@ -35,7 +35,7 @@ getopt_ulflags.c default_error_retval.c wfopen_input.c speed_table.c \ perror_nomsg_and_die.c perror_nomsg.c skip_whitespace.c bb_askpass.c \ warn_ignoring_args.c concat_subpath_file.c vfork_daemon_rexec.c \ - bb_echo.c bb_do_delay.c + bb_echo.c bb_do_delay.c skip_blank.c # conditionally compiled objects: LIBBB-$(CONFIG_FEATURE_SHADOWPASSWDS)+=pwd2spwd.c Index: libbb/skip_blank.c =================================================================== --- libbb/skip_blank.c (revision 0) +++ libbb/skip_blank.c (revision 0) @@ -0,0 +1,20 @@ +/* vi: set sw=4 ts=4: */ +/* + * skip_blank implementation for busybox + * + * Copyright (C) 2003 Manuel Novoa III + * + * Licensed under GPLv2 or later, see file LICENSE in this tarball for details. + */ + +#include +#include "libbb.h" + +const char *bb_skip_blank(const char *s) +{ + while (s && (bb_isblank(*s))) { + ++s; + } + + return s; +} Index: libbb/skip_whitespace.c =================================================================== --- libbb/skip_whitespace.c (revision 15260) +++ libbb/skip_whitespace.c (working copy) @@ -4,20 +4,7 @@ * * Copyright (C) 2003 Manuel Novoa III * - * 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 - * + * Licensed under GPLv2 or later, see file LICENSE in this tarball for details. */ #include Index: include/libbb.h =================================================================== --- include/libbb.h (revision 15260) +++ include/libbb.h (working copy) @@ -190,6 +190,7 @@ extern void chomp(char *s); extern void trim(char *s); extern const char *bb_skip_whitespace(const char *); +extern const char *bb_skip_blank(const char *); extern struct BB_applet *find_applet_by_name(const char *name); void run_applet_by_name(const char *name, int argc, char **argv); @@ -455,6 +456,7 @@ extern ssize_t bb_xread(int fd, void *buf, size_t count); extern void bb_xread_all(int fd, void *buf, size_t count); extern unsigned char bb_xread_char(int fd); +#define bb_isblank(ch) ((ch) == ' ' || (ch) == '\t') #ifndef COMM_LEN /*#include *//* Task command name length */ Index: findutils/xargs.c =================================================================== --- findutils/xargs.c (revision 15260) +++ findutils/xargs.c (working copy) @@ -1,3 +1,4 @@ +/* vi: set sw=4 ts=4: */ /* * Mini xargs implementation for busybox * Options are supported: "-prtx -n max_arg -s max_chars -e[ouf_str]" @@ -9,20 +10,8 @@ * - Mike Rendell * and David MacKenzie . * - * 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. + * Licensed under GPLv2 or later, see file LICENSE in this tarball for details. * - * 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 - * * xargs is described in the Single Unix Specification v3 at * http://www.opengroup.org/onlinepubs/007904975/utilities/xargs.html * @@ -95,16 +84,12 @@ bb_error_msg("%s: exited with status 255; aborting", args[0]); return 124; } - if (WIFSTOPPED(status)) { - bb_error_msg("%s: stopped by signal %d", - args[0], WSTOPSIG(status)); - return 125; + if (WIFSTOPPED(status) || WIFSIGNALED(status)) { + bb_error_msg("%s: %sed by signal %d", + args[0], + WIFSTOPPED(status)?"stopp":"terminat", + WIFSTOPPED(status)?WSTOPSIG(status):WTERMSIG(status)); } - if (WIFSIGNALED(status)) { - bb_error_msg("%s: terminated by signal %d", - args[0], WTERMSIG(status)); - return 125; - } if (WEXITSTATUS(status) != 0) return 123; return 0; @@ -124,8 +109,7 @@ static int eof_stdin_detected; -#define ISBLANK(c) ((c) == ' ' || (c) == '\t') -#define ISSPACE(c) (ISBLANK (c) || (c) == '\n' || (c) == '\r' \ +#define ISSPACE(c) (bb_isblank (c) || (c) == '\n' || (c) == '\r' \ || (c) == '\f' || (c) == '\v') #ifdef CONFIG_FEATURE_XARGS_SUPPORT_QUOTES Index: editors/ed.c =================================================================== --- editors/ed.c (revision 15260) +++ editors/ed.c (working copy) @@ -54,14 +54,8 @@ return EXIT_FAILURE; if (argc > 1) { - fileName = strdup(argv[1]); + fileName = bb_xstrdup(argv[1]); - if (fileName == NULL) { - bb_error_msg("No memory"); - termEdit(); - return EXIT_SUCCESS; - } - if (!readLines(fileName, 1)) { termEdit(); return EXIT_SUCCESS; @@ -116,16 +110,13 @@ continue; } - while ((endbuf > buf) && isblank(endbuf[-1])) + while ((endbuf > buf) && bb_isblank(endbuf[-1])) endbuf--; *endbuf = '\0'; - cp = buf; + cp = bb_skip_blank(buf); - while (isblank(*cp)) - cp++; - have1 = FALSE; have2 = FALSE; @@ -138,8 +129,7 @@ if (!getNum(&cp, &have1, &num1)) continue; - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); if (*cp == ',') { @@ -180,14 +170,13 @@ break; case 'f': - if (*cp && !isblank(*cp)) + if (*cp && !bb_isblank(*cp)) { bb_error_msg("Bad file command"); break; } - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); if (*cp == '\0') { @@ -218,8 +207,7 @@ break; case 'k': - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); if ((*cp < 'a') || (*cp > 'a') || cp[1]) { @@ -239,8 +227,7 @@ break; case 'q': - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); if (have1 || *cp) { @@ -256,10 +243,8 @@ buf[0] = '\0'; fgets(buf, sizeof(buf), stdin); - cp = buf; - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(buf); if ((*cp == 'y') || (*cp == 'Y')) return; @@ -267,14 +252,13 @@ break; case 'r': - if (*cp && !isblank(*cp)) + if (*cp && !bb_isblank(*cp)) { bb_error_msg("Bad read command"); break; } - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); if (*cp == '\0') { @@ -298,14 +282,13 @@ break; case 'w': - if (*cp && !isblank(*cp)) + if (*cp && !bb_isblank(*cp)) { bb_error_msg("Bad write command"); break; } - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); if (!have1) { num1 = 1; @@ -408,7 +391,7 @@ strcpy(buf, cmd); cp = buf; - if (isblank(*cp) || (*cp == '\0')) + if (bb_isblank(*cp) || (*cp == '\0')) { bb_error_msg("Bad delimiter for substitute"); @@ -689,8 +672,7 @@ while (TRUE) { - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); switch (*cp) { @@ -761,8 +743,7 @@ value += num * sign; - while (isblank(*cp)) - cp++; + cp = bb_skip_blank(cp); switch (*cp) { @@ -875,7 +856,6 @@ if (fd < 0) { perror(file); - return FALSE; } @@ -940,8 +920,7 @@ bufUsed += cc; bufPtr = bufBase; - } - while (cc > 0); + } while (cc > 0); if (cc < 0) { From lucasvr at gobolinux.org Thu Jun 1 14:28:09 2006 From: lucasvr at gobolinux.org (Lucas C. Villa Real) Date: Thu Jun 1 14:34:27 2006 Subject: [PATCH] CFLAGS_EXTRA and quotes In-Reply-To: <200605311816.52397.rob@landley.net> References: <2c03f9590605171201r274fe5c9t500355aa04484d39@mail.gmail.com> <200605252123.41266.vapier@gentoo.org> <2c03f9590605271056r654af4b2t965959a4672da617@mail.gmail.com> <200605311816.52397.rob@landley.net> Message-ID: <2c03f9590606011428l67046758p52d28716ad03165@mail.gmail.com> On 5/31/06, Rob Landley wrote: > 1) The USING_ALTERNATE_MODDIR serves no purpose. If you're going to make it > configurable at all, just have a sane default for the CONFIG entry. It was just added so that the text area doesn't confund users. Making the text area appear only when the user chooses to use an alternate MODDIR seems sane to me. > 2) Why is /lib/modules not the directory this goes in? Why does everybody > want to change every possible directory all of the sudden? This can't be > because Dec Ultrix had a different path for this because insmod deals with > linux kernel modules. Specifically linux. > > What's the motivation for this? Has anybody ever specified a different > MODDIR? There are a number of projects which use the Linux kernel but do not employ a "standard" Unix-like tree, from djb's package system to the project I'm part of, GoboLinux. The Linux kernel Makefile already allows one to specify the modules dir by changing the variable MODLIB. Module-Init-Tools also allows for passing --with-moddir=, so that a non-standard location can be used by modprobe and friends. We have been relying on these features for some time, and since I'm the one more involved with embedded in our group I've added the same features to BusyBox, so that no hardcoded directories specify how the filesystem must be organized. -- Lucas powered by /dev/dsp From erik at hovland.org Thu Jun 1 16:00:19 2006 From: erik at hovland.org (Erik Hovland) Date: Thu Jun 1 16:56:11 2006 Subject: [patch] abuse of strncpy Message-ID: <20060601230019.GI8986@mage.jpl.nasa.gov> package: busybox version: trunk (20060601) This patch addresses all of the uses of strncpy that I thought were abusive in that they allowed copy such that \0 termination could potentially be lost. Thanks E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- Index: networking/tftp.c =================================================================== --- networking/tftp.c (revision 15261) +++ networking/tftp.c (working copy) @@ -172,7 +172,10 @@ len = sizeof(sa); memset(&sa, 0, len); - bind(socketfd, (struct sockaddr *)&sa, len); + if (bind(socketfd, (struct sockaddr *)&sa, len) < 0) { + bb_perror_msg("bind"); + return EXIT_FAILURE; + } sa.sin_family = host->h_addrtype; sa.sin_port = port; Index: networking/libiproute/iptunnel.c =================================================================== --- networking/libiproute/iptunnel.c (revision 15261) +++ networking/libiproute/iptunnel.c (working copy) @@ -283,7 +283,7 @@ } if (p->name[0]) duparg2("name", *argv); - strncpy(p->name, *argv, IFNAMSIZ); + strncpy(p->name, *argv, IFNAMSIZ - 1); if (cmd == SIOCCHGTUNNEL && count == 0) { struct ip_tunnel_parm old_p; memset(&old_p, 0, sizeof(old_p)); Index: networking/zcip.c =================================================================== --- networking/zcip.c (revision 15261) +++ networking/zcip.c (working copy) @@ -319,7 +319,7 @@ // get the interface's ethernet address memset(&ifr, 0, sizeof (ifr)); - strncpy(ifr.ifr_name, intf, sizeof (ifr.ifr_name)); + strncpy(ifr.ifr_name, intf, sizeof (ifr.ifr_name) - 1); if (ioctl(fd, SIOCGIFHWADDR, &ifr) < 0) { why = "get ethernet address"; goto fail; Index: networking/udhcp/socket.c =================================================================== --- networking/udhcp/socket.c (revision 15261) +++ networking/udhcp/socket.c (working copy) @@ -120,7 +120,7 @@ return -1; } - strncpy(interface.ifr_name, inf, IFNAMSIZ); + strncpy(interface.ifr_name, inf, IFNAMSIZ - 1); if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE,(char *)&interface, sizeof(interface)) < 0) { close(fd); return -1; Index: archival/tar.c =================================================================== --- archival/tar.c (revision 15261) +++ archival/tar.c (working copy) @@ -208,7 +208,7 @@ memset(&header, 0, size); - strncpy(header.name, header_name, sizeof(header.name)); + strncpy(header.name, header_name, sizeof(header.name) - 1); putOctal(header.mode, sizeof(header.mode), statbuf->st_mode); putOctal(header.uid, sizeof(header.uid), statbuf->st_uid); @@ -235,7 +235,7 @@ if (!lpath) /* Already printed err msg inside xreadlink() */ return (FALSE); header.typeflag = SYMTYPE; - strncpy(header.linkname, lpath, sizeof(header.linkname)); + strncpy(header.linkname, lpath, sizeof(header.linkname) - 1); free(lpath); } else if (S_ISDIR(statbuf->st_mode)) { header.typeflag = DIRTYPE; Index: e2fsprogs/tune2fs.c =================================================================== --- e2fsprogs/tune2fs.c (revision 15261) +++ e2fsprogs/tune2fs.c (working copy) @@ -700,13 +700,13 @@ bb_error_msg("Warning: label too long, truncating\n"); memset(sb->s_volume_name, 0, sizeof(sb->s_volume_name)); strncpy(sb->s_volume_name, new_label, - sizeof(sb->s_volume_name)); + sizeof(sb->s_volume_name) - 1); ext2fs_mark_super_dirty(fs); } if (M_flag) { memset(sb->s_last_mounted, 0, sizeof(sb->s_last_mounted)); strncpy(sb->s_last_mounted, new_last_mounted, - sizeof(sb->s_last_mounted)); + sizeof(sb->s_last_mounted) - 1); ext2fs_mark_super_dirty(fs); } if (mntopts_cmd) Index: miscutils/crontab.c =================================================================== --- miscutils/crontab.c (revision 15261) +++ miscutils/crontab.c (working copy) @@ -63,7 +63,7 @@ if ((pas = getpwuid(UserId)) == NULL) bb_perror_msg_and_die("getpwuid"); - strncpy(caller, pas->pw_name, sizeof(caller)); + strncpy(caller, pas->pw_name, sizeof(caller) - 1); i = 1; if (ac > 1) { Index: loginutils/login.c =================================================================== --- loginutils/login.c (revision 15261) +++ loginutils/login.c (working copy) @@ -443,10 +443,10 @@ memset((void *) &utent, 0, sizeof utent); utent.ut_type = LOGIN_PROCESS; utent.ut_pid = pid; - strncpy(utent.ut_line, line, sizeof utent.ut_line); + strncpy(utent.ut_line, line, (sizeof utent.ut_line) - 1); /* XXX - assumes /dev/tty?? */ strncpy(utent.ut_id, utent.ut_line + 3, sizeof utent.ut_id); - strncpy(utent.ut_user, "LOGIN", sizeof utent.ut_user); + strncpy(utent.ut_user, "LOGIN", (sizeof utent.ut_user) - 1); t_tmp = (time_t)utent.ut_time; time(&t_tmp); } @@ -464,7 +464,7 @@ time_t t_tmp = (time_t)utent.ut_time; utent.ut_type = USER_PROCESS; - strncpy(utent.ut_user, name, sizeof utent.ut_user); + strncpy(utent.ut_user, name, (sizeof utent.ut_user) - 1); time(&t_tmp); /* other fields already filled in by checkutmp above */ setutent(); Index: loginutils/getty.c =================================================================== --- loginutils/getty.c (revision 15261) +++ loginutils/getty.c (working copy) @@ -484,9 +484,9 @@ /*endutent(); */ strncpy(ut.ut_user, "LOGIN", sizeof(ut.ut_user)); - strncpy(ut.ut_line, line, sizeof(ut.ut_line)); + strncpy(ut.ut_line, line, sizeof(ut.ut_line) - 1); if (fakehost) - strncpy(ut.ut_host, fakehost, sizeof(ut.ut_host)); + strncpy(ut.ut_host, fakehost, sizeof(ut.ut_host) - 1); time(&t); ut.ut_time = t; ut.ut_type = LOGIN_PROCESS; Index: util-linux/nfsmount.c =================================================================== --- util-linux/nfsmount.c (revision 15261) +++ util-linux/nfsmount.c (working copy) @@ -852,7 +852,7 @@ data.fd = fsock; memcpy((char *) &data.addr, (char *) &server_addr, sizeof(data.addr)); - strncpy(data.hostname, hostname, sizeof(data.hostname)); + strncpy(data.hostname, hostname, sizeof(data.hostname) - 1); /* clean up */ From erik at hovland.org Thu Jun 1 14:07:02 2006 From: erik at hovland.org (Erik Hovland) Date: Thu Jun 1 16:56:18 2006 Subject: [bug] busybox fails building in init.c Message-ID: <20060601210702.GC8986@mage.jpl.nasa.gov> package: busybox version: trunk When I attempt to build busybox using 'make allyesconfig' then disabling SE Linux, then typing 'make busybox', busybox fails attempting to find some symbols because they are hidden behind macros. Make error: /export/home/build/handhelds/busybox-trunk/init/init.c:178: warning: 'shutdown_signal' used but never defined /export/home/build/handhelds/busybox-trunk/init/init.c:146: warning: 'got_cont' defined but not used applets.c:(.text+0x9dcc0): undefined reference to `shutdown_signal.549418' collect2: ld returned 1 exit status make[1]: *** [busybox_unstripped] Error 1 make: *** [busybox] Error 2 The attached patch makes the functions available (but will also increase the size of busybox since they make the functions always compile in). I should add that this issue is a direct result of svn commit: -------------------- Author: pgf Date: 2006-06-01 06:17:49 -0700 (Thu, 01 Jun 2006) New Revision: 15259 Log: make halt and poweroff messages more accurate (i.e., claim "we're about to", rather than "it's done", and combine with reboot handler to save space. -------------------- Thanks E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- Index: init/init.c =================================================================== --- init/init.c (revision 15261) +++ init/init.c (working copy) @@ -143,7 +143,9 @@ #ifndef CONFIG_SYSLOGD static char *log_console = VC_5; #endif +#if !ENABLE_DEBUG_INIT static sig_atomic_t got_cont = 0; +#endif enum { LOG = 0x1, @@ -639,7 +641,6 @@ } } -#if !ENABLE_DEBUG_INIT static void init_reboot(unsigned long magic) { pid_t pid; @@ -695,6 +696,35 @@ sync(); } +static void shutdown_signal(int sig) +{ + char *m; + int rb; + + shutdown_system(); + + if (sig == SIGTERM) { + m = "reboot"; + rb = RB_AUTOBOOT; + } else if (sig == SIGUSR2) { + m = "poweroff"; + rb = RB_POWER_OFF; + } else { + m = "halt"; + rb = RB_HALT_SYSTEM; + } + message(CONSOLE | LOG, "Requesting system %s.", m); + sync(); + + /* allow time for last message to reach serial console */ + sleep(2); + + init_reboot(rb); + + loop_forever(); +} + +#if !ENABLE_DEBUG_INIT static void exec_signal(int sig ATTRIBUTE_UNUSED) { struct init_action *a, *tmp; @@ -746,34 +776,6 @@ } } -static void shutdown_signal(int sig) -{ - char *m; - int rb; - - shutdown_system(); - - if (sig == SIGTERM) { - m = "reboot"; - rb = RB_AUTOBOOT; - } else if (sig == SIGUSR2) { - m = "poweroff"; - rb = RB_POWER_OFF; - } else { - m = "halt"; - rb = RB_HALT_SYSTEM; - } - message(CONSOLE | LOG, "Requesting system %s.", m); - sync(); - - /* allow time for last message to reach serial console */ - sleep(2); - - init_reboot(rb); - - loop_forever(); -} - static void ctrlaltdel_signal(int sig ATTRIBUTE_UNUSED) { run_actions(CTRLALTDEL); From erik at hovland.org Thu Jun 1 13:37:29 2006 From: erik at hovland.org (Erik Hovland) Date: Thu Jun 1 16:56:28 2006 Subject: fdflush typo breaks build Message-ID: <20060601203729.GB8986@mage.jpl.nasa.gov> package: busybox version: trunk When I do a make allyesconfig (then disable SE Linux) and then type 'make busybox', the build fails with: ehovland@mage:handhelds/busybox-trunk>make busybox HOSTLINK scripts/usage In file included from /export/home/build/handhelds/busybox-trunk/scripts/usage.c:7: /export/home/build/handhelds/busybox-trunk/include/applets.h:112: error: syntax error before "fdflish_trivial_usage" make[1]: *** [scripts/usage] Error 1 make: *** [busybox] Error 2 The attached patch seems to fix the problem (assuming that it is a typo with the fdflush macro. E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- Index: include/applets.h =================================================================== --- include/applets.h (revision 15261) +++ include/applets.h (working copy) @@ -109,7 +109,7 @@ USE_FAKEIDENTD(APPLET(fakeidentd, _BB_DIR_USR_SBIN, _BB_SUID_NEVER)) USE_FALSE(APPLET(false, _BB_DIR_BIN, _BB_SUID_NEVER)) USE_FBSET(APPLET(fbset, _BB_DIR_USR_SBIN, _BB_SUID_NEVER)) -USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER, fdflish)) +USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER, fdflush)) USE_FDFORMAT(APPLET(fdformat, _BB_DIR_USR_BIN, _BB_SUID_NEVER)) USE_FDISK(APPLET(fdisk, _BB_DIR_SBIN, _BB_SUID_NEVER)) USE_FEATURE_GREP_FGREP_ALIAS(APPLET_NOUSAGE(fgrep, grep, _BB_DIR_BIN, _BB_SUID_NEVER)) From pgf at brightstareng.com Thu Jun 1 20:37:46 2006 From: pgf at brightstareng.com (Paul Fox) Date: Thu Jun 1 20:37:54 2006 Subject: fdflush typo breaks build In-Reply-To: erik's message of Thu, 01 Jun 2006 13:37:29 -0700. <20060601203729.GB8986@mage.jpl.nasa.gov> Message-ID: <8339.1149219466@brightstareng.com> > > --J2SCkAp4GZ/dPZZf > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > package: busybox > version: trunk > > When I do a make allyesconfig (then disable SE Linux) and then type > 'make busybox', the build fails with: > ehovland@mage:handhelds/busybox-trunk>make busybox > HOSTLINK scripts/usage > In file included from > /export/home/build/handhelds/busybox-trunk/scripts/usage.c:7: > /export/home/build/handhelds/busybox-trunk/include/applets.h:112: error: syntax error before "fdflish_trivial_usage" > make[1]: *** [scripts/usage] Error 1 > make: *** [busybox] Error 2 > > The attached patch seems to fix the problem (assuming that it is a typo > with the fdflush macro. applied. thanks. paul =--------------------- paul fox, pgf@brightstareng.com From pgf at brightstareng.com Thu Jun 1 21:14:49 2006 From: pgf at brightstareng.com (Paul Fox) Date: Thu Jun 1 21:15:04 2006 Subject: [bug] busybox fails building in init.c In-Reply-To: erik's message of Thu, 01 Jun 2006 14:07:02 -0700. <20060601210702.GC8986@mage.jpl.nasa.gov> Message-ID: <9220.1149221689@brightstareng.com> thanks for catching this. > > package: busybox > version: trunk > > When I attempt to build busybox using 'make allyesconfig' then disabling > SE Linux, then typing 'make busybox', busybox fails attempting to find > some symbols because they are hidden behind macros. simply turning on CONFIG_DEBUG_INIT will cause it, though the way the optimizer handles the "fail" variable in open_new_terminal(), the missing reference isn't always fatal. > > Make error: > /export/home/build/handhelds/busybox-trunk/init/init.c:178: warning: 'shutdown_signal' used but never defined > /export/home/build/handhelds/busybox-trunk/init/init.c:146: warning: 'got_cont' defined but not used > applets.c:(.text+0x9dcc0): undefined reference to `shutdown_signal.549418' > collect2: ld returned 1 exit status > make[1]: *** [busybox_unstripped] Error 1 > make: *** [busybox] Error 2 > > The attached patch makes the functions available (but will also increase > the size of busybox since they make the functions always compile in). i'm attaching a different patch with i believe is more correct, since the goal of CONFIG_DEBUG_INIT is to prevent the system from shutting down while you're debugging. it also doesn't increase the size (though the size increase was only with CONFIG_DEBUG_INIT, in any case). please test the attached. i can't reproduce the allyesconfig test, because my machine can't handle the compile-all-at-once phase. > > I should add that this issue is a direct result of svn commit: > -------------------- > Author: pgf > Date: 2006-06-01 06:17:49 -0700 (Thu, 01 Jun 2006) > New Revision: 15259 > > Log: > make halt and poweroff messages more accurate (i.e., claim "we're about > to", rather than "it's done", and combine with reboot handler to save > space. i believe this issue pre-existed that commit. paul Index: init/init.c =================================================================== --- init/init.c (revision 15262) +++ init/init.c (working copy) @@ -143,7 +143,9 @@ #ifndef CONFIG_SYSLOGD static char *log_console = VC_5; #endif +#if !ENABLE_DEBUG_INIT static sig_atomic_t got_cont = 0; +#endif enum { LOG = 0x1, @@ -175,7 +177,9 @@ /* Function prototypes */ static void delete_init_action(struct init_action *a); static int waitfor(const struct init_action *a, pid_t pid); +#if !ENABLE_DEBUG_INIT static void shutdown_signal(int sig); +#endif static void loop_forever(void) @@ -395,7 +399,11 @@ if (fail) _exit(1); /* else */ +#if !ENABLE_DEBUG_INIT shutdown_signal(SIGUSR1); +#else + _exit(2); +#endif } } =--------------------- paul fox, pgf@brightstareng.com From rep.nop at aon.at Fri Jun 2 00:54:02 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Fri Jun 2 00:54:18 2006 Subject: BUG with usage_compressed (?) In-Reply-To: <200605301629.21574.rob@landley.net> References: <20060530162613.GA14117@aon.at> <200605301629.21574.rob@landley.net> Message-ID: <20060602075402.GA30246@aon.at> On Tue, May 30, 2006 at 04:29:21PM -0400, Rob Landley wrote: >On Tuesday 30 May 2006 12:26 pm, Bernhard Fischer wrote: >> Houston..., >> >> The usage-messages are foobared (for me): >> This should print the helptext of sort, but it displays the one >> of start-stop-daemon: >> >> $ ./busybox sort -h >> sort: invalid option -- h >> BusyBox v1.2.0-pre0 (2006.05.30-16:12+0000) multi-call binary >> >> Usage: sort [OPTIONS] [--start|--stop] ... [-- arguments...] >> >> Program to start and stop services. > >I get sort. Just checked. What's your .config? > >> If i turn off USAGE_COMPRESSED, then all is well again. >> Steps to reproduce: >> make distclean defconfig menuconfig >> make busybox;./busybox sort -h > >I just did all that: > >landley@driftwood:~/busybox/busybox$ ./busybox sort -h >sort: invalid option -- h >BusyBox v1.2.0-pre0 (2006.05.30-20:25+0000) multi-call binary > >Usage: sort [-nrugMcszbdfimSTokt] [-o outfile] [-k start[.offset][opts] >[,end[.offset][opts]] [-t char] [FILE]... > >Sorts lines of text in the specified files > >> Can someone look into this, please? > >It's not reproducing here. What's your build environment? Turns out that it was broken by this change: 15257 landley: -USE_FDFLUSH(APPLET(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER)) +USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER, fdflish)) as noticed by erik hovland and fixed by pgf in r15262 All is well again, in this respect. > >Rob >-- >Never bet against the cheap plastic solution. > From wharms at bfs.de Fri Jun 2 01:07:30 2006 From: wharms at bfs.de (walter harms) Date: Fri Jun 2 01:07:43 2006 Subject: [patch] abuse of strncpy In-Reply-To: <20060601230019.GI8986@mage.jpl.nasa.gov> References: <20060601230019.GI8986@mage.jpl.nasa.gov> Message-ID: <447FF1C2.5050501@bfs.de> Hi Erik good catch, if you are concerned about security why not use strlcpy() or a bb supplied bb_strlcpy() if its not available ?. "the result is always a valid NUL-terminated string that fits in the buffer (unless, of course, the buffer size is zero)." strncpy() does not do it (IMHO: design error). re, wh Erik Hovland wrote: > package: busybox > version: trunk (20060601) > > This patch addresses all of the uses of strncpy that I thought were > abusive in that they allowed copy such that \0 termination could > potentially be lost. > > Thanks > > E > > > From rep.nop at aon.at Fri Jun 2 03:43:57 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Fri Jun 2 03:44:08 2006 Subject: [bug] busybox fails building in init.c In-Reply-To: <9220.1149221689@brightstareng.com> References: <20060601210702.GC8986@mage.jpl.nasa.gov> <9220.1149221689@brightstareng.com> Message-ID: <20060602104357.GB30246@aon.at> On Fri, Jun 02, 2006 at 12:14:49AM -0400, Paul Fox wrote: >thanks for catching this. > > > > > package: busybox > > version: trunk > > > > When I attempt to build busybox using 'make allyesconfig' then disabling > > SE Linux, then typing 'make busybox', busybox fails attempting to find > > some symbols because they are hidden behind macros. > >simply turning on CONFIG_DEBUG_INIT will cause it, though the way >the optimizer handles the "fail" variable in open_new_terminal(), >the missing reference isn't always fatal. > > > > > Make error: > > /export/home/build/handhelds/busybox-trunk/init/init.c:178: warning: 'shutdown_signal' used but never defined > > /export/home/build/handhelds/busybox-trunk/init/init.c:146: warning: 'got_cont' defined but not used > > applets.c:(.text+0x9dcc0): undefined reference to `shutdown_signal.549418' > > collect2: ld returned 1 exit status > > make[1]: *** [busybox_unstripped] Error 1 > > make: *** [busybox] Error 2 > > > > The attached patch makes the functions available (but will also increase > > the size of busybox since they make the functions always compile in). > >i'm attaching a different patch with i believe is more correct, >since the goal of CONFIG_DEBUG_INIT is to prevent the system from >shutting down while you're debugging. it also doesn't increase >the size (though the size increase was only with >CONFIG_DEBUG_INIT, in any case). > >please test the attached. i can't reproduce the allyesconfig >test, because my machine can't handle the compile-all-at-once >phase. > > > > > I should add that this issue is a direct result of svn commit: > > -------------------- > > Author: pgf > > Date: 2006-06-01 06:17:49 -0700 (Thu, 01 Jun 2006) > > New Revision: 15259 > > > > Log: > > make halt and poweroff messages more accurate (i.e., claim "we're about > > to", rather than "it's done", and combine with reboot handler to save > > space. > >i believe this issue pre-existed that commit. True. Fixed in r15264. Thanks all and sorry. From pgf at brightstareng.com Fri Jun 2 05:12:26 2006 From: pgf at brightstareng.com (Paul Fox) Date: Fri Jun 2 05:12:36 2006 Subject: BUG with usage_compressed (?) In-Reply-To: rep.nop's message of Fri, 02 Jun 2006 09:54:02 +0200. <20060602075402.GA30246@aon.at> Message-ID: <18914.1149250346@brightstareng.com> > >> The usage-messages are foobared (for me): > >> This should print the helptext of sort, but it displays the one > >> of start-stop-daemon: ... > > Turns out that it was broken by this change: > 15257 landley: > -USE_FDFLUSH(APPLET(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER)) > +USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER, fdflish)) > > as noticed by erik hovland and fixed by pgf in r15262 _that_ fixed it?? i certainly wouldn't have predicted that. paul =--------------------- paul fox, pgf@brightstareng.com From farmatito at tiscali.it Fri Jun 2 05:20:18 2006 From: farmatito at tiscali.it (Tito) Date: Fri Jun 2 05:20:52 2006 Subject: [patch] abuse of strncpy In-Reply-To: <447FF1C2.5050501@bfs.de> References: <20060601230019.GI8986@mage.jpl.nasa.gov> <447FF1C2.5050501@bfs.de> Message-ID: <200606021420.19217.farmatito@tiscali.it> On Friday 2 June 2006 10:07, walter harms wrote: > Hi Erik good catch, > if you are concerned about security why not use strlcpy() or a bb > supplied bb_strlcpy() if its not available ?. Hi, In libbb we have it ;-) /* Like strncpy but make sure the resulting string is always 0 terminated. */ char * safe_strncpy(char *dst, const char *src, size_t size) { dst[size-1] = '\0'; return strncpy(dst, src, size-1); } > "the result is always a valid NUL-terminated string that fits in the > buffer (unless, of course, the buffer size is zero)." > > strncpy() does not do it (IMHO: design error). > re, > wh > > Erik Hovland wrote: > > package: busybox > > version: trunk (20060601) > > > > This patch addresses all of the uses of strncpy that I thought were > > abusive in that they allowed copy such that \0 termination could > > potentially be lost. > > > > Thanks > > > > E > > > > > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > From rep.nop at aon.at Fri Jun 2 05:40:24 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Fri Jun 2 05:40:30 2006 Subject: BUG with usage_compressed (?) In-Reply-To: <18914.1149250346@brightstareng.com> References: <20060602075402.GA30246@aon.at> <18914.1149250346@brightstareng.com> Message-ID: <20060602124024.GA1838@aon.at> On Fri, Jun 02, 2006 at 08:12:26AM -0400, Paul Fox wrote: > > >> The usage-messages are foobared (for me): > > >> This should print the helptext of sort, but it displays the one > > >> of start-stop-daemon: > ... > > > > Turns out that it was broken by this change: > > 15257 landley: > > -USE_FDFLUSH(APPLET(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER)) > > +USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER, fdflish)) > > > > as noticed by erik hovland and fixed by pgf in r15262 > >_that_ fixed it?? i certainly wouldn't have predicted that. My bad, i had compressed_usage turned off. The glitch is still there.. From wharms at bfs.de Fri Jun 2 05:46:58 2006 From: wharms at bfs.de (walter harms) Date: Fri Jun 2 05:47:07 2006 Subject: [patch] abuse of strncpy In-Reply-To: <200606021420.19217.farmatito@tiscali.it> References: <20060601230019.GI8986@mage.jpl.nasa.gov> <447FF1C2.5050501@bfs.de> <200606021420.19217.farmatito@tiscali.it> Message-ID: <44803342.3030901@bfs.de> lets call it bb_strlcpy(), so there is less confusion. re, wh Tito wrote: > On Friday 2 June 2006 10:07, walter harms wrote: >> Hi Erik good catch, >> if you are concerned about security why not use strlcpy() or a bb >> supplied bb_strlcpy() if its not available ?. > Hi, > In libbb we have it ;-) > > /* Like strncpy but make sure the resulting string is always 0 terminated. */ > char * safe_strncpy(char *dst, const char *src, size_t size) > { > dst[size-1] = '\0'; > return strncpy(dst, src, size-1); > } > > >> "the result is always a valid NUL-terminated string that fits in the >> buffer (unless, of course, the buffer size is zero)." >> >> strncpy() does not do it (IMHO: design error). >> re, >> wh >> >> Erik Hovland wrote: >>> package: busybox >>> version: trunk (20060601) >>> >>> This patch addresses all of the uses of strncpy that I thought were >>> abusive in that they allowed copy such that \0 termination could >>> potentially be lost. >>> From rpjday at mindspring.com Fri Jun 2 06:05:39 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Fri Jun 2 06:07:08 2006 Subject: [patch] abuse of strncpy In-Reply-To: <44803342.3030901@bfs.de> References: <20060601230019.GI8986@mage.jpl.nasa.gov> <447FF1C2.5050501@bfs.de> <200606021420.19217.farmatito@tiscali.it> <44803342.3030901@bfs.de> Message-ID: On Fri, 2 Jun 2006, walter harms wrote: > lets call it bb_strlcpy(), so there is less confusion. > re, > wh i have a better idea -- let's not. in fact, let's do away with this whole notion of arbitrarily prefixing modified library routines with that thoroughly useless "bb_" prefix. in the first place, adding that "bb_" prefix makes what could be more universally-usable routines a little less usable, since anyone trying to incorporate them into another project will be stuck with those wholly irrelevant prefixes that have nothing to do with their project. (yes, i realize that caring about using BB routines in other projects is outside the scope of BB design, but i don't see any compelling reason to introduce difficulty for no apparent reason.) more to the point, seeing a routine whose name is "bb_strlcpy" tells me absolutely nothing about how that routine differs from the standard routine, or why it should in the first place. as a comparison, it *is* more meaningful to see a routine named "safe_strncpy" since, from the name alone, i at least have clue as to what the rationale for that routine is. but "bb_strlcpy"? if the purpose of redesigning that routine is to, say, guarantee that a null byte is added to the end, thsn suck it up and call it "strlcpy_null_term()" or something similar. not only is that more meaningful but, down the road, you never know when you might need *another* strlcpy-derived routine that does something slightly different. what will you call that? bb2_strlcpy? just sit down, write up a list of related routines you need in busybox, give them meaningful names and go with that. rday From farmatito at tiscali.it Fri Jun 2 06:33:18 2006 From: farmatito at tiscali.it (Tito) Date: Fri Jun 2 06:33:57 2006 Subject: [PATCH] fix minor bugs in hdparm and don't block when reading from stdin Message-ID: <200606021533.18348.farmatito@tiscali.it> Hi, this patch fixes two potential bugs with the -i -I flags, that could be reset during option parsing and makes hdparm not blocking when reading from stdin and nothing is piped to it. (in this case it displays the classical usage screen). Please apply, tested and almost trivial ;-P Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: hdparm_14.patch Type: text/x-diff Size: 1515 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060602/96862650/hdparm_14.bin From peter.kjellerstedt at axis.com Fri Jun 2 08:48:32 2006 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Fri Jun 2 08:48:45 2006 Subject: [patch] abuse of strncpy Message-ID: <50BF37ECE4954A4BA18C08D0C2CF88CB01A4423A@exmail1.se.axis.com> > -----Original Message----- > From: busybox-bounces@busybox.net > [mailto:busybox-bounces@busybox.net] On Behalf Of Tito > Sent: Friday, June 02, 2006 14:20 > To: busybox@busybox.net; wharms@bfs.de > Subject: Re: [patch] abuse of strncpy > > On Friday 2 June 2006 10:07, walter harms wrote: > > Hi Erik good catch, > > if you are concerned about security why not use strlcpy() or a bb > > supplied bb_strlcpy() if its not available ?. > > Hi, > In libbb we have it ;-) > > /* Like strncpy but make sure the resulting string is always > 0 terminated. */ > char * safe_strncpy(char *dst, const char *src, size_t size) > { > dst[size-1] = '\0'; > return strncpy(dst, src, size-1); > } Is it just me that find the name safe_strncpy() somewhat misleading when looking at its implementation? What if size == 0? I would suggest it is changed to the following: char * safe_strncpy(char *dst, const char *src, size_t size) { if (!size) { return dst; } else { dst[size-1] = '\0'; return strncpy(dst, src, size-1); } } And on the related subject of renaming the above function to bb_strlcpy(), that would be totally misleading, as strlcpy() has totally different semantics and functionality. //Peter From rob at landley.net Fri Jun 2 07:24:00 2006 From: rob at landley.net (Rob Landley) Date: Fri Jun 2 08:54:33 2006 Subject: Error in creating linux single floppy In-Reply-To: References: Message-ID: <200606021024.00731.rob@landley.net> On Thursday 01 June 2006 12:20 am, gopi chand komma wrote: > Hai, > > I have been succesful in creating linux single floppy. now i am > trying to build the same thing into a usb memory stick. when i am > doing this i am getting the follwing error while booting from the usb > device. > > ds : no socket drivers loaded. > kmod : filed to exec /sbinmdprobe -s -k block-major -1 > error=2 VFS : Cannot open root device "ram0" or 01:00 > please append a correct "root" boot options > kernel panic : VFS : unable to mount root fson 01:00 > > HOW TO LOAD SOCKET DRIVERS ? This has nothing whatsoever to do with BusyBox. > Please kindly send me some solution to the above problems Have you tried kernelnewbies? Or the #elinux or #edev channels on irc.freenode.net? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Fri Jun 2 08:54:08 2006 From: rob at landley.net (Rob Landley) Date: Fri Jun 2 08:54:58 2006 Subject: The getopt long thing breaks the tree. In-Reply-To: <20060601043938.GT32494@brightrain.aerifal.cx> References: <200605301255.38248.rob@landley.net> <200605312325.00300.rob@landley.net> <20060601043938.GT32494@brightrain.aerifal.cx> Message-ID: <200606021154.09335.rob@landley.net> On Thursday 01 June 2006 12:39 am, Rich Felker wrote: > On Wed, May 31, 2006 at 11:24:59PM -0400, Rob Landley wrote: > > On Wednesday 31 May 2006 9:40 pm, Rich Felker wrote: > > > On Wed, May 31, 2006 at 05:27:58PM -0400, Rob Landley wrote: > > > > > What i, personally, care about is standard compliance; There simply > > > > > is no such thing like getopt_long nor "struct option". See > > > > > http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html > > > > > > > > There's no such thing as mount in the darn standard either. You > > > > should stop using it immediately. > > > > > > The standard omits mount for a very good reason: not that it should > > > not exist, but that specifying such low-level, administrator-specific > > > things is not the job of the standard but of the particular > > > implementation. > > > > It is not a complete spec, and it doesn't say we can't rely on things > > that aren't in the spec. > > It doesn't say you can't, but it says that programs that do are not > strictly conforming applications. Whether you care or not... "Don't care" implies a mere lack of caring, where what I actually have is a noticeable amount of negative caring here. I care in the opposite direction. Busybox is not and has never has been a "strictly conforming" application in that since. We don't even plan to _provide_ a strictly conforming environment since we're not doing the internationalization stuff, so just about every applet has a set of environment variables we're supposed to care about, but don't. However, we plan to provide, as one of the configuration options, a reasonably accurate SUSv3 environment with only documented deviations. This doesn't mean we'll run in one, it means our apps behave according to the descriptions in the spec, with specific exceptions such as no internationalization support. Don't confuse the two. > > There's a difference between the environment we _provide_ and the > > environments in which we _build_ and _run_. Pointing to the spec for the > > environment we provide, I'll look at. Pointing to the spec about the > > environment in which we build and run is something about which I > > _DO_NOT_CARE_. > > .. I think we see. :) A) If you ignore what I say long enough, I'll start ignoring what _you_ say by putting you on my spam filter. B) You are aware that if I'm pushed enough, I'll delete platform.h and make _sure_ the project is Linux-only? I don't want to do that and I think that would upset Bernhard, but if it persistently becomes more trouble than it's worth and attracts idiots who don't take a hint when it's delivered with a hammer to the cranium, I have _mountains_ of escalation I can do here. > > The environment in which we build and run is Linux. > > Linux is not a single environment, it's a kernel. Says Richard Stallman. He is wrong. There's a standard collection of packages supported by Red Hat, SuSE, Debian, Gentoo, Slackware, Knoppix, Ubuntu, Yellow Dog, and tons of other distros. The common collection of applications that build and run on all of them is building on the Linux platform. Richard's still upset because the GNU project died around 1988 when it abandoned its monolithic kernel design for a microkernel design it couldn't implement. He can't let go. Linux was the successor to a bunch of stalled or blocked efforts (the GNU project, comp.os.minix, the berkeley CSRG), some of which later revived (Minix had a GPL release, several other follow-ups of the Berkeley CSRG are still viable or even successful, in the case of MacOS X). Linux inherited developers and technology from many sources, but it's its own project. The only GNU/Linux distribution is Debian because Debian was taken over by the FSF fairly early on and was the official FSF distribution of Linux until Debian forked away from the FSF very early because nobody can get along with Richard for long. If you care: http://www.faifzilla.org/ch10.html Which is less than half of the story, by the way. (Follow libc5 to libc6, Werner Almsberger is a Cygnus guy who can't stand Richard Stallman. The FSF annointed a Linux project as successor and handed over the name because the corresponding GNU project was _dead_. Just like they did when egcs became gcc 2.95, because the fsf-developed gcc was so dead it was starting to _smell_ so they handed over maintainership to the fork everybody was using.) Busybox 1.00 was a piece of Linux software. It was built on gcc 2.95 or greater, with glibc 2.1 or uClibc 0.9.26 or greater under GNU Make 3.79.1 and the 2.2 or newer Linux kernel. That's historical fact, that's what it NEEDED. Since then we've moved towards C99 but are still GCC-centric (3.2 now), and our C libraries are expected to be newer (glibc 2.2 or uClibc 0.9.27), and linux-2.4, and there's a push to require Make 3.80 that I'm still resisting but it's only a matter of time. And you'll notice, ever single release since 1.00 has been put together by me. I didn't become maintainer because Erik suddenly decided I should be maintainer. I'd been acting as maintainer for most of a year already, and I _did_ make some of the earlier decisions about portability since Erik wasn't around to do so. Shaun Jackman was the first person I was aware of to start poking non-Linux changes into the tree (newlib with libgloss). I've been making noises about better mmu-less support for a while, and slowly working on it. There's been a BSD support patch in bugs.busybox.net (netbsd?) for over a year that I've totally ignored because it was too intrusive. Trying to clean that up into a policy, I introduced platform.h and said it would be a good idea to run on things like MacOS X if it's easy to do so and we can hide the changes to things like platform.h. I have no problem with running on Digital Unix or Cygwin either. But NOT if it hurts our ability to run on Linux in the slightest. But you don't attack the standard Linux environment as stupid and that we should PORT busybox to MacOS X and rebase with that as our new standard platform. That's where it ENDS. Busybox is first and foremost a Linux project, and it always will be. We don't stop using glibc extensions just because they're glibc extensions. That is not a reason. If your platform hasn't got dprintf(), IMPLEMENT IT. I put in the platform.h define because I know there's a name conflict, fine. The current discussion never went through the stage "Since busybox uses getopt_long(), should we implement getopt_long() on non-linux platforms that want to run busybox?" It never even came up. And that's wrong. The suggestion that we can make busybox smaller by making getopt_ulflags() implement its own getopt behavior is a good one. It can make busybox smaller ON_LINUX, and it avoids side effects like argument reordering that are bad ON_LINUX. And that's a convincing argument. Reducing the requirements of other platforms to implement Linux APIs if they want to run busybox is a fringe benefit. Nothing more. > The environment > you're talking about is GNU/Linux, No, it's Linux. If I build a system with uClibc, BusyBox, dropbear, X.org, and the Linux kernel, it hasn't got a single GNU package in the final deployed system. How can that possibly be GNU/Linux? I may have used GNU tools to build it (unless I grab icc or some such), but that's like saying the Windows version of The Gimp is a microsoft product because it was built with Visual C. Watcom didn't own OS/2 for the Power PC either. > which I don't have any interest in > running anymore due to getting thoroughly sick of it after many years > of dealing with all the hacks and bloat. I'm trying to come up with better replacements for portions of it too. This trend is normal. When the mainline gets bloated enough, a slimmed-down fork emerges. Dropbear vs openssh. Galeon vs Mozilla (and Firefox vs Galeon, and it's still kinda bloated.) xfce fs kde/gnome. uClibc vs glibc, and BusyBox vs most of the GNU tools. Sometimes the forks are internal, such as the modular x.org rewrite (based on what was "tinyx"), or matt mackall's -tiny work going into the Linux kernel. That's one of the advantages of a modular design, you can replace a component with a better implementation. > > There are specs out there that say what > > a Linux environment should look like. The Linux Standard Base is one of > > them. > > The LSB is among the most idiotic "specs" I've ever read. Didn't say it was a good spec. :) > It's a waste > of hundreds of pages saying essentially "you must have an ABI > identical to glibc's". Ok, the spec there then is the glibc documentation. *shrug*. > Any spec (such as LSB or SVID) that includes > ABI is inherently stupid (from my point of view in case that wasn't > clear) since ABI is obviously an implementation issue and not > something that needs to be standardized. So TCP specifying what the on-the-wire protocol should look like (it's binary) was a bad thing? Linux still runs (statically linked) binaries that ran under 0.01. They disagree with you. > Moreover if that's not enough LSB actually contradicts POSIX/SUSv3 > intentionally due to bugs in Linux. It changes the rules so that the > buggy Linux behavior is not considered buggy. :) Unfortunately this > actually prevents the bugs in Linux from being fixed. :( "The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum, many years ago... My lack of caring is deep and profound. I'm not a fan of the LSB. There are multiple conflicting standards. Wheee. The application section of SUSv3 is incomplete, but vaguely sane. (Only vaguely: We're not implementing sccs.) And thus is the frame of reference from which we can document how we diverge when we get around to auditing things. > > Working around specific deficiencies in the Linux emulation of other > > platforms are just that: workarounds. > > Other platforms have no reason to emulate "Linux" (GNU/Linux). Doing > so will make them necessarily bloated and bogged down by legacy crap. I have no reason to care about those other platforms that are neither Linux nor remotely compatible with it. > > You're bitching about an upstream spec that > > doesn't specify _init_, so by itself it won't even _boot_. > > It doesn't specify init because programs running on the system have no > use in knowing what init is or whether it even exists. I know WHY the specs are incomplete. But the fact remains that no specification perfectly matches the real world on any system that isn't a toy in a laboratory or some overbred ISO9002 piece of crap along the lines of ADA. > This is the > correct way to write a standard. You do not specify the things that > people should not be relying on, and then the implementation is free > to do them in the way it deems most reasonable. And thus we use getopt, which is available on Linux. > Because POSIX/SUSv3 are a proper standard, unlike LSB/SVID, I can make > my own init program that just enables auto-reaping of children, runs a > single script, and sleeps for all eternity, and still have a compliant > system. It suits my needs and there's no legitimate reason for any > software but the boot scripts to care about how init works, so why > not? Busybox can be configured to violate any conceivable standard eight ways from sunday. You can configure busybox to provide only the applets that AREN'T mentioned in SUSv3, pretty easily, and remove required features from lots of the ones that are. This has always been the case, and should continue. > > > On the other hand, it's reasonable to assume that apps > > > which have nothing to do with low-level, implementation-specific > > > issues like mounting filesystems and configuring the network should be > > > able to get by with only the standard interfaces, and work > > > out-of-the-box on any (mostly-) posix compliant system. > > > > If you talk about "this test case breaks on MacOS X", that's real. If > > you say "this does not conform to the spec" I'll show you a spec it > > conforms to, even if it's the gcc man page or Johnathan Corbet's Linux > > device drivers book. > > I've said multiple times: what I talk about is "this test case breaks > on my implementation of the C library". Which inconveniences nobody in the world but you. > My implementation is based > exclusively on a reading of SUSv3, and aside from the fact that I > insist on never imposing arbitrary limits or unbounded time/memory use > when it's not necessary (I consider these quality/security issues), it > intentionally does not provide anything beyond what the standards > require. Good for you. Why should I care? > This is not pedantry for the sake of pedantry. We disagree on this. > It's a matter of > keeping the implementation small, fast, and simple, and of ensuring > that implementation may later be replaced by better ones which work in > a different manner yet which cannot have the same (extended) behavior > as the original code. I care about BusyBox working with glibc and uClibc because real world people, right now, want to deploy that. I'm interested in possibly working with klibc in future because that's getting bundled into the Linux kernel (it's in -mm now) and thus will be seeing wider use. I'm vaguely interested in working with MacOS X's C library for the simple reason that there are tens of millions of seats of that out in the wild, and it's not _that_ far from where we are now. I'm not interested in working with The Hurd, which already has way more seats than your thing does. > I can cite several major examples in glibc where > adding nonstandard functionality to various functions has made it > difficult (coding-wise, or often memory/performance-wise!) to update > the functions to conform to modern standards (see fnmatch for one, > uhg!!). Overspecification is the bane of code because it essentially > locks you into one implementation, and over time that implementation > will eventually become undesirable. When we deploy against uClibc or glibc, we use what's available to make our code smaller in real world systems. You are not talking about real world systems that are out there right now. Come back when you are. > > > I apologize that you feel like these issues are wasting your time. > > > > No, I feel they're introducing new goals to the project. We try to > > provide a SUSv3 environment, but A) that's just an config option, B) what > > we provide it on is Linux and things that are more or less compatible > > with Linux. Changes to support non-linux platforms which require such > > extensive changes to BusyBox that they can't be confined to something > > like platform.h may not be worth doing. > > Overall I agree. I hate platform-based ifdefs and the like. The > minimum I'd like to see (and which I have been submitting patches for) > is to make all the applets that have no dependence on Linux-specific > functionality so that they work on any SUSv3-compliant system. > > A slightly higher level that would also be nice is to make some of the > Linux-specific applets less dependent on the particular libc used, so > that they might work with dietlibc, newlib, my implementation, or > other weird stuff out there that could be useful in embedded > applications. I do NOT propose doing this with ifdefs, but instead > with minor changes that do not break glibc/uClibc but allow the code > to work with non-glibc-compat libs as well. I'm interested in looking at these. (This is not the same as automatic acceptance.) Allowing uClibc to configure out extra stuff we don't need is a good thing if it can save space on Linux. That is what I care about. > > It's the API Linux has, therefore it's what busybox should be > > primarily using. > > It's the api GNU libc has. Last I checked there's no __NR_getopt_long > in asm/unistd.h. :) I am not against rewriting our getopt_ulflags() to not rely on libc's getopt(). I've said this. I was actually pondering doing that myself about a year ago (whenever I first noticed that tar xvjfC didn't work on uClibc), although at the time touching Vladimir's code would have triggered a hissy-fit from the prima donna, so I just didn't go there. And since then, I haven't had time to do it personally. It may be possible for you to achieve your goals, but when I say the reasons you're putting forward to do something aren't convincing to me, all you do by hammering on those same reasons harder is get me to dismiss your opinions completely. I am _constantly_ asking "Do we really want to do that, why do we want to do that, what's the benefit of this, is there a better way, is there something else entirely we should do instead that renders this irrelevant, what else would this allow us to do..." There are conflicting goals ALL THE TIME, and I'm trying to resolve things so multiple different goals get met. Focusing in on a tiny area to the exclusion of all else is fine, but don't expect me to always agree with you. I'll happily tell you what my priorities are, and suggest how you can get your priorities without screwing up mine. Dismissing my priorities does not seem to me to be a useful move on your part. Standards compliance is _a_ goal but not _the_ goal, and there are many things that can be called standards compliance. We currently have the goal to _provide_ as close to an SUSv3 command line environment as we reasonably can without bloating the code, and to document the inevitable divergences where we decide not to go all the way. This says NOTHING about the environment we run in, and this says nothing about other specs. And it's also not a very high priority goal, we've been working towards it for a while and have made progress but we're not going to drop everything to focus on just that any time soon. > Rich Rob -- Never bet against the cheap plastic solution. From rob at landley.net Fri Jun 2 09:17:51 2006 From: rob at landley.net (Rob Landley) Date: Fri Jun 2 09:17:56 2006 Subject: Feature Freeze Friday June 9, release Monday June 26. Message-ID: <200606021217.51821.rob@landley.net> Ok, I'm running a bit behind. I'd like to calm things down soon for the 1.2.0 release. If you have anything else you'd like to get in for 1.2.0 that isn't a clear bugfix, could you please post it to the list by Friday the 9th. Anything that hasn't been posted to the list by Friday, and isn't a clear bugfix, will have to wait until the tree opens up again for 1.3. I'll try to work my way through the patch backlog (I've got 400 messages marked as "deal with this"... Sigh.) and I notice Bernhard's working through bugs.busybox.net (which I'll need to face once I'm caught up with the backlog, you can just _tell_ how much I'm looking forward to this). I'd like to get 1.2.0 out on Monday, June 26, which means I need to get the patch backlog cleared up at least a week before that to give people feature-complete snapshots they can test. After 1.2.0, I'm thinking of moving to a 4-month release cycle, or three new x.y.0 releases a year. (That would put the 1.3 release in October.) Hopefully that'll give me a chance to finish off some of the larger projects (like the passwd subsystem rewrite, and bbsh) that have been languishing for too long. Comments? Rob -- Never bet against the cheap plastic solution. From kenm at desertweyr.com Fri Jun 2 11:05:02 2006 From: kenm at desertweyr.com (Ken McGuire) Date: Fri Jun 2 11:03:47 2006 Subject: problems with hdparm in svn 15237/15261 Message-ID: <4480296E.2226.1127ADF@localhost> Rats! I screwed up and didn't send this to the list, sorry, I'll blame it on my mailer.... ;>) The endian issue is still present on ppc in svn 15261. hopefully it can get dealt with befor the 1.2.0 release. On 30 May 2006 at 15:58, Rob Landley wrote: > On Tuesday 30 May 2006 10:54 am, Ken McGuire wrote: > > Hi Rob, > > > > Grepping for BLKGETSIZE64 in the busybox source, it seems to be defined in > > several places, but not in hdparm.c. Grepping more generally it is defined > > in linux kernel headers in linux/fs.h in both 2.4 & 2.6. > > It seems like you've enabled large file support in busybox, but your libc > doesn't have it. (I'm guessing you're using uClibc and you've disabled large > file support?) > I'm only using uClibc for actual embedded stuff, in this case I'm just building in/for the native x86 environment, using the libc that comes with this old knoppix 3.3 system. I normally have it on in both places for embedded builds. The defconfig for busybox has large file support enabled, how might I check whether my libc has it enabled? /me compiles again... hmmm.. If I turn it off large file support in busybox I get the same error. (make clean busybox) Maybe there is more to this than meets the eye... > Possibly what we should do now that we've got platform.h is just detect > whether or not it's there and enable the CONFIG option behind the scenes. > (Then if you disable long file support in uClibc, busybox builds without it > but otherwise uses it...) > > > 2) on ppc (ubuntu 5.10) with gcc 4.0.2 > > > > "make clean defconfig busybox" > > > > builds without errors and the applets run, but hdparm produces incorrect > > results. > > Joy. > > > Firmware Revision: ADOC7AA6 > > Firmware Revision: DACOA76A > > Sigh, the classic nuxi problem. > > http://www.catb.org/jargon/html/N/NUXI-problem.html > > I'll take a look this evening... > Thanks... > > Looking at the Model & Serial # fields, I'd bet this is an endian > > Yup. Should be easy enough to fix, though... > > Rob > -- > Never bet against the cheap plastic solution. > ...ken... From sjackman at gmail.com Fri Jun 2 11:16:42 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Fri Jun 2 11:16:46 2006 Subject: [PATCH] rdate: bug fix (svn 11946) In-Reply-To: <7f45d9390605251040j1f771008g6719916ac3f08aeb@mail.gmail.com> References: <7f45d9390605251040j1f771008g6719916ac3f08aeb@mail.gmail.com> Message-ID: <7f45d9390606021116x7dc17b18i8f1c6b69b87149f3@mail.gmail.com> Please apply. This is a rather straight-forward bug and fix. Cheers, Shaun On 5/25/06, Shaun Jackman wrote: > A bug introduced in svn 11946 broke rdate. It no longer sets the > current system time when no options are specified. The options have > the opposite sense from what one might think, and, oddly enough, -ps > is intentionally a no-op. > > Quoth rdate(8) from the BSD System Manager's Manual: > > -p Do not set, just print the remote time > -s Do not print the time. > > Cheers, > Shaun > > 2006-05-25 Shaun Jackman > > * util-linux/rdate.c (rdate_main): Buf fix. No options should set > the current system time. > > # > # old_revision [0ebbc658c9951d7f719a4d50b757b9553ee767c7] > # > # patch "util-linux/rdate.c" > # from [555cb3960a83e6b9f7545b66399cc2a604529202] > # to [6087a3a4119be0a2249351ca73f68e6d09cb9dcf] > # > ============================================================ > --- util-linux/rdate.c 555cb3960a83e6b9f7545b66399cc2a604529202 > +++ util-linux/rdate.c 6087a3a4119be0a2249351ca73f68e6d09cb9dcf > @@ -69,7 +69,7 @@ > > remote_time = askremotedate(argv[optind]); > > - if (flags & 1) { > + if ((flags & 2) == 0) { > time_t current_time; > > time(¤t_time); > @@ -78,10 +78,10 @@ > else > if (stime(&remote_time) < 0) > bb_perror_msg_and_die("Could not set time of day"); > + } > > - /* No need to check for the -p flag as it's the only option left */ > + if ((flags & 1) == 0) > + printf("%s", ctime(&remote_time)); > > - } else printf("%s", ctime(&remote_time)); > - > return EXIT_SUCCESS; > } > > > -------------- next part -------------- 2006-05-25 Shaun Jackman * util-linux/rdate.c (rdate_main): Buf fix. No options should set the current system time. # # old_revision [0ebbc658c9951d7f719a4d50b757b9553ee767c7] # # patch "util-linux/rdate.c" # from [555cb3960a83e6b9f7545b66399cc2a604529202] # to [6087a3a4119be0a2249351ca73f68e6d09cb9dcf] # ============================================================ --- util-linux/rdate.c 555cb3960a83e6b9f7545b66399cc2a604529202 +++ util-linux/rdate.c 6087a3a4119be0a2249351ca73f68e6d09cb9dcf @@ -69,7 +69,7 @@ remote_time = askremotedate(argv[optind]); - if (flags & 1) { + if ((flags & 2) == 0) { time_t current_time; time(¤t_time); @@ -78,10 +78,10 @@ else if (stime(&remote_time) < 0) bb_perror_msg_and_die("Could not set time of day"); + } - /* No need to check for the -p flag as it's the only option left */ + if ((flags & 1) == 0) + printf("%s", ctime(&remote_time)); - } else printf("%s", ctime(&remote_time)); - return EXIT_SUCCESS; } From rep.nop at aon.at Fri Jun 2 12:14:15 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Fri Jun 2 12:14:27 2006 Subject: The getopt long thing breaks the tree. In-Reply-To: <200606021154.09335.rob@landley.net> References: <200605301255.38248.rob@landley.net> <200605312325.00300.rob@landley.net> <20060601043938.GT32494@brightrain.aerifal.cx> <200606021154.09335.rob@landley.net> Message-ID: <20060602191415.GS20193@aon.at> On Fri, Jun 02, 2006 at 11:54:08AM -0400, Rob Landley wrote: >On Thursday 01 June 2006 12:39 am, Rich Felker wrote: >> On Wed, May 31, 2006 at 11:24:59PM -0400, Rob Landley wrote: >> > On Wednesday 31 May 2006 9:40 pm, Rich Felker wrote: >> > > On Wed, May 31, 2006 at 05:27:58PM -0400, Rob Landley wrote: >> > > > > What i, personally, care about is standard compliance; There simply >> > > > > is no such thing like getopt_long nor "struct option". See >> > > > > http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html >> > > > >> > > > There's no such thing as mount in the darn standard either. You >> > > > should stop using it immediately. >> > > >> > > The standard omits mount for a very good reason: not that it should >> > > not exist, but that specifying such low-level, administrator-specific >> > > things is not the job of the standard but of the particular >> > > implementation. >> > >> > It is not a complete spec, and it doesn't say we can't rely on things >> > that aren't in the spec. >> >> It doesn't say you can't, but it says that programs that do are not >> strictly conforming applications. Whether you care or not... > >"Don't care" implies a mere lack of caring, where what I actually have is a >noticeable amount of negative caring here. I care in the opposite direction. > >Busybox is not and has never has been a "strictly conforming" application in >that since. We don't even plan to _provide_ a strictly conforming >environment since we're not doing the internationalization stuff, so just >about every applet has a set of environment variables we're supposed to care >about, but don't. > >However, we plan to provide, as one of the configuration options, a reasonably >accurate SUSv3 environment with only documented deviations. This doesn't >mean we'll run in one, it means our apps behave according to the descriptions >in the spec, with specific exceptions such as no internationalization >support. > >Don't confuse the two. > >> > There's a difference between the environment we _provide_ and the >> > environments in which we _build_ and _run_. Pointing to the spec for the >> > environment we provide, I'll look at. Pointing to the spec about the >> > environment in which we build and run is something about which I >> > _DO_NOT_CARE_. >> >> .. I think we see. :) > >A) If you ignore what I say long enough, I'll start ignoring what _you_ say by >putting you on my spam filter. > >B) You are aware that if I'm pushed enough, I'll delete platform.h and make >_sure_ the project is Linux-only? I don't want to do that and I think that >would upset Bernhard, but if it persistently becomes more trouble than it's >worth and attracts idiots who don't take a hint when it's delivered with a >hammer to the cranium, I have _mountains_ of escalation I can do here. > >> > The environment in which we build and run is Linux. >> >> Linux is not a single environment, it's a kernel. > >Says Richard Stallman. He is wrong. There's a standard collection of >packages supported by Red Hat, SuSE, Debian, Gentoo, Slackware, Knoppix, >Ubuntu, Yellow Dog, and tons of other distros. The common collection of >applications that build and run on all of them is building on the Linux >platform. > >Richard's still upset because the GNU project died around 1988 when it >abandoned its monolithic kernel design for a microkernel design it couldn't >implement. He can't let go. Linux was the successor to a bunch of stalled >or blocked efforts (the GNU project, comp.os.minix, the berkeley CSRG), some >of which later revived (Minix had a GPL release, several other follow-ups of >the Berkeley CSRG are still viable or even successful, in the case of MacOS >X). > >Linux inherited developers and technology from many sources, but it's its own >project. The only GNU/Linux distribution is Debian because Debian was taken >over by the FSF fairly early on and was the official FSF distribution of >Linux until Debian forked away from the FSF very early because nobody can get >along with Richard for long. > >If you care: http://www.faifzilla.org/ch10.html > >Which is less than half of the story, by the way. (Follow libc5 to libc6, >Werner Almsberger is a Cygnus guy who can't stand Richard Stallman. The FSF >annointed a Linux project as successor and handed over the name because the >corresponding GNU project was _dead_. Just like they did when egcs became >gcc 2.95, because the fsf-developed gcc was so dead it was starting to >_smell_ so they handed over maintainership to the fork everybody was using.) > >Busybox 1.00 was a piece of Linux software. It was built on gcc 2.95 or >greater, with glibc 2.1 or uClibc 0.9.26 or greater under GNU Make 3.79.1 and >the 2.2 or newer Linux kernel. That's historical fact, that's what it >NEEDED. Since then we've moved towards C99 but are still GCC-centric (3.2 >now), and our C libraries are expected to be newer (glibc 2.2 or uClibc >0.9.27), and linux-2.4, and there's a push to require Make 3.80 that I'm >still resisting but it's only a matter of time. > >And you'll notice, ever single release since 1.00 has been put together by me. >I didn't become maintainer because Erik suddenly decided I should be >maintainer. I'd been acting as maintainer for most of a year already, and I >_did_ make some of the earlier decisions about portability since Erik wasn't >around to do so. > >Shaun Jackman was the first person I was aware of to start poking non-Linux >changes into the tree (newlib with libgloss). I've been making noises about >better mmu-less support for a while, and slowly working on it. There's been >a BSD support patch in bugs.busybox.net (netbsd?) for over a year that I've >totally ignored because it was too intrusive. > >Trying to clean that up into a policy, I introduced platform.h and said it >would be a good idea to run on things like MacOS X if it's easy to do so and >we can hide the changes to things like platform.h. I have no problem with >running on Digital Unix or Cygwin either. But NOT if it hurts our ability to >run on Linux in the slightest. It doesn't hurt our ability to run on linux. It just provides means to deactivate stuff that may not (resp. is not in some cases) there, so busybox can be built and run on non-linux hosts. > >But you don't attack the standard Linux environment as stupid and that we >should PORT busybox to MacOS X and rebase with that as our new standard >platform. That's where it ENDS. Busybox is first and foremost a Linux >project, and it always will be. We don't stop using glibc extensions just >because they're glibc extensions. That is not a reason. If your platform >hasn't got dprintf(), IMPLEMENT IT. I put in the platform.h define because I >know there's a name conflict, fine. > >The current discussion never went through the stage "Since busybox uses >getopt_long(), should we implement getopt_long() on non-linux platforms that >want to run busybox?" It never even came up. And that's wrong. To be fair, it came up (on irc, fwiw). > >The suggestion that we can make busybox smaller by making getopt_ulflags() >implement its own getopt behavior is a good one. It can make busybox smaller >ON_LINUX, and it avoids side effects like argument reordering that are bad >ON_LINUX. And that's a convincing argument. > >Reducing the requirements of other platforms to implement Linux APIs if they >want to run busybox is a fringe benefit. Nothing more. > >> The environment >> you're talking about is GNU/Linux, > >No, it's Linux. If I build a system with uClibc, BusyBox, dropbear, X.org, >and the Linux kernel, it hasn't got a single GNU package in the final >deployed system. How can that possibly be GNU/Linux? > >I may have used GNU tools to build it (unless I grab icc or some such), but >that's like saying the Windows version of The Gimp is a microsoft product >because it was built with Visual C. Watcom didn't own OS/2 for the Power PC >either. > >> which I don't have any interest in >> running anymore due to getting thoroughly sick of it after many years >> of dealing with all the hacks and bloat. > >I'm trying to come up with better replacements for portions of it too. > >This trend is normal. When the mainline gets bloated enough, a slimmed-down >fork emerges. Dropbear vs openssh. Galeon vs Mozilla (and Firefox vs >Galeon, and it's still kinda bloated.) xfce fs kde/gnome. uClibc vs glibc, >and BusyBox vs most of the GNU tools. Yes. So how is providong means to ignore non-standard extensions which make busybox (as a binary) bigger a bad thing? That's really all what the getopt_long thing did. Nothing fancy, nothing intrusive. > >Sometimes the forks are internal, such as the modular x.org rewrite (based on >what was "tinyx"), or matt mackall's -tiny work going into the Linux kernel. >That's one of the advantages of a modular design, you can replace a component >with a better implementation. > >> > There are specs out there that say what >> > a Linux environment should look like. The Linux Standard Base is one of >> > them. >> >> The LSB is among the most idiotic "specs" I've ever read. > >Didn't say it was a good spec. :) > >> It's a waste >> of hundreds of pages saying essentially "you must have an ABI >> identical to glibc's". > >Ok, the spec there then is the glibc documentation. *shrug*. > >> Any spec (such as LSB or SVID) that includes >> ABI is inherently stupid (from my point of view in case that wasn't >> clear) since ABI is obviously an implementation issue and not >> something that needs to be standardized. > >So TCP specifying what the on-the-wire protocol should look like (it's binary) >was a bad thing? Linux still runs (statically linked) binaries that ran >under 0.01. They disagree with you. > >> Moreover if that's not enough LSB actually contradicts POSIX/SUSv3 >> intentionally due to bugs in Linux. It changes the rules so that the >> buggy Linux behavior is not considered buggy. :) Unfortunately this >> actually prevents the bugs in Linux from being fixed. :( > >"The nice thing about standards is that there are so many to choose from." - >Andrew S. Tanenbaum, many years ago... > >My lack of caring is deep and profound. I'm not a fan of the LSB. There are >multiple conflicting standards. Wheee. The application section of SUSv3 is >incomplete, but vaguely sane. (Only vaguely: We're not implementing sccs.) >And thus is the frame of reference from which we can document how we diverge >when we get around to auditing things. I was under the impression that SUSv3 also implied that we should try to provide a working, minimal set that only uses SUSv3. More fancy features building ontop of eventual extensions should be optional -- configurable. Apparently this is not the case, do i understand you correctly? >> > Working around specific deficiencies in the Linux emulation of other >> > platforms are just that: workarounds. >> >> Other platforms have no reason to emulate "Linux" (GNU/Linux). Doing >> so will make them necessarily bloated and bogged down by legacy crap. > >I have no reason to care about those other platforms that are neither Linux >nor remotely compatible with it. Well, in case of getopt, one platform adhered to SUSv3, so according to the probably wrong assumption that we aimed for SUSv3 as the (minimum) base, i thought that it would be good to be able to *run* busybox on platforms that adhere to SUSv3. That may not have been a valid assumption, though.. > >> > You're bitching about an upstream spec that >> > doesn't specify _init_, so by itself it won't even _boot_. >> >> It doesn't specify init because programs running on the system have no >> use in knowing what init is or whether it even exists. > >I know WHY the specs are incomplete. But the fact remains that no >specification perfectly matches the real world on any system that isn't a toy >in a laboratory or some overbred ISO9002 piece of crap along the lines of [snip rest of interresting discussion] From rob at landley.net Fri Jun 2 14:30:56 2006 From: rob at landley.net (Rob Landley) Date: Fri Jun 2 14:31:04 2006 Subject: [PATCH] check NM environment variable in depmod.pl In-Reply-To: <20060601.154438.30439943.nemoto@toshiba-tops.co.jp> References: <20060601.154438.30439943.nemoto@toshiba-tops.co.jp> Message-ID: <200606021730.56951.rob@landley.net> On Thursday 01 June 2006 2:44 am, Atsushi Nemoto wrote: > This patch make depmod.pl more robust in cross environment. If native > nm did not recognize target's object, you can override it with NM > environment variable. Applied. Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Fri Jun 2 16:31:00 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Fri Jun 2 16:31:09 2006 Subject: [PATCH] Revert __getopt_initialized hackery Message-ID: <7f45d9390606021631y11cebccfm11a3c70334f3df2a@mail.gmail.com> Please revert my patch that added the __getopt_initialized hackery to lash for newlib. Newlib is now using a different getopt implementation that no longer requires this hack. Thanks, Shaun 2006-06-02 Shaun Jackman * shell/lash.c (pseudo_exec) [_NEWLIB_VERSION]: Remove the __getopt_initialized hackery. --- shell/lash.c cecf69fba78e83f9fcd16423d1f982a684bf5b53 +++ shell/lash.c a9a72989d31101bcfc710fc0651b4e03269f7606 @@ -1268,12 +1268,6 @@ { char** argv_l=child->argv; int argc_l; -#ifdef _NEWLIB_VERSION - /* newlib uses __getopt_initialized for getopt() in - * addition to optind, see newlib/libc/sys/linux/getopt.c - */ - extern int __getopt_initialized = 0; -#endif for(argc_l=0;*argv_l!=NULL; argv_l++, argc_l++); optind = 1; run_applet_by_name(name, argc_l, child->argv); -------------- next part -------------- 2006-06-02 Shaun Jackman * shell/lash.c (pseudo_exec) [_NEWLIB_VERSION]: Remove the __getopt_initialized hackery. --- shell/lash.c cecf69fba78e83f9fcd16423d1f982a684bf5b53 +++ shell/lash.c a9a72989d31101bcfc710fc0651b4e03269f7606 @@ -1268,12 +1268,6 @@ { char** argv_l=child->argv; int argc_l; -#ifdef _NEWLIB_VERSION - /* newlib uses __getopt_initialized for getopt() in - * addition to optind, see newlib/libc/sys/linux/getopt.c - */ - extern int __getopt_initialized = 0; -#endif for(argc_l=0;*argv_l!=NULL; argv_l++, argc_l++); optind = 1; run_applet_by_name(name, argc_l, child->argv); From rep.nop at aon.at Sat Jun 3 03:24:34 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 03:24:41 2006 Subject: [PATCH] rdate: bug fix (svn 11946) In-Reply-To: <7f45d9390606021116x7dc17b18i8f1c6b69b87149f3@mail.gmail.com> References: <7f45d9390605251040j1f771008g6719916ac3f08aeb@mail.gmail.com> <7f45d9390606021116x7dc17b18i8f1c6b69b87149f3@mail.gmail.com> Message-ID: <20060603102434.GU20193@aon.at> On Fri, Jun 02, 2006 at 12:16:42PM -0600, Shaun Jackman wrote: >Please apply. This is a rather straight-forward bug and fix. Applied. From rep.nop at aon.at Sat Jun 3 03:28:44 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 03:28:50 2006 Subject: [PATCH] Revert __getopt_initialized hackery In-Reply-To: <7f45d9390606021631y11cebccfm11a3c70334f3df2a@mail.gmail.com> References: <7f45d9390606021631y11cebccfm11a3c70334f3df2a@mail.gmail.com> Message-ID: <20060603102844.GV20193@aon.at> On Fri, Jun 02, 2006 at 05:31:00PM -0600, Shaun Jackman wrote: >Please revert my patch that added the __getopt_initialized hackery to >lash for newlib. Newlib is now using a different getopt implementation >that no longer requires this hack. Applied. From yann.morin.1998 at anciens.enib.fr Sat Jun 3 04:48:32 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sat Jun 3 04:48:41 2006 Subject: [BusyBox 0000889]: modprobe won't use ' * ' symbols modules.alias In-Reply-To: <200605312131.11080.rob@landley.net> References: <200605312228.31855.yann.morin.1998@anciens.enib.fr> <200605312131.11080.rob@landley.net> Message-ID: <200606031348.33042.yann.morin.1998@anciens.enib.fr> On Thursday 01 June 2006 033, Rob Landley wrote: > Probably the easiest way to do this would be to modify the alias into a regex, > and the run the regex? Or use fnmatch(3)? That's what mainstream module-init-tools use. I've changed modprobe to use that and am testing it right now. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? From rep.nop at aon.at Sat Jun 3 04:56:38 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 04:56:46 2006 Subject: [PATCH] inet_common.c: use portable inet_pton instead of _aton In-Reply-To: <20060519025009.GA27746@brightrain.aerifal.cx> References: <20060519025009.GA27746@brightrain.aerifal.cx> Message-ID: <20060603115638.GX20193@aon.at> On Thu, May 18, 2006 at 10:50:09PM -0400, Rich Felker wrote: >compile error on my system. this could be handled with a macro but i >don't think it's worth the trouble.. What about the rest? To me it looks like a macro or a platform-specific internal helper would be ok libbb/inet_common.c:41: if (inet_aton(name, &s_in->sin_addr)) { networking/inetd.c:800: else if (!inet_aton (nsep->se_hostaddr, &nsep->se_ctrladdr_in.sin_addr)) { networking/udhcp/files.c:36: if (!inet_aton(line, addr)) { networking/ipcalc.c:142: ipaddr = inet_aton(ipstr, &a); networking/ipcalc.c:156: netmask = inet_aton(argv[1], &a); networking/arping.c:341: if (!inet_aton(target, &dst)) { networking/arping.c:351: if (source && !inet_aton(source, &src)) { networking/zcip.c:272: if (inet_aton(optarg, &ip) == 0 networking/ifconfig.c:438: } else if (inet_aton(host, &sai.sin_addr) == 0) { networking/nslookup.c:148: if(inet_aton(server,&server_in_addr)) networking/telnetd.c:421: if (inet_aton(optarg, &bind_addr) == 0) networking/dnsd.c:209: if (!inet_aton(iface_addr, &a.sin_addr)) networking/dnsd.c:317: if (!inet_aton((char*)answstr, &a)) {//dotted dec to long conv util-linux/nfsmount.c:200:#define HAVE_inet_aton util-linux/nfsmount.c:389:#ifdef HAVE_inet_aton util-linux/nfsmount.c:390: if (!inet_aton(hostname, &server_addr.sin_addr)) > >rich > >Index: libbb/inet_common.c >=================================================================== >--- libbb/inet_common.c (revision 15108) >+++ libbb/inet_common.c (working copy) >@@ -38,7 +38,7 @@ > return (1); > } > /* Look to see if it's a dotted quad. */ >- if (inet_aton(name, &s_in->sin_addr)) { >+ if (inet_pton(AF_INET, name, &s_in->sin_addr) > 0) { > return 0; > } > /* If we expect this to be a hostname, try hostname database first */ >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox From rep.nop at aon.at Sat Jun 3 05:03:52 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 05:03:57 2006 Subject: [PATCH] wget.c: don't rely on gnu macro timersub In-Reply-To: <20060519022510.GA26839@brightrain.aerifal.cx> References: <20060519022510.GA26839@brightrain.aerifal.cx> Message-ID: <20060603120352.GY20193@aon.at> On Thu, May 18, 2006 at 10:25:10PM -0400, Rich Felker wrote: >this patch should also shave a few bytes.. 895238 11320 646180 1552738 17b162 busybox.old-3.3.20060603-1347 895238 11320 646180 1552738 17b162 busybox.new-3.3.20060603-1347 842162 10244 645924 1498330 16dcda busybox.old-4.1.20060603-1347 842242 10244 645924 1498410 16dd2a busybox.new-4.1.20060603-1347 $ scripts/bloat-o-meter busybox_unstripped.old-4.1.20060603-1347 busybox_unstripped.new-4.1.20060603-1347 function old new delta timersub - 43 +43 progressmeter 1132 1166 +34 ------------------------------------------------------------------------------ (add/remove: 1/0 grow/shrink: 1/0 up/down: 77/0) Total: 77 bytes So i don't like it too much :) > >rich > >Index: networking/wget.c >=================================================================== >--- networking/wget.c (revision 15108) >+++ networking/wget.c (working copy) >@@ -717,6 +718,16 @@ > setitimer(ITIMER_REAL, &itv, NULL); > } > >+#undef timersub >+void timersub(struct timeval *a, struct timeval *b, struct timeval *result) >+{ >+ result->tv_sec = a->tv_sec - b->tv_sec; >+ result->tv_usec = a->tv_usec - b->tv_usec; >+ if (result->tv_usec < 0) { >+ result->tv_sec--; >+ result->tv_usec += 1000000; >+ } >+} > > static void > progressmeter(int flag) >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox From yann.morin.1998 at anciens.enib.fr Sat Jun 3 05:12:31 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sat Jun 3 05:12:36 2006 Subject: [PATCH] modprobe does not resolv shell patterns in aliases Message-ID: <200606031412.31148.yann.morin.1998@anciens.enib.fr> Hello all! This patch makes modprobe understand shell patterns (especially '*') in module aliases, such as: "alias usb:v0582p0075d*dc*dsc*dp*ic*isc*ip* snd_usb_audio" This shall fix issue http://busybox.net/bugs/view.php?id=889 Result of make bloatcheck: function old new delta static.check_dep 402 413 +11 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/0 up/down: 11/0) Total: 11 bytes Regards, Yann E. MORIN. PS: Bernhard, 64 bytes were enough in the end! ;-) -- .-----------------.--------------------.------------------.--------------------. | 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. | ?---------------------?----------------?------------------?--------------------? -------------- next part -------------- A non-text attachment was scrubbed... Name: 004-modprobe_star_alias.patch Type: text/x-diff Size: 1051 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060603/85f75ec7/004-modprobe_star_alias.bin From sjackman at gmail.com Sat Jun 3 08:12:29 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sat Jun 3 08:12:39 2006 Subject: [PATCH] rdate: bug fix (svn 11946) In-Reply-To: <20060603102434.GU20193@aon.at> References: <7f45d9390605251040j1f771008g6719916ac3f08aeb@mail.gmail.com> <7f45d9390606021116x7dc17b18i8f1c6b69b87149f3@mail.gmail.com> <20060603102434.GU20193@aon.at> Message-ID: <7f45d9390606030812x3b175705r38c34ed53976c850@mail.gmail.com> On 6/3/06, Bernhard Fischer wrote: > On Fri, Jun 02, 2006 at 12:16:42PM -0600, Shaun Jackman wrote: > >Please apply. This is a rather straight-forward bug and fix. > > Applied. Thanks, Bernhard. Cheers, Shaun From sjackman at gmail.com Sat Jun 3 11:25:36 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sat Jun 3 11:25:43 2006 Subject: [PATCH] Include netinet/in.h in libbb.h Message-ID: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> On 7/25/05, Rob Landley wrote: ... > But applied anyway... > > Rob This patch was never applied; please apply it now. libbb.h uses struct sockaddr_in which is defined in netinet/in.h but never included. Cheers, Shaun 2005-04-05 Shaun Jackman * include/libbb.h: Include netinet/in.h for struct sockaddr_in. Index: include/libbb.h =================================================================== --- include/libbb.h (revision 15270) +++ include/libbb.h (working copy) @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include =================================================================== CC applets/applets.o In file included from /home/sjackman/work/pathway/busybox/busybox-vfork/include/busybox.h:12, from /home/sjackman/work/pathway/busybox/busybox-vfork/applets/applets.c:15: /home/sjackman/work/pathway/busybox/busybox-vfork/include/libbb.h:312: warning:'struct sockaddr_in' declared inside parameter list /home/sjackman/work/pathway/busybox/busybox-vfork/include/libbb.h:312: warning:its scope is only this definition or declaration, which is probably not what you want /home/sjackman/work/pathway/busybox/busybox-vfork/include/libbb.h:314: warning:'struct sockaddr_in' declared inside parameter list -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-netinet-in.h Type: text/x-chdr Size: 447 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060603/074dbc58/busybox-netinet-in.h From sjackman at gmail.com Sat Jun 3 11:27:28 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sat Jun 3 11:27:33 2006 Subject: [PATCH] LDFLAGS configuration Message-ID: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> This patch adds LDFLAGS and LIBRARIES configuration options to complement the CFLAGS that already exists. Please apply. Cheers, Shaun 2006-06-03 Shaun Jackman * Config.in (LDFLAGS_OPTIONS, LIBRARIES_OPTIONS): New configuration options. * Rules.mak (LDFLAGS, LIBRARIES): Pull these values from the configuration. ============================================================ --- Config.in 279307d739f02a96ab25828c9363fd1a1a001333 +++ Config.in 06f85550d97096634c842cad5e670753d42cfbf8 @@ -303,6 +303,18 @@ if you want to add some simple compiler switches (like -march=i686), or check for warnings using -Werror, just those options here. +config LDFLAGS_OPTIONS + string "Any LDFLAGS options for the linker?" + default "" + help + Use this option to pass LDFLAGS options, such as -L, to the linker. + +config LIBRARIES_OPTIONS + string "Any LIBRARIES options for the linker?" + default "" + help + Use this option to pass LIBRARIES options, such as -l, to the linker. + config CONFIG_BUILD_AT_ONCE bool "Compile all sources at once" default n ============================================================ --- Rules.mak fd8ab5152aaf143bfc13accfaf6aacb22ec73c57 +++ Rules.mak b184c3f243bb9b10e6369b6be1bed0ad71f86d0d @@ -56,6 +56,8 @@ # especially from the command line, use this instead of CFLAGS directly. # For optimization overrides, it's better still to set OPTIMIZATION. CFLAGS_EXTRA=$(subst ",, $(strip $(EXTRA_CFLAGS_OPTIONS))) +LDFLAGS=$(subst ",, $(strip $(LDFLAGS_OPTIONS))) +LIBRARIES=$(subst ",, $(strip $(LIBRARIES_OPTIONS))) # To compile vs some other alternative libc, you may need to use/adjust # the following lines to meet your needs... -------------- next part -------------- 2006-06-03 Shaun Jackman * Config.in (LDFLAGS_OPTIONS, LIBRARIES_OPTIONS): New configuration options. * Rules.mak (LDFLAGS, LIBRARIES): Pull these values from the configuration. ============================================================ --- Config.in 279307d739f02a96ab25828c9363fd1a1a001333 +++ Config.in 06f85550d97096634c842cad5e670753d42cfbf8 @@ -303,6 +303,18 @@ if you want to add some simple compiler switches (like -march=i686), or check for warnings using -Werror, just those options here. +config LDFLAGS_OPTIONS + string "Any LDFLAGS options for the linker?" + default "" + help + Use this option to pass LDFLAGS options, such as -L, to the linker. + +config LIBRARIES_OPTIONS + string "Any LIBRARIES options for the linker?" + default "" + help + Use this option to pass LIBRARIES options, such as -l, to the linker. + config CONFIG_BUILD_AT_ONCE bool "Compile all sources at once" default n ============================================================ --- Rules.mak fd8ab5152aaf143bfc13accfaf6aacb22ec73c57 +++ Rules.mak b184c3f243bb9b10e6369b6be1bed0ad71f86d0d @@ -56,6 +56,8 @@ # especially from the command line, use this instead of CFLAGS directly. # For optimization overrides, it's better still to set OPTIMIZATION. CFLAGS_EXTRA=$(subst ",, $(strip $(EXTRA_CFLAGS_OPTIONS))) +LDFLAGS=$(subst ",, $(strip $(LDFLAGS_OPTIONS))) +LIBRARIES=$(subst ",, $(strip $(LIBRARIES_OPTIONS))) # To compile vs some other alternative libc, you may need to use/adjust # the following lines to meet your needs... From sjackman at gmail.com Sat Jun 3 11:39:56 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sat Jun 3 11:39:59 2006 Subject: [PATCH] shell/lash.c: set environment variable In-Reply-To: <200605261601.53063.rob@landley.net> References: <7f45d9390604211052v64dbb27aydd912021bc6ebb9c@mail.gmail.com> <200605261108.55703.rob@landley.net> <7f45d9390605260911w31991087h8f663ff1bdaf619d@mail.gmail.com> <200605261601.53063.rob@landley.net> Message-ID: <7f45d9390606031139g1bcc44daqc68a8483fefb5eff@mail.gmail.com> On 5/26/06, Rob Landley wrote: > On Friday 26 May 2006 12:11 pm, Shaun Jackman wrote: > > On 5/26/06, Rob Landley wrote: > > > I suppose in the short term I could always add this as a config option, > > > even though we're talking something like 35 bytes here... > > > > For the 35 bytes saved, I wouldn't bother with the config option. I > > don't know where exactly one places the cutoff, but for me it's > > somewhere above 35 bytes -- and for context, I'm on a 1 MB RAM & 2 MB > > flash system. > > I generally place it around 100 bytes myself, but lash is a special case. :) For the sake of argument -- and incidentally, furthering the acceptance of this patch -- let's set the lash limit at 42 bytes, leaving this patch a good 7 bytes to spare! Please apply. Many thanks! Shaun From rep.nop at aon.at Sat Jun 3 12:10:36 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 12:10:42 2006 Subject: [PATCH] modprobe does not resolv shell patterns in aliases In-Reply-To: <200606031412.31148.yann.morin.1998@anciens.enib.fr> References: <200606031412.31148.yann.morin.1998@anciens.enib.fr> Message-ID: <20060603191035.GZ20193@aon.at> On Sat, Jun 03, 2006 at 02:12:31PM +0200, Yann E. MORIN wrote: >Hello all! > >This patch makes modprobe understand shell patterns (especially '*') in module >aliases, such as: "alias usb:v0582p0075d*dc*dsc*dp*ic*isc*ip* snd_usb_audio" > >This shall fix issue http://busybox.net/bugs/view.php?id=889 > >Result of make bloatcheck: >function old new delta >static.check_dep 402 413 +11 >------------------------------------------------------------------------------ >(add/remove: 0/0 grow/shrink: 1/0 up/down: 11/0) Total: 11 bytes > >Regards, >Yann E. MORIN. > >PS: Bernhard, 64 bytes were enough in the end! ;-) :) Applied, thanks. From rep.nop at aon.at Sat Jun 3 12:13:05 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 12:13:09 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> Message-ID: <20060603191305.GA20193@aon.at> On Sat, Jun 03, 2006 at 12:27:28PM -0600, Shaun Jackman wrote: >This patch adds LDFLAGS and LIBRARIES configuration options to >complement the CFLAGS that already exists. Please apply. Doesn't saying make LDFLAGS="-Wl,--verbose -Wl,-n -Wl,-O1 -Wl,-t" work now even without this patch? From rep.nop at aon.at Sat Jun 3 12:18:35 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 12:18:40 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> Message-ID: <20060603191835.GB20193@aon.at> On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: >On 7/25/05, Rob Landley wrote: >... >>But applied anyway... >> >>Rob > >This patch was never applied; please apply it now. > >libbb.h uses struct sockaddr_in which is defined in netinet/in.h but >never included. This patch shouldn't be needed anymore since the order of includes were restructered recently. Applets have to include busybox.h as the first include, lib*/* has to include libbb.h as the first include. Applets and library functions MUST not include any header which is included by platform.h, busybox.h and platform.h, libbb.h respectively. See e.g. r15266 and r15267 from yesterday (and yes, there still are some directories which aren't yet converted. We'll get to them soon). Thanks for pointing this out anyway. cheers, Bernhard From sjackman at gmail.com Sat Jun 3 14:00:23 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Sat Jun 3 14:00:29 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <20060603191305.GA20193@aon.at> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <20060603191305.GA20193@aon.at> Message-ID: <7f45d9390606031400g5d6d36c5wf3f3474b84385295@mail.gmail.com> On 6/3/06, Bernhard Fischer wrote: > On Sat, Jun 03, 2006 at 12:27:28PM -0600, Shaun Jackman wrote: > >This patch adds LDFLAGS and LIBRARIES configuration options to > >complement the CFLAGS that already exists. Please apply. > > Doesn't saying make LDFLAGS="-Wl,--verbose -Wl,-n -Wl,-O1 -Wl,-t" > work now even without this patch? Yes, of course. The same can be said for EXTRA_CFLAGS. It's a pain to have to remember to pass the option to make every time make is run. A .config file is easier to keep in a version control system than options passed to make. Cheers, Shaun From rep.nop at aon.at Sat Jun 3 14:16:47 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 14:16:57 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060603191835.GB20193@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> Message-ID: <20060603211647.GC20193@aon.at> On Sat, Jun 03, 2006 at 09:18:35PM +0200, Bernhard Fischer wrote: >On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: >>On 7/25/05, Rob Landley wrote: >>... >>>But applied anyway... >>> >>>Rob >> >>This patch was never applied; please apply it now. >> >>libbb.h uses struct sockaddr_in which is defined in netinet/in.h but >>never included. > >This patch shouldn't be needed anymore since the order of includes were >restructered recently. Applets have to include busybox.h as the first >include, lib*/* has to include libbb.h as the first include. > >Applets and library functions MUST not include any header which is >included by platform.h, busybox.h and platform.h, libbb.h respectively. > >See e.g. r15266 and r15267 from yesterday (and yes, there still are some >directories which aren't yet converted. We'll get to them soon). Hm. We'll break dmalloc support with this header move, i think. #include should be after all other includes.. What should we do about this? I'd go for an #include "busybox_dmalloc.h" that basically reads #ifndef BUSYBOX_DMALLOC_H #define BUSYBOX_DMALLOC_H 1 #ifdef DMALLOC #include #endif #endif /* BUSYBOX_DMALLOC_H */ What do you think? From yann.morin.1998 at anciens.enib.fr Sat Jun 3 15:43:30 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sat Jun 3 15:43:40 2006 Subject: [BUG] hdparm & uClibc: BLKGETSIZE64 undeclared Message-ID: <200606040043.30547.yann.morin.1998@anciens.enib.fr> Hello all! Before I surrender to Morpheus, here is a nitpick in hdparm: /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c: In function `do_blkgetsize': /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: `BLKGETSIZE64' undeclared (first use in this function) /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: (Each undeclared identifier is reported only once /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: for each function it appears in.) Toolchain is: binutils-2.16.1 gcc-3.4.4 uClibc-0.9.28 linux-libc-headers-2.6.12.0 Target is armv5b-nslu2-linux-uclibc In glibc, BLKGETSIZE64 is defined in sys/mount.h In linux headers, it is defined in linux/fs.h In uClibc, it is not defined anywhere. In busybox, we do (re)define it in: e2fsprogs/blkid/blkid_getsize.c:48 e2fsprogs/ext2fs/getsize.c:47 util-linux/fdisk.c:55 What is the best solution here? Regards, and for those in the same area as me, good night, and sleep well! 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 rpjday at mindspring.com Sat Jun 3 15:46:06 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sat Jun 3 15:47:08 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060603191835.GB20193@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> Message-ID: On Sat, 3 Jun 2006, Bernhard Fischer wrote: > On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: > >On 7/25/05, Rob Landley wrote: > >... > >>But applied anyway... > >> > >>Rob > > > >This patch was never applied; please apply it now. > > > >libbb.h uses struct sockaddr_in which is defined in netinet/in.h but > >never included. > > This patch shouldn't be needed anymore since the order of includes > were restructered recently. Applets have to include busybox.h as the > first include, lib*/* has to include libbb.h as the first include. > > Applets and library functions MUST not include any header which is > included by platform.h, busybox.h and platform.h, libbb.h > respectively. all right, this is just plain creeping me out, when people start talking about a *required order* of header file inclusion. this is just plain not good. rday From rep.nop at aon.at Sat Jun 3 15:51:20 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 15:51:24 2006 Subject: [BUG] hdparm & uClibc: BLKGETSIZE64 undeclared In-Reply-To: <200606040043.30547.yann.morin.1998@anciens.enib.fr> References: <200606040043.30547.yann.morin.1998@anciens.enib.fr> Message-ID: <20060603225120.GE20193@aon.at> On Sun, Jun 04, 2006 at 12:43:30AM +0200, Yann E. MORIN wrote: >Hello all! > >Before I surrender to Morpheus, here is a nitpick in hdparm: > >/home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c: In function `do_blkgetsize': >/home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: `BLKGETSIZE64' undeclared (first use in this function) >/home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: (Each undeclared identifier is reported only once >/home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: for each function it appears in.) > >Toolchain is: >binutils-2.16.1 >gcc-3.4.4 >uClibc-0.9.28 >linux-libc-headers-2.6.12.0 > >Target is armv5b-nslu2-linux-uclibc > >In glibc, BLKGETSIZE64 is defined in sys/mount.h >In linux headers, it is defined in linux/fs.h >In uClibc, it is not defined anywhere. > >In busybox, we do (re)define it in: >e2fsprogs/blkid/blkid_getsize.c:48 >e2fsprogs/ext2fs/getsize.c:47 >util-linux/fdisk.c:55 > >What is the best solution here? I'd say that's a typical case for platform.h, either in the libc-checking section where you'd want to include sys/mount.h if you know that your libc provides it or in a __linux__ block where you copy the #define out of linux/fs.h. > >Regards, and for those in the same area as me, good night, and sleep well! Should do that too now. g'night all From rep.nop at aon.at Sat Jun 3 15:52:41 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Jun 3 15:52:44 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> Message-ID: <20060603225241.GF20193@aon.at> On Sat, Jun 03, 2006 at 06:46:06PM -0400, Robert P. J. Day wrote: >On Sat, 3 Jun 2006, Bernhard Fischer wrote: > >> On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: >> >On 7/25/05, Rob Landley wrote: >> >... >> >>But applied anyway... >> >> >> >>Rob >> > >> >This patch was never applied; please apply it now. >> > >> >libbb.h uses struct sockaddr_in which is defined in netinet/in.h but >> >never included. >> >> This patch shouldn't be needed anymore since the order of includes >> were restructered recently. Applets have to include busybox.h as the >> first include, lib*/* has to include libbb.h as the first include. >> >> Applets and library functions MUST not include any header which is >> included by platform.h, busybox.h and platform.h, libbb.h >> respectively. > >all right, this is just plain creeping me out, when people start >talking about a *required order* of header file inclusion. this is >just plain not good. go understand how some aspects of dmalloc work: http://www.dmalloc.com/ From dujinhui at gmail.com Sat Jun 3 23:46:14 2006 From: dujinhui at gmail.com (jackie) Date: Sat Jun 3 23:53:26 2006 Subject: init getty problem Message-ID: <29bf17cf0606032346tc2dc37esb75ade479bf3278b@mail.gmail.com> hi: all I am new here. I am trying to build linux in one floppy using Redhat 9.0 and Bochs 2.2. Busybox 1.1.3 is my choice for the cmd utilities. I use init, getty, login and shell in Busybox. There are some problems. After the system boots i see the login symbol and enter root then the password but it displays Login incorrect and some other information like this: mylinux login: root Password: Login incorrect mylinux login: Login timed out after 60 seconds. mylinux login: If i enter root but not the password then it will display "Login timed out after 60 seconds." only in ONE or TWO seconds. I just copy /etc/passwd /etc/shadow /etc/shadow- /etc/group in Redhat 9 to the floppy linux's file system . I modify the source code of Busybox and print the password before correct_password in login_main. It displays as this: pw_name UNKNOWN pw_passwd ! pw_uid 0 pw_gid 0 pw_gecos (null) pw_dir (null) pw_shell (null) And the file /etc/inittab is: #id:2:initdefault: ::sysinit:/etc/rc tty1::respawn:/sbin/getty 38400 tty1 tty2::respawn:/sbin/getty 38400 tty2 tty3::respawn:/sbin/getty 38400 tty3 If i don't use getty and invoke /bin/bash directly then it works. Do i lose somthing or have some file configured badly? I have "google"ed for a long time but get nothing valuable. Btw will tinylogin work ? Are Tinylogin utilities contained in Busybox? I see Tinylogin updates nothing after 2003. Some tutorial for how to use Busybox's init and getty to login linux system will be best. Any information or links will be great help. THKS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060604/ac175644/attachment.html From rpjday at mindspring.com Sun Jun 4 03:22:26 2006 From: rpjday at mindspring.com (Robert P. J. Day) Date: Sun Jun 4 03:23:47 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060603225241.GF20193@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> <20060603225241.GF20193@aon.at> Message-ID: On Sun, 4 Jun 2006, Bernhard Fischer wrote: > On Sat, Jun 03, 2006 at 06:46:06PM -0400, Robert P. J. Day wrote: > >On Sat, 3 Jun 2006, Bernhard Fischer wrote: > > > >> On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: > >> >On 7/25/05, Rob Landley wrote: > >> >... > >> >>But applied anyway... > >> >> > >> >>Rob > >> > > >> >This patch was never applied; please apply it now. > >> > > >> >libbb.h uses struct sockaddr_in which is defined in netinet/in.h but > >> >never included. > >> > >> This patch shouldn't be needed anymore since the order of includes > >> were restructered recently. Applets have to include busybox.h as the > >> first include, lib*/* has to include libbb.h as the first include. > >> > >> Applets and library functions MUST not include any header which is > >> included by platform.h, busybox.h and platform.h, libbb.h > >> respectively. > > > >all right, this is just plain creeping me out, when people start > >talking about a *required order* of header file inclusion. this is > >just plain not good. > > go understand how some aspects of dmalloc work: http://www.dmalloc.com/ i'm not sure i see your point. you're referring to a specific example of how an enhanced version of some functionality can be used in a program. *i'm* talking about the apparent need to enforce an ordering scheme on the all-encompassing header files being used for busybox overall. i don't think those two situations are comparable. rday From farmatito at tiscali.it Sun Jun 4 05:32:31 2006 From: farmatito at tiscali.it (Tito) Date: Sun Jun 4 05:32:59 2006 Subject: init getty problem In-Reply-To: <29bf17cf0606032346tc2dc37esb75ade479bf3278b@mail.gmail.com> References: <29bf17cf0606032346tc2dc37esb75ade479bf3278b@mail.gmail.com> Message-ID: <200606041432.31486.farmatito@tiscali.it> On Sunday 4 June 2006 08:46, jackie wrote: > hi: all > > I am new here. I am trying to build linux in one floppy using Redhat 9.0 and > Bochs 2.2. Busybox 1.1.3 is my choice for the cmd utilities. I use init, > getty, login and shell in Busybox. There are some problems. > After the system boots i see the login symbol and enter root then the > password but it displays Login incorrect and some other information like > this: > > mylinux login: root > Password: > Login incorrect > mylinux login: > Login timed out after 60 seconds. > mylinux login: > > > If i enter root but not the password then it will display "Login timed out > after 60 seconds." only in ONE or TWO seconds. > > I just copy /etc/passwd /etc/shadow /etc/shadow- /etc/group in Redhat 9 to > the floppy linux's file system . > > I modify the source code of Busybox and print the password before > correct_password in login_main. > > It displays as this: > > pw_name UNKNOWN > pw_passwd ! > pw_uid 0 > pw_gid 0 > pw_gecos (null) > pw_dir (null) > pw_shell (null) > > And the file /etc/inittab is: > > #id:2:initdefault: > ::sysinit:/etc/rc > tty1::respawn:/sbin/getty 38400 tty1 > tty2::respawn:/sbin/getty 38400 tty2 > tty3::respawn:/sbin/getty 38400 tty3 > > If i don't use getty and invoke /bin/bash directly then it works. > > Do i lose somthing or have some file configured badly? > > I have "google"ed for a long time but get nothing valuable. > > Btw will tinylogin work ? Are Tinylogin utilities contained in Busybox? I > see Tinylogin updates nothing after 2003. > > Some tutorial for how to use Busybox's init and getty to login linux system > will be best. > > Any information or links will be great help. > > THKS > Do you have /etc/nsswitch.conf and the required libnss*.so libraries? Ciao, Tito From yann.morin.1998 at anciens.enib.fr Sun Jun 4 05:55:12 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun Jun 4 05:55:18 2006 Subject: [PATCH] uClibc & BLKGETSIZE64 Message-ID: <200606041455.12235.yann.morin.1998@anciens.enib.fr> Hello all! The attached patch shall solve the following problem when compiling with hdparm enabled with a uClibc-based toolchain: /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c: In function `do_blkgetsize': /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: `BLKGETSIZE64' undeclared (first use in this function) /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: (Each undeclared identifier is reported only once /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: error: for each function it appears in.) The patch defines BLKGETSIZE64 conditionnaly to: - this is linux, - this is uClibc, - we do not have BLKGETSIZE64. I'm not quite sure this is the correct and complete fix, as e2fsprogs and fdisk do redefine it by themselves. They shall also be fixed to not do so, but should include platform.h instead. I'll leave to the respective maintainers to do that (I'm not really willing to dig in those two pieces of code). Also, future uClibc's might switch to defining this, but sys/mount.h has not changed for the last 4 years or so, which leads me to think it won't in the near future... Shall I ask there as well? Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? -------------- next part -------------- A non-text attachment was scrubbed... Name: 005-BLKGETSIZE64.patch Type: text/x-diff Size: 650 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060604/81fa7beb/005-BLKGETSIZE64.bin From rep.nop at aon.at Sun Jun 4 05:56:49 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jun 4 05:56:55 2006 Subject: init getty problem In-Reply-To: <200606041432.31486.farmatito@tiscali.it> References: <29bf17cf0606032346tc2dc37esb75ade479bf3278b@mail.gmail.com> <200606041432.31486.farmatito@tiscali.it> Message-ID: <20060604125648.GA8161@aon.at> On Sun, Jun 04, 2006 at 02:32:31PM +0200, Tito wrote: >On Sunday 4 June 2006 08:46, jackie wrote: >> hi: all >> >> I am new here. I am trying to build linux in one floppy using Redhat 9.0 and >> Bochs 2.2. Busybox 1.1.3 is my choice for the cmd utilities. I use init, >> getty, login and shell in Busybox. There are some problems. >> After the system boots i see the login symbol and enter root then the >> password but it displays Login incorrect and some other information like >> this: >> >> mylinux login: root >> Password: >> Login incorrect >> mylinux login: >> Login timed out after 60 seconds. >> mylinux login: >> >> >> If i enter root but not the password then it will display "Login timed out >> after 60 seconds." only in ONE or TWO seconds. >> >> I just copy /etc/passwd /etc/shadow /etc/shadow- /etc/group in Redhat 9 to >> the floppy linux's file system . >> >> I modify the source code of Busybox and print the password before >> correct_password in login_main. >> >> It displays as this: >> >> pw_name UNKNOWN >> pw_passwd ! >> pw_uid 0 >> pw_gid 0 >> pw_gecos (null) >> pw_dir (null) >> pw_shell (null) >> >> And the file /etc/inittab is: >> >> #id:2:initdefault: >> ::sysinit:/etc/rc >> tty1::respawn:/sbin/getty 38400 tty1 >> tty2::respawn:/sbin/getty 38400 tty2 >> tty3::respawn:/sbin/getty 38400 tty3 >> >> If i don't use getty and invoke /bin/bash directly then it works. >> >> Do i lose somthing or have some file configured badly? >> >> I have "google"ed for a long time but get nothing valuable. >> >> Btw will tinylogin work ? Are Tinylogin utilities contained in Busybox? I >> see Tinylogin updates nothing after 2003. >> >> Some tutorial for how to use Busybox's init and getty to login linux system >> will be best. >> >> Any information or links will be great help. >> >> THKS >> > >Do you have /etc/nsswitch.conf and the required libnss*.so libraries? Also make sure that you have shadow support enabled. The Tinylogin utilities are incooperated in busybox. The external project is no longer maintained (as far as i know). HTH From yann.morin.1998 at anciens.enib.fr Sun Jun 4 07:12:41 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun Jun 4 07:12:49 2006 Subject: [PATCH] cat's config options Message-ID: <200606041612.41146.yann.morin.1998@anciens.enib.fr> Hello all! This patch moves cat-dependent -vetET options just below cat. This is purely cosmetics. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? -------------- next part -------------- A non-text attachment was scrubbed... Name: 006-cat_config.patch Type: text/x-diff Size: 866 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060604/86f44a22/006-cat_config.bin From rep.nop at aon.at Sun Jun 4 07:35:33 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jun 4 07:35:40 2006 Subject: [BusyBox 0000799]: start-stop-daemon does not support --oknodo option In-Reply-To: References: Message-ID: <20060604143533.GB8161@aon.at> If anyone here can give it a whirl, then i'd be glad. PS: attaching the very same diff for your convenience. PPS: anyone up to joining the bug-sqashing party? :) Thanks in advance for feedback and cheers, On Sun, Jun 04, 2006 at 07:32:03AM -0700, bugs@busybox.net wrote: > >The following issue requires your FEEDBACK. >====================================================================== >http://busybox.net/bugs/view.php?id=799 >====================================================================== >Reported By: themastermind1 >Assigned To: BusyBox >====================================================================== >Project: BusyBox >Issue ID: 799 >Category: New Features >Reproducibility: always >Severity: minor >Priority: normal >Status: feedback >====================================================================== >Date Submitted: 03-26-2006 13:32 PST >Last Modified: 06-04-2006 07:32 PDT >====================================================================== >Summary: start-stop-daemon does not support --oknodo option >Description: >Many init scripts use the following start-stop-daemon option: > > -o|--oknodo exit status 0 (not 1) if nothing done > >====================================================================== > >---------------------------------------------------------------------- > bernhardf - 06-04-06 07:32 >---------------------------------------------------------------------- >Can you please check if the attached patch works for you? > >Thanks in advance. > > text data bss dec hex filename > 2055 8 24 2087 827 start_stop_daemon.o.orig > 1927 8 24 1959 7a7 start_stop_daemon.o > > >Issue History >Date Modified Username Field Change >====================================================================== >03-26-06 13:32 themastermind1 New Issue >03-26-06 13:32 themastermind1 Status new => assigned >03-26-06 13:32 themastermind1 Assigned To => BusyBox >06-04-06 07:30 bernhardf File Added: busybox.ssd.00.diff > >06-04-06 07:32 bernhardf Note Added: 0001399 >06-04-06 07:32 bernhardf Status assigned => feedback >====================================================================== > >_______________________________________________ >busybox-cvs mailing list >busybox-cvs@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox-cvs > -------------- next part -------------- Index: debianutils/start_stop_daemon.c =================================================================== --- debianutils/start_stop_daemon.c (revision 15279) +++ debianutils/start_stop_daemon.c (working copy) @@ -22,7 +22,7 @@ static int signal_nr = 15; static int user_id = -1; -static int quiet = 0; +static int quiet; static char *userspec = NULL; static char *cmdname = NULL; static char *execname = NULL; @@ -35,8 +35,7 @@ struct pid_list { static struct pid_list *found = NULL; -static inline void -push(pid_t pid) +static inline void push(pid_t pid) { struct pid_list *p; @@ -46,8 +45,7 @@ push(pid_t pid) found = p; } -static int -pid_is_exec(pid_t pid, const char *name) +static int pid_is_exec(pid_t pid, const char *name) { char buf[32]; struct stat sb, exec_stat; @@ -61,8 +59,7 @@ pid_is_exec(pid_t pid, const char *name) return (sb.st_dev == exec_stat.st_dev && sb.st_ino == exec_stat.st_ino); } -static int -pid_is_user(int pid, int uid) +static int pid_is_user(int pid, int uid) { struct stat sb; char buf[32]; @@ -73,8 +70,7 @@ pid_is_user(int pid, int uid) return (sb.st_uid == uid); } -static int -pid_is_cmd(pid_t pid, const char *name) +static int pid_is_cmd(pid_t pid, const char *name) { char buf[32]; FILE *f; @@ -98,8 +94,7 @@ pid_is_cmd(pid_t pid, const char *name) } -static void -check(int pid) +static void check(int pid) { if (execname && !pid_is_exec(pid, execname)) { return; @@ -114,8 +109,7 @@ check(int pid) } -static void -do_pidfile(void) +static void do_pidfile(void) { FILE *f; pid_t pid; @@ -130,8 +124,7 @@ do_pidfile(void) } -static void -do_procinit(void) +static void do_procinit(void) { DIR *procdir; struct dirent *entry; @@ -157,17 +150,16 @@ do_procinit(void) } -static void -do_stop(void) +static int do_stop(void) { - char what[1024]; + RESERVE_CONFIG_BUFFER(what, 1024); struct pid_list *p; int killed = 0; do_procinit(); if (cmdname) - strcpy(what, cmdname); + what=cmdname;//strcpy(what, cmdname); else if (execname) strcpy(what, execname); else if (pidfile) @@ -180,7 +172,9 @@ do_stop(void) if (!found) { if (!quiet) printf("no %s found; none killed.\n", what); - return; + if (ENABLE_FEATURE_CLEAN_UP) + RELEASE_CONFIG_BUFFER(what); + return -1; } for (p = found; p; p = p->next) { if (kill(p->pid, signal_nr) == 0) { @@ -197,21 +191,31 @@ do_stop(void) printf(" %d", -p->pid); printf(").\n"); } + if (ENABLE_FEATURE_CLEAN_UP) + RELEASE_CONFIG_BUFFER(what); + return killed; } #if ENABLE_FEATURE_START_STOP_DAEMON_LONG_OPTIONS static const struct option ssd_long_options[] = { { "stop", 0, NULL, 'K' }, { "start", 0, NULL, 'S' }, - { "background", 0, NULL, 'b' }, + { "background", 0, NULL, 'b' }, { "quiet", 0, NULL, 'q' }, - { "make-pidfile", 0, NULL, 'm' }, - { "startas", 1, NULL, 'a' }, + { "make-pidfile", 0, NULL, 'm' }, +#if ENABLE_FEATURE_START_STOP_DAEMON_FANCY + { "oknodo", 0, NULL, 'o' }, + { "verbose", 0, NULL, 'v' }, +#endif + { "startas", 1, NULL, 'a' }, { "name", 1, NULL, 'n' }, { "signal", 1, NULL, 's' }, { "user", 1, NULL, 'u' }, { "exec", 1, NULL, 'x' }, - { "pidfile", 1, NULL, 'p' }, + { "pidfile", 1, NULL, 'p' }, +#if ENABLE_FEATURE_START_STOP_DAEMON_FANCY + { "retry", 1, NULL, 'R' }, +#endif { 0, 0, 0, 0 } }; #endif @@ -221,42 +225,48 @@ static const struct option ssd_long_opti #define SSD_OPT_BACKGROUND 4 #define SSD_OPT_QUIET 8 #define SSD_OPT_MAKEPID 16 +#if ENABLE_FEATURE_START_STOP_DAEMON_FANCY +#define SSD_OPT_OKNODO 32 +#define SSD_OPT_VERBOSE 64 -int -start_stop_daemon_main(int argc, char **argv) +#endif + +int start_stop_daemon_main(int argc, char **argv) { unsigned long opt; char *signame = NULL; char *startas = NULL; - +#if ENABLE_FEATURE_START_STOP_DAEMON_FANCY +// char *retry_arg = NULL; +// int retries = -1; +#endif #if ENABLE_FEATURE_START_STOP_DAEMON_LONG_OPTIONS bb_applet_long_options = ssd_long_options; #endif /* Check required one context option was given */ - bb_opt_complementally = "K:S:?:K--S:S--K"; - opt = bb_getopt_ulflags(argc, argv, "KSbqma:n:s:u:x:p:", - &startas, &cmdname, &signame, &userspec, &execname, &pidfile); - + bb_opt_complementally = "K:S:?:K--S:S--K:m?p:K?xpun:S?xa"; + opt = bb_getopt_ulflags(argc, argv, "KSbqm" +// USE_FEATURE_START_STOP_DAEMON_FANCY("ovR:") + USE_FEATURE_START_STOP_DAEMON_FANCY("ov") + "a:n:s:u:x:p:" +// USE_FEATURE_START_STOP_DAEMON_FANCY(,&retry_arg) + ,&startas, &cmdname, &signame, &userspec, &execname, &pidfile); - quiet = opt & SSD_OPT_QUIET; + quiet = (opt & SSD_OPT_QUIET) + USE_FEATURE_START_STOP_DAEMON_FANCY(&& !(opt & SSD_OPT_VERBOSE)); if (signame) { signal_nr = bb_xgetlarg(signame, 10, 0, NSIG); } - if (!execname && !pidfile && !userspec && !cmdname) - bb_error_msg_and_die ("need at least one of -x, -p, -u, or -n"); - if (!startas) startas = execname; - if ((opt & SSD_CTX_START) && !startas) - bb_error_msg_and_die ("-S needs -x or -a"); - - if ((opt & SSD_OPT_MAKEPID) && pidfile == NULL) - bb_error_msg_and_die ("-m needs -p"); - +// USE_FEATURE_START_STOP_DAEMON_FANCY( +// if (retry_arg) +// retries = bb_xgetlarg(retry_arg, 10, 0, INT_MAX); +// ) argc -= optind; argv += optind; @@ -264,8 +274,10 @@ start_stop_daemon_main(int argc, char ** user_id = bb_xgetpwnam(userspec); if (opt & SSD_CTX_STOP) { - do_stop(); - return EXIT_SUCCESS; + int i = do_stop(); + return + USE_FEATURE_START_STOP_DAEMON_FANCY((opt & SSD_OPT_OKNODO) + ? 0 :) !!(i<=0); } do_procinit(); @@ -273,7 +285,8 @@ start_stop_daemon_main(int argc, char ** if (found) { if (!quiet) printf("%s already running.\n%d\n", execname ,found->pid); - return EXIT_SUCCESS; + USE_FEATURE_START_STOP_DAEMON_FANCY(return !(opt & SSD_OPT_OKNODO);) + SKIP_FEATURE_START_STOP_DAEMON_FANCY(return EXIT_FAILURE;) } *--argv = startas; if (opt & SSD_OPT_BACKGROUND) { @@ -282,10 +295,9 @@ start_stop_daemon_main(int argc, char ** } if (opt & SSD_OPT_MAKEPID) { /* user wants _us_ to make the pidfile */ - FILE *pidf = fopen(pidfile, "w"); + FILE *pidf = bb_xfopen(pidfile, "w"); + pid_t pidt = getpid(); - if (pidf == NULL) - bb_perror_msg_and_die("Unable to write pidfile '%s'", pidfile); fprintf(pidf, "%d\n", pidt); fclose(pidf); } Index: debianutils/Config.in =================================================================== --- debianutils/Config.in (revision 15279) +++ debianutils/Config.in (working copy) @@ -61,6 +61,15 @@ config CONFIG_START_STOP_DAEMON termination of system-level processes, usually the ones started during the startup of the system. +config CONFIG_FEATURE_START_STOP_DAEMON_FANCY + bool "Support additional arguments" + default y + depends on CONFIG_START_STOP_DAEMON + help + Support additional arguments. + -o|--oknodo ignored since we exit with 0 anyway + -v|--verbose + config CONFIG_FEATURE_START_STOP_DAEMON_LONG_OPTIONS bool "Enable long options" default n Index: include/usage.h =================================================================== --- include/usage.h (revision 15279) +++ include/usage.h (working copy) @@ -2681,6 +2681,10 @@ USE_FEATURE_DATE_ISOFMT( \ "\n\t-n|--name \tstop processes with this name" \ "\n\t-p|--pidfile \t\tsave or load pid using a pid-file" \ "\n\t-q|--quiet\t\t\tbe quiet" \ +USE_FEATURE_START_STOP_DAEMON_FANCY( \ + "\n\t-o|--oknodo\t\t\texit status 0 if nothing done" \ + "\n\t-v|--verbose\t\t\tbe verbose" \ +) \ "\n\t-s|--signal \t\tsignal to send (default TERM)" #ifdef CONFIG_FEATURE_STAT_FORMAT From rep.nop at aon.at Sun Jun 4 07:50:28 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jun 4 07:50:35 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060603211647.GC20193@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> <20060603211647.GC20193@aon.at> Message-ID: <20060604145028.GC8161@aon.at> On Sat, Jun 03, 2006 at 11:16:47PM +0200, Bernhard Fischer wrote: >On Sat, Jun 03, 2006 at 09:18:35PM +0200, Bernhard Fischer wrote: >>On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: >>>On 7/25/05, Rob Landley wrote: >>>... >>>>But applied anyway... >>>> >>>>Rob >>> >>>This patch was never applied; please apply it now. >>> >>>libbb.h uses struct sockaddr_in which is defined in netinet/in.h but >>>never included. >> >>This patch shouldn't be needed anymore since the order of includes were >>restructered recently. Applets have to include busybox.h as the first >>include, lib*/* has to include libbb.h as the first include. >> >>Applets and library functions MUST not include any header which is >>included by platform.h, busybox.h and platform.h, libbb.h respectively. >> >>See e.g. r15266 and r15267 from yesterday (and yes, there still are some >>directories which aren't yet converted. We'll get to them soon). > >Hm. We'll break dmalloc support with this header move, i think. >#include should be after all other includes.. > >What should we do about this? I'd go for an >#include "busybox_dmalloc.h" >that basically reads >#ifndef BUSYBOX_DMALLOC_H >#define BUSYBOX_DMALLOC_H 1 >#ifdef DMALLOC >#include >#endif >#endif /* BUSYBOX_DMALLOC_H */ > >What do you think? Also, this would allow for providing size-optimized functions like proposed in patches/woot.txt, so i want to have such an #include. I don't care whether we call it "busybox_dmalloc.h" or "busybox_end.h" or "busybox_include_me_after_all_other_global_includes.h" Thanks, From yann.morin.1998 at anciens.enib.fr Sun Jun 4 07:58:03 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun Jun 4 07:58:10 2006 Subject: [BusyBox 0000799]: start-stop-daemon does not support --oknodo option In-Reply-To: <20060604143533.GB8161@aon.at> References: <20060604143533.GB8161@aon.at> Message-ID: <200606041658.03925.yann.morin.1998@anciens.enib.fr> On Sunday 04 June 2006 163, Bernhard Fischer wrote: > PPS: anyone up to joining the bug-sqashing party? :) I'll be looking at those related to modprobe, as usual :-) : - 836: on-demand module loading with 2.6.X and modprobe with '-' in module names - 815: modprobe problem (whatever that might be... :-/ ) - 679: modprobe incrorrectly reads module parametrs from modules.conf - 655: Kernel26 modprobe '-' in module names - 276: Linux 2.6 module autoloading breaks when support for 2.4 modules is disabled Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? From rep.nop at aon.at Sun Jun 4 11:49:16 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jun 4 11:49:24 2006 Subject: [patch] save 448B Message-ID: <20060604184916.GD8161@aon.at> Hi, - use bb_msg_... in more places. While i think that this patch should be ok, i'd be glad if someone could look over it (been staring at it for too long). TIA, Bernhard PS: (defconfig + IMA gives): text data bss dec hex filename 895477 11660 647300 1554437 17b805 busybox.old-3.3.20060604-2016 894853 11660 647300 1553813 17b595 busybox.new-3.3.20060604-2016 824919 9100 645216 1479235 169243 busybox.old-4.1.20060604-2016 824471 9100 645216 1478787 169083 busybox.new-4.1.20060604-2016 $ diffstat str.02c.diff coreutils/dd.c | 2 - coreutils/diff.c | 9 +------ coreutils/stty.c | 14 +++++------ coreutils/test.c | 20 ++++------------ editors/sed.c | 2 - findutils/find.c | 32 +++++++++++---------------- findutils/grep.c | 4 +-- include/libbb.h | 2 + libbb/messages.c | 8 +++++- networking/libiproute/ip_parse_common_args.c | 2 - networking/libiproute/ipaddress.c | 10 ++++---- networking/libiproute/iplink.c | 4 +-- networking/libiproute/iproute.c | 10 ++++---- networking/libiproute/iptunnel.c | 6 ++--- networking/libiproute/utils.c | 6 ----- networking/libiproute/utils.h | 4 +-- networking/udhcp/dhcpc.c | 2 - shell/ash.c | 2 - shell/lash.c | 4 +-- 19 files changed, 63 insertions(+), 80 deletions(-) -------------- next part -------------- Index: networking/libiproute/iptunnel.c =================================================================== --- networking/libiproute/iptunnel.c (revision 15268) +++ networking/libiproute/iptunnel.c (working copy) @@ -259,9 +259,9 @@ NEXT_ARG(); if (strcmp(*argv, "inherit") != 0) { if (get_unsigned(&uval, *argv, 0)) - invarg("invalid TTL\n", *argv); + invarg(*argv, "TTL"); if (uval > 255) - invarg("TTL must be <=255\n", *argv); + invarg(*argv, "TTL must be <=255"); p->iph.ttl = uval; } } else if (strcmp(*argv, "tos") == 0 || @@ -270,7 +270,7 @@ NEXT_ARG(); if (strcmp(*argv, "inherit") != 0) { if (rtnl_dsfield_a2n(&uval, *argv)) - invarg("bad TOS value", *argv); + invarg(*argv, "TOS"); p->iph.tos = uval; } else p->iph.tos = 1; Index: networking/libiproute/utils.c =================================================================== --- networking/libiproute/utils.c (revision 15268) +++ networking/libiproute/utils.c (working copy) @@ -240,12 +240,6 @@ exit(-1); } -void invarg(char *msg, char *arg) -{ - bb_error_msg("argument \"%s\" is wrong: %s", arg, msg); - exit(-1); -} - void duparg(char *key, char *arg) { bb_error_msg("duplicate \"%s\": \"%s\" is the second value.", key, arg); Index: networking/libiproute/utils.h =================================================================== --- networking/libiproute/utils.h (revision 15268) +++ networking/libiproute/utils.h (working copy) @@ -1,13 +1,13 @@ #ifndef __UTILS_H__ #define __UTILS_H__ 1 +#include "libbb.h" #include #include #include "libnetlink.h" #include "ll_map.h" #include "rtm_map.h" -#include "libbb.h" extern int preferred_family; extern int show_stats; @@ -77,7 +77,7 @@ extern const char *format_host(int af, int len, void *addr, char *buf, int buflen); extern const char *rt_addr_n2a(int af, int len, void *addr, char *buf, int buflen); -void invarg(char *, char *) ATTRIBUTE_NORETURN; +#define invarg(arg,opt) {bb_error_msg(bb_msg_invalid_arg, arg, opt);exit(-1);} void duparg(char *, char *) ATTRIBUTE_NORETURN; void duparg2(char *, char *) ATTRIBUTE_NORETURN; int matches(char *arg, char *pattern); Index: networking/libiproute/ipaddress.c =================================================================== --- networking/libiproute/ipaddress.c (revision 15268) +++ networking/libiproute/ipaddress.c (working copy) @@ -430,11 +430,11 @@ if (flush) { if (argc <= 0) { - fprintf(stderr, "Flush requires arguments.\n"); + bb_error_msg(bb_msg_requires_arg, "flush"); return -1; } if (filter.family == AF_PACKET) { - fprintf(stderr, "Cannot flush link addresses.\n"); + bb_error_msg("Cannot flush link addresses."); return -1; } } @@ -456,7 +456,7 @@ filter.scopemask = -1; if (rtnl_rtscope_a2n(&scope, *argv)) { if (strcmp(*argv, "all") != 0) { - invarg("invalid \"scope\"\n", *argv); + invarg(*argv, "scope"); } scope = RT_SCOPE_NOWHERE; filter.scopemask = 0; @@ -711,7 +711,7 @@ uint32_t scope = 0; NEXT_ARG(); if (rtnl_rtscope_a2n(&scope, *argv)) { - invarg(*argv, "invalid scope value"); + invarg(*argv, "scope"); } req.ifa.ifa_scope = scope; scoped = 1; @@ -744,7 +744,7 @@ } if (d == NULL) { - bb_error_msg("Not enough information: \"dev\" argument is required"); + bb_error_msg(bb_msg_requires_arg,"\"dev\""); return -1; } if (l && matches(d, l) != 0) { Index: networking/libiproute/iplink.c =================================================================== --- networking/libiproute/iplink.c (revision 15268) +++ networking/libiproute/iplink.c (working copy) @@ -252,7 +252,7 @@ if (mtu != -1) duparg("mtu", *argv); if (get_integer(&mtu, *argv, 0)) - invarg("Invalid \"mtu\" value\n", *argv); + invarg(*argv, "mtu"); } else if (strcmp(*argv, "multicast") == 0) { NEXT_ARG(); mask |= IFF_MULTICAST; @@ -286,7 +286,7 @@ } if (!dev) { - bb_error_msg("Not enough of information: \"dev\" argument is required."); + bb_error_msg(bb_msg_requires_arg, "\"dev\""); exit(-1); } Index: networking/libiproute/ip_parse_common_args.c =================================================================== --- networking/libiproute/ip_parse_common_args.c (revision 15268) +++ networking/libiproute/ip_parse_common_args.c (working copy) @@ -56,7 +56,7 @@ else if (strcmp(argv[1], "link") == 0) preferred_family = AF_PACKET; else - invarg(argv[1], "invalid protocol family"); + invarg(argv[1], "protocol family"); } else if (strcmp(opt, "-4") == 0) { preferred_family = AF_INET; } else if (strcmp(opt, "-6") == 0) { Index: networking/libiproute/iproute.c =================================================================== --- networking/libiproute/iproute.c (revision 15268) +++ networking/libiproute/iproute.c (working copy) @@ -343,14 +343,14 @@ NEXT_ARG(); } if (get_unsigned(&mtu, *argv, 0)) { - invarg("\"mtu\" value is invalid\n", *argv); + invarg(*argv, "mtu"); } rta_addattr32(mxrta, sizeof(mxbuf), RTAX_MTU, mtu); } else if (matches(*argv, "protocol") == 0) { uint32_t prot; NEXT_ARG(); if (rtnl_rtprot_a2n(&prot, *argv)) - invarg("\"protocol\" value is invalid\n", *argv); + invarg(*argv, "protocol"); req.r.rtm_protocol = prot; proto_ok =1; } else if (strcmp(*argv, "dev") == 0 || @@ -487,7 +487,7 @@ filter.tb = RT_TABLE_MAIN; if (flush && argc <= 0) { - fprintf(stderr, "\"ip route flush\" requires arguments.\n"); + bb_error_msg(bb_msg_requires_arg, "\"ip route flush\""); return -1; } @@ -498,7 +498,7 @@ filter.protocolmask = -1; if (rtnl_rtprot_a2n(&prot, *argv)) { if (strcmp(*argv, "all") != 0) { - invarg("invalid \"protocol\"\n", *argv); + invarg(*argv, "protocol"); } prot = 0; filter.protocolmask = 0; @@ -541,7 +541,7 @@ if (matches(*argv, "cache") == 0) { filter.tb = -1; } else if (matches(*argv, "main") != 0) { - invarg("invalid \"table\"", *argv); + invarg(*argv, "table"); } } else if (matches(*argv, "cache") == 0) { filter.tb = -1; Index: networking/udhcp/dhcpc.c =================================================================== --- networking/udhcp/dhcpc.c (revision 15268) +++ networking/udhcp/dhcpc.c (working copy) @@ -206,7 +206,7 @@ {"script", required_argument, 0, 's'}, {"timeout", required_argument, 0, 'T'}, {"version", no_argument, 0, 'v'}, - {"retries", required_argument, 0, 't'}, + {"retries", required_argument, 0, 't'}, {0, 0, 0, 0} }; Index: shell/lash.c =================================================================== --- shell/lash.c (revision 15270) +++ shell/lash.c (working copy) @@ -284,7 +284,7 @@ } } else { if (sscanf(child->argv[1], "%%%d", &jobnum) != 1) { - bb_error_msg("%s: bad argument '%s'", child->argv[0], child->argv[1]); + bb_error_msg(bb_msg_invalid_arg, child->argv[1], child->argv[0]); return EXIT_FAILURE; } for (job = child->family->job_list->head; job; job = job->next) { @@ -465,7 +465,7 @@ static int builtin_unset(struct child_prog *child) { if (child->argv[1] == NULL) { - printf( "unset: parameter required.\n"); + printf(bb_msg_requires_arg, "unset"); return EXIT_FAILURE; } unsetenv(child->argv[1]); Index: shell/ash.c =================================================================== --- shell/ash.c (revision 15268) +++ shell/ash.c (working copy) @@ -8762,7 +8762,7 @@ xminusc = minusc; if (*xargv == NULL) { if (xminusc) - sh_error("-c requires an argument"); + sh_error(bb_msg_requires_arg, "-c"); sflag = 1; } if (iflag == 2 && sflag == 1 && isatty(0) && isatty(1)) Index: coreutils/dd.c =================================================================== --- coreutils/dd.c (revision 15268) +++ coreutils/dd.c (working copy) @@ -96,7 +96,7 @@ noerror = TRUE; ibuf += 7; } else { - bb_error_msg_and_die("invalid conversion `%s'", argv[i]+5); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i]+5, "conv"); } if (ibuf[0] == '\0') break; if (ibuf[0] == ',') ibuf++; Index: coreutils/diff.c =================================================================== --- coreutils/diff.c (revision 15268) +++ coreutils/diff.c (working copy) @@ -1158,7 +1158,7 @@ while (*dirlist2 != NULL && strcmp(*dirlist2, start) < 0) dirlist2++; if ((*dirlist1 == NULL) || (*dirlist2 == NULL)) - bb_error_msg("Invalid argument to -S"); + bb_error_msg(bb_msg_invalid_arg, "NULL", "-S"); } /* Now that both dirlist1 and dirlist2 contain sorted directory @@ -1194,7 +1194,6 @@ int diff_main(int argc, char **argv) { - char *ep; int gotstdin = 0; char *U_opt; @@ -1229,11 +1228,7 @@ context = 3; /* This is the default number of lines of context. */ if (cmd_flags & FLAG_U) { - context = strtol(U_opt, &ep, 10); - if (context == 0) { - bb_error_msg("Invalid context length"); - bb_show_usage(); - } + context = bb_xgetlarg(U_opt, 10, 1, INT_MAX); } argc -= optind; argv += optind; Index: coreutils/test.c =================================================================== --- coreutils/test.c (revision 15268) +++ coreutils/test.c (working copy) @@ -178,7 +178,6 @@ static int newerf(const char *f1, const char *f2); static int olderf(const char *f1, const char *f2); static int equalf(const char *f1, const char *f2); -static void syntax(const char *op, const char *msg); static int test_eaccess(char *path, int mode); static int is_a_group_member(gid_t gid); static void initialize_group_array(void); @@ -230,20 +229,11 @@ res = !oexpr(t_lex(*t_wp)); if (*t_wp != NULL && *++t_wp != NULL) - syntax(*t_wp, "unknown operand"); + bb_error_msg_and_die("%s: unknown operand", *t_wp); return (res); } -static void syntax(const char *op, const char *msg) -{ - if (op && *op) { - bb_error_msg_and_die("%s: %s", op, msg); - } else { - bb_error_msg_and_die("%s", msg); - } -} - static arith_t oexpr(enum token n) { arith_t res; @@ -279,18 +269,18 @@ arith_t res; if (n == EOI) { - syntax(NULL, "argument expected"); + bb_error_msg_and_die("argument expected"); } if (n == LPAREN) { res = oexpr(t_lex(*++t_wp)); if (t_lex(*++t_wp) != RPAREN) - syntax(NULL, "closing paren expected"); + bb_error_msg_and_die("closing paren expected"); return res; } if (t_wp_op && t_wp_op->op_type == UNOP) { /* unary expression */ if (*++t_wp == NULL) - syntax(t_wp_op->op_text, "argument expected"); + bb_error_msg_and_die(bb_msg_requires_arg, t_wp_op->op_text); switch (n) { case STREZ: return strlen(*t_wp) == 0; @@ -320,7 +310,7 @@ op = t_wp_op; if ((opnd2 = *++t_wp) == (char *) 0) - syntax(op->op_text, "argument expected"); + bb_error_msg_and_die(bb_msg_requires_arg, op->op_text); switch (op->op_num) { case STREQ: Index: coreutils/stty.c =================================================================== --- coreutils/stty.c (revision 15268) +++ coreutils/stty.c (working copy) @@ -23,6 +23,7 @@ //#define TEST +#include "busybox.h" #include #include #include @@ -45,7 +46,6 @@ #include #include #include -#include "busybox.h" #define STREQ(a, b) (strcmp ((a), (b)) == 0) @@ -608,7 +608,7 @@ for (i = 0; i < NUM_control_info; ++i) if (STREQ(argv[k], control_info[i].name)) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); match_found = 1; ++k; set_control_char(&control_info[i], argv[k], &mode); @@ -619,14 +619,14 @@ if (match_found == 0) { if (STREQ(argv[k], "ispeed")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_speed(input_speed, argv[k], &mode); speed_was_set = 1; require_set_attr = 1; } else if (STREQ(argv[k], "ospeed")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_speed(output_speed, argv[k], &mode); speed_was_set = 1; @@ -635,13 +635,13 @@ #ifdef TIOCGWINSZ else if (STREQ(argv[k], "rows")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_window_size((int) bb_xparse_number(argv[k], stty_suffixes), -1); } else if (STREQ(argv[k], "cols") || STREQ(argv[k], "columns")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_window_size(-1, (int) bb_xparse_number(argv[k], stty_suffixes)); @@ -654,7 +654,7 @@ #ifdef HAVE_C_LINE else if (STREQ(argv[k], "line")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; mode.c_line = bb_xparse_number(argv[k], stty_suffixes); require_set_attr = 1; Index: libbb/messages.c =================================================================== --- libbb/messages.c (revision 15268) +++ libbb/messages.c (working copy) @@ -38,11 +38,17 @@ const char * const bb_msg_unknown = "(unknown)"; #endif #ifdef L_can_not_create_raw_socket - const char * const bb_msg_can_not_create_raw_socket = "can`t create raw socket"; + const char * const bb_msg_can_not_create_raw_socket = "can't create raw socket"; #endif #ifdef L_perm_denied_are_you_root const char * const bb_msg_perm_denied_are_you_root = "permission denied. (are you root?)"; #endif +#ifdef L_msg_requires_arg + const char * const bb_msg_requires_arg = "%s requires an argument"; +#endif +#ifdef L_msg_invalid_arg + const char * const bb_msg_invalid_arg = "invalid argument `%s' to `%s'"; +#endif #ifdef L_msg_standard_input const char * const bb_msg_standard_input = "standard input"; #endif Index: include/libbb.h =================================================================== --- include/libbb.h (revision 15268) +++ include/libbb.h (working copy) @@ -341,6 +341,8 @@ extern const char * const bb_msg_unknown; extern const char * const bb_msg_can_not_create_raw_socket; extern const char * const bb_msg_perm_denied_are_you_root; +extern const char * const bb_msg_requires_arg; +extern const char * const bb_msg_invalid_arg; extern const char * const bb_msg_standard_input; extern const char * const bb_msg_standard_output; Index: findutils/find.c =================================================================== --- findutils/find.c (revision 15268) +++ findutils/find.c (working copy) @@ -20,10 +20,6 @@ #include #include -//XXX just found out about libbb/messages.c . maybe move stuff there ? - ghoz -static const char msg_req_arg[] = "option `%s' requires an argument"; -static const char msg_invalid_arg[] = "invalid argument `%s' to `%s'"; - static char *pattern; #ifdef CONFIG_FEATURE_FIND_PRINT0 static char printsep = '\n'; @@ -188,7 +184,7 @@ } if (mask == 0 || type[1] != '\0') - bb_error_msg_and_die(msg_invalid_arg, type, "-type"); + bb_error_msg_and_die(bb_msg_invalid_arg, type, "-type"); return mask; } @@ -217,22 +213,22 @@ #endif else if (strcmp(argv[i], "-name") == 0) { if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-name"); + bb_error_msg_and_die(bb_msg_requires_arg, "-name"); pattern = argv[i]; #ifdef CONFIG_FEATURE_FIND_TYPE } else if (strcmp(argv[i], "-type") == 0) { if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-type"); + bb_error_msg_and_die(bb_msg_requires_arg, "-type"); type_mask = find_type(argv[i]); #endif #ifdef CONFIG_FEATURE_FIND_PERM } else if (strcmp(argv[i], "-perm") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-perm"); + bb_error_msg_and_die(bb_msg_requires_arg, "-perm"); perm_mask = strtol(argv[i], &end, 8); if ((end[0] != '\0') || (perm_mask > 07777)) - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-perm"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-perm"); if ((perm_char = argv[i][0]) == '-') perm_mask = -perm_mask; #endif @@ -240,10 +236,10 @@ } else if (strcmp(argv[i], "-mtime") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-mtime"); + bb_error_msg_and_die(bb_msg_requires_arg, "-mtime"); mtime_days = strtol(argv[i], &end, 10); if (end[0] != '\0') - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-mtime"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-mtime"); if ((mtime_char = argv[i][0]) == '-') mtime_days = -mtime_days; #endif @@ -251,10 +247,10 @@ } else if (strcmp(argv[i], "-mmin") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-mmin"); + bb_error_msg_and_die(bb_msg_requires_arg, "-mmin"); mmin_mins = strtol(argv[i], &end, 10); if (end[0] != '\0') - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-mmin"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-mmin"); if ((mmin_char = argv[i][0]) == '-') mmin_mins = -mmin_mins; #endif @@ -281,7 +277,7 @@ } else if (strcmp(argv[i], "-newer") == 0) { struct stat stat_newer; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-newer"); + bb_error_msg_and_die(bb_msg_requires_arg, "-newer"); xstat (argv[i], &stat_newer); newer_mtime = stat_newer.st_mtime; #endif @@ -289,10 +285,10 @@ } else if (strcmp(argv[i], "-inum") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-inum"); + bb_error_msg_and_die(bb_msg_requires_arg, "-inum"); inode_num = strtol(argv[i], &end, 10); if (end[0] != '\0') - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-inum"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-inum"); #endif #ifdef CONFIG_FEATURE_FIND_EXEC } else if (strcmp(argv[i], "-exec") == 0) { @@ -301,14 +297,14 @@ while (i++) { if (i == argc) - bb_error_msg_and_die(msg_req_arg, "-exec"); + bb_error_msg_and_die(bb_msg_requires_arg, "-exec"); if (*argv[i] == ';') break; cmd_string = bb_xasprintf("%s %s", cmd_string, argv[i]); } if (*cmd_string == 0) - bb_error_msg_and_die(msg_req_arg, "-exec"); + bb_error_msg_and_die(bb_msg_requires_arg, "-exec"); cmd_string++; exec_str = xmalloc(sizeof(char *)); Index: findutils/grep.c =================================================================== --- findutils/grep.c (revision 15268) +++ findutils/grep.c (working copy) @@ -313,12 +313,12 @@ if(opt & GREP_OPT_A) { lines_after = strtoul(slines_after, &junk, 10); if(*junk != '\0') - bb_error_msg_and_die("invalid context length argument"); + bb_error_msg_and_die(bb_msg_invalid_arg, slines_after, "-A"); } if(opt & GREP_OPT_B) { lines_before = strtoul(slines_before, &junk, 10); if(*junk != '\0') - bb_error_msg_and_die("invalid context length argument"); + bb_error_msg_and_die(bb_msg_invalid_arg, slines_before, "-B"); } /* sanity checks after parse may be invalid numbers ;-) */ if ((opt & (GREP_OPT_c|GREP_OPT_q|GREP_OPT_l|GREP_OPT_L))) { Index: editors/sed.c =================================================================== --- editors/sed.c (revision 15278) +++ editors/sed.c (working copy) @@ -1166,7 +1166,7 @@ * files were specified or '-' was specified, take input from stdin. * Otherwise, we process all the files specified. */ if (argv[optind] == NULL) { - if(bbg.in_place) bb_error_msg_and_die("Filename required for -i"); + if(bbg.in_place) bb_error_msg_and_die(bb_msg_requires_arg, "-i "); add_input_file(stdin); process_files(); } else { From rep.nop at aon.at Sun Jun 4 13:14:53 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jun 4 13:15:02 2006 Subject: [patch] save ~600B In-Reply-To: <20060604184916.GD8161@aon.at> References: <20060604184916.GD8161@aon.at> Message-ID: <20060604201452.GE8161@aon.at> On Sun, Jun 04, 2006 at 08:49:16PM +0200, Bernhard Fischer wrote: >Hi, > >- use bb_msg_... in more places. > >While i think that this patch should be ok, i'd be glad if someone could >look over it (been staring at it for too long). > >TIA, >Bernhard updated version 02e -------------- next part -------------- Index: networking/ip.c =================================================================== --- networking/ip.c (revision 15268) +++ networking/ip.c (working copy) @@ -59,7 +59,7 @@ else if (strcmp(argv[1], "link") == 0) preferred_family = AF_PACKET; else - invarg(argv[1], "invalid protocol family"); + invarg(bb_msg_invalid_arg, argv[1], "-family"); } else if (strcmp(opt, "-4") == 0) { preferred_family = AF_INET; } else if (strcmp(opt, "-6") == 0) { Index: networking/libiproute/iptunnel.c =================================================================== --- networking/libiproute/iptunnel.c (revision 15268) +++ networking/libiproute/iptunnel.c (working copy) @@ -259,9 +259,9 @@ NEXT_ARG(); if (strcmp(*argv, "inherit") != 0) { if (get_unsigned(&uval, *argv, 0)) - invarg("invalid TTL\n", *argv); + invarg(*argv, "TTL"); if (uval > 255) - invarg("TTL must be <=255\n", *argv); + invarg(*argv, "TTL must be <=255"); p->iph.ttl = uval; } } else if (strcmp(*argv, "tos") == 0 || @@ -270,7 +270,7 @@ NEXT_ARG(); if (strcmp(*argv, "inherit") != 0) { if (rtnl_dsfield_a2n(&uval, *argv)) - invarg("bad TOS value", *argv); + invarg(*argv, "TOS"); p->iph.tos = uval; } else p->iph.tos = 1; Index: networking/libiproute/utils.c =================================================================== --- networking/libiproute/utils.c (revision 15268) +++ networking/libiproute/utils.c (working copy) @@ -240,9 +240,9 @@ exit(-1); } -void invarg(char *msg, char *arg) +void invarg(const char const *arg, const char const *opt) { - bb_error_msg("argument \"%s\" is wrong: %s", arg, msg); + bb_error_msg(bb_msg_invalid_arg, arg, opt); exit(-1); } Index: networking/libiproute/utils.h =================================================================== --- networking/libiproute/utils.h (revision 15268) +++ networking/libiproute/utils.h (working copy) @@ -1,13 +1,13 @@ #ifndef __UTILS_H__ #define __UTILS_H__ 1 +#include "libbb.h" #include #include #include "libnetlink.h" #include "ll_map.h" #include "rtm_map.h" -#include "libbb.h" extern int preferred_family; extern int show_stats; @@ -77,7 +77,7 @@ extern const char *format_host(int af, int len, void *addr, char *buf, int buflen); extern const char *rt_addr_n2a(int af, int len, void *addr, char *buf, int buflen); -void invarg(char *, char *) ATTRIBUTE_NORETURN; +void invarg(const char const*, const char const*) ATTRIBUTE_NORETURN; void duparg(char *, char *) ATTRIBUTE_NORETURN; void duparg2(char *, char *) ATTRIBUTE_NORETURN; int matches(char *arg, char *pattern); Index: networking/libiproute/ipaddress.c =================================================================== --- networking/libiproute/ipaddress.c (revision 15268) +++ networking/libiproute/ipaddress.c (working copy) @@ -430,11 +430,11 @@ if (flush) { if (argc <= 0) { - fprintf(stderr, "Flush requires arguments.\n"); + bb_error_msg(bb_msg_requires_arg, "flush"); return -1; } if (filter.family == AF_PACKET) { - fprintf(stderr, "Cannot flush link addresses.\n"); + bb_error_msg("Cannot flush link addresses."); return -1; } } @@ -456,7 +456,7 @@ filter.scopemask = -1; if (rtnl_rtscope_a2n(&scope, *argv)) { if (strcmp(*argv, "all") != 0) { - invarg("invalid \"scope\"\n", *argv); + invarg(*argv, "scope"); } scope = RT_SCOPE_NOWHERE; filter.scopemask = 0; @@ -711,7 +711,7 @@ uint32_t scope = 0; NEXT_ARG(); if (rtnl_rtscope_a2n(&scope, *argv)) { - invarg(*argv, "invalid scope value"); + invarg(*argv, "scope"); } req.ifa.ifa_scope = scope; scoped = 1; @@ -744,7 +744,7 @@ } if (d == NULL) { - bb_error_msg("Not enough information: \"dev\" argument is required"); + bb_error_msg(bb_msg_requires_arg,"\"dev\""); return -1; } if (l && matches(d, l) != 0) { Index: networking/libiproute/iplink.c =================================================================== --- networking/libiproute/iplink.c (revision 15268) +++ networking/libiproute/iplink.c (working copy) @@ -252,7 +252,7 @@ if (mtu != -1) duparg("mtu", *argv); if (get_integer(&mtu, *argv, 0)) - invarg("Invalid \"mtu\" value\n", *argv); + invarg(*argv, "mtu"); } else if (strcmp(*argv, "multicast") == 0) { NEXT_ARG(); mask |= IFF_MULTICAST; @@ -286,7 +286,7 @@ } if (!dev) { - bb_error_msg("Not enough of information: \"dev\" argument is required."); + bb_error_msg(bb_msg_requires_arg, "\"dev\""); exit(-1); } Index: networking/libiproute/ip_parse_common_args.c =================================================================== --- networking/libiproute/ip_parse_common_args.c (revision 15268) +++ networking/libiproute/ip_parse_common_args.c (working copy) @@ -56,7 +56,7 @@ else if (strcmp(argv[1], "link") == 0) preferred_family = AF_PACKET; else - invarg(argv[1], "invalid protocol family"); + invarg(argv[1], "protocol family"); } else if (strcmp(opt, "-4") == 0) { preferred_family = AF_INET; } else if (strcmp(opt, "-6") == 0) { Index: networking/libiproute/iproute.c =================================================================== --- networking/libiproute/iproute.c (revision 15268) +++ networking/libiproute/iproute.c (working copy) @@ -343,14 +343,14 @@ NEXT_ARG(); } if (get_unsigned(&mtu, *argv, 0)) { - invarg("\"mtu\" value is invalid\n", *argv); + invarg(*argv, "mtu"); } rta_addattr32(mxrta, sizeof(mxbuf), RTAX_MTU, mtu); } else if (matches(*argv, "protocol") == 0) { uint32_t prot; NEXT_ARG(); if (rtnl_rtprot_a2n(&prot, *argv)) - invarg("\"protocol\" value is invalid\n", *argv); + invarg(*argv, "protocol"); req.r.rtm_protocol = prot; proto_ok =1; } else if (strcmp(*argv, "dev") == 0 || @@ -487,7 +487,7 @@ filter.tb = RT_TABLE_MAIN; if (flush && argc <= 0) { - fprintf(stderr, "\"ip route flush\" requires arguments.\n"); + bb_error_msg(bb_msg_requires_arg, "\"ip route flush\""); return -1; } @@ -498,7 +498,7 @@ filter.protocolmask = -1; if (rtnl_rtprot_a2n(&prot, *argv)) { if (strcmp(*argv, "all") != 0) { - invarg("invalid \"protocol\"\n", *argv); + invarg(*argv, "protocol"); } prot = 0; filter.protocolmask = 0; @@ -541,7 +541,7 @@ if (matches(*argv, "cache") == 0) { filter.tb = -1; } else if (matches(*argv, "main") != 0) { - invarg("invalid \"table\"", *argv); + invarg(*argv, "table"); } } else if (matches(*argv, "cache") == 0) { filter.tb = -1; Index: networking/udhcp/dhcpc.c =================================================================== --- networking/udhcp/dhcpc.c (revision 15268) +++ networking/udhcp/dhcpc.c (working copy) @@ -206,7 +206,7 @@ {"script", required_argument, 0, 's'}, {"timeout", required_argument, 0, 'T'}, {"version", no_argument, 0, 'v'}, - {"retries", required_argument, 0, 't'}, + {"retries", required_argument, 0, 't'}, {0, 0, 0, 0} }; Index: archival/unzip.c =================================================================== --- archival/unzip.c (revision 15268) +++ archival/unzip.c (working copy) @@ -86,7 +86,7 @@ static void unzip_read(int fd, void *buf, size_t count) { if (bb_xread(fd, buf, count) != count) { - bb_error_msg_and_die("Read failure"); + bb_error_msg_and_die(bb_msg_read_error); } } @@ -95,7 +95,7 @@ /* Create all leading directories */ char *name = bb_xstrdup(fn); if (bb_make_directory(dirname(name), 0777, FILEUTILS_RECUR)) { - bb_error_msg_and_die("Failed to create directory"); + bb_error_msg_and_die("Exiting"); /* bb_make_directory is noisy */ } free(name); } @@ -282,8 +282,8 @@ unzip_skip(src_fd, zip_header.formated.extra_len); if ((verbosity == v_list) && !list_header_done){ - printf(" Length Date Time Name\n"); - printf(" -------- ---- ---- ----\n"); + printf(" Length Date Time Name\n" + " -------- ---- ---- ----\n"); list_header_done = 1; } Index: shell/lash.c =================================================================== --- shell/lash.c (revision 15270) +++ shell/lash.c (working copy) @@ -284,7 +284,7 @@ } } else { if (sscanf(child->argv[1], "%%%d", &jobnum) != 1) { - bb_error_msg("%s: bad argument '%s'", child->argv[0], child->argv[1]); + bb_error_msg(bb_msg_invalid_arg, child->argv[1], child->argv[0]); return EXIT_FAILURE; } for (job = child->family->job_list->head; job; job = job->next) { @@ -465,7 +465,7 @@ static int builtin_unset(struct child_prog *child) { if (child->argv[1] == NULL) { - printf( "unset: parameter required.\n"); + printf(bb_msg_requires_arg, "unset"); return EXIT_FAILURE; } unsetenv(child->argv[1]); Index: shell/ash.c =================================================================== --- shell/ash.c (revision 15268) +++ shell/ash.c (working copy) @@ -8762,7 +8762,7 @@ xminusc = minusc; if (*xargv == NULL) { if (xminusc) - sh_error("-c requires an argument"); + sh_error(bb_msg_requires_arg, "-c"); sflag = 1; } if (iflag == 2 && sflag == 1 && isatty(0) && isatty(1)) Index: coreutils/dd.c =================================================================== --- coreutils/dd.c (revision 15268) +++ coreutils/dd.c (working copy) @@ -96,7 +96,7 @@ noerror = TRUE; ibuf += 7; } else { - bb_error_msg_and_die("invalid conversion `%s'", argv[i]+5); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i]+5, "conv"); } if (ibuf[0] == '\0') break; if (ibuf[0] == ',') ibuf++; Index: coreutils/diff.c =================================================================== --- coreutils/diff.c (revision 15268) +++ coreutils/diff.c (working copy) @@ -1158,7 +1158,7 @@ while (*dirlist2 != NULL && strcmp(*dirlist2, start) < 0) dirlist2++; if ((*dirlist1 == NULL) || (*dirlist2 == NULL)) - bb_error_msg("Invalid argument to -S"); + bb_error_msg(bb_msg_invalid_arg, "NULL", "-S"); } /* Now that both dirlist1 and dirlist2 contain sorted directory @@ -1194,7 +1194,6 @@ int diff_main(int argc, char **argv) { - char *ep; int gotstdin = 0; char *U_opt; @@ -1229,11 +1228,7 @@ context = 3; /* This is the default number of lines of context. */ if (cmd_flags & FLAG_U) { - context = strtol(U_opt, &ep, 10); - if (context == 0) { - bb_error_msg("Invalid context length"); - bb_show_usage(); - } + context = bb_xgetlarg(U_opt, 10, 1, INT_MAX); } argc -= optind; argv += optind; Index: coreutils/test.c =================================================================== --- coreutils/test.c (revision 15268) +++ coreutils/test.c (working copy) @@ -178,7 +178,6 @@ static int newerf(const char *f1, const char *f2); static int olderf(const char *f1, const char *f2); static int equalf(const char *f1, const char *f2); -static void syntax(const char *op, const char *msg); static int test_eaccess(char *path, int mode); static int is_a_group_member(gid_t gid); static void initialize_group_array(void); @@ -230,20 +229,11 @@ res = !oexpr(t_lex(*t_wp)); if (*t_wp != NULL && *++t_wp != NULL) - syntax(*t_wp, "unknown operand"); + bb_error_msg_and_die("%s: unknown operand", *t_wp); return (res); } -static void syntax(const char *op, const char *msg) -{ - if (op && *op) { - bb_error_msg_and_die("%s: %s", op, msg); - } else { - bb_error_msg_and_die("%s", msg); - } -} - static arith_t oexpr(enum token n) { arith_t res; @@ -279,18 +269,18 @@ arith_t res; if (n == EOI) { - syntax(NULL, "argument expected"); + bb_error_msg_and_die("argument expected"); } if (n == LPAREN) { res = oexpr(t_lex(*++t_wp)); if (t_lex(*++t_wp) != RPAREN) - syntax(NULL, "closing paren expected"); + bb_error_msg_and_die("closing paren expected"); return res; } if (t_wp_op && t_wp_op->op_type == UNOP) { /* unary expression */ if (*++t_wp == NULL) - syntax(t_wp_op->op_text, "argument expected"); + bb_error_msg_and_die(bb_msg_requires_arg, t_wp_op->op_text); switch (n) { case STREZ: return strlen(*t_wp) == 0; @@ -320,7 +310,7 @@ op = t_wp_op; if ((opnd2 = *++t_wp) == (char *) 0) - syntax(op->op_text, "argument expected"); + bb_error_msg_and_die(bb_msg_requires_arg, op->op_text); switch (op->op_num) { case STREQ: Index: coreutils/stty.c =================================================================== --- coreutils/stty.c (revision 15268) +++ coreutils/stty.c (working copy) @@ -23,6 +23,7 @@ //#define TEST +#include "busybox.h" #include #include #include @@ -45,7 +46,6 @@ #include #include #include -#include "busybox.h" #define STREQ(a, b) (strcmp ((a), (b)) == 0) @@ -608,7 +608,7 @@ for (i = 0; i < NUM_control_info; ++i) if (STREQ(argv[k], control_info[i].name)) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); match_found = 1; ++k; set_control_char(&control_info[i], argv[k], &mode); @@ -619,14 +619,14 @@ if (match_found == 0) { if (STREQ(argv[k], "ispeed")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_speed(input_speed, argv[k], &mode); speed_was_set = 1; require_set_attr = 1; } else if (STREQ(argv[k], "ospeed")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_speed(output_speed, argv[k], &mode); speed_was_set = 1; @@ -635,13 +635,13 @@ #ifdef TIOCGWINSZ else if (STREQ(argv[k], "rows")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_window_size((int) bb_xparse_number(argv[k], stty_suffixes), -1); } else if (STREQ(argv[k], "cols") || STREQ(argv[k], "columns")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; set_window_size(-1, (int) bb_xparse_number(argv[k], stty_suffixes)); @@ -654,7 +654,7 @@ #ifdef HAVE_C_LINE else if (STREQ(argv[k], "line")) { if (k == argc - 1) - bb_error_msg_and_die("missing argument to `%s'", argv[k]); + bb_error_msg_and_die(bb_msg_requires_arg, argv[k]); ++k; mode.c_line = bb_xparse_number(argv[k], stty_suffixes); require_set_attr = 1; Index: libbb/messages.c =================================================================== --- libbb/messages.c (revision 15268) +++ libbb/messages.c (working copy) @@ -38,11 +38,17 @@ const char * const bb_msg_unknown = "(unknown)"; #endif #ifdef L_can_not_create_raw_socket - const char * const bb_msg_can_not_create_raw_socket = "can`t create raw socket"; + const char * const bb_msg_can_not_create_raw_socket = "can't create raw socket"; #endif #ifdef L_perm_denied_are_you_root const char * const bb_msg_perm_denied_are_you_root = "permission denied. (are you root?)"; #endif +#ifdef L_msg_requires_arg + const char * const bb_msg_requires_arg = "%s requires an argument"; +#endif +#ifdef L_msg_invalid_arg + const char * const bb_msg_invalid_arg = "invalid argument `%s' to `%s'"; +#endif #ifdef L_msg_standard_input const char * const bb_msg_standard_input = "standard input"; #endif Index: include/libbb.h =================================================================== --- include/libbb.h (revision 15268) +++ include/libbb.h (working copy) @@ -341,6 +341,8 @@ extern const char * const bb_msg_unknown; extern const char * const bb_msg_can_not_create_raw_socket; extern const char * const bb_msg_perm_denied_are_you_root; +extern const char * const bb_msg_requires_arg; +extern const char * const bb_msg_invalid_arg; extern const char * const bb_msg_standard_input; extern const char * const bb_msg_standard_output; Index: findutils/find.c =================================================================== --- findutils/find.c (revision 15268) +++ findutils/find.c (working copy) @@ -20,10 +20,6 @@ #include #include -//XXX just found out about libbb/messages.c . maybe move stuff there ? - ghoz -static const char msg_req_arg[] = "option `%s' requires an argument"; -static const char msg_invalid_arg[] = "invalid argument `%s' to `%s'"; - static char *pattern; #ifdef CONFIG_FEATURE_FIND_PRINT0 static char printsep = '\n'; @@ -188,7 +184,7 @@ } if (mask == 0 || type[1] != '\0') - bb_error_msg_and_die(msg_invalid_arg, type, "-type"); + bb_error_msg_and_die(bb_msg_invalid_arg, type, "-type"); return mask; } @@ -217,22 +213,22 @@ #endif else if (strcmp(argv[i], "-name") == 0) { if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-name"); + bb_error_msg_and_die(bb_msg_requires_arg, "-name"); pattern = argv[i]; #ifdef CONFIG_FEATURE_FIND_TYPE } else if (strcmp(argv[i], "-type") == 0) { if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-type"); + bb_error_msg_and_die(bb_msg_requires_arg, "-type"); type_mask = find_type(argv[i]); #endif #ifdef CONFIG_FEATURE_FIND_PERM } else if (strcmp(argv[i], "-perm") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-perm"); + bb_error_msg_and_die(bb_msg_requires_arg, "-perm"); perm_mask = strtol(argv[i], &end, 8); if ((end[0] != '\0') || (perm_mask > 07777)) - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-perm"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-perm"); if ((perm_char = argv[i][0]) == '-') perm_mask = -perm_mask; #endif @@ -240,10 +236,10 @@ } else if (strcmp(argv[i], "-mtime") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-mtime"); + bb_error_msg_and_die(bb_msg_requires_arg, "-mtime"); mtime_days = strtol(argv[i], &end, 10); if (end[0] != '\0') - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-mtime"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-mtime"); if ((mtime_char = argv[i][0]) == '-') mtime_days = -mtime_days; #endif @@ -251,10 +247,10 @@ } else if (strcmp(argv[i], "-mmin") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-mmin"); + bb_error_msg_and_die(bb_msg_requires_arg, "-mmin"); mmin_mins = strtol(argv[i], &end, 10); if (end[0] != '\0') - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-mmin"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-mmin"); if ((mmin_char = argv[i][0]) == '-') mmin_mins = -mmin_mins; #endif @@ -281,7 +277,7 @@ } else if (strcmp(argv[i], "-newer") == 0) { struct stat stat_newer; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-newer"); + bb_error_msg_and_die(bb_msg_requires_arg, "-newer"); xstat (argv[i], &stat_newer); newer_mtime = stat_newer.st_mtime; #endif @@ -289,10 +285,10 @@ } else if (strcmp(argv[i], "-inum") == 0) { char *end; if (++i == argc) - bb_error_msg_and_die(msg_req_arg, "-inum"); + bb_error_msg_and_die(bb_msg_requires_arg, "-inum"); inode_num = strtol(argv[i], &end, 10); if (end[0] != '\0') - bb_error_msg_and_die(msg_invalid_arg, argv[i], "-inum"); + bb_error_msg_and_die(bb_msg_invalid_arg, argv[i], "-inum"); #endif #ifdef CONFIG_FEATURE_FIND_EXEC } else if (strcmp(argv[i], "-exec") == 0) { @@ -301,14 +297,14 @@ while (i++) { if (i == argc) - bb_error_msg_and_die(msg_req_arg, "-exec"); + bb_error_msg_and_die(bb_msg_requires_arg, "-exec"); if (*argv[i] == ';') break; cmd_string = bb_xasprintf("%s %s", cmd_string, argv[i]); } if (*cmd_string == 0) - bb_error_msg_and_die(msg_req_arg, "-exec"); + bb_error_msg_and_die(bb_msg_requires_arg, "-exec"); cmd_string++; exec_str = xmalloc(sizeof(char *)); Index: findutils/grep.c =================================================================== --- findutils/grep.c (revision 15268) +++ findutils/grep.c (working copy) @@ -313,12 +313,12 @@ if(opt & GREP_OPT_A) { lines_after = strtoul(slines_after, &junk, 10); if(*junk != '\0') - bb_error_msg_and_die("invalid context length argument"); + bb_error_msg_and_die(bb_msg_invalid_arg, slines_after, "-A"); } if(opt & GREP_OPT_B) { lines_before = strtoul(slines_before, &junk, 10); if(*junk != '\0') - bb_error_msg_and_die("invalid context length argument"); + bb_error_msg_and_die(bb_msg_invalid_arg, slines_before, "-B"); } /* sanity checks after parse may be invalid numbers ;-) */ if ((opt & (GREP_OPT_c|GREP_OPT_q|GREP_OPT_l|GREP_OPT_L))) { Index: editors/sed.c =================================================================== --- editors/sed.c (revision 15278) +++ editors/sed.c (working copy) @@ -1166,7 +1166,7 @@ * files were specified or '-' was specified, take input from stdin. * Otherwise, we process all the files specified. */ if (argv[optind] == NULL) { - if(bbg.in_place) bb_error_msg_and_die("Filename required for -i"); + if(bbg.in_place) bb_error_msg_and_die(bb_msg_requires_arg, "-i "); add_input_file(stdin); process_files(); } else { Index: util-linux/fsck_minix.c =================================================================== --- util-linux/fsck_minix.c (revision 15268) +++ util-linux/fsck_minix.c (working copy) @@ -456,12 +456,13 @@ return; } if (BLOCK_SIZE * nr != lseek(IN, BLOCK_SIZE * nr, SEEK_SET)) { - printf("Read error: unable to seek to block in file '%s'\n", - current_name); + printf("%s: unable to seek to block in file '%s'\n", + bb_msg_read_error, current_name); errors_uncorrected = 1; memset(addr, 0, BLOCK_SIZE); } else if (BLOCK_SIZE != read(IN, addr, BLOCK_SIZE)) { - printf("Read error: bad block in file '%s'\n", current_name); + printf("%s: bad block in file '%s'\n", + bb_msg_read_error, current_name); errors_uncorrected = 1; memset(addr, 0, BLOCK_SIZE); } @@ -483,7 +484,8 @@ if (BLOCK_SIZE * nr != lseek(IN, BLOCK_SIZE * nr, SEEK_SET)) die("seek failed in write_block"); if (BLOCK_SIZE != write(IN, addr, BLOCK_SIZE)) { - printf("Write error: bad block in file '%s'\n", current_name); + printf("%s: bad block in file '%s'\n", + bb_msg_write_error, current_name); errors_uncorrected = 1; } } From rep.nop at aon.at Sun Jun 4 13:25:45 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Jun 4 13:25:50 2006 Subject: redundant code in unzip.c ? Message-ID: <20060604202545.GF8161@aon.at> Hi, in unzip.c, one can read: Index: archival/unzip.c =================================================================== --- archival/unzip.c (revision 15268) +++ archival/unzip.c (working copy) @@ -320,9 +320,9 @@ if (verbosity == v_normal) { printf(" creating: %s\n", dst_fn); } unzip_create_leading_dirs(dst_fn); +// isn't this call ---v already done by unzip_create_leading_dirs above? if (bb_make_directory(dst_fn, 0777, 0)) { +// --------------------^ - bb_error_msg_and_die("Failed to create directory"); + bb_error_msg_and_die("Exiting"); } } else { Also, repeating the error message which was already emitted by bb_make_directory() sounds odd, so just saying "Exiting" should be enough, i'd say. If the call really is redundant, the whole if should be deleted. Comments? From rep.nop at aon.at Mon Jun 5 03:35:53 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 03:36:02 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> <20060603225241.GF20193@aon.at> Message-ID: <20060605103553.GH8161@aon.at> On Sun, Jun 04, 2006 at 06:22:26AM -0400, Robert P. J. Day wrote: >On Sun, 4 Jun 2006, Bernhard Fischer wrote: > >> On Sat, Jun 03, 2006 at 06:46:06PM -0400, Robert P. J. Day wrote: >> >On Sat, 3 Jun 2006, Bernhard Fischer wrote: >> > >> >> On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: >> >> >On 7/25/05, Rob Landley wrote: >> >> >... >> >> >>But applied anyway... >> >> >> >> >> >>Rob >> >> > >> >> >This patch was never applied; please apply it now. >> >> > >> >> >libbb.h uses struct sockaddr_in which is defined in netinet/in.h but >> >> >never included. >> >> >> >> This patch shouldn't be needed anymore since the order of includes >> >> were restructered recently. Applets have to include busybox.h as the >> >> first include, lib*/* has to include libbb.h as the first include. >> >> >> >> Applets and library functions MUST not include any header which is >> >> included by platform.h, busybox.h and platform.h, libbb.h >> >> respectively. >> > >> >all right, this is just plain creeping me out, when people start >> >talking about a *required order* of header file inclusion. this is >> >just plain not good. >> >> go understand how some aspects of dmalloc work: http://www.dmalloc.com/ > >i'm not sure i see your point. you're referring to a specific example >of how an enhanced version of some functionality can be used in a >program. > >*i'm* talking about the apparent need to enforce an ordering scheme on >the all-encompassing header files being used for busybox overall. i Not sure if i understand what you mean. >don't think those two situations are comparable. Our platform.h serves (umong other things) as a "config.h" so we don't get errors when an applet does #include which will most likely not exist on your cygwin installation nor on your linux installation. See? From wharms at bfs.de Mon Jun 5 03:55:02 2006 From: wharms at bfs.de (walter harms) Date: Mon Jun 5 03:55:16 2006 Subject: [patch] abuse of strncpy In-Reply-To: <50BF37ECE4954A4BA18C08D0C2CF88CB01A4423A@exmail1.se.axis.com> References: <50BF37ECE4954A4BA18C08D0C2CF88CB01A4423A@exmail1.se.axis.com> Message-ID: <44840D86.8020107@bfs.de> Just for my curiosity, "different semantics and functionality" ? man strlcpy() says: size_t strlcpy (char * dest, const char * src, size_t size); while strncpy: char *strncpy(char *dest, const char *src, size_t n); A grep over busybox (some older version) shows that the return value is actualy used only once. The bb_strlcpy() is only used for system that do not provide a strlcpy by them self (perhaps this can be dropped). re, wh Peter Kjellerstedt wrote: >> -----Original Message----- >> From: busybox-bounces@busybox.net >> [mailto:busybox-bounces@busybox.net] On Behalf Of Tito >> Sent: Friday, June 02, 2006 14:20 >> To: busybox@busybox.net; wharms@bfs.de >> Subject: Re: [patch] abuse of strncpy >> >> On Friday 2 June 2006 10:07, walter harms wrote: >>> Hi Erik good catch, >>> if you are concerned about security why not use strlcpy() or a bb >>> supplied bb_strlcpy() if its not available ?. >> Hi, >> In libbb we have it ;-) >> >> /* Like strncpy but make sure the resulting string is always >> 0 terminated. */ >> char * safe_strncpy(char *dst, const char *src, size_t size) >> { >> dst[size-1] = '\0'; >> return strncpy(dst, src, size-1); >> } > > Is it just me that find the name safe_strncpy() somewhat misleading > when looking at its implementation? What if size == 0? > > I would suggest it is changed to the following: > > char * safe_strncpy(char *dst, const char *src, size_t size) > { > if (!size) { > return dst; > } else { > dst[size-1] = '\0'; > return strncpy(dst, src, size-1); > } > } > > And on the related subject of renaming the above function to > bb_strlcpy(), that would be totally misleading, as strlcpy() has > totally different semantics and functionality. > > //Peter > > > From wharms at bfs.de Mon Jun 5 04:04:06 2006 From: wharms at bfs.de (walter harms) Date: Mon Jun 5 04:04:14 2006 Subject: [patch] save ~600B In-Reply-To: <20060604201452.GE8161@aon.at> References: <20060604184916.GD8161@aon.at> <20060604201452.GE8161@aon.at> Message-ID: <44840FA6.2040204@bfs.de> hi bernhard, just a minor question. Does exit(-1) make sense ? so far i remember the shell expects 0-255. re, wh Bernhard Fischer wrote: > On Sun, Jun 04, 2006 at 08:49:16PM +0200, Bernhard Fischer wrote: >> Hi, >> >> - use bb_msg_... in more places. >> >> While i think that this patch should be ok, i'd be glad if someone could >> look over it (been staring at it for too long). >> >> TIA, >> Bernhard > > updated version 02e > > > =================================================================== > --- networking/libiproute/utils.c (revision 15268) > +++ networking/libiproute/utils.c (working copy) > @@ -240,9 +240,9 @@ > exit(-1); > } > > -void invarg(char *msg, char *arg) > +void invarg(const char const *arg, const char const *opt) > { > - bb_error_msg("argument \"%s\" is wrong: %s", arg, msg); > + bb_error_msg(bb_msg_invalid_arg, arg, opt); > exit(-1); > } > > Index: networking/libiproute/utils.h From rep.nop at aon.at Mon Jun 5 04:28:24 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 04:28:28 2006 Subject: init getty problem Message-ID: <20060605112824.GI8161@aon.at> ----- Forwarded message from jackie ----- Date: Mon, 5 Jun 2006 19:10:37 +0800 From: jackie Subject: Re: init getty problem thks for your kindly reply I enable shadow supported and the problem solved. "Login timed out 60 seconds" is the Bochs simulator's problem. I confige it to run with "ips: 1000000" and my cpu's ips is 2000000. From rep.nop at aon.at Mon Jun 5 04:48:56 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 04:49:03 2006 Subject: [patch] save ~600B In-Reply-To: <44840FA6.2040204@bfs.de> References: <20060604184916.GD8161@aon.at> <20060604201452.GE8161@aon.at> <44840FA6.2040204@bfs.de> Message-ID: <20060605114856.GJ8161@aon.at> On Mon, Jun 05, 2006 at 01:04:06PM +0200, walter harms wrote: >hi bernhard, >just a minor question. >Does exit(-1) make sense ? so far i remember the shell expects 0-255. IMO it does make sense. It it a means to make sure to return ~0, no matter what return type the shell happens to use. So, for "the shell" -- which likely happens to use unsigned char -- we return 255, while we wouldn't have to change all explicit calls to {_,}exit(255) iff the type would change, for whatever reason. Makes sense? If it doesn't, then i'd say "it was already there, thus it's not my fault" :P cheers, >re, > wh > > >Bernhard Fischer wrote: >>On Sun, Jun 04, 2006 at 08:49:16PM +0200, Bernhard Fischer wrote: >>>Hi, >>> >>>- use bb_msg_... in more places. >>> >>>While i think that this patch should be ok, i'd be glad if someone could >>>look over it (been staring at it for too long). >>> >>>TIA, >>>Bernhard >> >>updated version 02e >> >> >>=================================================================== >>--- networking/libiproute/utils.c (revision 15268) >>+++ networking/libiproute/utils.c (working copy) >>@@ -240,9 +240,9 @@ >> exit(-1); >> } >> >>-void invarg(char *msg, char *arg) >>+void invarg(const char const *arg, const char const *opt) >> { >>- bb_error_msg("argument \"%s\" is wrong: %s", arg, msg); >>+ bb_error_msg(bb_msg_invalid_arg, arg, opt); >> exit(-1); >> } >> >>Index: networking/libiproute/utils.h > From rep.nop at aon.at Mon Jun 5 04:50:37 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 04:50:43 2006 Subject: [patch] save ~600B In-Reply-To: <20060605114856.GJ8161@aon.at> References: <20060604184916.GD8161@aon.at> <20060604201452.GE8161@aon.at> <44840FA6.2040204@bfs.de> <20060605114856.GJ8161@aon.at> Message-ID: <20060605115037.GK8161@aon.at> On Mon, Jun 05, 2006 at 01:48:56PM +0200, Bernhard Fischer wrote: >On Mon, Jun 05, 2006 at 01:04:06PM +0200, walter harms wrote: >>hi bernhard, >>just a minor question. >>Does exit(-1) make sense ? so far i remember the shell expects 0-255. > >IMO it does make sense. It it a means to make sure to return ~0, no >matter what return type the shell happens to use. >So, for "the shell" -- which likely happens to use unsigned char -- we >return 255, while we wouldn't have to change all explicit calls to s/wouldn't/would/; >{_,}exit(255) iff the type would change, for whatever reason. >Makes sense? > >If it doesn't, then i'd say "it was already there, thus it's not my fault" :P > >cheers, >>re, >> wh >> >> >>Bernhard Fischer wrote: >>>On Sun, Jun 04, 2006 at 08:49:16PM +0200, Bernhard Fischer wrote: >>>>Hi, >>>> >>>>- use bb_msg_... in more places. >>>> >>>>While i think that this patch should be ok, i'd be glad if someone could >>>>look over it (been staring at it for too long). >>>> >>>>TIA, >>>>Bernhard >>> >>>updated version 02e >>> >>> >>>=================================================================== >>>--- networking/libiproute/utils.c (revision 15268) >>>+++ networking/libiproute/utils.c (working copy) >>>@@ -240,9 +240,9 @@ >>> exit(-1); >>> } >>> >>>-void invarg(char *msg, char *arg) >>>+void invarg(const char const *arg, const char const *opt) >>> { >>>- bb_error_msg("argument \"%s\" is wrong: %s", arg, msg); >>>+ bb_error_msg(bb_msg_invalid_arg, arg, opt); >>> exit(-1); >>> } >>> >>>Index: networking/libiproute/utils.h >> >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox > From wharms at bfs.de Mon Jun 5 05:08:35 2006 From: wharms at bfs.de (walter harms) Date: Mon Jun 5 05:08:41 2006 Subject: [patch] save ~600B In-Reply-To: <20060605114856.GJ8161@aon.at> References: <20060604184916.GD8161@aon.at> <20060604201452.GE8161@aon.at> <44840FA6.2040204@bfs.de> <20060605114856.GJ8161@aon.at> Message-ID: <44841EC3.6060707@bfs.de> Bernhard Fischer wrote: > On Mon, Jun 05, 2006 at 01:04:06PM +0200, walter harms wrote: >> hi bernhard, >> just a minor question. >> Does exit(-1) make sense ? so far i remember the shell expects 0-255. > > IMO it does make sense. It it a means to make sure to return ~0, no > matter what return type the shell happens to use. > So, for "the shell" -- which likely happens to use unsigned char -- we > return 255, while we wouldn't have to change all explicit calls to > {_,}exit(255) iff the type would change, for whatever reason. > Makes sense? > > If it doesn't, then i'd say "it was already there, thus it's not my fault" :P > > cheers, >> re, >> wh >> personally i am the fan of exit( EXIT_FAILURE ) ; we should define a way in the style guide. and get rid of stuff like: exit(ERROR); re, wh From pgf at brightstareng.com Mon Jun 5 05:41:27 2006 From: pgf at brightstareng.com (Paul Fox) Date: Mon Jun 5 05:41:37 2006 Subject: [patch] save ~600B In-Reply-To: wharms's message of Mon, 05 Jun 2006 14:08:35 +0200. <44841EC3.6060707@bfs.de> Message-ID: <22035.1149511287@brightstareng.com> wharm wrote: > Bernhard Fischer wrote: > > On Mon, Jun 05, 2006 at 01:04:06PM +0200, walter harms wrote: > >> hi bernhard, > >> just a minor question. > >> Does exit(-1) make sense ? so far i remember the shell expects 0-255. > > > > IMO it does make sense. It it a means to make sure to return ~0, no > > matter what return type the shell happens to use. > > So, for "the shell" -- which likely happens to use unsigned char -- we > > return 255, while we wouldn't have to change all explicit calls to > > {_,}exit(255) iff the type would change, for whatever reason. > > Makes sense? only if that's what the programmer intended. in my experience, people that write "exit(-1)" usually are confusing the exit status or the program with the return code from a C function, and are forgetting that the traditional error exit status for a program is "1", or some other small non-zero integer. > personally i am the fan of > exit( EXIT_FAILURE ) ; and "EXIT_FAILURE" is cleverly defined as "1", right? why not just "exit(1)"? this keeps it simple, concise, and transparent. > we should define a way in the style guide. > and get rid of stuff like: > exit(ERROR); i agree. but "s/ERROR/EXIT_FAILURE/" accomplishes nothing. paul =--------------------- paul fox, pgf@brightstareng.com From wharms at bfs.de Mon Jun 5 07:44:07 2006 From: wharms at bfs.de (walter harms) Date: Mon Jun 5 07:44:18 2006 Subject: [patch] save ~600B In-Reply-To: <22035.1149511287@brightstareng.com> References: <22035.1149511287@brightstareng.com> Message-ID: <44844337.3080103@bfs.de> Paul Fox wrote: > wharm wrote: > > Bernhard Fischer wrote: > > > On Mon, Jun 05, 2006 at 01:04:06PM +0200, walter harms wrote: > > >> hi bernhard, > > >> just a minor question. > > >> Does exit(-1) make sense ? so far i remember the shell expects 0-255. > > > > > > IMO it does make sense. It it a means to make sure to return ~0, no > > > matter what return type the shell happens to use. > > > So, for "the shell" -- which likely happens to use unsigned char -- we > > > return 255, while we wouldn't have to change all explicit calls to > > > {_,}exit(255) iff the type would change, for whatever reason. > > > Makes sense? > > only if that's what the programmer intended. in my experience, > people that write "exit(-1)" usually are confusing the exit > status or the program with the return code from a C function, and > are forgetting that the traditional error exit status for a > program is "1", or some other small non-zero integer. > > > personally i am the fan of > > exit( EXIT_FAILURE ) ; > > and "EXIT_FAILURE" is cleverly defined as "1", right? why > not just "exit(1)"? this keeps it simple, concise, and transparent. > > > we should define a way in the style guide. > > and get rid of stuff like: > > exit(ERROR); > > i agree. but "s/ERROR/EXIT_FAILURE/" accomplishes nothing. > you are right about the actual result (but i read somewhere some smart system defined exit_* to something wired, never mind). personaly (read: what i actualy trying to do) i want to conform with posix since this is common ground. we both know what EXIT_FAILURE means even if we do not know the aktual number. But was does ERROR mean ? -1, 99, 255 ? I thing we agree that the exit status should be compareable between the bb programs not sometime -1 sometimes 1 or what ever. That is the reason why i said i should belong to the style guide. It is not a matter of live-or-death but readability is not bad after all. re, wh /* i know i does not matter in thins case but: #ifdef vax11c #define EXIT_SUCCESS 1 #define EXIT_FAILURE 2 #endif */ From rob at landley.net Mon Jun 5 07:37:53 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 08:03:56 2006 Subject: [PATCH] Implement doubly-linked list In-Reply-To: <200606012018.41685.yann.morin.1998@anciens.enib.fr> References: <200606010022.28386.yann.morin.1998@anciens.enib.fr> <200605312308.49800.rob@landley.net> <200606012018.41685.yann.morin.1998@anciens.enib.fr> Message-ID: <200606051037.53955.rob@landley.net> On Thursday 01 June 2006 2:18 pm, Yann E. MORIN wrote: > On Thursday 01 June 2006 050, Rob Landley wrote: > > On Wednesday 31 May 2006 6:22 pm, Yann E. MORIN wrote: > > > Here is at last my implementation of doubly-linked lists. > > > > What uses do you have in mind for this? > > Well, it seems some applets makes use of doubly-linked lists. At least > modprobe and ed do. Maybe others as well. See these two messages: > http://www.busybox.net/lists/busybox/2006-May/021645.html > http://www.busybox.net/lists/busybox/2006-May/021661.html I'm offline right now (catching up with email on another interminable Pittsburgh bus ride), but ed can still be removed and I haven't looked at modprobe. You can do anything with a singly linked list you can with a doubly linked one, it's just slower in places. But neither applet has any speed-critical sections I'm aware of... > What annoys me is that some applets makes use of linked lists, and each has > its own implementation. Gathering (singly- or doubly-) linked list > management in a common place seems sensible to me, so that one does'nt have > to re-invent the wheel every time. And because it is a good candidate for > code size reduction as well. Code size reduction yay. Penalizing existing applets, not yay. > > It's an extra 4 bytes per node, plus the code to deal with it. Having > > _both_ singly and doubly linked lists makes little sense, but having > > things that only need singly linked lists be doubly linked makes little > > sense either... > > Yes I do agree. What would be the best practice? > - only doubly-linked lists for all: > -> a 4-byte impact at run-time per node > -> a small impact in code size (35 bytes) > - both types of lists: > -> no run-time impact, as nodes are the strict necessary size. > -> a bigger, but not huge, impact on code size. 3) Rewrite the doubly linked list bits to use singly linked lists? I don't even know what's involved yet, but if I get some time I'll take a look. > > llist_get_front() will segfault if *head is NULL. > > Shame on me. Note for tonight: bed time is 10PM, no later. :-] Oh I've done worse. This is normal review. :) > > - free(*head); > > + if (ENABLE_FEATURE_CLEAN_UP) > > + free(*head); > > We don't know who's calling us, it could be something long-running > > (httpd? Or possibly what httpd _should_ be doing?) Thus the free isn't > > optional. > > That was not my understanding of FEATURE_CLEAN_UP. I didn't understand that > we should take into conideration wether the applet was blindly fast (ls) > or long-running (httpd). But that makes sense. It's more a question of "when is leaking ok?" ls -lR can actually be a bad place for making a free optional, because we don't know how big a filesystem we're going to operate on. If you ls -lR a big nfs mount on a small embedded system, you shouldn't trigger the OOM killer. But if you know you're allocating a finite amount of memory and you know when it goes away if you don't free it, explicitly freeing it can become optional to save code size. > > And yeah, I finally found the chunk you were referring to and it's a case > > of the variable being #ifdefed out and the code barfing on an undeclared > > variable before it gets as far as dead code elimination. The two > > techniques don't mix... > > Yep. Sounds so blatently obvious when you explain things! :-) > > So what next? Let's hold off on this cleanup until the 1.3 timeframe. Possibly having doubly linked list infrastructure is a good thing, but I want to identify more users and make sure they can't easily be rewritten to use our existing lists. (There are all sorts of singly linked list users who aren't using llist_t, I've converted a couple recently...) > Regars, > Yann E. MORIN. Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Mon Jun 5 09:49:38 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Mon Jun 5 09:49:47 2006 Subject: [PATCH] stdio: Add %m Message-ID: <7f45d9390606050949u84cbcd6yd01823e96f8a621@mail.gmail.com> This patch to newlib adds the %m format, which outputs strerror(errno). This format is a glibc extension. I'm not usually a champion of non-standard extensions to any libc. However, this particular extension is used fairly widely and is mostly non-invasive. In particular, busybox uses %m and the maintainers will not accept patches converting this format to %s and strerror(errno) due to the latter taking more space by making, typically, two additional function calls -- one to __errno_location and one to strerror. Cheers, Shaun 2006-06-05 Shaun Jackman * newlib/libc/stdio/vfprintf.c (_vfprintf_r, _vfiprintf_r): Add the %m format, which outputs strerror(errno). This format is a glibc extension. Index: newlib/libc/stdio/vfprintf.c =================================================================== RCS file: /cvs/src/src/newlib/libc/stdio/vfprintf.c,v retrieving revision 1.43 diff -u -r1.43 vfprintf.c --- newlib/libc/stdio/vfprintf.c 28 Oct 2005 21:38:59 -0000 1.43 +++ newlib/libc/stdio/vfprintf.c 5 Jun 2006 16:34:50 -0000 @@ -905,6 +905,10 @@ sign = '-'; break; #endif /* FLOATING_POINT */ + case 'm': /* glibc extension */ + cp = strerror(errno); + size = strlen(cp); + break; case 'n': #ifndef _NO_LONGLONG if (flags & QUADINT) -------------- next part -------------- 2006-06-05 Shaun Jackman * newlib/libc/stdio/vfprintf.c (_vfprintf_r, _vfiprintf_r): Add the %m format, which outputs strerror(errno). This format is a glibc extension. Index: newlib/libc/stdio/vfprintf.c =================================================================== RCS file: /cvs/src/src/newlib/libc/stdio/vfprintf.c,v retrieving revision 1.43 diff -u -r1.43 vfprintf.c --- newlib/libc/stdio/vfprintf.c 28 Oct 2005 21:38:59 -0000 1.43 +++ newlib/libc/stdio/vfprintf.c 5 Jun 2006 16:34:50 -0000 @@ -905,6 +905,10 @@ sign = '-'; break; #endif /* FLOATING_POINT */ + case 'm': /* glibc extension */ + cp = strerror(errno); + size = strlen(cp); + break; case 'n': #ifndef _NO_LONGLONG if (flags & QUADINT) From peter.kjellerstedt at axis.com Mon Jun 5 10:28:41 2006 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Mon Jun 5 10:28:49 2006 Subject: [patch] abuse of strncpy Message-ID: <50BF37ECE4954A4BA18C08D0C2CF88CB01A4423D@exmail1.se.axis.com> > -----Original Message----- > From: busybox-bounces@busybox.net > [mailto:busybox-bounces@busybox.net] On Behalf Of walter harms > Sent: den 5 juni 2006 12:55 > Cc: busybox@busybox.net > Subject: Re: [patch] abuse of strncpy > > Just for my curiosity, "different semantics and functionality" ? > > man strlcpy() says: > size_t strlcpy (char * dest, const char * src, size_t size); > > while strncpy: > char *strncpy(char *dest, const char *src, size_t n); Well, there are two major differences between strncpy() and strlcpy(): 1) strncpy() returns the dest address strlcpy() returns the resulting length which may be >= size, in which case the string was truncated 2) strncpy() pads the destination with NUL characters if there is space strlcpy() always adds one NUL character (if size > 0) So, whether to use strncpy() or strlcpy() is not only about copying a string and making sure it fits in a destination buffer. A reason for using strncpy() may be due to security reasons where you want to make sure that no random data is left in the destination buffer after the copied string. On the other hand, if that is of no concern, strlcpy() should be the right choice as it needs to copy/pad less data and thus should be faster if the destination buffer is large. For more information about strncpy() vs strlcpy(), see: http://www.courtesan.com/todd/papers/strlcpy.html > A grep over busybox (some older version) shows that the > return value is actualy used only once. > > The bb_strlcpy() is only used for system that do not provide > a strlcpy by them self (perhaps this can be dropped). > > re, > wh //Peter From rob at landley.net Mon Jun 5 10:41:17 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 10:41:21 2006 Subject: BUG with usage_compressed (?) In-Reply-To: <20060602075402.GA30246@aon.at> References: <20060530162613.GA14117@aon.at> <200605301629.21574.rob@landley.net> <20060602075402.GA30246@aon.at> Message-ID: <200606051341.17388.rob@landley.net> On Friday 02 June 2006 3:54 am, Bernhard Fischer wrote: > >It's not reproducing here. What's your build environment? > > Turns out that it was broken by this change: > 15257 landley: > -USE_FDFLUSH(APPLET(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER)) > +USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, > _BB_SUID_NEVER, fdflish)) > > as noticed by erik hovland and fixed by pgf in r15262 > > All is well again, in this respect. Which was obvious breakage on my part and I'm glad it's fixed, I'm just wondering why it didn't hit me... Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Mon Jun 5 10:46:29 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 10:46:36 2006 Subject: BUG with usage_compressed (?) In-Reply-To: <200606051341.17388.rob@landley.net> References: <20060530162613.GA14117@aon.at> <200605301629.21574.rob@landley.net> <20060602075402.GA30246@aon.at> <200606051341.17388.rob@landley.net> Message-ID: <20060605174629.GL8161@aon.at> On Mon, Jun 05, 2006 at 01:41:17PM -0400, Rob Landley wrote: >On Friday 02 June 2006 3:54 am, Bernhard Fischer wrote: >> >It's not reproducing here. What's your build environment? >> >> Turns out that it was broken by this change: >> 15257 landley: >> -USE_FDFLUSH(APPLET(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER)) >> +USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, >> _BB_SUID_NEVER, fdflish)) >> >> as noticed by erik hovland and fixed by pgf in r15262 >> >> All is well again, in this respect. > >Which was obvious breakage on my part and I'm glad it's fixed, I'm just >wondering why it didn't hit me... It's still there, see later mail in this thread. From rob at landley.net Mon Jun 5 11:01:07 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 11:01:49 2006 Subject: The getopt long thing breaks the tree. In-Reply-To: <20060602191415.GS20193@aon.at> References: <200605301255.38248.rob@landley.net> <200606021154.09335.rob@landley.net> <20060602191415.GS20193@aon.at> Message-ID: <200606051401.08162.rob@landley.net> On Friday 02 June 2006 3:14 pm, Bernhard Fischer wrote: > >This trend is normal. When the mainline gets bloated enough, a > > slimmed-down fork emerges. Dropbear vs openssh. Galeon vs Mozilla (and > > Firefox vs Galeon, and it's still kinda bloated.) xfce fs kde/gnome. > > uClibc vs glibc, and BusyBox vs most of the GNU tools. > > Yes. So how is providong means to ignore non-standard extensions which > make busybox (as a binary) bigger a bad thing? That's really all what > the getopt_long thing did. Nothing fancy, nothing intrusive. Something that can make busybox smaller on all platforms needs no further justification. :) > >"The nice thing about standards is that there are so many to choose from." > > - Andrew S. Tanenbaum, many years ago... > > > >My lack of caring is deep and profound. I'm not a fan of the LSB. There > > are multiple conflicting standards. Wheee. The application section of > > SUSv3 is incomplete, but vaguely sane. (Only vaguely: We're not > > implementing sccs.) And thus is the frame of reference from which we can > > document how we diverge when we get around to auditing things. > > I was under the impression that SUSv3 also implied that we should try to > provide a working, minimal set that only uses SUSv3. More fancy features > building ontop of eventual extensions should be optional -- > configurable. > > Apparently this is not the case, do i understand you correctly? I'm not against having both projects, but they're separate things. Providing an susv3 conforming environment is something I know how to test, by creating a test suite from reading susv3. Running in a purely susv3 environment isn't something I don't know how to test, because no non-toy environment is purely susv3 (it wouldn't even be able to boot without including stuff that's not in the spec). And if we work in some theoretical pure susv3 environment but find out that approach sucks on Linux or MacOS X, that's still no good. For the first thing, us providing extensions beyond susv3 is not a problem. For the second thing, us using extensions beyond susv3 _is_ a problem. But some of those extensions do indeed make us smaller, so there's an inherent conflict here, and to resolve it we'd either have to accept sub-optimal solutions on a regular basis or else implement stuff twice, which fights against the goal of simplicity of implementation. It's not necessarily an unresolvable problem, but the two issues are _not_ the same thing. > >> > Working around specific deficiencies in the Linux emulation of other > >> > platforms are just that: workarounds. > >> > >> Other platforms have no reason to emulate "Linux" (GNU/Linux). Doing > >> so will make them necessarily bloated and bogged down by legacy crap. > > > >I have no reason to care about those other platforms that are neither > > Linux nor remotely compatible with it. > > Well, in case of getopt, one platform adhered to SUSv3, so according to > the probably wrong assumption that we aimed for SUSv3 as the (minimum) > base, That we provide, not that we run on... > i thought that it would be good to be able to *run* busybox on > platforms that adhere to SUSv3. That may not have been a valid > assumption, though.. In the specific case of getopt() that permutes our arguments, you're right it sucks and it's possible that doing away with it would help everybody, Linux included. Parsing command line arguments to a set of flags and option strings shouldn't be brain surgery, and if we're gluing enough crap onto the front of the library function already, it's possible that by not using the library function at all we'll wind up smaller. Even the function's implementation doesn't shrink, if the lack of permutation means that more apps can use it, and we avoid bugs like the "tar xvjfc" thing, the better behavior might be worth a sufficiently small size penalty. It's very much worth a look. For 1.3.0. It's possible to arrive at the same goal through different means, and the same implementation for different reasons. When I say "that's not a compelling reason for me" that's not the end of the argument, but it does mean that hammering on that reason over and over, ignoring what I said, is likely to annoy me. :) Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Mon Jun 5 11:05:52 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 11:06:00 2006 Subject: ctype.h stuff, saves ~2kB [was: Re: [PATCH] ed stuff #1] In-Reply-To: <20060601193942.GC15547@aon.at> References: <20060601193942.GC15547@aon.at> Message-ID: <20060605180552.GA4573@aon.at> On Thu, Jun 01, 2006 at 09:39:42PM +0200, Bernhard Fischer wrote: >Hi, > >ed is a) bloated and b) broken. Not sure anymore about the broken. From the looks it doesn't implement 'H', which led me to think it didn't behave ok. >The attached patchlet starts to look a tiny bit into a) By now that thing turned into a vaguely insane-sized patch of >80kB. Without too much love, it saves 2255 bytes for defconfig+IMA: text data bss dec hex filename 847079 9100 645216 1501395 16e8d3 busybox_old 844840 9084 645216 1499140 16e004 busybox_unstripped bloatcheck does about agree function old new delta static.busy_loop 3251 3766 +515 static.find_range 399 453 +54 static.vi_word_motion 204 240 +36 static.mke2fs_main 4469 4500 +31 static.bb_isxdigit - 30 +30 static.bb_isalnum - 30 +30 static.vi_back_motion 169 198 +29 static.vi_end_motion 183 209 +26 static.bb_skip_blank - 20 +20 static.read_hex 128 145 +17 static.gethdr 186 201 +15 ext2fs_open_inode_scan 334 349 +15 static.next_token 860 871 +11 static.tune2fs_main 3741 3750 +9 static.zcip_main 1827 1835 +8 ext2fs_block_iterate2 1453 1461 +8 static.assign 113 118 +5 static.run_list_real 2427 2431 +4 static.xargs_exec 257 260 +3 static.printenv_main 129 132 +3 static.parse_stream 1513 1516 +3 static.doset 312 315 +3 static.rdexp 278 280 +2 static.isassign 66 68 +2 static.fixredir 86 88 +2 static.setlocalenv 128 129 +1 static.isalnum_ 33 34 +1 static.bb_xgetularg_bnd_sfx 191 192 +1 static.bb_xgetlarg 101 100 -1 static.bb_ask_confirmation 62 61 -1 static.wc_main 462 460 -2 static.valid_name 56 54 -2 static.umaskcmd 316 314 -2 static.tftp_main 2095 2093 -2 static.is_number 28 26 -2 static.e2fsck_main 3663 3661 -2 static.cal_main 828 826 -2 static.raw_read_blk 242 239 -3 static.makedevs_main 1225 1222 -3 static.fbset_main 2064 2061 -3 static.udhcpd_main 2353 2349 -4 static.trim 81 77 -4 static.hwclock_main 624 620 -4 static.arith 1912 1908 -4 static.trim_trailing_spaces_and_print 51 46 -5 static.st_expr_expand 457 452 -5 static.next_word 91 86 -5 static.ipcrm_main 698 693 -5 static.grave 997 992 -5 static.get_token 66 61 -5 static.dot_skip_over_ws 58 53 -5 static.strip_line 53 47 -6 static.passwd_main 2760 2754 -6 static.parse_file_cmd 103 97 -6 static.lookup 296 290 -6 static.httpd_main 1029 1023 -6 static.decode 65 59 -6 static.bb_skip_whitespace 27 21 -6 static.strings_main 390 383 -7 static.rx_main 1095 1088 -7 static.ronly 38 31 -7 static.getn 177 170 -7 static.bb_mode_string 128 121 -7 static.awk_split 452 445 -7 static.awk_printf 446 439 -7 static.u_signal_names 331 323 -8 static.partname 165 157 -8 static.expand_variable 710 702 -8 static.edit_int 78 70 -8 static.dotrap 276 268 -8 static.subgetc 756 747 -9 static.msh_main 1277 1268 -9 static.make_device 1044 1035 -9 static.initring 53 44 -9 e2p_edit_feature 396 387 -9 static.redirect_opt_num 69 59 -10 static.nslookup_main 215 205 -10 static.kill_main 620 610 -10 static.gzip_main 901 891 -10 static.get_trimmed_slice 47 37 -10 static.get_address 204 194 -10 static.forkexec 1363 1353 -10 static.fdisk_main 2258 2248 -10 static.vi_End_motion 86 75 -11 static.parse_url 312 301 -11 static.include_conf 962 951 -11 static.expand 2427 2416 -11 ext2fs_parse_version_string 51 40 -11 static.vi_Word_motion 93 81 -12 static.vi_Back_motion 89 77 -12 static.bb_dump_add 399 387 -12 static.login_main 1962 1949 -13 static.get_uid_gid 130 117 -13 static.endofname 61 48 -13 static.list_table 1965 1951 -14 static.get_one_address 281 267 -14 static.skip_over_blank 40 25 -15 static.less_main 2292 2277 -15 static.singlemount 4623 4607 -16 static.printf_main 595 579 -16 static.handleIncoming 2235 2219 -16 static.ftpcmd 290 274 -16 static.read_line 163 146 -17 static.parse_conf 1389 1372 -17 static.new_process_module_arguments 1061 1044 -17 static.lsmod_main 448 431 -17 static.fold_main 677 660 -17 static.ifupdown_main 2465 2447 -18 static.uniq_main 447 428 -19 static.setup_redirect 257 238 -19 static.print_e2fsck_message 1254 1235 -19 __parsegrent 237 218 -19 static.read_int 609 589 -20 static.parse_tag_value 107 87 -20 static.config 1586 1566 -20 static.base_device 212 192 -20 static.skip_thing 327 304 -23 static.skip_over_word 70 47 -23 static.read_config_file 1146 1122 -24 static.od_main 589 564 -25 static.ni 244 219 -25 __pgsreader 207 181 -26 static.normalize 220 193 -27 static.getNum 537 510 -27 static.readtoken1 2873 2845 -28 static.parse_word 95 66 -29 static.getty_main 2632 2602 -30 static.syslogd_main 1301 1269 -32 static.mutate_name 233 201 -32 static.fileAction 815 783 -32 blkid_get_devname 1726 1694 -32 static.add_cmd 1204 1167 -37 cmdedit_read_input 3763 3725 -38 static.modprobe_main 1553 1513 -40 static.diffreg 2809 2767 -42 static.if_readlist_proc 733 690 -43 static.get_key 540 493 -47 static.add_interface 269 218 -51 static.wget_main 3242 3182 -60 .rodata 187416 187352 -64 static.refresh 1027 958 -69 static.bb_dump_dump 3043 2973 -70 static.set_os 85 - -85 static.do_cmd 8380 8286 -94 static.ed_main 3050 2854 -196 static.run_command 709 - -709 ------------------------------------------------------------------------------ (add/remove: 3/2 grow/shrink: 25/116 up/down: 884/-2903) Total: -2019 bytes Note that "static.busy_loop" grew since gcc now can inline "static.run_command" into it's only caller. The only caveat is cmdedit.c. Herein, we seem to have a problem possibly due to input_forward() and it's callers disagreeing who should do the check for "cursorComments? Ok to checkin? > > text data bss dec hex filename > 864338 10244 645924 1520506 17337a busybox_old > 864114 10244 645924 1520282 17329a busybox_unstripped > >thanks, From rob at landley.net Mon Jun 5 11:10:07 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 11:10:09 2006 Subject: [PATCH] shell/lash.c: set environment variable In-Reply-To: <7f45d9390606031139g1bcc44daqc68a8483fefb5eff@mail.gmail.com> References: <7f45d9390604211052v64dbb27aydd912021bc6ebb9c@mail.gmail.com> <200605261601.53063.rob@landley.net> <7f45d9390606031139g1bcc44daqc68a8483fefb5eff@mail.gmail.com> Message-ID: <200606051410.07408.rob@landley.net> On Saturday 03 June 2006 2:39 pm, Shaun Jackman wrote: > On 5/26/06, Rob Landley wrote: > > On Friday 26 May 2006 12:11 pm, Shaun Jackman wrote: > > > On 5/26/06, Rob Landley wrote: > > > > I suppose in the short term I could always add this as a config > > > > option, even though we're talking something like 35 bytes here... > > > > > > For the 35 bytes saved, I wouldn't bother with the config option. I > > > don't know where exactly one places the cutoff, but for me it's > > > somewhere above 35 bytes -- and for context, I'm on a 1 MB RAM & 2 MB > > > flash system. > > > > I generally place it around 100 bytes myself, but lash is a special case. > > :) > > For the sake of argument -- and incidentally, furthering the > acceptance of this patch -- let's set the lash limit at 42 bytes, > leaving this patch a good 7 bytes to spare! Please apply. > > Many thanks! > Shaun Actually I made some changes that shrink lash last week. I've got pending stuff in my tree for this, and if I combine that shrinkage with this change I think that I can avoid a net increase in the size of lash... I need more spare time. (The fact that 3 of the past 5 weekends I was out of town didn't help here. And next weekend I have somewhere else to be. I've been _waaaay_ overscheduled the past couple months. Sigh...) Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Mon Jun 5 11:15:20 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 11:15:28 2006 Subject: ctype.h stuff, saves ~2kB [was: Re: [PATCH] ed stuff #1] In-Reply-To: <20060605180552.GA4573@aon.at> References: <20060601193942.GC15547@aon.at> <20060605180552.GA4573@aon.at> Message-ID: <20060605181520.GM8161@aon.at> On Mon, Jun 05, 2006 at 08:05:52PM +0200, Bernhard Fischer wrote: >On Thu, Jun 01, 2006 at 09:39:42PM +0200, Bernhard Fischer wrote: >>Hi, >> >>ed is a) bloated and b) broken. > >Not sure anymore about the broken. From the looks it doesn't implement >'H', which led me to think it didn't behave ok. > >>The attached patchlet starts to look a tiny bit into a) > >By now that thing turned into a vaguely insane-sized patch of >80kB. >Without too much love, it saves 2255 bytes for defconfig+IMA: ... now with said patch, > text data bss dec hex filename > 847079 9100 645216 1501395 16e8d3 busybox_old > 844840 9084 645216 1499140 16e004 busybox_unstripped > >bloatcheck does about agree > >function old new delta >static.busy_loop 3251 3766 +515 >static.find_range 399 453 +54 >static.vi_word_motion 204 240 +36 >static.mke2fs_main 4469 4500 +31 >static.bb_isxdigit - 30 +30 >static.bb_isalnum - 30 +30 >static.vi_back_motion 169 198 +29 >static.vi_end_motion 183 209 +26 >static.bb_skip_blank - 20 +20 >static.read_hex 128 145 +17 >static.gethdr 186 201 +15 >ext2fs_open_inode_scan 334 349 +15 >static.next_token 860 871 +11 >static.tune2fs_main 3741 3750 +9 >static.zcip_main 1827 1835 +8 >ext2fs_block_iterate2 1453 1461 +8 >static.assign 113 118 +5 >static.run_list_real 2427 2431 +4 >static.xargs_exec 257 260 +3 >static.printenv_main 129 132 +3 >static.parse_stream 1513 1516 +3 >static.doset 312 315 +3 >static.rdexp 278 280 +2 >static.isassign 66 68 +2 >static.fixredir 86 88 +2 >static.setlocalenv 128 129 +1 >static.isalnum_ 33 34 +1 >static.bb_xgetularg_bnd_sfx 191 192 +1 >static.bb_xgetlarg 101 100 -1 >static.bb_ask_confirmation 62 61 -1 >static.wc_main 462 460 -2 >static.valid_name 56 54 -2 >static.umaskcmd 316 314 -2 >static.tftp_main 2095 2093 -2 >static.is_number 28 26 -2 >static.e2fsck_main 3663 3661 -2 >static.cal_main 828 826 -2 >static.raw_read_blk 242 239 -3 >static.makedevs_main 1225 1222 -3 >static.fbset_main 2064 2061 -3 >static.udhcpd_main 2353 2349 -4 >static.trim 81 77 -4 >static.hwclock_main 624 620 -4 >static.arith 1912 1908 -4 >static.trim_trailing_spaces_and_print 51 46 -5 >static.st_expr_expand 457 452 -5 >static.next_word 91 86 -5 >static.ipcrm_main 698 693 -5 >static.grave 997 992 -5 >static.get_token 66 61 -5 >static.dot_skip_over_ws 58 53 -5 >static.strip_line 53 47 -6 >static.passwd_main 2760 2754 -6 >static.parse_file_cmd 103 97 -6 >static.lookup 296 290 -6 >static.httpd_main 1029 1023 -6 >static.decode 65 59 -6 >static.bb_skip_whitespace 27 21 -6 >static.strings_main 390 383 -7 >static.rx_main 1095 1088 -7 >static.ronly 38 31 -7 >static.getn 177 170 -7 >static.bb_mode_string 128 121 -7 >static.awk_split 452 445 -7 >static.awk_printf 446 439 -7 >static.u_signal_names 331 323 -8 >static.partname 165 157 -8 >static.expand_variable 710 702 -8 >static.edit_int 78 70 -8 >static.dotrap 276 268 -8 >static.subgetc 756 747 -9 >static.msh_main 1277 1268 -9 >static.make_device 1044 1035 -9 >static.initring 53 44 -9 >e2p_edit_feature 396 387 -9 >static.redirect_opt_num 69 59 -10 >static.nslookup_main 215 205 -10 >static.kill_main 620 610 -10 >static.gzip_main 901 891 -10 >static.get_trimmed_slice 47 37 -10 >static.get_address 204 194 -10 >static.forkexec 1363 1353 -10 >static.fdisk_main 2258 2248 -10 >static.vi_End_motion 86 75 -11 >static.parse_url 312 301 -11 >static.include_conf 962 951 -11 >static.expand 2427 2416 -11 >ext2fs_parse_version_string 51 40 -11 >static.vi_Word_motion 93 81 -12 >static.vi_Back_motion 89 77 -12 >static.bb_dump_add 399 387 -12 >static.login_main 1962 1949 -13 >static.get_uid_gid 130 117 -13 >static.endofname 61 48 -13 >static.list_table 1965 1951 -14 >static.get_one_address 281 267 -14 >static.skip_over_blank 40 25 -15 >static.less_main 2292 2277 -15 >static.singlemount 4623 4607 -16 >static.printf_main 595 579 -16 >static.handleIncoming 2235 2219 -16 >static.ftpcmd 290 274 -16 >static.read_line 163 146 -17 >static.parse_conf 1389 1372 -17 >static.new_process_module_arguments 1061 1044 -17 >static.lsmod_main 448 431 -17 >static.fold_main 677 660 -17 >static.ifupdown_main 2465 2447 -18 >static.uniq_main 447 428 -19 >static.setup_redirect 257 238 -19 >static.print_e2fsck_message 1254 1235 -19 >__parsegrent 237 218 -19 >static.read_int 609 589 -20 >static.parse_tag_value 107 87 -20 >static.config 1586 1566 -20 >static.base_device 212 192 -20 >static.skip_thing 327 304 -23 >static.skip_over_word 70 47 -23 >static.read_config_file 1146 1122 -24 >static.od_main 589 564 -25 >static.ni 244 219 -25 >__pgsreader 207 181 -26 >static.normalize 220 193 -27 >static.getNum 537 510 -27 >static.readtoken1 2873 2845 -28 >static.parse_word 95 66 -29 >static.getty_main 2632 2602 -30 >static.syslogd_main 1301 1269 -32 >static.mutate_name 233 201 -32 >static.fileAction 815 783 -32 >blkid_get_devname 1726 1694 -32 >static.add_cmd 1204 1167 -37 >cmdedit_read_input 3763 3725 -38 >static.modprobe_main 1553 1513 -40 >static.diffreg 2809 2767 -42 >static.if_readlist_proc 733 690 -43 >static.get_key 540 493 -47 >static.add_interface 269 218 -51 >static.wget_main 3242 3182 -60 >.rodata 187416 187352 -64 >static.refresh 1027 958 -69 >static.bb_dump_dump 3043 2973 -70 >static.set_os 85 - -85 >static.do_cmd 8380 8286 -94 >static.ed_main 3050 2854 -196 >static.run_command 709 - -709 >------------------------------------------------------------------------------ >(add/remove: 3/2 grow/shrink: 25/116 up/down: 884/-2903) Total: -2019 >bytes > > >Note that "static.busy_loop" grew since gcc now can inline >"static.run_command" into it's only caller. > >The only caveat is cmdedit.c. Herein, we seem to have a problem possibly >due to input_forward() and it's callers disagreeing who should do the >check for "cursorinput_forward() return e.g false if the check failed and else true. >This potentially allows to shrink vi_word_motion(), vi_back_motion(), >vi_end_motion(), but I didn't look close. > >vi's find_range() is a bit of a beast :) > >Overall it appears to provide for a relatively nice size-savings. > >These two questions still stand unanswered: >>Comments? Ok to checkin? >> >> text data bss dec hex filename >> 864338 10244 645924 1520506 17337a busybox_old >> 864114 10244 645924 1520282 17329a busybox_unstripped >> >>thanks, >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox > -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_ctype_callers.01g.diff.bz2 Type: application/octet-stream Size: 20234 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060605/37a1d3a7/fix_ctype_callers.01g.diff-0001.obj From rep.nop at aon.at Mon Jun 5 11:17:56 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 11:18:06 2006 Subject: [PATCH] shell/lash.c: set environment variable In-Reply-To: <200606051410.07408.rob@landley.net> References: <7f45d9390604211052v64dbb27aydd912021bc6ebb9c@mail.gmail.com> <200605261601.53063.rob@landley.net> <7f45d9390606031139g1bcc44daqc68a8483fefb5eff@mail.gmail.com> <200606051410.07408.rob@landley.net> Message-ID: <20060605181756.GN8161@aon.at> On Mon, Jun 05, 2006 at 02:10:07PM -0400, Rob Landley wrote: >On Saturday 03 June 2006 2:39 pm, Shaun Jackman wrote: >> On 5/26/06, Rob Landley wrote: >> > On Friday 26 May 2006 12:11 pm, Shaun Jackman wrote: >> > > On 5/26/06, Rob Landley wrote: >> > > > I suppose in the short term I could always add this as a config >> > > > option, even though we're talking something like 35 bytes here... >> > > >> > > For the 35 bytes saved, I wouldn't bother with the config option. I >> > > don't know where exactly one places the cutoff, but for me it's >> > > somewhere above 35 bytes -- and for context, I'm on a 1 MB RAM & 2 MB >> > > flash system. >> > >> > I generally place it around 100 bytes myself, but lash is a special case. >> > :) >> >> For the sake of argument -- and incidentally, furthering the >> acceptance of this patch -- let's set the lash limit at 42 bytes, >> leaving this patch a good 7 bytes to spare! Please apply. >> >> Many thanks! >> Shaun > >Actually I made some changes that shrink lash last week. I've got pending >stuff in my tree for this, and if I combine that shrinkage with this change I >think that I can avoid a net increase in the size of lash... Heh text data bss dec hex filename 7481 196 60 7737 1e39 shell/lash.o.orig 7288 196 60 7544 1d78 shell/lash.o see the "ctype.h stuff" patch, incarnation 01g i just sent ;) From yann.morin.1998 at anciens.enib.fr Mon Jun 5 11:43:39 2006 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Mon Jun 5 11:43:48 2006 Subject: [PATCH] Implement doubly-linked list In-Reply-To: <200606051037.53955.rob@landley.net> References: <200606010022.28386.yann.morin.1998@anciens.enib.fr> <200606012018.41685.yann.morin.1998@anciens.enib.fr> <200606051037.53955.rob@landley.net> Message-ID: <200606052043.40012.yann.morin.1998@anciens.enib.fr> Hello Rob & all! On Monday 05 June 2006 163, Rob Landley wrote: > > > What uses do you have in mind for this? > > Well, it seems some applets makes use of doubly-linked lists. At least [--SNIP: modprobe & ed--] > I'm offline right now (catching up with email on another interminable > Pittsburgh bus ride), but ed can still be removed and I haven't looked at > modprobe. Well, I'm building a list (sic!) of applets that need linked list support, wether singly- or doubly-linked, how they use these lists (with a size + void*, with a plain structure, etc...), wether they need both way traversal, etc... See below... > You can do anything with a singly linked list you can with a doubly linked > one, it's just slower in places. But neither applet has any speed-critical > sections I'm aware of... As a side note, modprobe would _not_ strictly need doubly-linked lists, as the list is either tarversed one way or the other (inserting uses tail->head, while removing uses head->tail), thus reversing the list would be as good as using a doubly-linked list. So yes, _in_this_case_, doubly-linked lists are no real use. > Code size reduction yay. Penalizing existing applets, not yay. Agreed. > > Yes I do agree. What would be the best practice? [--SNIP--] > 3) Rewrite the doubly linked list bits to use singly linked lists? Yep, but that would require more functions (or macros?) to easily get to the previous element without each time hand-rolling-back the list. > I don't even know what's involved yet, but if I get some time I'll take a > look. Your enlighten regard on this would be indeed appreciated! At least some global directions as to what is wanted/needed. > > > llist_get_front() will segfault if *head is NULL. > > Shame on me. Note for tonight: bed time is 10PM, no later. :-] > Oh I've done worse. This is normal review. :) Oh, you didn't, did you? Behold! The maintainer is not almighty! Hehe! :-))) [--SNIP: FEATURE_CLEAN_UP explanations--] Again, it sounds so obvious once said this way! > Let's hold off on this cleanup until the 1.3 timeframe. Possibly having > doubly linked list infrastructure is a good thing, but I want to identify > more users and make sure they can't easily be rewritten to use our existing > lists. (There are all sorts of singly linked list users who aren't using > llist_t, I've converted a couple recently...) A job I've started, but which is extremely time-consuming... I'll share my list as soon as it is in a shape suitable for discussion. For now, I've identified 29 applets using linked lists, totalling 43 linked lists (all sorts, singly- or doubly-linked, plain structures, size-and-void*, ...), not counting e2fsprogs, shells and devfsd. But the job isn't yet finished, I've only searched for something called 'next' !!! Once I've managed a more complete listing of lists, I'll list what kind of lists are used, how many times, etc... and post for comments. But I agree that will have to wait for the 1.3.x timeframe! Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? From rob at landley.net Mon Jun 5 11:43:59 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 11:44:01 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060603211647.GC20193@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> <20060603211647.GC20193@aon.at> Message-ID: <200606051443.59576.rob@landley.net> On Saturday 03 June 2006 5:16 pm, Bernhard Fischer wrote: > >See e.g. r15266 and r15267 from yesterday (and yes, there still are some > >directories which aren't yet converted. We'll get to them soon). > > Hm. We'll break dmalloc support with this header move, i think. > #include should be after all other includes.. Fun. Would have been nice if it had had a comment to that effect... Obviously, there are some #includes that dmalloc doesn't need to be after, simply because there is C code that doesn't need to be after. So the question is, _which_ #includes does dmalloc need to be after? Possibly if we're moving most common #includes into libbb.h anyway (so we can get the ordering right in _one_ place), then we can have dmalloc.h be at the end of libbb.h and life is good. > What should we do about this? I'd go for an > #include "busybox_dmalloc.h" > that basically reads > #ifndef BUSYBOX_DMALLOC_H > #define BUSYBOX_DMALLOC_H 1 > #ifdef DMALLOC > #include > #endif > #endif /* BUSYBOX_DMALLOC_H */ > > What do you think? Query: Why are we supporting dmalloc again? (Who uses it, and what for? What's the benefit?) Rob -- Never bet against the cheap plastic solution. From sjackman at gmail.com Mon Jun 5 12:19:51 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Mon Jun 5 12:19:56 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <200606051443.59576.rob@landley.net> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> <20060603211647.GC20193@aon.at> <200606051443.59576.rob@landley.net> Message-ID: <7f45d9390606051219q77c5971fgaf6ea435426633c@mail.gmail.com> On 6/5/06, Rob Landley wrote: > Query: Why are we supporting dmalloc again? (Who uses it, and what for? > What's the benefit?) It's useful for finding memory leaks and other heap abuses. I most recently used it to track down the memory leak in ls. Cheers, Shaun From erik at hovland.org Thu Jun 1 13:37:29 2006 From: erik at hovland.org (Erik Hovland) Date: Mon Jun 5 12:40:17 2006 Subject: fdflush typo breaks build Message-ID: <20060601203729.GB8986@mage.jpl.nasa.gov> package: busybox version: trunk When I do a make allyesconfig (then disable SE Linux) and then type 'make busybox', the build fails with: ehovland@mage:handhelds/busybox-trunk>make busybox HOSTLINK scripts/usage In file included from /export/home/build/handhelds/busybox-trunk/scripts/usage.c:7: /export/home/build/handhelds/busybox-trunk/include/applets.h:112: error: syntax error before "fdflish_trivial_usage" make[1]: *** [scripts/usage] Error 1 make: *** [busybox] Error 2 The attached patch seems to fix the problem (assuming that it is a typo with the fdflush macro. E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- Index: include/applets.h =================================================================== --- include/applets.h (revision 15261) +++ include/applets.h (working copy) @@ -109,7 +109,7 @@ USE_FAKEIDENTD(APPLET(fakeidentd, _BB_DIR_USR_SBIN, _BB_SUID_NEVER)) USE_FALSE(APPLET(false, _BB_DIR_BIN, _BB_SUID_NEVER)) USE_FBSET(APPLET(fbset, _BB_DIR_USR_SBIN, _BB_SUID_NEVER)) -USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER, fdflish)) +USE_FDFLUSH(APPLET_ODDNAME(fdflush, freeramdisk, _BB_DIR_BIN, _BB_SUID_NEVER, fdflush)) USE_FDFORMAT(APPLET(fdformat, _BB_DIR_USR_BIN, _BB_SUID_NEVER)) USE_FDISK(APPLET(fdisk, _BB_DIR_SBIN, _BB_SUID_NEVER)) USE_FEATURE_GREP_FGREP_ALIAS(APPLET_NOUSAGE(fgrep, grep, _BB_DIR_BIN, _BB_SUID_NEVER)) From sjackman at gmail.com Mon Jun 5 13:27:29 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Mon Jun 5 13:27:37 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> Message-ID: <7f45d9390606051327u53d3e1bbh148f1b2ca2b9280a@mail.gmail.com> On 5/30/06, Shaun Jackman wrote: > KERNEL_VERSION is defined conditionally on __linux__, but it's used > throughout without any qualification. It's safest to simply define it > unconditionally. > > Cheers, > Shaun > > 2006-05-30 Shaun Jackman > > * include/platform.h: Define KERNEL_VERSION unconditionally. This patch was applied in svn 15258 by Rob Landley. I didn't see an `applied' mail cross the mailing list, so I thought I'd post one. Cheers, Shaun From rep.nop at aon.at Mon Jun 5 14:13:11 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 14:13:24 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <7f45d9390606051219q77c5971fgaf6ea435426633c@mail.gmail.com> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> <20060603211647.GC20193@aon.at> <200606051443.59576.rob@landley.net> <7f45d9390606051219q77c5971fgaf6ea435426633c@mail.gmail.com> Message-ID: <20060605211311.GO8161@aon.at> On Mon, Jun 05, 2006 at 01:19:51PM -0600, Shaun Jackman wrote: >On 6/5/06, Rob Landley wrote: >>Query: Why are we supporting dmalloc again? (Who uses it, and what for? >>What's the benefit?) > >It's useful for finding memory leaks and other heap abuses. I most >recently used it to track down the memory leak in ls. Yes, it's very handy. Rob, you moving the the #include before the xmalloc prototype (r15287) is not ok (see comment in libbb.h for xmalloc). We have to make sure to at least include the stdlib.h (where {m,c,re}alloc and free come from) before including dmalloc.h. Other candidates who should come before dmalloc.h is e.g. string.h and strings.h Also our xmalloc, xrealloc et. al. prototypes have to come *before* we include dmalloc.h, so it can override our impl (and abort). PS: http://dmalloc.com/docs/5.4.2/online/dmalloc_13.html#SEC13 I'm using check-funcs on a regular basis for other stuff, and it really works best if you just make sure to have dmalloc.h as the last include. It's the least error-prone approach. From farmatito at tiscali.it Mon Jun 5 15:04:48 2006 From: farmatito at tiscali.it (Tito) Date: Mon Jun 5 15:06:02 2006 Subject: The getopt long thing breaks the tree. In-Reply-To: <200606051401.08162.rob@landley.net> References: <200605301255.38248.rob@landley.net> <20060602191415.GS20193@aon.at> <200606051401.08162.rob@landley.net> Message-ID: <200606060004.49081.farmatito@tiscali.it> On Monday 5 June 2006 20:01, Rob Landley wrote: > On Friday 02 June 2006 3:14 pm, Bernhard Fischer wrote: > > >This trend is normal. When the mainline gets bloated enough, a > > > slimmed-down fork emerges. Dropbear vs openssh. Galeon vs Mozilla (and > > > Firefox vs Galeon, and it's still kinda bloated.) xfce fs kde/gnome. > > > uClibc vs glibc, and BusyBox vs most of the GNU tools. > > > > Yes. So how is providong means to ignore non-standard extensions which > > make busybox (as a binary) bigger a bad thing? That's really all what > > the getopt_long thing did. Nothing fancy, nothing intrusive. > > Something that can make busybox smaller on all platforms needs no further > justification. :) > > > >"The nice thing about standards is that there are so many to choose from." > > > - Andrew S. Tanenbaum, many years ago... > > > > > >My lack of caring is deep and profound. I'm not a fan of the LSB. There > > > are multiple conflicting standards. Wheee. The application section of > > > SUSv3 is incomplete, but vaguely sane. (Only vaguely: We're not > > > implementing sccs.) And thus is the frame of reference from which we can > > > document how we diverge when we get around to auditing things. > > > > I was under the impression that SUSv3 also implied that we should try to > > provide a working, minimal set that only uses SUSv3. More fancy features > > building ontop of eventual extensions should be optional -- > > configurable. > > > > Apparently this is not the case, do i understand you correctly? > > I'm not against having both projects, but they're separate things. > > Providing an susv3 conforming environment is something I know how to test, by > creating a test suite from reading susv3. Running in a purely susv3 > environment isn't something I don't know how to test, because no non-toy > environment is purely susv3 (it wouldn't even be able to boot without > including stuff that's not in the spec). And if we work in some theoretical > pure susv3 environment but find out that approach sucks on Linux or MacOS X, > that's still no good. > > For the first thing, us providing extensions beyond susv3 is not a problem. > For the second thing, us using extensions beyond susv3 _is_ a problem. But > some of those extensions do indeed make us smaller, so there's an inherent > conflict here, and to resolve it we'd either have to accept sub-optimal > solutions on a regular basis or else implement stuff twice, which fights > against the goal of simplicity of implementation. > > It's not necessarily an unresolvable problem, but the two issues are _not_ the > same thing. > > > >> > Working around specific deficiencies in the Linux emulation of other > > >> > platforms are just that: workarounds. > > >> > > >> Other platforms have no reason to emulate "Linux" (GNU/Linux). Doing > > >> so will make them necessarily bloated and bogged down by legacy crap. > > > > > >I have no reason to care about those other platforms that are neither > > > Linux nor remotely compatible with it. > > > > Well, in case of getopt, one platform adhered to SUSv3, so according to > > the probably wrong assumption that we aimed for SUSv3 as the (minimum) > > base, > > That we provide, not that we run on... > > > i thought that it would be good to be able to *run* busybox on > > platforms that adhere to SUSv3. That may not have been a valid > > assumption, though.. > > In the specific case of getopt() that permutes our arguments, you're right it > sucks and it's possible that doing away with it would help everybody, Linux > included. hi, I fear that removing argument permutation (you mean reordering?) will increase bb's overall size as several applets use it: int main_applet(int argc, char **argv) { unsigned long opts = bb_getopt_ulflags(); argv+=optind; argc-=optind; while(argc--) { do_something_with(argv++); } return 0; } The fact to have all non-options as last arguments makes it easy to parse them....... Ciao, Tito > Parsing command line arguments to a set of flags and option > strings shouldn't be brain surgery, and if we're gluing enough crap onto the > front of the library function already, it's possible that by not using the > library function at all we'll wind up smaller. Even the function's > implementation doesn't shrink, if the lack of permutation means that more > apps can use it, and we avoid bugs like the "tar xvjfc" thing, the better > behavior might be worth a sufficiently small size penalty. It's very much > worth a look. For 1.3.0. > > It's possible to arrive at the same goal through different means, and the same > implementation for different reasons. When I say "that's not a compelling > reason for me" that's not the end of the argument, but it does mean that > hammering on that reason over and over, ignoring what I said, is likely to > annoy me. :) > > Rob From rep.nop at aon.at Mon Jun 5 15:15:31 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Jun 5 15:15:43 2006 Subject: ctype.h stuff, saves ~2kB [was: Re: [PATCH] ed stuff #1] In-Reply-To: <20060605181520.GM8161@aon.at> References: <20060601193942.GC15547@aon.at> <20060605180552.GA4573@aon.at> <20060605181520.GM8161@aon.at> Message-ID: <20060605221531.GP8161@aon.at> On Mon, Jun 05, 2006 at 08:15:20PM +0200, Bernhard Fischer wrote: >On Mon, Jun 05, 2006 at 08:05:52PM +0200, Bernhard Fischer wrote: >>On Thu, Jun 01, 2006 at 09:39:42PM +0200, Bernhard Fischer wrote: >>>Hi, >>> >>>ed is a) bloated and b) broken. >> >>Not sure anymore about the broken. From the looks it doesn't implement >>'H', which led me to think it didn't behave ok. >> >>>The attached patchlet starts to look a tiny bit into a) >> >>By now that thing turned into a vaguely insane-sized patch of >80kB. >>Without too much love, it saves 2255 bytes for defconfig+IMA: > >... now with said patch, Update on the ctype_callers.01g.diff (the patch from this thread). text data bss dec hex filename 1595 0 24 1619 653 coreutils/tr.o.orig 1535 0 24 1559 617 coreutils/tr.o So the 2-byte size increase from the bloatcheck below is now a 58 Byte size-win from shrinking tr and a 4 byte win from looking at what is...() stuff tr really wants. > >> text data bss dec hex filename >> 847079 9100 645216 1501395 16e8d3 busybox_old >> 844840 9084 645216 1499140 16e004 busybox_unstripped >> >>bloatcheck does about agree >> >>function old new delta >>static.busy_loop 3251 3766 +515 >>static.find_range 399 453 +54 >>static.vi_word_motion 204 240 +36 >>static.mke2fs_main 4469 4500 +31 >>static.bb_isxdigit - 30 +30 >>static.bb_isalnum - 30 +30 >>static.vi_back_motion 169 198 +29 >>static.vi_end_motion 183 209 +26 >>static.bb_skip_blank - 20 +20 >>static.read_hex 128 145 +17 >>static.gethdr 186 201 +15 >>ext2fs_open_inode_scan 334 349 +15 >>static.next_token 860 871 +11 >>static.tune2fs_main 3741 3750 +9 >>static.zcip_main 1827 1835 +8 >>ext2fs_block_iterate2 1453 1461 +8 >>static.assign 113 118 +5 >>static.run_list_real 2427 2431 +4 >>static.xargs_exec 257 260 +3 >>static.printenv_main 129 132 +3 >>static.parse_stream 1513 1516 +3 >>static.doset 312 315 +3 >>static.rdexp 278 280 +2 >>static.isassign 66 68 +2 >>static.fixredir 86 88 +2 >>static.setlocalenv 128 129 +1 >>static.isalnum_ 33 34 +1 >>static.bb_xgetularg_bnd_sfx 191 192 +1 >>static.bb_xgetlarg 101 100 -1 >>static.bb_ask_confirmation 62 61 -1 >>static.wc_main 462 460 -2 >>static.valid_name 56 54 -2 >>static.umaskcmd 316 314 -2 >>static.tftp_main 2095 2093 -2 >>static.is_number 28 26 -2 >>static.e2fsck_main 3663 3661 -2 >>static.cal_main 828 826 -2 >>static.raw_read_blk 242 239 -3 >>static.makedevs_main 1225 1222 -3 >>static.fbset_main 2064 2061 -3 >>static.udhcpd_main 2353 2349 -4 >>static.trim 81 77 -4 >>static.hwclock_main 624 620 -4 >>static.arith 1912 1908 -4 >>static.trim_trailing_spaces_and_print 51 46 -5 >>static.st_expr_expand 457 452 -5 >>static.next_word 91 86 -5 >>static.ipcrm_main 698 693 -5 >>static.grave 997 992 -5 >>static.get_token 66 61 -5 >>static.dot_skip_over_ws 58 53 -5 >>static.strip_line 53 47 -6 >>static.passwd_main 2760 2754 -6 >>static.parse_file_cmd 103 97 -6 >>static.lookup 296 290 -6 >>static.httpd_main 1029 1023 -6 >>static.decode 65 59 -6 >>static.bb_skip_whitespace 27 21 -6 >>static.strings_main 390 383 -7 >>static.rx_main 1095 1088 -7 >>static.ronly 38 31 -7 >>static.getn 177 170 -7 >>static.bb_mode_string 128 121 -7 >>static.awk_split 452 445 -7 >>static.awk_printf 446 439 -7 >>static.u_signal_names 331 323 -8 >>static.partname 165 157 -8 >>static.expand_variable 710 702 -8 >>static.edit_int 78 70 -8 >>static.dotrap 276 268 -8 >>static.subgetc 756 747 -9 >>static.msh_main 1277 1268 -9 >>static.make_device 1044 1035 -9 >>static.initring 53 44 -9 >>e2p_edit_feature 396 387 -9 >>static.redirect_opt_num 69 59 -10 >>static.nslookup_main 215 205 -10 >>static.kill_main 620 610 -10 >>static.gzip_main 901 891 -10 >>static.get_trimmed_slice 47 37 -10 >>static.get_address 204 194 -10 >>static.forkexec 1363 1353 -10 >>static.fdisk_main 2258 2248 -10 >>static.vi_End_motion 86 75 -11 >>static.parse_url 312 301 -11 >>static.include_conf 962 951 -11 >>static.expand 2427 2416 -11 >>ext2fs_parse_version_string 51 40 -11 >>static.vi_Word_motion 93 81 -12 >>static.vi_Back_motion 89 77 -12 >>static.bb_dump_add 399 387 -12 >>static.login_main 1962 1949 -13 >>static.get_uid_gid 130 117 -13 >>static.endofname 61 48 -13 >>static.list_table 1965 1951 -14 >>static.get_one_address 281 267 -14 >>static.skip_over_blank 40 25 -15 >>static.less_main 2292 2277 -15 >>static.singlemount 4623 4607 -16 >>static.printf_main 595 579 -16 >>static.handleIncoming 2235 2219 -16 >>static.ftpcmd 290 274 -16 >>static.read_line 163 146 -17 >>static.parse_conf 1389 1372 -17 >>static.new_process_module_arguments 1061 1044 -17 >>static.lsmod_main 448 431 -17 >>static.fold_main 677 660 -17 >>static.ifupdown_main 2465 2447 -18 >>static.uniq_main 447 428 -19 >>static.setup_redirect 257 238 -19 >>static.print_e2fsck_message 1254 1235 -19 >>__parsegrent 237 218 -19 >>static.read_int 609 589 -20 >>static.parse_tag_value 107 87 -20 >>static.config 1586 1566 -20 >>static.base_device 212 192 -20 >>static.skip_thing 327 304 -23 >>static.skip_over_word 70 47 -23 >>static.read_config_file 1146 1122 -24 >>static.od_main 589 564 -25 >>static.ni 244 219 -25 >>__pgsreader 207 181 -26 >>static.normalize 220 193 -27 >>static.getNum 537 510 -27 >>static.readtoken1 2873 2845 -28 >>static.parse_word 95 66 -29 >>static.getty_main 2632 2602 -30 >>static.syslogd_main 1301 1269 -32 >>static.mutate_name 233 201 -32 >>static.fileAction 815 783 -32 >>blkid_get_devname 1726 1694 -32 >>static.add_cmd 1204 1167 -37 >>cmdedit_read_input 3763 3725 -38 >>static.modprobe_main 1553 1513 -40 >>static.diffreg 2809 2767 -42 >>static.if_readlist_proc 733 690 -43 >>static.get_key 540 493 -47 >>static.add_interface 269 218 -51 >>static.wget_main 3242 3182 -60 >>.rodata 187416 187352 -64 >>static.refresh 1027 958 -69 >>static.bb_dump_dump 3043 2973 -70 >>static.set_os 85 - -85 >>static.do_cmd 8380 8286 -94 >>static.ed_main 3050 2854 -196 >>static.run_command 709 - -709 >>------------------------------------------------------------------------------ >>(add/remove: 3/2 grow/shrink: 25/116 up/down: 884/-2903) Total: -2019 >>bytes >> >> >>Note that "static.busy_loop" grew since gcc now can inline >>"static.run_command" into it's only caller. >> >>The only caveat is cmdedit.c. Herein, we seem to have a problem possibly >>due to input_forward() and it's callers disagreeing who should do the >>check for "cursor>input_forward() return e.g false if the check failed and else true. >>This potentially allows to shrink vi_word_motion(), vi_back_motion(), >>vi_end_motion(), but I didn't look close. >> >>vi's find_range() is a bit of a beast :) >> >>Overall it appears to provide for a relatively nice size-savings. >> >>These two questions still stand unanswered: >>>Comments? Ok to checkin? >>> >>> text data bss dec hex filename >>> 864338 10244 645924 1520506 17337a busybox_old >>> 864114 10244 645924 1520282 17329a busybox_unstripped >>> >>>thanks, From rob at landley.net Mon Jun 5 16:08:27 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 16:08:29 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060604145028.GC8161@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603211647.GC20193@aon.at> <20060604145028.GC8161@aon.at> Message-ID: <200606051908.28039.rob@landley.net> On Sunday 04 June 2006 10:50 am, Bernhard Fischer wrote: > Also, this would allow for providing size-optimized functions like > proposed in patches/woot.txt, so i want to have such an #include. > I don't care whether we call it "busybox_dmalloc.h" or > "busybox_end.h" or > "busybox_include_me_after_all_other_global_includes.h" This is another reason to move the other standard #includes into libbb.h, then we can override them in there if necessary. Rob -- Never bet against the cheap plastic solution. From timothy.m.fierst at lmco.com Mon Jun 5 16:54:59 2006 From: timothy.m.fierst at lmco.com (Fierst, Timothy M) Date: Mon Jun 5 16:55:08 2006 Subject: Inetd will not start telnetd Message-ID: I'm using busybox-1.1.2. I cannot get the inetd built into busybox to start telnetd (also builtin to busybox). If I build busybox with the standalone version of telnetd, everything works fine. My inetd.conf entry: telnet stream tcp nowait root /usr/sbin/telnetd telnetd When I start inetd by the following command: > inetd Then I enter a: > netstat -ant Which shows no daemons at all. When I run telnetd manually the same netstat command shows telnetd listening on port 23. My /etc/services file looks like: telnet 23/tcp I'm using binutils-2.16.1, gcc-3.4.4, and glibc-2.3.5. Running on an m68k mvme16x box. I am mounting devpts, and have it config'd in on busybox (hence telnetd standalone working). Yes, I know ssh is a better option, but at this point I'm going with telnetd, at least until I can verify my inetd is working. Any help would be GREATLY appreciated. I'm at my boiling point trying to figure this out. Sorry if this isn't actually a busybox problem, I will be trying non-busybox versions of inetd and telnetd tomorrow. Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060605/308a2fc9/attachment.htm From timothy.m.fierst at lmco.com Mon Jun 5 16:43:42 2006 From: timothy.m.fierst at lmco.com (Fierst, Timothy M) Date: Mon Jun 5 17:02:47 2006 Subject: Inetd will not start telnetd Message-ID: I'm using busybox-1.1.2. I cannot get the inetd built into busybox to start telnetd (also builtin to busybox). If I build busybox with the standalone version of telnetd, everything works fine. My inetd.conf entry: telnet stream tcp nowait root /usr/sbin/telnetd telnetd When I start inetd by the following command: > inetd Then I enter a: > netstat -ant Which shows no daemons at all. When I run telnetd manually the same netstat command shows telnetd listening on port 23. My /etc/services file looks like: telnet 23/tcp I'm using binutils-2.16.1, gcc-3.4.4, and glibc-2.3.5. Running on a m68k mvme16x box. I am mounting devpts, and have it config'd in on busybox (hence telnetd standalone working). Yes, I know ssh is a better option, but at this point I'm going with telnetd, at least until I can verify my inetd is working. Any help would be GREATLY appreciated. I'm at my boiling point trying to figure this out. Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20060605/b72a8c6d/attachment.html From rob at landley.net Mon Jun 5 19:25:44 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 19:25:47 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <7f45d9390606051219q77c5971fgaf6ea435426633c@mail.gmail.com> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <200606051443.59576.rob@landley.net> <7f45d9390606051219q77c5971fgaf6ea435426633c@mail.gmail.com> Message-ID: <200606052225.44761.rob@landley.net> On Monday 05 June 2006 3:19 pm, Shaun Jackman wrote: > On 6/5/06, Rob Landley wrote: > > Query: Why are we supporting dmalloc again? (Who uses it, and what for? > > What's the benefit?) > > It's useful for finding memory leaks and other heap abuses. I most > recently used it to track down the memory leak in ls. We _intentionally_ leak memory, it's how we free most of it... Oh well, as long as it's useful enough that people who use it are willing to maintain it... > Cheers, > Shaun Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jun 5 19:23:14 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 19:25:55 2006 Subject: [PATCH] Implement doubly-linked list In-Reply-To: <200606052043.40012.yann.morin.1998@anciens.enib.fr> References: <200606010022.28386.yann.morin.1998@anciens.enib.fr> <200606051037.53955.rob@landley.net> <200606052043.40012.yann.morin.1998@anciens.enib.fr> Message-ID: <200606052223.17790.rob@landley.net> On Monday 05 June 2006 2:43 pm, Yann E. MORIN wrote: > > > Yes I do agree. What would be the best practice? > > [--SNIP--] > > > 3) Rewrite the doubly linked list bits to use singly linked lists? > > Yep, but that would require more functions (or macros?) to easily get to > the previous element without each time hand-rolling-back the list. Not brain surgery either. Something like... llist_t *llist_prev(llist_t **list_head, llist_t *this) { llist_t *prev=*llist_head; while (prev && prev->link != this) prev = prev->link; return prev; } Not the world's most efficient code, but it's very small. I'm trying to figure out whether it's worth the extra test to avoid traversing the whole list for the last entry... > > I don't even know what's involved yet, but if I get some time I'll take a > > look. > > Your enlighten regard on this would be indeed appreciated! At least some > global directions as to what is wanted/needed. Doubly linked lists are _always_ a performance hack. The question is, do we have anything that cares enough? I haven't seen an example yet... > > > > llist_get_front() will segfault if *head is NULL. > > > > > > Shame on me. Note for tonight: bed time is 10PM, no later. :-] > > > > Oh I've done worse. This is normal review. :) > > Oh, you didn't, did you? Behold! The maintainer is not almighty! Hehe! > :-))) All the time. Recently, we have: http://busybox.net/downloads/patches/svn-15207.patch And http://busybox.net/downloads/patches/svn-15171.patch > [--SNIP: FEATURE_CLEAN_UP explanations--] > > Again, it sounds so obvious once said this way! I've been programming since I was 12 years old. I've seen just about all the common mistakes because I've _made_ them, at least once... > > Let's hold off on this cleanup until the 1.3 timeframe. Possibly having > > doubly linked list infrastructure is a good thing, but I want to identify > > more users and make sure they can't easily be rewritten to use our > > existing lists. (There are all sorts of singly linked list users who > > aren't using llist_t, I've converted a couple recently...) > > A job I've started, but which is extremely time-consuming... Join the club. :) > I'll share my > list as soon as it is in a shape suitable for discussion. For now, I've > identified 29 applets using linked lists, totalling 43 linked lists (all > sorts, singly- or doubly-linked, plain structures, size-and-void*, ...), > not counting e2fsprogs, shells and devfsd. But the job isn't yet finished, > I've only searched for something called 'next' !!! One thing I've been sort of pondering is whether we can teach our current llist_t infrastructure to use structures that have a next pointer as their first element. In _theory_ we can typecast any structure that starts with a next pointer to llist_t, and it should work for traversing said next pointer. (The compiler is _not_ allowed to reorder structure members, and we told it not to insert any unnecessary padding.) I'm not sure how it would work out. Where would it benefit? Is it worth the trouble? Hasn't gone beyond the vague idea at this point... Possibly we should teach _every_ list data structure to have its allocation be inline instead of a data pointer. (With a wrapper to strdup strings, which is a common thing to do.) It would save memory, and it would save allocations which fragment memory. Dunno. > Once I've managed a more complete listing of lists, I'll list what kind of > lists are used, how many times, etc... and post for comments. > > But I agree that will have to wait for the 1.3.x timeframe! > > Regards, > Yann E. MORIN. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jun 5 19:29:46 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 19:29:45 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060605211311.GO8161@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <7f45d9390606051219q77c5971fgaf6ea435426633c@mail.gmail.com> <20060605211311.GO8161@aon.at> Message-ID: <200606052229.46422.rob@landley.net> On Monday 05 June 2006 5:13 pm, Bernhard Fischer wrote: > On Mon, Jun 05, 2006 at 01:19:51PM -0600, Shaun Jackman wrote: > >On 6/5/06, Rob Landley wrote: > >>Query: Why are we supporting dmalloc again? (Who uses it, and what for? > >>What's the benefit?) > > > >It's useful for finding memory leaks and other heap abuses. I most > >recently used it to track down the memory leak in ls. > > Yes, it's very handy. > > Rob, you moving the the #include before the xmalloc > prototype (r15287) is not ok (see comment in libbb.h for xmalloc). Then it needs a _comment_ that it shouldn't be moved. And we should move the specific protype(s) it needs before where it is now. I'm fine with sequencing requirements, just not hidden or scattered sequencing requirements. > We have to make sure to at least include the stdlib.h (where > {m,c,re}alloc and free come from) before including dmalloc.h. > Other candidates who should come before dmalloc.h is e.g. string.h > and strings.h Woot. It's currently at the end of the #includes that we're doing in libbb.h. We need to move #includes like strings.h into libbb.h from where they are in the individual applets. > Also our xmalloc, xrealloc et. al. prototypes have to come *before* we > include dmalloc.h, so it can override our impl (and abort). > > PS: http://dmalloc.com/docs/5.4.2/online/dmalloc_13.html#SEC13 > I'm using check-funcs on a regular basis for other stuff, and it really > works best if you just make sure to have dmalloc.h as the last include. > It's the least error-prone approach. Ok. I've advocated moving the other common #includes into libbb.h, this would support that. :) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Mon Jun 5 19:33:02 2006 From: rob at landley.net (Rob Landley) Date: Mon Jun 5 19:33:33 2006 Subject: The getopt long thing breaks the tree. In-Reply-To: <200606060004.49081.farmatito@tiscali.it> References: <200605301255.38248.rob@landley.net> <200606051401.08162.rob@landley.net> <200606060004.49081.farmatito@tiscali.it> Message-ID: <200606052233.02771.rob@landley.net> On Monday 05 June 2006 6:04 pm, Tito wrote: > I fear that removing argument permutation (you mean reordering?) will > increase bb's overall size as several applets use it: > > int main_applet(int argc, char **argv) > { > unsigned long opts = bb_getopt_ulflags(); > > argv+=optind; > argc-=optind; > > while(argc--) { > do_something_with(argv++); > } > return 0; > } llist_t *optind; unsigned long opts = bb_getopt_ulflags(blah, &optind); > The fact to have all non-options as last arguments makes it easy to parse > them....... Agreed. But modifying our environment sucks, and screws up the ps display. Rob -- Never bet against the cheap plastic solution. From timothy.m.fierst at lmco.com Mon Jun 5 23:35:38 2006 From: timothy.m.fierst at lmco.com (Fierst, Timothy M) Date: Mon Jun 5 23:35:46 2006 Subject: Inetd will not start telnetd Message-ID: I just compiled in syslogd and got the following message while trying to start inetd: daemon.err inetd[189]: telnet/tcp: unknown service I have all the libnsss_* libraries in my /lib/ folder (busybox is statically linked) My /etc/services has read permissions (I'm logged in as root). Looking at the log message I see this has been encountered before. I will search the mailing list to try to find the solution. Thanks, Tim ________________________________ From: busybox-bounces@busybox.net [mailto:busybox-bounces@busybox.net] On Behalf Of Fierst, Timothy M Sent: Monday, June 05, 2006 6:55 PM To: busybox@busybox.net Subject: Inetd will not start telnetd I'm using busybox-1.1.2. I cannot get the inetd built into busybox to start telnetd (also builtin to busybox). If I build busybox with the standalone version of telnetd, everything works fine. My inetd.conf entry: telnet stream tcp nowait root /usr/sbin/telnetd telnetd When I start inetd by the following command: > inetd Then I enter a: > netstat -ant Which shows no daemons at all. When I run telnetd manually the same netstat command shows telnetd listening on port 23. My /etc/services file looks like: telnet 23/tcp I'm using binutils-2.16.1, gcc-3.4.4, and glibc-2.3.5. Running on an m68k mvme16x box. I am mounting devpts, and have it config'd in on busybox (hence telnetd standalone working). Yes, I know ssh is a better option, but at this point I'm going with telnetd, at least until I can verify my inetd is working. Any help would be GREATLY appreciated. I'm at my boiling point trying to figure this out. Sorry if this isn't actually a busybox problem, I will be trying non-busybox versions of inetd and telnetd tomorrow. Thanks, Tim From ps.m at gmx.net Mon Jun 5 23:53:40 2006 From: ps.m at gmx.net (Peter S. Mazinger) Date: Mon Jun 5 23:54:13 2006 Subject: The getopt long thing breaks the tree. In-Reply-To: <20060602191415.GS20193@aon.at> Message-ID: On Fri, 2 Jun 2006, Bernhard Fischer wrote: > On Fri, Jun 02, 2006 at 11:54:08AM -0400, Rob Landley wrote: > >On Thursday 01 June 2006 12:39 am, Rich Felker wrote: > >> On Wed, May 31, 2006 at 11:24:59PM -0400, Rob Landley wrote: > >> > On Wednesday 31 May 2006 9:40 pm, Rich Felker wrote: > >> > > On Wed, May 31, 2006 at 05:27:58PM -0400, Rob Landley wrote: > >> > > > > What i, personally, care about is standard compliance; There simply > >> > > > > is no such thing like getopt_long nor "struct option". See > >> > > > > http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html > >> > > > > >> > > > There's no such thing as mount in the darn standard either. You > >> > > > should stop using it immediately. > >> > > > >> > > The standard omits mount for a very good reason: not that it should > >> > > not exist, but that specifying such low-level, administrator-specific > >> > > things is not the job of the standard but of the particular > >> > > implementation. > >> > > >> > It is not a complete spec, and it doesn't say we can't rely on things > >> > that aren't in the spec. > >> > >> It doesn't say you can't, but it says that programs that do are not > >> strictly conforming applications. Whether you care or not... > > > >"Don't care" implies a mere lack of caring, where what I actually have is a > >noticeable amount of negative caring here. I care in the opposite direction. > > > >Busybox is not and has never has been a "strictly conforming" application in > >that since. We don't even plan to _provide_ a strictly conforming > >environment since we're not doing the internationalization stuff, so just > >about every applet has a set of environment variables we're supposed to care > >about, but don't. > > > >However, we plan to provide, as one of the configuration options, a reasonably > >accurate SUSv3 environment with only documented deviations. This doesn't > >mean we'll run in one, it means our apps behave according to the descriptions > >in the spec, with specific exceptions such as no internationalization > >support. > > > >Don't confuse the two. > > > >> > There's a difference between the environment we _provide_ and the > >> > environments in which we _build_ and _run_. Pointing to the spec for the > >> > environment we provide, I'll look at. Pointing to the spec about the > >> > environment in which we build and run is something about which I > >> > _DO_NOT_CARE_. > >> > >> .. I think we see. :) > > > >A) If you ignore what I say long enough, I'll start ignoring what _you_ say by > >putting you on my spam filter. > > > >B) You are aware that if I'm pushed enough, I'll delete platform.h and make > >_sure_ the project is Linux-only? I don't want to do that and I think that > >would upset Bernhard, but if it persistently becomes more trouble than it's > >worth and attracts idiots who don't take a hint when it's delivered with a > >hammer to the cranium, I have _mountains_ of escalation I can do here. > > > >> > The environment in which we build and run is Linux. > >> > >> Linux is not a single environment, it's a kernel. > > > >Says Richard Stallman. He is wrong. There's a standard collection of > >packages supported by Red Hat, SuSE, Debian, Gentoo, Slackware, Knoppix, > >Ubuntu, Yellow Dog, and tons of other distros. The common collection of > >applications that build and run on all of them is building on the Linux > >platform. > > > >Richard's still upset because the GNU project died around 1988 when it > >abandoned its monolithic kernel design for a microkernel design it couldn't > >implement. He can't let go. Linux was the successor to a bunch of stalled > >or blocked efforts (the GNU project, comp.os.minix, the berkeley CSRG), some > >of which later revived (Minix had a GPL release, several other follow-ups of > >the Berkeley CSRG are still viable or even successful, in the case of MacOS > >X). > > > >Linux inherited developers and technology from many sources, but it's its own > >project. The only GNU/Linux distribution is Debian because Debian was taken > >over by the FSF fairly early on and was the official FSF distribution of > >Linux until Debian forked away from the FSF very early because nobody can get > >along with Richard for long. > > > >If you care: http://www.faifzilla.org/ch10.html > > > >Which is less than half of the story, by the way. (Follow libc5 to libc6, > >Werner Almsberger is a Cygnus guy who can't stand Richard Stallman. The FSF > >annointed a Linux project as successor and handed over the name because the > >corresponding GNU project was _dead_. Just like they did when egcs became > >gcc 2.95, because the fsf-developed gcc was so dead it was starting to > >_smell_ so they handed over maintainership to the fork everybody was using.) > > > >Busybox 1.00 was a piece of Linux software. It was built on gcc 2.95 or > >greater, with glibc 2.1 or uClibc 0.9.26 or greater under GNU Make 3.79.1 and > >the 2.2 or newer Linux kernel. That's historical fact, that's what it > >NEEDED. Since then we've moved towards C99 but are still GCC-centric (3.2 > >now), and our C libraries are expected to be newer (glibc 2.2 or uClibc > >0.9.27), and linux-2.4, and there's a push to require Make 3.80 that I'm > >still resisting but it's only a matter of time. > > > >And you'll notice, ever single release since 1.00 has been put together by me. > >I didn't become maintainer because Erik suddenly decided I should be > >maintainer. I'd been acting as maintainer for most of a year already, and I > >_did_ make some of the earlier decisions about portability since Erik wasn't > >around to do so. > > > >Shaun Jackman was the first person I was aware of to start poking non-Linux > >changes into the tree (newlib with libgloss). I've been making noises about > >better mmu-less support for a while, and slowly working on it. There's been > >a BSD support patch in bugs.busybox.net (netbsd?) for over a year that I've > >totally ignored because it was too intrusive. > > > >Trying to clean that up into a policy, I introduced platform.h and said it > >would be a good idea to run on things like MacOS X if it's easy to do so and > >we can hide the changes to things like platform.h. I have no problem with > >running on Digital Unix or Cygwin either. But NOT if it hurts our ability to > >run on Linux in the slightest. > > It doesn't hurt our ability to run on linux. It just provides means to > deactivate stuff that may not (resp. is not in some cases) there, so > busybox can be built and run on non-linux hosts. > > > >But you don't attack the standard Linux environment as stupid and that we > >should PORT busybox to MacOS X and rebase with that as our new standard > >platform. That's where it ENDS. Busybox is first and foremost a Linux > >project, and it always will be. We don't stop using glibc extensions just > >because they're glibc extensions. That is not a reason. If your platform > >hasn't got dprintf(), IMPLEMENT IT. I put in the platform.h define because I > >know there's a name conflict, fine. > > > >The current discussion never went through the stage "Since busybox uses > >getopt_long(), should we implement getopt_long() on non-linux platforms that > >want to run busybox?" It never even came up. And that's wrong. > > To be fair, it came up (on irc, fwiw). > > > >The suggestion that we can make busybox smaller by making getopt_ulflags() > >implement its own getopt behavior is a good one. It can make busybox smaller > >ON_LINUX, and it avoids side effects like argument reordering that are bad > >ON_LINUX. And that's a convincing argument. > > > >Reducing the requirements of other platforms to implement Linux APIs if they > >want to run busybox is a fringe benefit. Nothing more. > > > >> The environment > >> you're talking about is GNU/Linux, > > > >No, it's Linux. If I build a system with uClibc, BusyBox, dropbear, X.org, > >and the Linux kernel, it hasn't got a single GNU package in the final > >deployed system. How can that possibly be GNU/Linux? > > > >I may have used GNU tools to build it (unless I grab icc or some such), but > >that's like saying the Windows version of The Gimp is a microsoft product > >because it was built with Visual C. Watcom didn't own OS/2 for the Power PC > >either. > > > >> which I don't have any interest in > >> running anymore due to getting thoroughly sick of it after many years > >> of dealing with all the hacks and bloat. > > > >I'm trying to come up with better replacements for portions of it too. > > > >This trend is normal. When the mainline gets bloated enough, a slimmed-down > >fork emerges. Dropbear vs openssh. Galeon vs Mozilla (and Firefox vs > >Galeon, and it's still kinda bloated.) xfce fs kde/gnome. uClibc vs glibc, > >and BusyBox vs most of the GNU tools. > > Yes. So how is providong means to ignore non-standard extensions which > make busybox (as a binary) bigger a bad thing? That's really all what > the getopt_long thing did. Nothing fancy, nothing intrusive. > > > >Sometimes the forks are internal, such as the modular x.org rewrite (based on > >what was "tinyx"), or matt mackall's -tiny work going into the Linux kernel. > >That's one of the advantages of a modular design, you can replace a component > >with a better implementation. > > > >> > There are specs out there that say what > >> > a Linux environment should look like. The Linux Standard Base is one of > >> > them. > >> > >> The LSB is among the most idiotic "specs" I've ever read. > > > >Didn't say it was a good spec. :) > > > >> It's a waste > >> of hundreds of pages saying essentially "you must have an ABI > >> identical to glibc's". > > > >Ok, the spec there then is the glibc documentation. *shrug*. > > > >> Any spec (such as LSB or SVID) that includes > >> ABI is inherently stupid (from my point of view in case that wasn't > >> clear) since ABI is obviously an implementation issue and not > >> something that needs to be standardized. > > > >So TCP specifying what the on-the-wire protocol should look like (it's binary) > >was a bad thing? Linux still runs (statically linked) binaries that ran > >under 0.01. They disagree with you. > > > >> Moreover if that's not enough LSB actually contradicts POSIX/SUSv3 > >> intentionally due to bugs in Linux. It changes the rules so that the > >> buggy Linux behavior is not considered buggy. :) Unfortunately this > >> actually prevents the bugs in Linux from being fixed. :( > > > >"The nice thing about standards is that there are so many to choose from." - > >Andrew S. Tanenbaum, many years ago... > > > >My lack of caring is deep and profound. I'm not a fan of the LSB. There are > >multiple conflicting standards. Wheee. The application section of SUSv3 is > >incomplete, but vaguely sane. (Only vaguely: We're not implementing sccs.) > >And thus is the frame of reference from which we can document how we diverge > >when we get around to auditing things. > > I was under the impression that SUSv3 also implied that we should try to > provide a working, minimal set that only uses SUSv3. More fancy features > building ontop of eventual extensions should be optional -- > configurable. > > Apparently this is not the case, do i understand you correctly? > > >> > Working around specific deficiencies in the Linux emulation of other > >> > platforms are just that: workarounds. > >> > >> Other platforms have no reason to emulate "Linux" (GNU/Linux). Doing > >> so will make them necessarily bloated and bogged down by legacy crap. > > > >I have no reason to care about those other platforms that are neither Linux > >nor remotely compatible with it. > > Well, in case of getopt, one platform adhered to SUSv3, so according to > the probably wrong assumption that we aimed for SUSv3 as the (minimum) > base, i thought that it would be good to be able to *run* busybox on > platforms that adhere to SUSv3. That may not have been a valid > assumption, though.. I should mention that uClibc provides a config option to disable GNU getopt use, leaving only a minimal (call it SuSv3 compliant) getopt() but removing getopt_long() and getopt_long_only() Peter > >> > You're bitching about an upstream spec that > >> > doesn't specify _init_, so by itself it won't even _boot_. > >> > >> It doesn't specify init because programs running on the system have no > >> use in knowing what init is or whether it even exists. > > > >I know WHY the specs are incomplete. But the fact remains that no > >specification perfectly matches the real world on any system that isn't a toy > >in a laboratory or some overbred ISO9002 piece of crap along the lines of > [snip rest of interresting discussion] > > -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From alfred.hitch at gmail.com Tue Jun 6 00:18:13 2006 From: alfred.hitch at gmail.com (alfred hitch) Date: Tue Jun 6 00:24:16 2006 Subject: 2.4 module on 2.6 kernel with busybox v 1 Message-ID: <29f916510606060018s659d472fh619f2a4966e1f0ba@mail.gmail.com> Hi Guys, I will appreciate some help on a (perhaps) trivial issue I am facing. I am trying to insmod some 2.4 module binaries I have with me. On a 2.6.12 kernel from snapgear 3.3 with busybox v1. It's giving me : insmod: Cannot insert XXX invalid module format (-1). Exec format error. I have enabled support for 2.4 modules in busybox compilation screen. Any pointers will be helpfull. Cheers, Alfred From rep.nop at aon.at Tue Jun 6 00:45:03 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jun 6 00:45:10 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <200606052229.46422.rob@landley.net> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <7f45d9390606051219q77c5971fgaf6ea435426633c@mail.gmail.com> <20060605211311.GO8161@aon.at> <200606052229.46422.rob@landley.net> Message-ID: <20060606074503.GA3015@aon.at> On Mon, Jun 05, 2006 at 10:29:46PM -0400, Rob Landley wrote: >On Monday 05 June 2006 5:13 pm, Bernhard Fischer wrote: >> On Mon, Jun 05, 2006 at 01:19:51PM -0600, Shaun Jackman wrote: >> >On 6/5/06, Rob Landley wrote: >> >>Query: Why are we supporting dmalloc again? (Who uses it, and what for? >> >>What's the benefit?) >> > >> >It's useful for finding memory leaks and other heap abuses. I most >> >recently used it to track down the memory leak in ls. >> >> Yes, it's very handy. >> >> Rob, you moving the the #include before the xmalloc >> prototype (r15287) is not ok (see comment in libbb.h for xmalloc). > >Then it needs a _comment_ that it shouldn't be moved. And we should move the >specific protype(s) it needs before where it is now. > >I'm fine with sequencing requirements, just not hidden or scattered sequencing >requirements. [] I'll try to find the time to take care of this. From rep.nop at aon.at Tue Jun 6 00:47:58 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Jun 6 00:48:01 2006 Subject: procps In-Reply-To: <200606052233.02771.rob@landley.net> References: <200605301255.38248.rob@landley.net> <200606051401.08162.rob@landley.net> <200606060004.49081.farmatito@tiscali.it> <200606052233.02771.rob@landley.net> Message-ID: <20060606074758.GB3015@aon.at> On Mon, Jun 05, 2006 at 10:33:02PM -0400, Rob Landley wrote: >On Monday 05 June 2006 6:04 pm, Tito wrote: >Agreed. But modifying our environment sucks, and screws up the ps display. Speaking of procps.. top (which is a memory-hog) displays as "exe". Anyone looked into this already or do we just not care? From alfred.hitch at gmail.com Tue Jun 6 02:45:35 2006 From: alfred.hitch at gmail.com (alfred hitch) Date: Tue Jun 6 02:45:38 2006 Subject: 2.4 module on 2.6 kernel with busybox v 1 In-Reply-To: <20060606081557.GA13216@fms-computer.local> References: <29f916510606060018s659d472fh619f2a4966e1f0ba@mail.gmail.com> <20060606081557.GA13216@fms-computer.local> Message-ID: <29f916510606060245n4cfb371bu9e4ee969f213d0cc@mail.gmail.com> yea they are ! I had to upgrade compiler to get 2.6 working. How does that make a difference ? How to correct this ? There got to be someway to get pre compiled binaries to work on new OS ? any modversion off etc ? Cheers, Alfred On 6/6/06, Jan Setzer wrote: > > Hello, > > > I am trying to insmod some 2.4 module binaries I have with me. > > On a 2.6.12 kernel from snapgear 3.3 with busybox v1. > > > > It's giving me : insmod: Cannot insert XXX invalid module format > > (-1). Exec format error. > > > > I have enabled support for 2.4 modules in busybox compilation screen. > > Any pointers will be helpfull. > > Maybe you've compilied the modules with differen compiler-versions. > > Best whishs > > Jan Setzer > -- > jan.setzer@fms-computer.com > http://www.fms-computer.com > From rob at landley.net Tue Jun 6 08:39:10 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 08:39:52 2006 Subject: The getopt long thing breaks the tree. In-Reply-To: References: Message-ID: <200606061139.11088.rob@landley.net> On Tuesday 06 June 2006 2:53 am, Peter S. Mazinger wrote: If the quote is more than about 5 consecutive pages of text, could we trim it a _little_ please? > > Well, in case of getopt, one platform adhered to SUSv3, so according to > > the probably wrong assumption that we aimed for SUSv3 as the (minimum) > > base, i thought that it would be good to be able to *run* busybox on > > platforms that adhere to SUSv3. That may not have been a valid > > assumption, though.. > > I should mention that uClibc provides a config option to disable GNU > getopt use, leaving only a minimal (call it SuSv3 compliant) getopt() but > removing getopt_long() and getopt_long_only() Yup. What does getopt() really get us at that point, though? We _already_ have to parse the getopt format string in order to see what &pointers to stuff results back into and what flags to set in getopt_ulflags(). Going "if (*argv[i] == '-') {}" ain't brain surgery on top of that... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 08:43:02 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 08:43:38 2006 Subject: procps In-Reply-To: <20060606074758.GB3015@aon.at> References: <200605301255.38248.rob@landley.net> <200606052233.02771.rob@landley.net> <20060606074758.GB3015@aon.at> Message-ID: <200606061143.03173.rob@landley.net> On Tuesday 06 June 2006 3:47 am, Bernhard Fischer wrote: > On Mon, Jun 05, 2006 at 10:33:02PM -0400, Rob Landley wrote: > >On Monday 05 June 2006 6:04 pm, Tito wrote: > > > >Agreed. But modifying our environment sucks, and screws up the ps > > display. > > 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 -- Never bet against the cheap plastic solution. From pgf at brightstareng.com Tue Jun 6 09:24:02 2006 From: pgf at brightstareng.com (Paul Fox) Date: Tue Jun 6 09:24:15 2006 Subject: OT: tiny mDNS? Message-ID: <17741.1149611042@brightstareng.com> anyone have pointers to a small mDNS client, appropriate for your basic ethernet-connected embedded system? i'm familiar with the major implementations mostly in name only (howl, avahi). is the avahi daemon small enough to consider? we did put the portable apple code on one product, but it was a little cumbersome and large for my tastes. (i'm hoping someone will say they have a busybox applet all ready to go. ;-) paul =--------------------- paul fox, pgf@brightstareng.com From timothy.m.fierst at lmco.com Tue Jun 6 09:53:40 2006 From: timothy.m.fierst at lmco.com (Fierst, Timothy M) Date: Tue Jun 6 09:53:51 2006 Subject: Inetd will not start telnetd Message-ID: Yeah, I tried different combinations of etc/services, all with the line "telnet 23/tcp" in them. Made sure the file was readable to all. I think the real problem is with my dynamic libnsss_* libraries. If my inetd.conf file changes from: telnet stream tcp nowait root /usr/sbin/telnetd telnetd to: 23 stream tcp nowait root /usr/sbin/telnetd telnetd everything works fine. I have all my libnsss_* files in my /lib/ directory, but maybe there is more to it than that. My busybox is linked statically but with glibc, the libnsss_* can only be linked dynamically. -Tim -----Original Message----- From: Ralph Siemsen [mailto:rsiemsen@rossvideo.com] Sent: Tuesday, June 06, 2006 6:28 AM To: Fierst, Timothy M Cc: busybox@busybox.net Subject: Re: Inetd will not start telnetd Fierst, Timothy M wrote: > I just compiled in syslogd and got the following message while trying to > start inetd: > > daemon.err inetd[189]: telnet/tcp: unknown service Check that the /etc/services file exists and has an entry for telnet. -R From e.spakman at inter.nl.net Tue Jun 6 09:46:03 2006 From: e.spakman at inter.nl.net (Eric Spakman) Date: Tue Jun 6 10:38:39 2006 Subject: OT: tiny mDNS? In-Reply-To: <17741.1149611042@brightstareng.com> References: <17741.1149611042@brightstareng.com> Message-ID: <20060606184603.C6AEAEF0.e.spakman@inter.nl.net> Hello Paul, After much testing the version from Apple seems to be the smallest and best working. Avahi is much bigger/difficult and has various dependencies. I will send you the package and buildtool setup later. I can't commit it because it's not GPL-ed.... Sorry, there isn't a busybox applet AFAIK ;-) Eric >anyone have pointers to a small mDNS client, appropriate for your >basic ethernet-connected embedded system? i'm familiar with the >major implementations mostly in name only (howl, avahi). is the >avahi daemon small enough to consider? we did put the portable >apple code on one product, but it was a little cumbersome and >large for my tastes. (i'm hoping someone will say they have a >busybox applet all ready to go. ;-) > >paul >=--------------------- > paul fox, pgf@brightstareng.com >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox From rob at landley.net Tue Jun 6 12:01:10 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 12:01:16 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> Message-ID: <200606061501.10839.rob@landley.net> On Thursday 01 June 2006 11:48 am, Shaun Jackman wrote: > On 5/31/06, Robert P. J. Day wrote: > > or conditionally define it to be something generically meaningless if > > the OS is *not* linux? > > I thought of that, and initially thought, "What's the point", since > KERNEL_VERSION just assembles a constant anyways. > KERNEL_VERSION(2,6,0) is simply a pretty way of writing 0x20600. I > didn't think mucking with a macro that only defines a constant had any > benefit. > > There is, however, an inherent problem with get_linux_version_code. It > returns the version of not only Linux, but any system that implements > uname. It seems some incorrect decisions could be made if busybox were > running on FreeBSD 6.1, and Busybox thought it were running on Linux > 6.1.0, or possibly Linux 0.6.1. Looking at it now, it seems > get_linux_version_code would simply crash -- thou shalt not follow the > NULL pointer [1] -- if it were passed a version number with only two > digits. See, I'm interested in MacOS X because millions of people actually _use_ it. I've never been able to keep freebsd/netbsd/openbsd/dragonfly straight, but I do know that Apple hired away a decent chunk of the FreeBSD developers (like Jordan Hubbard) to staff MacOS X. I'm sure more people have wandered in since (kerneltrap.org and kernelplanet.org cover them from time to time, for no readily apparent reason). I really can't bring myself to care in the abstract, though. When FreeBSD developers start showing up with patches, I'll worry about it. :) That said, let's take a look at cleaning this up: networking/interface.c: we don't care about pre-2.4, and certainly not pre-2.1. That test can just get yanked. modultils/rmmod.c: the combination of CONFIG_FEATURE_2_6_MODULES, ENABLE_FEATURE_2_4_MODULES, and the kernel version check for 2.6.0 is just icky. (I understand why it's there, but it's still icky. Pondering the utility of a busybox built to be 2.4/2.6 kernel agnostic. Possibly we're getting to the point where 2.4 vs 2.6 module support is one switch...) However, this is linux-specific code and anybody trying to build _any_ of this on non-linux is doing something nonsensical, so it's not relevant to the topic at hand. libbb/loop.c: This test matters, but again loopback mounting is linux-specific (the current code certainly is)... util-linux/nfsmount.c: All this is checking for earlier than 2.4, and thus it can go. (Note some tests are inverted.) util-linux/mkswap.c: again, we only care about 2.4 vs 2.6, not 2.2 and earlier. Yankable. init/init.c: defines but apparently does not use KERNEL_VERSION(). Huh? e2fsprogs/mke2fs.c: again, < 2.2 is not an interesting test. > My conclusion is that any branch on get_linux_version_code should > probably also specify which branch to take if it's *not* running on > Linux, but a generic POSIX/SUS system. Read the code first. Most of it can be removed, and more than half of it is in code that's pretty deeply Linux-specific anyway. > Cheers, > Shaun > > [1] 2. Thou shalt not follow the NULL pointer, for chaos and madness > await thee at its end. 2) If chaos and madness are already a given if you get that far, thou shalt not add a test to rearrange the deck chairs on the titanic. > Clearly the holy scriptures were mis-transcribed here, as the words > should have been ``null pointer'', to minimize confusion between the > concept of null pointers and the macro NULL (of which more anon). > Otherwise, the meaning is plain. A null pointer points to regions > filled with dragons, demons, core dumps, and numberless other foul > creatures, all of which delight in frolicing in thy program if thou > disturb their sleep. And on linux and any other sane unix-like system going back to the 1970's we have an inaccessible page mapped there and any attempt to read from it or write to it gives a clean segfault. > A null pointer doth not point to a 0 of any type, Yes, it does. And we check for this all over the place. if(!thing || !*thing) blah. Any system that doesn't understand that is too stupid to live, and will NEVER be supported. Period. Full stop. > despite some blasphemous old code which impiously assumes this. You are, quite simply, wrong. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 12:03:24 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 12:03:24 2006 Subject: [PATCH] Implement doubly-linked list In-Reply-To: <20060601173654.GA15547@aon.at> References: <200606010022.28386.yann.morin.1998@anciens.enib.fr> <200606010130.23943.yann.morin.1998@anciens.enib.fr> <20060601173654.GA15547@aon.at> Message-ID: <200606061503.24441.rob@landley.net> On Thursday 01 June 2006 1:36 pm, Bernhard Fischer wrote: > On Thu, Jun 01, 2006 at 01:30:23AM +0200, Yann E. MORIN wrote: > >On Thursday 01 June 2006 002, Yann E. MORIN wrote: > >> 003-doubly_linked_lists.patch > >> - adds the configuration option CONFIG_FEATURE_DLLIST: > >> - prompt is visible only if building the shared library, > >> - defaults to no, > > May i point you to xargs.c's xlist_t which wants a singly-linked list > with a runlength for the data? > Didn't look, but perhaps there are other users (ed has a LINE -- i'm > thinking of busyboxifying ed, it's seems to be very, very bloated and > doesn't even pass two dozends of the GNU ed's tests, FWIW), Have fun. (I didn't say it was a _good_ ed. Just that the patches directory should go, ideally before 1.2.0). Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 12:06:13 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 12:06:12 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: <20060601174448.GB15547@aon.at> References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> <20060601174448.GB15547@aon.at> Message-ID: <200606061506.13588.rob@landley.net> On Thursday 01 June 2006 1:44 pm, Bernhard Fischer wrote: > nitpicking.. > May i point to the archives, where i wanted a > #define KERNEL_VERSION(os,maj,min,patch) \ > os##_kernel_version(maj,min,patch) > > This would IMO be the most robust solution. Think about what you're suggesting, please. Every single use of KERNEL_VERSION() (both current use and _conceivable_ use) is asking "does this kernel version support what I'm about to try to do". Asking for KERNEL_VERSION(1.2.3) without specifying whether it's linux, darwin, or System V you're asking about is NONSENSICAL. Let's start by removing the questions we're asking that we no longer care about, that is "is this < a 2.4 Linux kernel". Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 12:13:34 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 12:13:32 2006 Subject: ok, what's the official take on "endianness"? In-Reply-To: References: Message-ID: <200606061513.35007.rob@landley.net> On Thursday 01 June 2006 1:46 pm, Robert P. J. Day wrote: > probably a silly question, but what's the whole story on best > practises for dealing with endianness? We recently grew better support for endianness in platform.h. We define BB_BIG_ENDIAN and BB_LITTLE_ENDIAN, each of which is true or false depending on the current platform. We also have six macros: SWAP_BE16(), SWAP_BE32(), SWAP_BE64(), SWAP_LE16(), SWAP_LE32(), and SWAP_LE64(). Each of these returns the modified data (if you want to convert in place, assign it back to itself.) Use these when you know the data is in a given format, so: uint32_t external; external = SWAP_LE32(external); external += 42; external = SWAP_LE32(external); On a little-endian system, the swap is a NOP, and the assignment to itself gets optimized away. On a big-endian system, it should swap before doing the addition, and then swap it back afterwards. > rday Rob -- Never bet against the cheap plastic solution. From kenm at desertweyr.com Tue Jun 6 13:11:28 2006 From: kenm at desertweyr.com (Ken McGuire) Date: Tue Jun 6 13:10:10 2006 Subject: ok, what's the official take on "endianness"? and hdparm problem In-Reply-To: <200606061513.35007.rob@landley.net> References: Message-ID: <44858D10.5333.1AE0B7A@localhost> On 6 Jun 2006 at 15:13, Rob Landley wrote: > On Thursday 01 June 2006 1:46 pm, Robert P. J. Day wrote: > > probably a silly question, but what's the whole story on best > > practises for dealing with endianness? > > We recently grew better support for endianness in platform.h. > > We define BB_BIG_ENDIAN and BB_LITTLE_ENDIAN, each of which is true or false > depending on the current platform. > > We also have six macros: SWAP_BE16(), SWAP_BE32(), SWAP_BE64(), SWAP_LE16(), > SWAP_LE32(), and SWAP_LE64(). Each of these returns the modified data (if > you want to convert in place, assign it back to itself.) Use these when you > know the data is in a given format, so: > > uint32_t external; > > external = SWAP_LE32(external); > external += 42; > external = SWAP_LE32(external); > > On a little-endian system, the swap is a NOP, and the assignment to itself > gets optimized away. On a big-endian system, it should swap before doing the > addition, and then swap it back afterwards. > > > rday > > Rob > -- > Never bet against the cheap plastic solution. > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > Rob, I think I have found where the problem with hdparm is when running on my ppc system. To review; iBook ppc G3 running ubuntu 5.10, gcc 4.0.2 busybox svn 15284. hdparm -I /dev/hda produces incorrect results which appear to be an endian problem. I poked around in hdparm.c and found the nice new macros described below. I also found this in "identify()": if (BB_BIG_ENDIAN) { swab(id_supplied, buf, sizeof(buf)); val = buf; } else val = id_supplied; Even with the nice new macros, hdparm still produced the same errors as in earlier versions (svn 15237). I removed the above test and the busybox hdparm now produces the same result as the ubuntu hdparm (v6.1) I have attached a patch for this, but have only tested it on one ppc system so far. There also may be some other cleanup that you might want to do as gcc reports that buf[] is now unused. ...ken... From kenm at desertweyr.com Tue Jun 6 13:11:28 2006 From: kenm at desertweyr.com (Ken McGuire) Date: Tue Jun 6 13:10:22 2006 Subject: ok, what's the official take on "endianness"? and hdparm problem In-Reply-To: <200606061513.35007.rob@landley.net> References: Message-ID: <44858D10.13863.1AE0A6A@localhost> * This message contains the file 'patch.bb1', which has been * uuencoded. If you are using Pegasus Mail, then you can use * the browser's eXtract function to lift the original contents * out to a file, otherwise you will have to extract the message * and uudecode it manually. begin 660 patch.bb1 M26YD97@Z(&UI&9F.PH@"B`@ ` end From bug1 at ihug.co.nz Tue Jun 6 13:37:03 2006 From: bug1 at ihug.co.nz (Glenn L. McGrath) Date: Tue Jun 6 13:37:16 2006 Subject: Inetd will not start telnetd In-Reply-To: References: Message-ID: <20060607083703.2e3fce5f.bug1@ihug.co.nz> On Tue, 06 Jun 2006 11:53:40 -0500 "Fierst, Timothy M" wrote: > Yeah, I tried different combinations of etc/services, all with the line > "telnet 23/tcp" in them. Made sure the file was readable to all. > > I think the real problem is with my dynamic libnsss_* libraries. If my > inetd.conf file changes from: > > telnet stream tcp nowait root /usr/sbin/telnetd telnetd > > to: > > 23 stream tcp nowait root /usr/sbin/telnetd telnetd > > everything works fine. I have all my libnsss_* files in my /lib/ > directory, but maybe there is more to it than that. My busybox is > linked statically but with glibc, the libnsss_* can only be linked > dynamically. Do you have an /etc/services file? /etc/services is used to resolve port names to numbers. Glenn From bug1 at ihug.co.nz Tue Jun 6 13:38:40 2006 From: bug1 at ihug.co.nz (Glenn L. McGrath) Date: Tue Jun 6 13:39:03 2006 Subject: Inetd will not start telnetd In-Reply-To: <20060607083703.2e3fce5f.bug1@ihug.co.nz> References: <20060607083703.2e3fce5f.bug1@ihug.co.nz> Message-ID: <20060607083840.38969e6c.bug1@ihug.co.nz> On Wed, 7 Jun 2006 08:37:03 +1200 "Glenn L. McGrath" wrote: > Do you have an /etc/services file? Duoh, guess i should read before posting Glenn From sjackman at gmail.com Tue Jun 6 13:56:19 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Tue Jun 6 13:56:22 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: <200606061501.10839.rob@landley.net> References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> <7f45d9390606010848t5adb385ao12bbcbd5314effd4@mail.gmail.com> <200606061501.10839.rob@landley.net> Message-ID: <7f45d9390606061356u14a47b6cp50dd9d880f39f828@mail.gmail.com> I was only being troubled by network/interface.c. If that check can go away, then I have no further complaints. On 6/6/06, Rob Landley wrote: > On Thursday 01 June 2006 11:48 am, Shaun Jackman wrote: > > [1] 2. Thou shalt not follow the NULL pointer, for chaos and madness > > await thee at its end. I should have mentioned that I was quoting `The Ten Commandments for C Programmers (Annotated Edition)' by Henry Spencer. These are not my words. Sorry for the confusion. > And on linux and any other sane unix-like system going back to the 1970's we > have an inaccessible page mapped there and any attempt to read from it or > write to it gives a clean segfault. On an embedded system without an MMU or even an MPU, this desirable feature is sadly not an option. Considering uClinux is only a configuration of Linux these days, your statement is false. > > A null pointer doth not point to a 0 of any type, > > Yes, it does. And we check for this all over the place. > > if(!thing || !*thing) blah. > > Any system that doesn't understand that is too stupid to live, and will NEVER > be supported. Period. Full stop. It's not saying that a NULL pointer is not 0, this is in fact defined by the C standard. It's saying that dereferensing the NULL pointer does not necessarily give another NULL pointer. There used to be systems that depended on assert(*NULL == NULL), allowing your above test to be reduced to simply if(!*thing), which used to be a common idiom for if(thing == NULL || *thing == NULL). > > despite some blasphemous old code which impiously assumes this. > > You are, quite simply, wrong. ... unless you've misunderstood the original statement. Although, I suppose all rebuttals have to start with the basic assumption that the opposition has understood the proposition's argument. Cheers, Shaun From rob at landley.net Tue Jun 6 14:18:50 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 14:19:03 2006 Subject: [PATCH] ed stuff #1 In-Reply-To: <20060601193942.GC15547@aon.at> References: <20060601193942.GC15547@aon.at> Message-ID: <200606061718.52367.rob@landley.net> On Thursday 01 June 2006 3:39 pm, Bernhard Fischer wrote: > Hi, > > ed is a) bloated and b) broken. > The attached patchlet starts to look a tiny bit into a) > > Comments? Ok to checkin? > > text data bss dec hex filename > 864338 10244 645924 1520506 17337a busybox_old > 864114 10244 645924 1520282 17329a busybox_unstripped > > thanks, I have no attachment whatsoever to ed, but I do care about libbb. You're adding a new function and attributing it to Manuel Nova from three years ago? Why have both skip_whitespace() and skip_blank()? What's the point? I notice that ed.c uses isblank() for everything, and never isspace(), so it's not actually _distinguishing_ between them. That seems more like a stylistic choice than anything else. If you really do feel the need to add skip_blank(), just throw it in skip_whitespace.c (since you're touching that file anyway...) and make it a mult-obj file. But better yet, can ed.c just use skip_whitespace? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 14:26:56 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 14:26:56 2006 Subject: ctype.h stuff, saves ~2kB [was: Re: [PATCH] ed stuff #1] In-Reply-To: <20060605181520.GM8161@aon.at> References: <20060601193942.GC15547@aon.at> <20060605180552.GA4573@aon.at> <20060605181520.GM8161@aon.at> Message-ID: <200606061726.56580.rob@landley.net> On Monday 05 June 2006 2:15 pm, Bernhard Fischer wrote: > On Mon, Jun 05, 2006 at 08:05:52PM +0200, Bernhard Fischer wrote: > >On Thu, Jun 01, 2006 at 09:39:42PM +0200, Bernhard Fischer wrote: > >>Hi, > >> > >>ed is a) bloated and b) broken. > > > >Not sure anymore about the broken. From the looks it doesn't implement > >'H', which led me to think it didn't behave ok. > > > >>The attached patchlet starts to look a tiny bit into a) > > > >By now that thing turned into a vaguely insane-sized patch of >80kB. > >Without too much love, it saves 2255 bytes for defconfig+IMA: > > ... now with said patch, We're not adding stuff that starts with two underscores. I don't care what the rationale is, we're not the kernel and we're not a C library. We have a perfectly good "static" keyword when we don't want to export something. If you want to substitute out isdigit() and isspace() because you can do it smaller, cool. That belongs in libbb.h or platform.h, and we should be able to #undef and/or #define to bb_isdigit() to make it work. However, keep in mind this might only be a win on glibc, but not on uClibc. What environments have you _tested_ this in? Building stuff into BusyBox that's _only_ a size win against glibc ranks up there with optimizing the idle loop in terms of pointless activities... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 14:31:53 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 14:31:56 2006 Subject: [patch] abuse of strncpy In-Reply-To: References: <20060601230019.GI8986@mage.jpl.nasa.gov> <44803342.3030901@bfs.de> Message-ID: <200606061731.53902.rob@landley.net> On Friday 02 June 2006 9:05 am, Robert P. J. Day wrote: > On Fri, 2 Jun 2006, walter harms wrote: > > lets call it bb_strlcpy(), so there is less confusion. > > re, > > wh > > i have a better idea -- let's not. in fact, let's do away with this > whole notion of arbitrarily prefixing modified library routines with > that thoroughly useless "bb_" prefix. I'm not a fan of the bb_prefix. It's a recent addition, and it was originally there solely due to name collisions. I see no downside to removing it. > in the first place, adding that "bb_" prefix makes what could be more > universally-usable routines a little less usable, since anyone trying > to incorporate them into another project will be stuck with those > wholly irrelevant prefixes that have nothing to do with their project. You are aware libbb doesn't export a stable API, and it's unlikely to start? > (yes, i realize that caring about using BB routines in other projects > is outside the scope of BB design, but i don't see any compelling > reason to introduce difficulty for no apparent reason.) *shrug* > more to the point, seeing a routine whose name is "bb_strlcpy" tells > me absolutely nothing about how that routine differs from the standard > routine, or why it should in the first place. There's no standard strlcpy in glibc, because Ulrich Dr. Pepper has an "interesting" personality. > as a comparison, it *is* more meaningful to see a routine named > "safe_strncpy" since, from the name alone, i at least have clue as to > what the rationale for that routine is. but "bb_strlcpy"? if the > purpose of redesigning that routine is to, say, guarantee that a null > byte is added to the end, thsn suck it up and call it > "strlcpy_null_term()" or something similar. I'd be quite happy to call it walrus(), and with enough usages I suspect people would figure it out. I don't consider bb_strlcpy() confusing. We had a bb_strlen() that was _exactly_ the normal strlen, which was renamed for technical reasons. We lived for years. > not only is that more meaningful but, down the road, you never know > when you might need *another* strlcpy-derived routine that does > something slightly different. what will you call that? bb2_strlcpy? bb_strlcpy2(). > just sit down, write up a list of related routines you need in > busybox, give them meaningful names and go with that. That sounds way too much like work. > rday Rob -- Never bet against the cheap plastic solution. From farmatito at tiscali.it Tue Jun 6 14:35:03 2006 From: farmatito at tiscali.it (Tito) Date: Tue Jun 6 14:35:53 2006 Subject: ok, what's the official take on "endianness"? and hdparm problem In-Reply-To: <44858D10.5333.1AE0B7A@localhost> References: <44858D10.5333.1AE0B7A@localhost> Message-ID: <200606062335.03930.farmatito@tiscali.it> On Tuesday 6 June 2006 22:11, Ken McGuire wrote: > On 6 Jun 2006 at 15:13, Rob Landley wrote: > > > On Thursday 01 June 2006 1:46 pm, Robert P. J. Day wrote: > > > probably a silly question, but what's the whole story on best > > > practises for dealing with endianness? > > > > We recently grew better support for endianness in platform.h. > > > > We define BB_BIG_ENDIAN and BB_LITTLE_ENDIAN, each of which is true or false > > depending on the current platform. > > > > We also have six macros: SWAP_BE16(), SWAP_BE32(), SWAP_BE64(), SWAP_LE16(), > > SWAP_LE32(), and SWAP_LE64(). Each of these returns the modified data (if > > you want to convert in place, assign it back to itself.) Use these when you > > know the data is in a given format, so: > > > > uint32_t external; > > > > external = SWAP_LE32(external); > > external += 42; > > external = SWAP_LE32(external); > > > > On a little-endian system, the swap is a NOP, and the assignment to itself > > gets optimized away. On a big-endian system, it should swap before doing the > > addition, and then swap it back afterwards. > > > > > rday > > > > Rob > > -- > > Never bet against the cheap plastic solution. > > _______________________________________________ > > busybox mailing list > > busybox@busybox.net > > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > > Rob, > I think I have found where the problem with hdparm is when running on my ppc > system. To review; iBook ppc G3 running ubuntu 5.10, gcc 4.0.2 busybox svn > 15284. hdparm -I /dev/hda produces incorrect results which appear to be an > endian problem. > > I poked around in hdparm.c and found the nice new macros described below. I > also found this in "identify()": > > if (BB_BIG_ENDIAN) { > swab(id_supplied, buf, sizeof(buf)); > val = buf; > } else val = id_supplied; > > > Even with the nice new macros, hdparm still produced the same errors as in > earlier versions (svn 15237). I removed the above test and the busybox hdparm > now produces the same result as the ubuntu hdparm (v6.1) I have attached a > patch for this, but have only tested it on one ppc system so far. There also > may be some other cleanup that you might want to do as gcc reports that buf[] > is now unused. > ...ken... In fact in newer hdparm code this test is gone. From hdparm 6.6+: void identify (__u16 *id_supplied) { __u16 val[256], ii, jj, kk; __u16 like_std = 1, std = 0, min_std = 0xffff; __u16 dev = NO_DEV, eqpt = NO_DEV; __u8 have_mode = 0, err_dma = 0; __u8 chksum = 0; __u32 ll, mm, nn; __u64 bb, bbbig; /* (:) */ int transport; memcpy(val, id_supplied, sizeof(val)); /* calculate checksum over all bytes */ for(ii = GEN_CONFIG; ii<=INTEGRITY; ii++) { chksum += val[ii] + (val[ii] >> 8); } /* check if we recognise the device type */ printf("\n"); if(!(val[GEN_CONFIG] & NOT_ATA)) { dev = ATA_DEV; Ciao, Tito > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > From rob at landley.net Tue Jun 6 14:39:14 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 14:39:16 2006 Subject: [patch] abuse of strncpy In-Reply-To: <50BF37ECE4954A4BA18C08D0C2CF88CB01A4423D@exmail1.se.axis.com> References: <50BF37ECE4954A4BA18C08D0C2CF88CB01A4423D@exmail1.se.axis.com> Message-ID: <200606061739.14497.rob@landley.net> On Monday 05 June 2006 1:28 pm, Peter Kjellerstedt wrote: > Well, there are two major differences between strncpy() and strlcpy(): I find it amusing to note that in 1992, having been programming in C for less than 3 years, I implemented a strlcpy() in one of my Turbo C programs without ever having _heard_ of anybody else doing it, as a way to fix the obviously defective strncpy() which is NOT guaranteed to produce a properly terminated string so what's the _POINT_? I never could decide if the l stood for "landley" or "length", but it just seemed so darn _obvious_ that I was surprised somebody else hadn't done it. (And you can check, Turbo C's standard library didn't have it.) From this context, I find the current argument downright silly... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:04:37 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:04:41 2006 Subject: [bug] busybox fails building in init.c In-Reply-To: <9220.1149221689@brightstareng.com> References: <9220.1149221689@brightstareng.com> Message-ID: <200606061804.38131.rob@landley.net> On Friday 02 June 2006 12:14 am, Paul Fox wrote: Random comments... > enum { > LOG = 0x1, Why did this get changed from a #define to an enum? We #ifdef to see if it's already defined, and if not make an enum. That's silly. Plus the enum range violation there's a comment on. Plus MAYBE_CONSOLE should just be (2 * ENABLE_FEATURE_EXTRA_QUIET). *shudder*. I need to rewrite this whole file, it's icky... > @@ -175,7 +177,9 @@ > /* Function prototypes */ > static void delete_init_action(struct init_action *a); > static int waitfor(const struct init_action *a, pid_t pid); > +#if !ENABLE_DEBUG_INIT > static void shutdown_signal(int sig); > +#endif Need an #ifdef around a function prototype is stupid. We used to just declare functions in the right order so they didn't need prototypes. That's a bit complicated in this case, but should be doable. Of course what this code _needs_ is a complete rewrite... > static void loop_forever(void) > @@ -395,7 +399,11 @@ > if (fail) > _exit(1); > /* else */ > +#if !ENABLE_DEBUG_INIT > shutdown_signal(SIGUSR1); > +#else > + _exit(2); > +#endif if (!ENABLE_DEBUG_INIT) shutdown_signal(sigusr1); else _exit(2); Which gets us back to the function prototype mess. I need to rewrite init again... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:13:33 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:13:31 2006 Subject: problems with hdparm in svn 15237/15261 In-Reply-To: <4480296E.2226.1127ADF@localhost> References: <4480296E.2226.1127ADF@localhost> Message-ID: <200606061813.33818.rob@landley.net> On Friday 02 June 2006 2:05 pm, Ken McGuire wrote: > Rats! I screwed up and didn't send this to the list, sorry, I'll blame it > on my mailer.... ;>) > > The endian issue is still present on ppc in svn 15261. hopefully it can get > dealt with befor the 1.2.0 release. ... > > > 2) on ppc (ubuntu 5.10) with gcc 4.0.2 > > > > > > "make clean defconfig busybox" > > > > > > builds without errors and the applets run, but hdparm produces > > > incorrect results. > > > > Joy. > > > > > Firmware Revision: ADOC7AA6 > > > Firmware Revision: DACOA76A > > > > Sigh, the classic nuxi problem. > > > > http://www.catb.org/jargon/html/N/NUXI-problem.html > > > > I'll take a look this evening... > > Thanks... Ok, starting on line 584, of miscutils/hdparm.c, we have: if (BB_BIG_ENDIAN) { swab(id_supplied, buf, sizeof(buf)); val = buf; } else val = id_supplied; buf is uint16_t buf[256] and val is uint16_t *val. So either: A) BB_BIG_ENDIAN isn't set correctly for you, B) swab() is acting like memcpy(). Any way you could track that down? This seems fairly simple but I'm not spotting why it's happening... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:19:11 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:19:11 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060603191835.GB20193@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> Message-ID: <200606061819.12260.rob@landley.net> On Saturday 03 June 2006 3:18 pm, Bernhard Fischer wrote: > On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: > >On 7/25/05, Rob Landley wrote: > >... > > > >>But applied anyway... > >> > >>Rob > > > >This patch was never applied; please apply it now. > > > >libbb.h uses struct sockaddr_in which is defined in netinet/in.h but > >never included. > > This patch shouldn't be needed anymore since the order of includes were > restructered recently. Applets have to include busybox.h as the first > include, lib*/* has to include libbb.h as the first include. > > Applets and library functions MUST not include any header which is > included by platform.h, busybox.h and platform.h, libbb.h respectively. "Must" is a bit strong. Shouldn't. In general, it would be nice if applets could just #include one header file and all the weird issues that keep coming up about which header files apply to which platforms and what order they have to go in in order to avoid stomping each other (yes, the recent Red Hat build break) were just not an applet's problem. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:20:18 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:20:19 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060603225241.GF20193@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603225241.GF20193@aon.at> Message-ID: <200606061820.18242.rob@landley.net> On Saturday 03 June 2006 6:52 pm, Bernhard Fischer wrote: > >all right, this is just plain creeping me out, when people start > >talking about a *required order* of header file inclusion. this is > >just plain not good. > > go understand how some aspects of dmalloc work: http://www.dmalloc.com/ I'd just like to point out that I don't use dmalloc, I'm not going to start using dmalloc, and if despite that I have to read up on and understand dmalloc anyway, I'm going to yank it. Just FYI. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:24:25 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:24:24 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> Message-ID: <200606061824.25838.rob@landley.net> On Saturday 03 June 2006 2:27 pm, Shaun Jackman wrote: > This patch adds LDFLAGS and LIBRARIES configuration options to > complement the CFLAGS that already exists. Please apply. "Hello, I'd like to register a complaint. Hello miss?" "What do you mean miss?" "I'm terribly sorry, I have a cold..." Has anybody else noticed that on a 2 ghz Pentium M (with TWO MEGABYTES of L2 cache), make help sits there for a full two seconds before dumping the help text? And that it does so because it runs gcc several times to figure out what C flags it can use, and that we don't cache this information anywhere between runs even though it shouldn't change unless you reinstall your compiler. Would somebody like to fix this before I try to? I'm still pretty dangerous when it comes to makefiles, and I'll probably break something... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:25:54 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:25:54 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <7f45d9390606031400g5d6d36c5wf3f3474b84385295@mail.gmail.com> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <20060603191305.GA20193@aon.at> <7f45d9390606031400g5d6d36c5wf3f3474b84385295@mail.gmail.com> Message-ID: <200606061825.55170.rob@landley.net> On Saturday 03 June 2006 5:00 pm, Shaun Jackman wrote: > On 6/3/06, Bernhard Fischer wrote: > > On Sat, Jun 03, 2006 at 12:27:28PM -0600, Shaun Jackman wrote: > > >This patch adds LDFLAGS and LIBRARIES configuration options to > > >complement the CFLAGS that already exists. Please apply. > > > > Doesn't saying make LDFLAGS="-Wl,--verbose -Wl,-n -Wl,-O1 -Wl,-t" > > work now even without this patch? > > Yes, of course. The same can be said for EXTRA_CFLAGS. It's a pain to > have to remember to pass the option to make every time make is run. A > .config file is easier to keep in a version control system than > options passed to make. Does supplying it as an environment variable work? LDFLAGS="-Wl,--verbose -Wl,-n -Wl,-O1 -Wl,-t" make There are such things as wrapper scripts... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:30:59 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:30:59 2006 Subject: [BUG] hdparm & uClibc: BLKGETSIZE64 undeclared In-Reply-To: <200606040043.30547.yann.morin.1998@anciens.enib.fr> References: <200606040043.30547.yann.morin.1998@anciens.enib.fr> Message-ID: <200606061830.59774.rob@landley.net> On Saturday 03 June 2006 6:43 pm, Yann E. MORIN wrote: > /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c: In function > `do_blkgetsize': /home/ymorin/dev/src/busybox-svn/miscutils/hdparm.c:1373: > error: `BLKGETSIZE64' undeclared (first use in this function) ... > uClibc-0.9.28 > linux-libc-headers-2.6.12.0 ... > In busybox, we do (re)define it in: > e2fsprogs/blkid/blkid_getsize.c:48 > e2fsprogs/ext2fs/getsize.c:47 > util-linux/fdisk.c:55 Both of which are external crap that was nailed to the tree and had "busybox" painted on the side without nearly enough cleanup. > What is the best solution here? Linux version skew issues belong in platform.h. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 15:32:36 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 15:32:36 2006 Subject: [BUG] hdparm & uClibc: BLKGETSIZE64 undeclared In-Reply-To: <20060603225120.GE20193@aon.at> References: <200606040043.30547.yann.morin.1998@anciens.enib.fr> <20060603225120.GE20193@aon.at> Message-ID: <200606061832.36505.rob@landley.net> On Saturday 03 June 2006 6:51 pm, Bernhard Fischer wrote: > I'd say that's a typical case for platform.h, either in the > libc-checking section where you'd want to include sys/mount.h if > you know that your libc provides it or in a __linux__ block where you > copy the #define out of linux/fs.h. At a guess we can probably #include unconditionally, followed by an #ifdef with a copy of the #define. Rob -- Never bet against the cheap plastic solution. From kenm at desertweyr.com Tue Jun 6 15:35:22 2006 From: kenm at desertweyr.com (Ken McGuire) Date: Tue Jun 6 15:33:54 2006 Subject: problems with hdparm in svn 15237/15261 In-Reply-To: <200606061813.33818.rob@landley.net> References: <4480296E.2226.1127ADF@localhost> Message-ID: <4485AECA.7196.231CC98@localhost> On 6 Jun 2006 at 18:13, Rob Landley wrote: > On Friday 02 June 2006 2:05 pm, Ken McGuire wrote: > > Rats! I screwed up and didn't send this to the list, sorry, I'll blame it > > on my mailer.... ;>) > > > > The endian issue is still present on ppc in svn 15261. hopefully it can get > > dealt with befor the 1.2.0 release. > ... > > > > 2) on ppc (ubuntu 5.10) with gcc 4.0.2 > > > > > > > > "make clean defconfig busybox" > > > > > > > > builds without errors and the applets run, but hdparm produces > > > > incorrect results. > > > > > > Joy. > > > > > > > Firmware Revision: ADOC7AA6 > > > > Firmware Revision: DACOA76A > > > > > > Sigh, the classic nuxi problem. > > > > > > http://www.catb.org/jargon/html/N/NUXI-problem.html > > > > > > I'll take a look this evening... > > > > Thanks... > > Ok, starting on line 584, of miscutils/hdparm.c, we have: > > if (BB_BIG_ENDIAN) { > swab(id_supplied, buf, sizeof(buf)); > val = buf; > } else val = id_supplied; > > buf is uint16_t buf[256] and val is uint16_t *val. > > So either: > > A) BB_BIG_ENDIAN isn't set correctly for you, > > B) swab() is acting like memcpy(). > > Any way you could track that down? This seems fairly simple but I'm not > spotting why it's happening... > > Rob > -- > Never bet against the cheap plastic solution. > I added a printf before the swab(...), and BB_BIG_ENDIAN is definately being set. I removed the test and busybox hdparm functioned properly. So the swab doesn't seem to be needed. See Tito's post responding to my last post about endianess: Re: ok, what's the official take on "endianness"? and hdparm problem ...ken... From erik at hovland.org Tue Jun 6 15:34:58 2006 From: erik at hovland.org (Erik Hovland) Date: Tue Jun 6 15:35:04 2006 Subject: [patch] various bugs and strncpy abuse followup Message-ID: <20060606223458.GB16710@mage.jpl.nasa.gov> After the very helpful feedback and the continual searching for bugs, I have expanded my patch associated to various bugs all over busybox. This patchset has gotten bigger. So I have taken to splitting them up by file and annotating them in patch. I hope that is useful. Let me know if there is some way I can make this easier to go over or help with acceptance. Feel free to address each patch seperately in responding. I would not be surprised at all if I accidentally introduced regressions. I have not yet tried running the unit testing. But I have attempted to understand why each bug is a bug and addressed it according to its severity. I appreciate any attention you might give this work. E archival/dpkg_deb.c | 6 +++-- archival/rpm.c | 3 +- archival/tar.c | 8 +++---- console-tools/loadkmap.c | 3 +- coreutils/chown.c | 4 ++- e2fsprogs/ext2fs/ext_attr.c | 5 +++- e2fsprogs/ext2fs/flushb.c | 3 +- e2fsprogs/ext2fs/mkjournal.c | 3 +- e2fsprogs/ext2fs/read_bb_file.c | 2 - e2fsprogs/mke2fs.c | 8 ++++--- e2fsprogs/tune2fs.c | 4 +-- init/init.c | 10 +++++++-- libbb/concat_subpath_file.c | 2 + libbb/login.c | 5 +++- libbb/loop.c | 4 ++- loginutils/getty.c | 9 ++++---- loginutils/login.c | 15 +++---------- loginutils/vlock.c | 19 +++++++++++------ miscutils/crontab.c | 2 - miscutils/devfsd.c | 14 +++++++------ networking/ifupdown.c | 12 ----------- networking/libiproute/iplink.c | 42 ++------------------------------------- networking/libiproute/iproute.c | 12 ++++++----- networking/libiproute/iptunnel.c | 2 - networking/tftp.c | 25 +++++++++++++---------- networking/udhcp/socket.c | 2 - networking/zcip.c | 2 - procps/fuser.c | 3 +- shell/lash.c | 2 - shell/msh.c | 6 ++++- util-linux/fdisk.c | 2 - util-linux/mdev.c | 3 +- util-linux/nfsmount.c | 2 - 33 files changed, 118 insertions(+), 126 deletions(-) -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-patches.tar.bz2 Type: application/octet-stream Size: 8621 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060606/ab023703/busybox-patches.tar.obj From rob at landley.net Tue Jun 6 16:00:57 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:00:58 2006 Subject: [PATCH] cat's config options In-Reply-To: <200606041612.41146.yann.morin.1998@anciens.enib.fr> References: <200606041612.41146.yann.morin.1998@anciens.enib.fr> Message-ID: <200606061900.57295.rob@landley.net> On Sunday 04 June 2006 10:12 am, Yann E. MORIN wrote: > Hello all! > > This patch moves cat-dependent -vetET options just below cat. This is > purely cosmetics. > > Regards, > Yann E. MORIN. Yanked the unused -vetET config option instead. (I checked in catv because I decided to make that a separate applet rather than mess up cat.c.) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:03:56 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:03:54 2006 Subject: [BusyBox 0000799]: start-stop-daemon does not support --oknodo option In-Reply-To: <20060604143533.GB8161@aon.at> References: <20060604143533.GB8161@aon.at> Message-ID: <200606061903.56235.rob@landley.net> On Sunday 04 June 2006 10:35 am, Bernhard Fischer wrote: > If anyone here can give it a whirl, then i'd be glad. Although busybox crawled out of the primordial ooze of the debian boot disk, I don't use debian nor most debian-utils... > PPS: anyone up to joining the bug-sqashing party? :) I'm working on the darn patch backlog. Once I've caught up on my email, I'm copying all the still marked-as-unread messages to a separate folder so I can go through them. I have 60 of them just from my _personal_ email, let alone the busybox mailing list folder... This is going to take a while. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:06:19 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:07:02 2006 Subject: [patch] save ~600B In-Reply-To: <20060605114856.GJ8161@aon.at> References: <20060604184916.GD8161@aon.at> <44840FA6.2040204@bfs.de> <20060605114856.GJ8161@aon.at> Message-ID: <200606061906.19676.rob@landley.net> On Monday 05 June 2006 7:48 am, Bernhard Fischer wrote: > On Mon, Jun 05, 2006 at 01:04:06PM +0200, walter harms wrote: > >hi bernhard, > >just a minor question. > >Does exit(-1) make sense ? so far i remember the shell expects 0-255. > > IMO it does make sense. It it a means to make sure to return ~0, no > matter what return type the shell happens to use. How does this differ from exit(1)? > If it doesn't, then i'd say "it was already there, thus it's not my fault" > :P Oh there's no shortage of code that falls under that category, but we do the best we can to clean it up faster than it gets dirty... > cheers, Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:16:48 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:16:49 2006 Subject: [patch] save ~600B In-Reply-To: <44841EC3.6060707@bfs.de> References: <20060604184916.GD8161@aon.at> <20060605114856.GJ8161@aon.at> <44841EC3.6060707@bfs.de> Message-ID: <200606061916.48590.rob@landley.net> On Monday 05 June 2006 8:08 am, walter harms wrote: > personally i am the fan of > exit( EXIT_FAILURE ) ; Unix-like systems have returned at least 8 bit error codes with 0 meaning success and nonzero meaning failure since 1970. (In 1969, it was 6 bit. :P) This was copied by DOS, Windows, OS/2, you name it. Any system that can't handle that is one that BusyBox should not even attempt to support. Also, filehandles 0, 1, and 2 are stdin, stdout, and stderr respectively, and a null pointer is 0, and FALSE is 0, and any nonzero value is true. (Although if they define a TRUE macro it could be 1 or -1 since -1 is all bits set so it makes a certain amount of sense. You can trust our ENABLE values to be 1 if they're true, though.) char defaults to unsigned (because we hit the compiler on the head with a HAMMER, that's why). Integer arithmetic uses ones' complement notation. We restrict our use of floating point as much as possible and have config options around any uses of it such as "sort". Busybox trusts that the c99 types for uint8_t, uint16_t, uint32_t, and uint64_t are all available, plus the corresponding signed ones. You can also use c99 // comments. Our compiler must be capable of doing dead code elimination and simple local constant propagation. It's not currently merging duplicate strings or eliminating unused static functions, which is sad. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:19:30 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:19:32 2006 Subject: redundant code in unzip.c ? In-Reply-To: <20060604202545.GF8161@aon.at> References: <20060604202545.GF8161@aon.at> Message-ID: <200606061919.31212.rob@landley.net> Glenn, what do you know about this one? Rob On Sunday 04 June 2006 4:25 pm, Bernhard Fischer wrote: > Hi, > > in unzip.c, one can read: > > Index: archival/unzip.c > =================================================================== > --- archival/unzip.c (revision 15268) > +++ archival/unzip.c (working copy) > @@ -320,9 +320,9 @@ > if (verbosity == v_normal) { > printf(" creating: %s\n", dst_fn); > } > unzip_create_leading_dirs(dst_fn); > +// isn't this call ---v already done by unzip_create_leading_dirs above? > if (bb_make_directory(dst_fn, 0777, 0)) { > +// --------------------^ > - bb_error_msg_and_die("Failed to create directory"); > + bb_error_msg_and_die("Exiting"); > } > } else { > > Also, repeating the error message which was already emitted by > bb_make_directory() sounds odd, so just saying "Exiting" should be > enough, i'd say. > If the call really is redundant, the whole if should be deleted. > > Comments? > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:22:58 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:22:54 2006 Subject: [PATCH] stdio: Add %m In-Reply-To: <7f45d9390606050949u84cbcd6yd01823e96f8a621@mail.gmail.com> References: <7f45d9390606050949u84cbcd6yd01823e96f8a621@mail.gmail.com> Message-ID: <200606061922.58520.rob@landley.net> On Monday 05 June 2006 12:49 pm, Shaun Jackman wrote: > In particular, busybox uses %m and the maintainers will not accept > patches converting this format to %s and strerror(errno) due to the > latter taking more space by making, typically, two additional function > calls -- one to __errno_location and one to strerror. Plus the extra code to load another argument onto the stack. It adds up. Also because although the result looks bad, it isn't a build break or a loss of functionality in the non-error case. (Worst case scenario you just don't see the error details.) > Cheers, > Shaun Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:38:26 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:38:24 2006 Subject: Inetd will not start telnetd In-Reply-To: References: Message-ID: <200606061938.26988.rob@landley.net> On Tuesday 06 June 2006 2:35 am, Fierst, Timothy M wrote: > I just compiled in syslogd and got the following message while trying to > start > inetd: > > daemon.err inetd[189]: telnet/tcp: unknown service > > I have all the libnsss_* libraries in my /lib/ folder (busybox is > statically linked) > My /etc/services has read permissions (I'm logged in as root). I don't use inetd (it's another applet on my "this is really ugly, rewrite it from scratch someday" list, but I'm unlikely to get to it soon because I prefer to run standalone daemons). Sounds like it should work, though. Let's see... > I'm using busybox-1.1.2. Check. > My inetd.conf entry: > > telnet stream tcp nowait root /usr/sbin/telnetd telnetd Ok... > My /etc/services file looks like: > > telnet 23/tcp Check. > I'm using binutils-2.16.1, gcc-3.4.4, and glibc-2.3.5. Running on an > m68k mvme16x box. Wow, we build for that? Cool. Lemme see what I can reproduce on Intel... Nope, it's working just fine for me here (with current -svn). > I am mounting devpts, and have it config'd in on busybox (hence telnetd > standalone working). Dunno. > Yes, I know ssh is a better option, but at this point I'm going with > telnetd, at least until > > I can verify my inetd is working. The error message you're getting is that it's not finding telnet in /etc/services. Presumably inetd isn't finding it. Dunno why not. > Any help would be GREATLY appreciated. I'm at my boiling point trying > to figure this out. > > Sorry if this isn't actually a busybox problem, I will be trying > non-busybox versions of inetd and telnetd tomorrow. How did that work out? > Thanks, > > Tim Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:42:38 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:42:34 2006 Subject: 2.4 module on 2.6 kernel with busybox v 1 In-Reply-To: <29f916510606060018s659d472fh619f2a4966e1f0ba@mail.gmail.com> References: <29f916510606060018s659d472fh619f2a4966e1f0ba@mail.gmail.com> Message-ID: <200606061942.38789.rob@landley.net> On Tuesday 06 June 2006 3:18 am, alfred hitch wrote: > Hi Guys, > > I will appreciate some help on a (perhaps) trivial issue I am facing. > I am trying to insmod some 2.4 module binaries I have with me. > On a 2.6.12 kernel from snapgear 3.3 with busybox v1. My condolences. Kernel modules for 2.6.9 won't load on 2.6.12, and you're trying to get 2.4 module binaries to load? > It's giving me : insmod: Cannot insert XXX invalid module format > (-1). Exec format error. > > I have enabled support for 2.4 modules in busybox compilation screen. > Any pointers will be helpfull. This is a kernel issue, not a busybox issue. The kernel developers made it clear _seven_years_ago_ why linux kernel modules aren't going to have a stable ABI, ever: http://lwn.net/1999/1209/kernel.php3 You need to rebuild the module from source for the correct kernel version. > Cheers, > Alfred Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 16:47:41 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 16:47:39 2006 Subject: Inetd will not start telnetd In-Reply-To: References: Message-ID: <200606061947.41399.rob@landley.net> On Tuesday 06 June 2006 12:53 pm, Fierst, Timothy M wrote: > Yeah, I tried different combinations of etc/services, all with the line > "telnet 23/tcp" in them. Made sure the file was readable to all. > > I think the real problem is with my dynamic libnsss_* libraries. If my > inetd.conf file changes from: > > telnet stream tcp nowait root /usr/sbin/telnetd telnetd > > to: > > 23 stream tcp nowait root /usr/sbin/telnetd telnetd > > everything works fine. I have all my libnsss_* files in my /lib/ > directory, but maybe there is more to it than that. My busybox is > linked statically but with glibc, the libnsss_* can only be linked > dynamically. And you need a working library loader, too. (Did you install /lib/ld-linux.so?) It would be _so_ nice if there was a Linux-building-list we could foist these questions off onto... > -Tim Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 17:28:22 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 17:28:26 2006 Subject: ok, what's the official take on "endianness"? and hdparm problem In-Reply-To: <44858D10.13863.1AE0A6A@localhost> References: <44858D10.13863.1AE0A6A@localhost> Message-ID: <200606062028.22794.rob@landley.net> On Tuesday 06 June 2006 4:11 pm, Ken McGuire wrote: > * This message contains the file 'patch.bb1', which has been > * uuencoded. If you are using Pegasus Mail, then you can use > * the browser's eXtract function to lift the original contents > * out to a file, otherwise you will have to extract the message > * and uudecode it manually. Ever heard of mime encoding? You can also cut and paste the patch inline. Whitespace mangling's better than that mess... I uudecoded it by hand, noticed you removed the swab entirely, scratched my head for a bit, went and pondered the code, and realized that both callers of identify() were already adjusting the endianness of the data before calling identify(). (Which is weird, how did this _ever_ work on a big endian system? It's broken back in 1.1.1, I think...) The correct thing to do isn't to remove the adjustment from identify, but to remove it from each of the callers so it's done in one place. http://busybox.net/downloads/patches/svn-15301.patch Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 17:30:11 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 17:30:14 2006 Subject: OT: tiny mDNS? In-Reply-To: <17741.1149611042@brightstareng.com> References: <17741.1149611042@brightstareng.com> Message-ID: <200606062030.11984.rob@landley.net> On Tuesday 06 June 2006 12:24 pm, Paul Fox wrote: > anyone have pointers to a small mDNS client, appropriate for your > basic ethernet-connected embedded system? What's an mdns, and how does it differ from the dnsd we've got in the tree now? (Which I still haven't had a chance to look much at. I miss the days when I could read existing code in the tree and write new code rather than rushing to keep up with an endless stream of other people's new patches... But it's on my to-do list.) > i'm familiar with the > major implementations mostly in name only (howl, avahi). is the > avahi daemon small enough to consider? we did put the portable > apple code on one product, but it was a little cumbersome and > large for my tastes. (i'm hoping someone will say they have a > busybox applet all ready to go. ;-) What _is_ it? Ctrl-alt-google: http://www.multicastdns.org/ Lovely. If it uses the same packet formats, we should be able to extend our current dns daemon to do it. Eventually... > paul Rob -- Never bet against the cheap plastic solution. From kenm at desertweyr.com Tue Jun 6 19:36:49 2006 From: kenm at desertweyr.com (Ken McGuire) Date: Tue Jun 6 19:35:26 2006 Subject: ok, what's the official take on "endianness"? and hdparm problem In-Reply-To: <200606062028.22794.rob@landley.net> References: <44858D10.13863.1AE0A6A@localhost> Message-ID: <4485E761.11529.30EE4AC@localhost> On 6 Jun 2006 at 20:28, Rob Landley wrote: > On Tuesday 06 June 2006 4:11 pm, Ken McGuire wrote: > > * This message contains the file 'patch.bb1', which has been > > * uuencoded. If you are using Pegasus Mail, then you can use > > * the browser's eXtract function to lift the original contents > > * out to a file, otherwise you will have to extract the message > > * and uudecode it manually. > > Ever heard of mime encoding? > Indeed, my face is red... > You can also cut and paste the patch inline. Whitespace mangling's better > than that mess... > Appologies again... > I uudecoded it by hand, noticed you removed the swab entirely, scratched my > head for a bit, went and pondered the code, and realized that both callers of > identify() were already adjusting the endianness of the data before calling > identify(). (Which is weird, how did this _ever_ work on a big endian > system? It's broken back in 1.1.1, I think...) > I had never used busybox hdparm on ppc before busybox 1.1.2 and it was broken there. I've been using busybox/buildroot/uClibc since early 2002, mostly on ARM, some x86 and some MIPS. > The correct thing to do isn't to remove the adjustment from identify, but to > remove it from each of the callers so it's done in one place. > Thanks for the patience, I just did a svn up, re-compiled and busybox hdparm seems to produce the proper results.. !! > http://busybox.net/downloads/patches/svn-15301.patch > I'll read over the patch and see what I can learn, Thanks... > Rob > -- > Never bet against the cheap plastic solution. > ...ken... From rob at landley.net Tue Jun 6 21:10:45 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 21:10:47 2006 Subject: [PATCH] include/platform.h: Define KERNEL_VERSION unconditionally In-Reply-To: <7f45d9390606061356u14a47b6cp50dd9d880f39f828@mail.gmail.com> References: <7f45d9390605301639v4a996781w42488a81233be8ef@mail.gmail.com> <200606061501.10839.rob@landley.net> <7f45d9390606061356u14a47b6cp50dd9d880f39f828@mail.gmail.com> Message-ID: <200606070010.46286.rob@landley.net> On Tuesday 06 June 2006 4:56 pm, Shaun Jackman wrote: > I was only being troubled by network/interface.c. If that check can go > away, then I have no further complaints. Should be able to. Checking the netbsd version of that command for comparison purposes might be informative... > On 6/6/06, Rob Landley wrote: > > On Thursday 01 June 2006 11:48 am, Shaun Jackman wrote: > > > [1] 2. Thou shalt not follow the NULL pointer, for chaos and madness > > > await thee at its end. > > I should have mentioned that I was quoting `The Ten Commandments for C > Programmers (Annotated Edition)' by Henry Spencer. These are not my > words. Sorry for the confusion. Oh I've heard it before, although it was several few years ago. And when he was trying to wean people off the "all the world's a VAX" mentality, it made a certain amount of sense to question everything. But NULL is 0, and by _relying_ on that we can make busybox smaller. (0 is false, the null pointer is false. This is good to know.) > > And on linux and any other sane unix-like system going back to the 1970's > > we have an inaccessible page mapped there and any attempt to read from it > > or write to it gives a clean segfault. > > On an embedded system without an MMU or even an MPU, this desirable > feature is sadly not an option. Considering uClinux is only a > configuration of Linux these days, your statement is false. I'm aware that on a nommu system you don't get a segfault for anything. (I programmed under DOS for years, they put the _interrupt_table_ down there.) But these days anybody who tries to debug software on a nommu system _first_ had better know they're playing with fire... > > > A null pointer doth not point to a 0 of any type, > > > > Yes, it does. And we check for this all over the place. > > > > if(!thing || !*thing) blah. > > > > Any system that doesn't understand that is too stupid to live, and will > > NEVER be supported. Period. Full stop. > > It's not saying that a NULL pointer is not 0, this is in fact defined > by the C standard. It's saying that dereferensing the NULL pointer > does not necessarily give another NULL pointer. I mentioned a moment ago that dereferencing the NULL pointer usually gives a segfault, right? > There used to be > systems that depended on assert(*NULL == NULL) They're nuts. We don't. > , allowing your above > test to be reduced to simply if(!*thing), which used to be a common > idiom for if(thing == NULL || *thing == NULL). Again, we don't. I'm fairly certain BusyBox doesn't contain significant amounts of code ported directly from 1970's minicomputers. I'd probably have noticed by now. > > > despite some blasphemous old code which impiously assumes this. > > > > You are, quite simply, wrong. > > ... unless you've misunderstood the original statement. Although, I > suppose all rebuttals have to start with the basic assumption that the > opposition has understood the proposition's argument. *shrug*. I'm a computer historian, which means I've at least read about systems where NULL wasn't 0, where char was 12 bits long, where identifiers were 6 characters at most and this was used as a form of commenting... I assumed you were advocating a change from current policy rather than restating the obvious. Dereferencing a NULL pointer is bad, sure, and on Linux systems with an MMU, you get a segfault if you do this, so we're unlikely to accidentally do it for long even by accident. > Cheers, > Shaun Rob -- Never bet against the cheap plastic solution. From rob at landley.net Tue Jun 6 21:14:35 2006 From: rob at landley.net (Rob Landley) Date: Tue Jun 6 21:14:36 2006 Subject: ok, what's the official take on "endianness"? and hdparm problem In-Reply-To: <200606062335.03930.farmatito@tiscali.it> References: <44858D10.5333.1AE0B7A@localhost> <200606062335.03930.farmatito@tiscali.it> Message-ID: <200606070014.36261.rob@landley.net> On Tuesday 06 June 2006 5:35 pm, Tito wrote: > > Even with the nice new macros, hdparm still produced the same errors as > > in earlier versions (svn 15237). I removed the above test and the busybox > > hdparm now produces the same result as the ubuntu hdparm (v6.1) I have > > attached a patch for this, but have only tested it on one ppc system so > > far. There also may be some other cleanup that you might want to do as > > gcc reports that buf[] is now unused. > > ...ken... > > In fact in newer hdparm code this test is gone. > From hdparm 6.6+: So they moved the endianness adjustment from the one common function to independently do it in each of the callers, to maximize duplicated code. Nice to know. > /* calculate checksum over all bytes */ > for(ii = GEN_CONFIG; ii<=INTEGRITY; ii++) { > chksum += val[ii] + (val[ii] >> 8); > } They're actually doing a checksum now? Rob -- Never bet against the cheap plastic solution. From farmatito at tiscali.it Tue Jun 6 23:43:46 2006 From: farmatito at tiscali.it (Tito) Date: Tue Jun 6 23:44:35 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <20060606223458.GB16710@mage.jpl.nasa.gov> References: <20060606223458.GB16710@mage.jpl.nasa.gov> Message-ID: <200606070843.46909.farmatito@tiscali.it> On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > After the very helpful feedback and the continual searching for bugs, I > have expanded my patch associated to various bugs all over busybox. > > This patchset has gotten bigger. So I have taken to splitting them up by > file and annotating them in patch. I hope that is useful. Let me know if > there is some way I can make this easier to go over or help with > acceptance. > > Feel free to address each patch seperately in responding. I would not be > surprised at all if I accidentally introduced regressions. I have not > yet tried running the unit testing. But I have attempted to understand > why each bug is a bug and addressed it according to its severity. > > I appreciate any attention you might give this work. > Hi, some comments about the devfsd patch: 1) --- miscutils/devfsd.c (revision 15298) +++ miscutils/devfsd.c (working copy) @@ -964,8 +964,9 @@ regexpr, numexpr); if ( !make_dir_tree (destination) || lstat (source, &source_stat) != 0) - return; - lstat (destination, &dest_stat); + return; + if (lstat (destination, &dest_stat) != 0) + return;; new_mode = source_stat.st_mode & ~S_ISVTX; if (info->type == DEVFSD_NOTIFY_CREATE) new_mode |= S_ISVTX; This is unneeded. The original code does: if (lstat (destination, &dest_stat) != 0) dest_stat.st_mode = 0; but we have already initialised dest_stat.st_mode to 0 so we can spare the if statement. Please drop this part. 2) @@ -1090,7 +1091,8 @@ dest_stat.st_mode = 0; snprintf (dpath, sizeof dpath, "%s%s", mount_point, spath + rootlen); - lstat (dpath, &dest_stat); + if (lstat (dpath, &dest_stat) < 0) + bb_error_msg("Unable to stat %s", dpath); if ( S_ISLNK (source_stat.st_mode) || (source_stat.st_mode & S_ISVTX) ) copy_inode (dpath, &dest_stat, (source_stat.st_mode & ~S_ISVTX) , spath, &source_stat); Originally was: } snprintf (dpath, sizeof dpath, "%s%s", mount_point, spath + rootlen); if (lstat (dpath, &dest_stat) != 0) dest_stat.st_mode = 0; Same as above. Please drop this part. 3) @@ -1311,9 +1313,9 @@ /* compare_string_array returns i>=0 */ i=compare_string_array(field_names, variable); Good catch, at the time I wrote this compare_string_array didn't return values < 0. BTW, if I remember correctly here it is unlikely to happen, but who knows..... Maybe we should fix also the comment or remove it totally. - if ( i > 6 && (i > 1 && gv_info == NULL)) - return (NULL); - if( i >= 0 || i <= 3) + if (i > 6 || (i > 1 && gv_info == NULL) || i < 0) + return (NULL); Good catch too!!! + if( i <= 3 && i >= 0 ) { debug_msg_logger(LOG_INFO, "%s: i=%d %s", __FUNCTION__, i ,field_names[i+7]); return(field_names[i+7]); Thanks for auditing this old code. Ciao, Tito From farmatito at tiscali.it Wed Jun 7 00:09:27 2006 From: farmatito at tiscali.it (Tito) Date: Wed Jun 7 00:11:19 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <20060606223458.GB16710@mage.jpl.nasa.gov> References: <20060606223458.GB16710@mage.jpl.nasa.gov> Message-ID: <200606070909.27702.farmatito@tiscali.it> On Wednesday 7 June 2006 00:34, you wrote: > After the very helpful feedback and the continual searching for bugs, I > have expanded my patch associated to various bugs all over busybox. > > This patchset has gotten bigger. So I have taken to splitting them up by > file and annotating them in patch. I hope that is useful. Let me know if > there is some way I can make this easier to go over or help with > acceptance. > > Feel free to address each patch seperately in responding. I would not be > surprised at all if I accidentally introduced regressions. I have not > yet tried running the unit testing. But I have attempted to understand > why each bug is a bug and addressed it according to its severity. > > I appreciate any attention you might give this work. > > E Hi, in the vlock patch: I can't say due to my limited knowledge if it makes sense to have error messages in signal handlers, but nonetheless they could be shorter. ;-) static void release_vt(int signo) { - if (!o_lock_all) - ioctl(vfd, VT_RELDISP, 1); - else - ioctl(vfd, VT_RELDISP, 0); + if (!o_lock_all) { + if (ioctl(vfd, VT_RELDISP, 1) < 0) + bb_error_msg("failed in attempting to release the display"); + } else + if (ioctl(vfd, VT_RELDISP, 0) < 0) + bb_error_msg("failed in attempting to release the display"); } static void release_vt(int signo) { if (ioctl(vfd, VT_RELDISP, (!o_lock_all) ? 1 : 0) < 0) { bb_perror_msg("VT_RELDISP"); } } or maybe static void release_vt(int signo) { if (ioctl(vfd, VT_RELDISP, (!o_lock_all)) < 0) { bb_perror_msg("VT_RELDISP"); } } static void acquire_vt(int signo) { - ioctl(vfd, VT_RELDISP, VT_ACKACQ); + if (ioctl(vfd, VT_RELDISP, VT_ACKACQ) < 0) + bb_error_msg("failed in attempting to release the display"); } static void acquire_vt(int signo) { if (ioctl(vfd, VT_RELDISP, VT_ACKACQ) < 0) bb_perror_msg("VT_ACKACQ"); } static void restore_terminal(void) { - ioctl(vfd, VT_SETMODE, &ovtm); + if (ioctl(vfd, VT_SETMODE, &ovtm) < 0) + bb_error_msg("failed to set the mode of the active vt"); tcsetattr(STDIN_FILENO, TCSANOW, &oterm); } static void restore_terminal(void) { if (ioctl(vfd, VT_SETMODE, &ovtm) < 0) bb_perror_msg("VT_SETMODE"); tcsetattr(STDIN_FILENO, TCSANOW, &oterm); } @@ -106,7 +110,8 @@ vtm.mode = VT_PROCESS; vtm.relsig = SIGUSR1; vtm.acqsig = SIGUSR2; - ioctl(vfd, VT_SETMODE, &vtm); + if (ioctl(vfd, VT_SETMODE, &vtm) < 0) + bb_perror_msg_and_die("VT_SETMODE"); Ciao, Tito From farmatito at tiscali.it Wed Jun 7 00:12:56 2006 From: farmatito at tiscali.it (Tito) Date: Wed Jun 7 00:13:46 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <20060606223458.GB16710@mage.jpl.nasa.gov> References: <20060606223458.GB16710@mage.jpl.nasa.gov> Message-ID: <200606070912.56440.farmatito@tiscali.it> On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > After the very helpful feedback and the continual searching for bugs, I > have expanded my patch associated to various bugs all over busybox. > > This patchset has gotten bigger. So I have taken to splitting them up by > file and annotating them in patch. I hope that is useful. Let me know if > there is some way I can make this easier to go over or help with > acceptance. > > Feel free to address each patch seperately in responding. I would not be > surprised at all if I accidentally introduced regressions. I have not > yet tried running the unit testing. But I have attempted to understand > why each bug is a bug and addressed it according to its severity. > > I appreciate any attention you might give this work. > Hi, please shorten the error message. BUG: Does not check return value of ioctl FIX: Add a check and bail if it fails. Index: console-tools/loadkmap.c =================================================================== --- console-tools/loadkmap.c (revision 15298) +++ console-tools/loadkmap.c (working copy) @@ -70,7 +70,8 @@ ke.kb_index = j; ke.kb_table = i; ke.kb_value = ibuff[j]; - ioctl(fd, KDSKBENT, &ke); + if (ioctl(fd, KDSKBENT, &ke) < 0) + bb_error_msg("failed attempting to load key index %d in keymap %d", j, i); -------> bb_perror_msg("KDSKBENT"); } } } Ciao, Tito From alfred.hitch at gmail.com Wed Jun 7 00:35:45 2006 From: alfred.hitch at gmail.com (alfred hitch) Date: Wed Jun 7 00:35:55 2006 Subject: 2.4 module on 2.6 kernel with busybox v 1 In-Reply-To: <200606061942.38789.rob@landley.net> References: <29f916510606060018s659d472fh619f2a4966e1f0ba@mail.gmail.com> <200606061942.38789.rob@landley.net> Message-ID: <29f916510606070035k61911a4at617e268e6bfb4e5d@mail.gmail.com> Oh I see now, Sorry was on 2.4 world for so long :( Anyways, here is my summary of what I could understand from diff. posts and googl'ing. 1) 2.4 allowed binary form driver loading. diff, kernel versions could be loaded with same binary driver module. 2) 2.6 : No ways can you run a pre compiled binary onto a diff. kernel machine. Source, compiler everything should match ? ! All this is done by forcefully asking for 2.4 Makefiles to be changed to 2.6 format. Which includes the vermagic technically speaking. ? No ways to get past this ? And then why do I see in the busybox compilation , option for 2.1 , 2.4 kernel etc ? Alfred On 6/6/06, Rob Landley wrote: > On Tuesday 06 June 2006 3:18 am, alfred hitch wrote: > > Hi Guys, > > > > I will appreciate some help on a (perhaps) trivial issue I am facing. > > I am trying to insmod some 2.4 module binaries I have with me. > > On a 2.6.12 kernel from snapgear 3.3 with busybox v1. > > My condolences. Kernel modules for 2.6.9 won't load on 2.6.12, and you're > trying to get 2.4 module binaries to load? > > > It's giving me : insmod: Cannot insert XXX invalid module format > > (-1). Exec format error. > > > > I have enabled support for 2.4 modules in busybox compilation screen. > > Any pointers will be helpfull. > > This is a kernel issue, not a busybox issue. The kernel developers made it > clear _seven_years_ago_ why linux kernel modules aren't going to have a > stable ABI, ever: > > http://lwn.net/1999/1209/kernel.php3 > > You need to rebuild the module from source for the correct kernel version. > > > Cheers, > > Alfred > > Rob > -- > Never bet against the cheap plastic solution. > From bug1 at ihug.co.nz Wed Jun 7 00:37:54 2006 From: bug1 at ihug.co.nz (Glenn L. McGrath) Date: Wed Jun 7 00:37:59 2006 Subject: redundant code in unzip.c ? In-Reply-To: <20060604202545.GF8161@aon.at> References: <20060604202545.GF8161@aon.at> Message-ID: <20060607193754.074931cb.bug1@ihug.co.nz> On Sun, 4 Jun 2006 22:25:45 +0200 Bernhard Fischer wrote: > Hi, > > in unzip.c, one can read: > > Index: archival/unzip.c > =================================================================== > --- archival/unzip.c (revision 15268) > +++ archival/unzip.c (working copy) > @@ -320,9 +320,9 @@ > if (verbosity == v_normal) { > printf(" creating: %s\n", dst_fn); > } > unzip_create_leading_dirs(dst_fn); > +// isn't this call ---v already done by unzip_create_leading_dirs above? > if (bb_make_directory(dst_fn, 0777, 0)) { > +// --------------------^ > - bb_error_msg_and_die("Failed to create directory"); > + bb_error_msg_and_die("Exiting"); > } > } else { > > Also, repeating the error message which was already emitted by > bb_make_directory() sounds odd, so just saying "Exiting" should be > enough, i'd say. > If the call really is redundant, the whole if should be deleted. I agree, they shouldnt be there. If that unzip_create_leading_dirs call is removed then the whole function could be removed as its only used 1 other time. Look back in CVS it looks like i checked it in, dont why, must have jsut been a mistake. Glenn From stephane.billiart at gmail.com Wed Jun 7 02:37:48 2006 From: stephane.billiart at gmail.com (Stephane Billiart) Date: Wed Jun 7 03:33:19 2006 Subject: [patch] typo in ftpgetput.c Message-ID: <20060607093748.GA7282@localhost.localdomain> Attached patch fixes the build if we have ftpput without ftpget, broken since r14997. -- St?phane Billiart http://perso.orange.fr/billiart/ -------------- next part -------------- Index: networking/ftpgetput.c =================================================================== --- networking/ftpgetput.c (revision 15301) +++ networking/ftpgetput.c (working copy) @@ -117,7 +117,7 @@ #if !ENABLE_FTPGET #define ftp_receive 0 #else -static int ftp_recieve(ftp_host_info_t *server, FILE *control_stream, +static int ftp_receive(ftp_host_info_t *server, FILE *control_stream, const char *local_path, char *server_path) { char buf[512]; @@ -303,7 +303,7 @@ ftp_action = ftp_send; } if (ENABLE_FTPGET && (!ENABLE_FTPPUT || bb_applet_name[3] == 'g')) { - ftp_action = ftp_recieve; + ftp_action = ftp_receive; } /* Set default values */ From stephane.billiart at gmail.com Wed Jun 7 04:12:32 2006 From: stephane.billiart at gmail.com (stephane.billiart@gmail.com) Date: Wed Jun 7 04:12:43 2006 Subject: [patch] build fix for ftpgetput.c Message-ID: <20060607111232.GC3843@localhost.localdomain> Attached patch fixes the build if we have ftpput without ftpget, broken since r14997. -- St?phane Billiart http://perso.orange.fr/billiart/ -------------- next part -------------- Index: networking/ftpgetput.c =================================================================== --- networking/ftpgetput.c (revision 15301) +++ networking/ftpgetput.c (working copy) @@ -117,7 +117,7 @@ #if !ENABLE_FTPGET #define ftp_receive 0 #else -static int ftp_recieve(ftp_host_info_t *server, FILE *control_stream, +static int ftp_receive(ftp_host_info_t *server, FILE *control_stream, const char *local_path, char *server_path) { char buf[512]; @@ -303,7 +303,7 @@ ftp_action = ftp_send; } if (ENABLE_FTPGET && (!ENABLE_FTPPUT || bb_applet_name[3] == 'g')) { - ftp_action = ftp_recieve; + ftp_action = ftp_receive; } /* Set default values */ From rep.nop at aon.at Wed Jun 7 06:33:16 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 06:33:23 2006 Subject: [patch] build fix for ftpgetput.c In-Reply-To: <20060607111232.GC3843@localhost.localdomain> References: <20060607111232.GC3843@localhost.localdomain> Message-ID: <20060607133316.GA32306@aon.at> On Wed, Jun 07, 2006 at 01:12:32PM +0200, stephane.billiart@gmail.com wrote: >Attached patch fixes the build if we have ftpput without ftpget, >broken since r14997. Applied. Thanks.. From vapier at gentoo.org Wed Jun 7 06:59:46 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 06:56:07 2006 Subject: uClinux support in busybox In-Reply-To: <200605262021.48350.rob@landley.net> References: <7f45d9390605240854pc826edcy94af0ac79dd5e891@mail.gmail.com> <7f45d9390605250948k22c57850g3e31a8935481789e@mail.gmail.com> <200605262021.48350.rob@landley.net> Message-ID: <200606070959.47389.vapier@gentoo.org> On Friday 26 May 2006 20:21, Rob Landley wrote: > I'm interested in merging this, by the way. I got forwarded a copy of the > uClinux patch a few months ago, but the version was _ancient_. i'm merging the safe/obvious stuff ... the more intrusive i'll cleanup and post to the 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/20060607/2af89a0b/attachment.pgp From vapier at gentoo.org Wed Jun 7 07:17:34 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:13:50 2006 Subject: svn 15195 In-Reply-To: <200605311714.57260.rob@landley.net> References: <200605311714.57260.rob@landley.net> Message-ID: <200606071017.34755.vapier@gentoo.org> On Wednesday 31 May 2006 17:14, Rob Landley wrote: > Finally getting around to reviewing this: clicky link since rob keeps forgetting :P http://www.busybox.net/cgi-bin/viewcvs.cgi?rev=15195&view=rev -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/20060607/d00c1aa3/attachment.pgp From vapier at gentoo.org Wed Jun 7 07:26:05 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:22:24 2006 Subject: [patch] abuse of strncpy In-Reply-To: <200606061731.53902.rob@landley.net> References: <20060601230019.GI8986@mage.jpl.nasa.gov> <200606061731.53902.rob@landley.net> Message-ID: <200606071026.05685.vapier@gentoo.org> On Tuesday 06 June 2006 17:31, Rob Landley wrote: > On Friday 02 June 2006 9:05 am, Robert P. J. Day wrote: > > On Fri, 2 Jun 2006, walter harms wrote: > > > lets call it bb_strlcpy(), so there is less confusion. > > > re, > > > wh > > > > i have a better idea -- let's not. in fact, let's do away with this > > whole notion of arbitrarily prefixing modified library routines with > > that thoroughly useless "bb_" prefix. > > I'm not a fan of the bb_prefix. It's a recent addition, and it was > originally there solely due to name collisions. I see no downside to > removing it. that'll put us back to having naming space issues then ? -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/20060607/d69544e5/attachment-0001.pgp From vapier at gentoo.org Wed Jun 7 07:26:49 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:23:08 2006 Subject: [patch] abuse of strncpy In-Reply-To: <20060601230019.GI8986@mage.jpl.nasa.gov> References: <20060601230019.GI8986@mage.jpl.nasa.gov> Message-ID: <200606071026.50196.vapier@gentoo.org> On Thursday 01 June 2006 19:00, Erik Hovland wrote: > --- networking/tftp.c???(revision 15261) > +++ networking/tftp.c???(working copy) > @@ -172,7 +172,10 @@ > ????????len = sizeof(sa); > ? > ????????memset(&sa, 0, len); > -???????bind(socketfd, (struct sockaddr *)&sa, len); > +???????if (bind(socketfd, (struct sockaddr *)&sa, len) < 0) { > +???????????????bb_perror_msg("bind"); > +???????????????return EXIT_FAILURE; > +???????} > ? > ????????sa.sin_family = host->h_addrtype; > ????????sa.sin_port = port; what does this have to do with strncpy() ? -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/20060607/a4405212/attachment.pgp From vapier at gentoo.org Wed Jun 7 07:29:36 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:25:52 2006 Subject: [PATCH] fix minor bugs in hdparm and don't block when reading from stdin In-Reply-To: <200606021533.18348.farmatito@tiscali.it> References: <200606021533.18348.farmatito@tiscali.it> Message-ID: <200606071029.36783.vapier@gentoo.org> On Friday 02 June 2006 09:33, Tito wrote: > +++ miscutils/hdparm.c 2006-06-02 15:21:51.000000000 +0200 > @@ -2124,8 +2124,8 @@ > - USE_FEATURE_HDPARM_GET_IDENTITY(get_IDentity = (c == 'I')); > - USE_FEATURE_HDPARM_GET_IDENTITY(get_identity = (c == 'i')); > + USE_FEATURE_HDPARM_GET_IDENTITY(get_IDentity |= (c == > 'I')); + USE_FEATURE_HDPARM_GET_IDENTITY(get_identity |= (c > == 'i')); 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/20060607/749eda43/attachment.pgp From vapier at gentoo.org Wed Jun 7 07:35:29 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:31:44 2006 Subject: [PATCH] ping: broken In-Reply-To: <7f45d9390605301531y4325f5f9g6b3134427f96cf72@mail.gmail.com> References: <7f45d9390605301515n223a37a9o800ef49aa2adb526@mail.gmail.com> <7f45d9390605301531y4325f5f9g6b3134427f96cf72@mail.gmail.com> Message-ID: <200606071035.30284.vapier@gentoo.org> On Tuesday 30 May 2006 18:31, Shaun Jackman wrote: > On 5/30/06, Shaun Jackman wrote: > > Can somebody verify for me that there's something wrong with ping? It > > looks to me as though it transmits 64 bytes, and then checks that 192 > > bytes were written, which fails. > > A patch fixing this issue follows. Please apply. looks like Rob applied this -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/20060607/e059b70c/attachment.pgp From vapier at gentoo.org Wed Jun 7 07:38:06 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:34:20 2006 Subject: [patch] save ~600B In-Reply-To: <22035.1149511287@brightstareng.com> References: <22035.1149511287@brightstareng.com> Message-ID: <200606071038.06393.vapier@gentoo.org> On Monday 05 June 2006 08:41, Paul Fox wrote: > wharm wrote: > > personally i am the fan of > > exit( EXIT_FAILURE ) ; > > and "EXIT_FAILURE" is cleverly defined as "1", right? why > not just "exit(1)"? this keeps it simple, concise, and transparent. funny, i find EXIT_FAILURE a lot easier to read ... especially when some functions return 0 to mean success while others return 0 to mean failure -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/20060607/a94be6a2/attachment.pgp From vapier at gentoo.org Wed Jun 7 07:49:24 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:45:41 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200606061824.25838.rob@landley.net> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606061824.25838.rob@landley.net> Message-ID: <200606071049.24823.vapier@gentoo.org> On Tuesday 06 June 2006 18:24, Rob Landley wrote: > On Saturday 03 June 2006 2:27 pm, Shaun Jackman wrote: > > This patch adds LDFLAGS and LIBRARIES configuration options to > > complement the CFLAGS that already exists. Please apply. > > "Hello, I'd like to register a complaint. Hello miss?" > > "What do you mean miss?" > > "I'm terribly sorry, I have a cold..." > > Has anybody else noticed that on a 2 ghz Pentium M (with TWO MEGABYTES of > L2 cache), make help sits there for a full two seconds before dumping the > help text? i'm guessing this has nothing to do with Shaun's post -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/20060607/89df0175/attachment.pgp From vapier at gentoo.org Wed Jun 7 07:51:18 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 07:47:33 2006 Subject: [PATCH] uClibc & BLKGETSIZE64 In-Reply-To: <200606041455.12235.yann.morin.1998@anciens.enib.fr> References: <200606041455.12235.yann.morin.1998@anciens.enib.fr> Message-ID: <200606071051.19065.vapier@gentoo.org> On Sunday 04 June 2006 08:55, Yann E. MORIN wrote: > Also, future uClibc's might switch to defining this, but sys/mount.h has > not changed for the last 4 years or so, which leads me to think it won't in > the near future... Shall I ask there as well? ive updated uClibc to latest version from glibc -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/20060607/ea5ec89a/attachment.pgp From pgf at brightstareng.com Wed Jun 7 07:47:22 2006 From: pgf at brightstareng.com (Paul Fox) Date: Wed Jun 7 07:48:39 2006 Subject: [patch] save ~600B In-Reply-To: vapier's message of Wed, 07 Jun 2006 10:38:06 -0400. <200606071038.06393.vapier@gentoo.org> Message-ID: <5667.1149691642@brightstareng.com> mike wrote: > On Monday 05 June 2006 08:41, Paul Fox wrote: > > wharm wrote: > > > personally i am the fan of > > > exit( EXIT_FAILURE ) ; > > > > and "EXIT_FAILURE" is cleverly defined as "1", right? why > > not just "exit(1)"? this keeps it simple, concise, and transparent. > > funny, i find EXIT_FAILURE a lot easier to read ... especially when some > functions return 0 to mean success while others return 0 to mean failure but programs aren't functions. if i see "exit (EXIT_FAILURE)", i'll probably have to go and check to see what it's defined correctly, and i'll also have to check to be sure they also haven't been writing "return (EXIT_FAILURE)". paul =--------------------- paul fox, pgf@brightstareng.com From erik at hovland.org Wed Jun 7 07:49:10 2006 From: erik at hovland.org (Erik Hovland) Date: Wed Jun 7 08:25:58 2006 Subject: [patch] abuse of strncpy In-Reply-To: <200606071026.50196.vapier@gentoo.org> References: <20060601230019.GI8986@mage.jpl.nasa.gov> <200606071026.50196.vapier@gentoo.org> Message-ID: <20060607144910.GA22246@hovland.org> On Wed, Jun 07, 2006 at 10:26:49AM -0400, Mike Frysinger wrote: > On Thursday 01 June 2006 19:00, Erik Hovland wrote: > > --- networking/tftp.c???(revision 15261) > > +++ networking/tftp.c???(working copy) > > @@ -172,7 +172,10 @@ > > ????????len = sizeof(sa); > > ? > > ????????memset(&sa, 0, len); > > -???????bind(socketfd, (struct sockaddr *)&sa, len); > > +???????if (bind(socketfd, (struct sockaddr *)&sa, len) < 0) { > > +???????????????bb_perror_msg("bind"); > > +???????????????return EXIT_FAILURE; > > +???????} > > ? > > ????????sa.sin_family = host->h_addrtype; > > ????????sa.sin_port = port; > > what does this have to do with strncpy() ? Heh, it doesn't. I accidentally slipped in some patches that were to correct calls to functions which return values but are not checked. My latest post on patches attempts to address all of the fixes so that there isn't confusion like this. Sorry for the sloppiness. E -- Erik Hovland mail: erik@hovland.org web: http://hovland.org/ PGP/GPG public key available on request From sjackman at gmail.com Wed Jun 7 08:54:17 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Wed Jun 7 08:54:23 2006 Subject: [PATCH] ping: broken In-Reply-To: <200606071035.30284.vapier@gentoo.org> References: <7f45d9390605301515n223a37a9o800ef49aa2adb526@mail.gmail.com> <7f45d9390605301531y4325f5f9g6b3134427f96cf72@mail.gmail.com> <200606071035.30284.vapier@gentoo.org> Message-ID: <7f45d9390606070854ke74746fq8880db440b090ebd@mail.gmail.com> On 6/7/06, Mike Frysinger wrote: > looks like Rob applied this > -mike Thanks for pointing this out, Mike. Rob, I'd much appreciate a one-word `Applied.' email upon commit. Cheers, Shaun From sjackman at gmail.com Wed Jun 7 09:08:57 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Wed Jun 7 09:09:02 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200606061825.55170.rob@landley.net> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <20060603191305.GA20193@aon.at> <7f45d9390606031400g5d6d36c5wf3f3474b84385295@mail.gmail.com> <200606061825.55170.rob@landley.net> Message-ID: <7f45d9390606070908p557ca70di87872f935426b57@mail.gmail.com> On 6/6/06, Rob Landley wrote: > Does supplying it as an environment variable work? > > LDFLAGS="-Wl,--verbose -Wl,-n -Wl,-O1 -Wl,-t" make > > There are such things as wrapper scripts... Yes, using an environment variable would work, although it's not recommended. See below for comments from the make's manual. I'd much prefer, and it seems far more congruous, to set LDFLAGS in the same place one sets CFLAGS. It seems pretty arbitrary that CFLAGS can be set in the configuration process, but LDFLAGS cannot. Cheers, Shaun info make: 6.9 Variables from the environment When `make' runs a command script, variables defined in the makefile are placed into the environment of that command. This allows you to pass values to sub-`make' invocations (*note Recursive Use of `make': Recursion.). By default, only variables that came from the environment or the command line are passed to recursive invocations. You can use the `export' directive to pass other variables. Other use of variables from the environment is not recommended. It is not wise for makefiles to depend for their functioning on environment variables set up outside their control, since this would cause different users to get different results from the same makefile. This is against the whole purpose of most makefiles. From rep.nop at aon.at Wed Jun 7 09:33:23 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 09:33:28 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200606071049.24823.vapier@gentoo.org> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606061824.25838.rob@landley.net> <200606071049.24823.vapier@gentoo.org> Message-ID: <20060607163323.GA2422@aon.at> On Wed, Jun 07, 2006 at 10:49:24AM -0400, Mike Frysinger wrote: >On Tuesday 06 June 2006 18:24, Rob Landley wrote: >> On Saturday 03 June 2006 2:27 pm, Shaun Jackman wrote: >> > This patch adds LDFLAGS and LIBRARIES configuration options to >> > complement the CFLAGS that already exists. Please apply. >> >> "Hello, I'd like to register a complaint. Hello miss?" >> >> "What do you mean miss?" >> >> "I'm terribly sorry, I have a cold..." >> >> Has anybody else noticed that on a 2 ghz Pentium M (with TWO MEGABYTES of >> L2 cache), make help sits there for a full two seconds before dumping the >> help text? > >i'm guessing this has nothing to do with Shaun's post Most likely, yes. Also it's fun since a configure script could do exactly this (caching the settings) over runs. An easy fix for not looking at the gcc-flags for noconfig targets (resp. notools target since some noconfig targets need hosttools and these may need to check for flags for the HOSTCC) would be to just not check for them if ($(MAKECMDGOAL),help) Whether skipping these works for all versions of make is left as an exercise for the curious (could be that i did it already in the buildsys-patch i sent to the list WRT 'compressed_usage broke parallel builds' -- http://www.busybox.net/lists/busybox/2006-May/021764.html). Rob, what about instead fixing the testsuite so it can be run when building out of tree? :P From rep.nop at aon.at Wed Jun 7 09:44:01 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 09:44:06 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <7f45d9390606070908p557ca70di87872f935426b57@mail.gmail.com> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <20060603191305.GA20193@aon.at> <7f45d9390606031400g5d6d36c5wf3f3474b84385295@mail.gmail.com> <200606061825.55170.rob@landley.net> <7f45d9390606070908p557ca70di87872f935426b57@mail.gmail.com> Message-ID: <20060607164401.GB2422@aon.at> On Wed, Jun 07, 2006 at 10:08:57AM -0600, Shaun Jackman wrote: >On 6/6/06, Rob Landley wrote: >>Does supplying it as an environment variable work? >> >>LDFLAGS="-Wl,--verbose -Wl,-n -Wl,-O1 -Wl,-t" make >> >>There are such things as wrapper scripts... > >Yes, using an environment variable would work, although it's not >recommended. See below for comments from the make's manual. I'd much >prefer, and it seems far more congruous, to set LDFLAGS in the same >place one sets CFLAGS. It seems pretty arbitrary that CFLAGS can be >set in the configuration process, but LDFLAGS cannot. Well, and what about ASFLAGS and all the other variables like LOADLIBES, LDLIBS, and, most prominently, CPPFLAGS? I'm not strongly opposed to adding config-entries for it/them (as i won't use them myself since passing them to make via a wrapper or cmdline history Works For Me), FWIW. I'll let Mr. Landley decide on this ;) cheers, From rep.nop at aon.at Wed Jun 7 09:48:48 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 09:48:53 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <200606061819.12260.rob@landley.net> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <20060603191835.GB20193@aon.at> <200606061819.12260.rob@landley.net> Message-ID: <20060607164847.GC2422@aon.at> On Tue, Jun 06, 2006 at 06:19:11PM -0400, Rob Landley wrote: >On Saturday 03 June 2006 3:18 pm, Bernhard Fischer wrote: >> On Sat, Jun 03, 2006 at 12:25:36PM -0600, Shaun Jackman wrote: >> >On 7/25/05, Rob Landley wrote: >> >... >> > >> >>But applied anyway... >> >> >> >>Rob >> > >> >This patch was never applied; please apply it now. >> > >> >libbb.h uses struct sockaddr_in which is defined in netinet/in.h but >> >never included. >> >> This patch shouldn't be needed anymore since the order of includes were >> restructered recently. Applets have to include busybox.h as the first >> include, lib*/* has to include libbb.h as the first include. >> >> Applets and library functions MUST not include any header which is >> included by platform.h, busybox.h and platform.h, libbb.h respectively. > >"Must" is a bit strong. Shouldn't. Well MUST not include any header which is included by platform.h or have to duplicate the appropriate checks from platform.h for the respective include files. Applets shouldn't include stuff already included by busybox.h and libbb.h (as the second include usually serves no purpose and just stresses the preprocessor). > >In general, it would be nice if applets could just #include one header file >and all the weird issues that keep coming up about which header files apply >to which platforms and what order they have to go in in order to avoid >stomping each other (yes, the recent Red Hat build break) were just not an >applet's problem. I'm not a big fan of catch-it-all private headers, but if you prefer it that way, i can live. From rep.nop at aon.at Wed Jun 7 09:58:38 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 09:58:43 2006 Subject: [patch] save ~600B In-Reply-To: <20060604201452.GE8161@aon.at> References: <20060604184916.GD8161@aon.at> <20060604201452.GE8161@aon.at> Message-ID: <20060607165838.GD2422@aon.at> On Sun, Jun 04, 2006 at 10:14:53PM +0200, Bernhard Fischer wrote: >On Sun, Jun 04, 2006 at 08:49:16PM +0200, Bernhard Fischer wrote: >>Hi, >> >>- use bb_msg_... in more places. >> >>While i think that this patch should be ok, i'd be glad if someone could >>look over it (been staring at it for too long). >> >>TIA, >>Bernhard > >updated version 02e Since i didn't see any objection (nor a real review of the actual patch) i'll just go and i apply it later today.. We can cleanup return codes later on From rob at landley.net Wed Jun 7 12:42:58 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 12:43:00 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200606071049.24823.vapier@gentoo.org> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606061824.25838.rob@landley.net> <200606071049.24823.vapier@gentoo.org> Message-ID: <200606071542.58437.rob@landley.net> On Wednesday 07 June 2006 10:49 am, Mike Frysinger wrote: > On Tuesday 06 June 2006 18:24, Rob Landley wrote: > > On Saturday 03 June 2006 2:27 pm, Shaun Jackman wrote: > > > This patch adds LDFLAGS and LIBRARIES configuration options to > > > complement the CFLAGS that already exists. Please apply. > > > > "Hello, I'd like to register a complaint. Hello miss?" > > > > "What do you mean miss?" > > > > "I'm terribly sorry, I have a cold..." > > > > Has anybody else noticed that on a 2 ghz Pentium M (with TWO MEGABYTES of > > L2 cache), make help sits there for a full two seconds before dumping the > > help text? > > i'm guessing this has nothing to do with Shaun's post It has to do with the fact that the slowdown I'm seeing is due to explicit flag querying at the beginning of the make run, which is done even when it isn't needed, and that breaking up the flags to be more granular is a mechanism to cope with increasing the complexity of the configuration we do, and preparation for an increase in complexity is likely to actually encourage such an increase in complexity, most likely resulting in proliferation of flag probing and even more of a slowdown. Therefore, I'm not interested in increasing flag specification granularity before we implement a cacheing mechanism for probed flags, and that's aside from the potential increased mnemonic burden on developers attempting to configure their build environment that increased granularity brings with it. Sorry, thought it was obvious. > -mike Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 12:51:55 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 12:51:57 2006 Subject: 2.4 module on 2.6 kernel with busybox v 1 In-Reply-To: <29f916510606070035k61911a4at617e268e6bfb4e5d@mail.gmail.com> References: <29f916510606060018s659d472fh619f2a4966e1f0ba@mail.gmail.com> <200606061942.38789.rob@landley.net> <29f916510606070035k61911a4at617e268e6bfb4e5d@mail.gmail.com> Message-ID: <200606071551.55436.rob@landley.net> On Wednesday 07 June 2006 3:35 am, alfred hitch wrote: > Oh I see now, > Sorry was on 2.4 world for so long :( > > Anyways, here is my summary of what I could understand from diff. > posts and googl'ing. > > 1) 2.4 allowed binary form driver loading. diff, kernel versions could > be loaded with same binary driver module. Not really. The pace of development was much, much slower, and they didn't introduce new features or rewrite much existing code in the stable series (they had -devel forks and backported bugfixes), so it tended to work by accident a lot. In 2.6, they introduce new developments between each major dot release, and have minor dot releases (2.6.16.20) that are bugfix-only. If you look at the number of lines of code merged, each 2.6 version has almost as much development as went on in an entire development series five years ago. (As a percentage of the total it's not quite as big, but it's up there.) 2.2 and 2.4 weren't a moving target because 2.3 and 2.5 did that. 2.6 is a moving target, and this is intentional. They've never supported binary-only modules, and they've stopped humoring them. If your code is GPL, submit it for inclusion in the tree and they'll fix it up each time they change something. Doesn't matter how obscure the hardware is, the "summit" architecture has something like 4 machines on the entire planet, and yet it's merged. If you can't submit it into the tree, they want to know why not. Which brings up license compliance issues... :) > 2) 2.6 : No ways can you run a pre compiled binary onto a diff. kernel > machine. Source, compiler everything should match ? ! You might be able to apply a source patch to a different kernel version and build a new module that works. But it's not guaranteed, a lot of internal APIs change. (Linux Weekly News has a list of the changes during the 2.6 series... http://lwn.net/Articles/2.6-kernel-api/ ) > All this is done by forcefully asking for 2.4 Makefiles to be changed > to 2.6 format. Which includes the vermagic technically speaking. ? I have no idea what you're asking about here. > No ways to get past this ? > And then why do I see in the busybox compilation , option for 2.1 , > 2.4 kernel etc ? You don't see option for 2.1 kernel anymore. 2.4 had some different things in user space, most noticeably module loading uses a completely different API. (It used to be done in user space, now you feed a block of data to the kernel and it does all the linking. Different API, but that's ok because it's different module binaries anyway.) Most 2.6 distros use different module loading tools (Rusty's module tools on kernel.org instead of old 2.4 modutils package), but the busybox insmod is neither, and at least potentially handles both. > Alfred Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 12:54:31 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 12:54:31 2006 Subject: svn 15195 In-Reply-To: <200606071017.34755.vapier@gentoo.org> References: <200605311714.57260.rob@landley.net> <200606071017.34755.vapier@gentoo.org> Message-ID: <200606071554.32174.rob@landley.net> On Wednesday 07 June 2006 10:17 am, Mike Frysinger wrote: > On Wednesday 31 May 2006 17:14, Rob Landley wrote: > > Finally getting around to reviewing this: > > clicky link since rob keeps forgetting :P No, I just expect people can look it up themselves. I can add something like this to the busybox main page if you think it would help, though:
(Presumably something slightly less disgusting, but keep in mind I don't have time to do much javascript...) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 12:55:25 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 12:55:24 2006 Subject: [PATCH] ping: broken In-Reply-To: <7f45d9390606070854ke74746fq8880db440b090ebd@mail.gmail.com> References: <7f45d9390605301515n223a37a9o800ef49aa2adb526@mail.gmail.com> <200606071035.30284.vapier@gentoo.org> <7f45d9390606070854ke74746fq8880db440b090ebd@mail.gmail.com> Message-ID: <200606071555.25752.rob@landley.net> On Wednesday 07 June 2006 11:54 am, Shaun Jackman wrote: > On 6/7/06, Mike Frysinger wrote: > > looks like Rob applied this > > -mike > > Thanks for pointing this out, Mike. Rob, I'd much appreciate a > one-word `Applied.' email upon commit. I do, most of the time. Since this message doesn't say which patch it's talking about I don't know whether I did this time or not. Yesterday I went through and culled out four hundred and seventy two back email messages I have marked as "to be dealt with", copied them all into one folder, and this evening I hope to have time to start sorting through them. I'd also like to point out that posting an "applied" message to the list for every single commit I do is about as bad as subscribing the busybox list to the svn commit message list. This is why I don't _always_ do that when there's a big enough surge of patch applying. I flood the list enough as it is just replying to things. There is an svn commit list, and the svn web viewer thingy can show you the current status of a file. > Cheers, > Shaun Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 13:17:09 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 13:17:10 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606070843.46909.farmatito@tiscali.it> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070843.46909.farmatito@tiscali.it> Message-ID: <200606071617.09519.rob@landley.net> On Wednesday 07 June 2006 2:43 am, Tito wrote: > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > > Hi, > some comments about the devfsd patch: I just marked devfsd as deprecated. It's not going away in 1.2.x, and probably not in 1.3.x, but I don't plan on it being around forever. Just FYI. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 13:31:16 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 13:31:19 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606070909.27702.farmatito@tiscali.it> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070909.27702.farmatito@tiscali.it> Message-ID: <200606071631.16726.rob@landley.net> On Wednesday 07 June 2006 3:09 am, Tito wrote: > Hi, in the vlock patch: > > I can't say due to my limited knowledge if it makes sense > to have error messages in signal handlers, but nonetheless > they could be shorter. ;-) > > static void release_vt(int signo) > { > - if (!o_lock_all) > - ioctl(vfd, VT_RELDISP, 1); > - else > - ioctl(vfd, VT_RELDISP, 0); > + if (!o_lock_all) { > + if (ioctl(vfd, VT_RELDISP, 1) < 0) > + bb_error_msg("failed in attempting to release the display"); > + } else > + if (ioctl(vfd, VT_RELDISP, 0) < 0) > + bb_error_msg("failed in attempting to release the display"); > } It's not Busybox's policy to test if you encountered bad ram during the course of operation. Will the user not otherwise notice this failure if the console doesn't unlock? What exactly are they supposed to do about it if it happens? Is it at all likely to happen in the regular course of operations? (What would cause this to happen? The ioctl returns an error primarily because the console might not have been locked in the first place, not because the kernel can't be trusted to do its job reliably...) Could ignoring this error conceivably be any worse than reporting it? It's not like the program is going to DO anything about it, the error message is just the program is sticking its tongue out at the user. There are lots of errors we don't test for because we ignoring it is no worse than reporting it. If we can't do anything useful about it and it's not going to eat your data, is it worth the bytes being pedantic over a "this should never happen"? Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 13:32:38 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 13:32:37 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606070912.56440.farmatito@tiscali.it> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070912.56440.farmatito@tiscali.it> Message-ID: <200606071632.38348.rob@landley.net> On Wednesday 07 June 2006 3:12 am, Tito wrote: > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > > After the very helpful feedback and the continual searching for bugs, I > > have expanded my patch associated to various bugs all over busybox. > > > > This patchset has gotten bigger. So I have taken to splitting them up by > > file and annotating them in patch. I hope that is useful. Let me know if > > there is some way I can make this easier to go over or help with > > acceptance. > > > > Feel free to address each patch seperately in responding. I would not be > > surprised at all if I accidentally introduced regressions. I have not > > yet tried running the unit testing. But I have attempted to understand > > why each bug is a bug and addressed it according to its severity. > > > > I appreciate any attention you might give this work. > > Hi, please shorten the error message. > > BUG: Does not check return value of ioctl > > FIX: Add a check and bail if it fails. > > Index: console-tools/loadkmap.c > =================================================================== > --- console-tools/loadkmap.c (revision 15298) > +++ console-tools/loadkmap.c (working copy) > @@ -70,7 +70,8 @@ > ke.kb_index = j; > ke.kb_table = i; > ke.kb_value = ibuff[j]; > - ioctl(fd, KDSKBENT, &ke); > + if (ioctl(fd, KDSKBENT, &ke) < 0) > + bb_error_msg("failed attempting to load key index %d in keymap %d", > j, i); -------> bb_perror_msg("KDSKBENT"); > } > } > } We have bb_perror_msg_and_die() for a reason. If it's not worth exiting, it's probably not worth worrying about. Rob -- Never bet against the cheap plastic solution. From natanael.copa at gmail.com Wed Jun 7 13:33:56 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed Jun 7 13:37:49 2006 Subject: [patch] save ~600B In-Reply-To: <5667.1149691642@brightstareng.com> References: <5667.1149691642@brightstareng.com> Message-ID: <1149712436.15017.131.camel@localhost> On Wed, 2006-06-07 at 10:47 -0400, Paul Fox wrote: > mike wrote: > > On Monday 05 June 2006 08:41, Paul Fox wrote: > > > wharm wrote: > > > > personally i am the fan of > > > > exit( EXIT_FAILURE ) ; > > > > > > and "EXIT_FAILURE" is cleverly defined as "1", right? why > > > not just "exit(1)"? this keeps it simple, concise, and transparent. > > > > funny, i find EXIT_FAILURE a lot easier to read ... especially when some > > functions return 0 to mean success while others return 0 to mean failure > > but programs aren't functions. > > if i see "exit (EXIT_FAILURE)", i'll probably have to go and > check to see what it's defined correctly, and i'll also have to > check to be sure they also haven't been writing "return (EXIT_FAILURE)". Just to have something more to compare with: http://www.freebsd.org/cgi/man.cgi?query=sysexits&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html But this is a discussion of taste. I prefer apples over pears.... -- Natanael Copa From rep.nop at aon.at Wed Jun 7 13:46:14 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 13:46:20 2006 Subject: ctype.h stuff, saves ~2kB [was: Re: [PATCH] ed stuff #1] In-Reply-To: <200606061726.56580.rob@landley.net> References: <20060601193942.GC15547@aon.at> <20060605180552.GA4573@aon.at> <20060605181520.GM8161@aon.at> <200606061726.56580.rob@landley.net> Message-ID: <20060607204614.GQ8161@aon.at> On Tue, Jun 06, 2006 at 05:26:56PM -0400, Rob Landley wrote: >On Monday 05 June 2006 2:15 pm, Bernhard Fischer wrote: >> On Mon, Jun 05, 2006 at 08:05:52PM +0200, Bernhard Fischer wrote: >> >On Thu, Jun 01, 2006 at 09:39:42PM +0200, Bernhard Fischer wrote: >> >>Hi, >> >> >> >>ed is a) bloated and b) broken. >> > >> >Not sure anymore about the broken. From the looks it doesn't implement >> >'H', which led me to think it didn't behave ok. >> > >> >>The attached patchlet starts to look a tiny bit into a) >> > >> >By now that thing turned into a vaguely insane-sized patch of >80kB. >> >Without too much love, it saves 2255 bytes for defconfig+IMA: >> >> ... now with said patch, > >We're not adding stuff that starts with two underscores. I don't care what >the rationale is, we're not the kernel and we're not a C library. We have a >perfectly good "static" keyword when we don't want to export something. > >If you want to substitute out isdigit() and isspace() because you can do it >smaller, cool. That belongs in libbb.h or platform.h, and we should be able >to #undef and/or #define to bb_isdigit() to make it work. Did you look at the patch? We have bb_ functions for out-of-line users and we also have the macros. > >However, keep in mind this might only be a win on glibc, but not on uClibc. Yes. Apparently uClibc has less bloated implementations of these. It's trivial to use the non-bloated for the uclibc case and "ours" for glibc. >What environments have you _tested_ this in? Building stuff into BusyBox >that's _only_ a size win against glibc ranks up there with optimizing the >idle loop in terms of pointless activities... Hehe It's purely a size tweak in case the libc under us has bloated versions of these, which glibc for whatever reasons seems to have. From rep.nop at aon.at Wed Jun 7 13:49:43 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 13:49:50 2006 Subject: [PATCH] ed stuff #1 In-Reply-To: <200606061718.52367.rob@landley.net> References: <20060601193942.GC15547@aon.at> <200606061718.52367.rob@landley.net> Message-ID: <20060607204943.GR8161@aon.at> On Tue, Jun 06, 2006 at 05:18:50PM -0400, Rob Landley wrote: >On Thursday 01 June 2006 3:39 pm, Bernhard Fischer wrote: >> Hi, >> >> ed is a) bloated and b) broken. >> The attached patchlet starts to look a tiny bit into a) >> >> Comments? Ok to checkin? >> >> text data bss dec hex filename >> 864338 10244 645924 1520506 17337a busybox_old >> 864114 10244 645924 1520282 17329a busybox_unstripped >> >> thanks, > >I have no attachment whatsoever to ed, but I do care about libbb. You're >adding a new function and attributing it to Manuel Nova from three years ago? That attribution is not strictly correct, agree.. > >Why have both skip_whitespace() and skip_blank()? What's the point? I notice >that ed.c uses isblank() for everything, and never isspace(), so it's not >actually _distinguishing_ between them. That seems more like a stylistic >choice than anything else. Well i don't know ed too well and thought that since blank != space it would be safer to keep it like it was. Perhaps someone more familiar with ed can shed some light? > >If you really do feel the need to add skip_blank(), just throw it in >skip_whitespace.c (since you're touching that file anyway...) and make it a >mult-obj file. But better yet, can ed.c just use skip_whitespace? As said, space is not the same as blank, so i'm really not sure if ed could use skip_whitespace or not. From rob at landley.net Wed Jun 7 13:53:30 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 13:53:30 2006 Subject: svn 15315 Message-ID: <200606071653.31040.rob@landley.net> About the (on linux) comment: Linux is the default evironment. Most of our apps only work on Linux, in one way or another. Half of our _directories_ are linux-specific (the console directory, the init directory, the linux module utilities, the linux system utilities, our process utilities are /proc based, I have no idea what other platforms do for syslogd. In theory e2fsprogs and debian utilities could compile for non-linux, but that's a clear port _from_ Linux in that case.) Most of the rest is sprinkled with Linux stuff. The archival directory has rpm and deb utilities, login has vlock, miscutils has devfsd, eject, hdparm... All of this stuff is "on linux". That's the default assumption. Rob (And yes, Mike, I'm not putting a URL for this. No, I didn't forget, I chose not to.) -- Never bet against the cheap plastic solution. From vapier at gentoo.org Wed Jun 7 13:57:45 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 13:54:08 2006 Subject: svn 15195 In-Reply-To: <200606071554.32174.rob@landley.net> References: <200605311714.57260.rob@landley.net> <200606071017.34755.vapier@gentoo.org> <200606071554.32174.rob@landley.net> Message-ID: <200606071657.48166.vapier@gentoo.org> On Wednesday 07 June 2006 15:54, Rob Landley wrote: > On Wednesday 07 June 2006 10:17 am, Mike Frysinger wrote: > > On Wednesday 31 May 2006 17:14, Rob Landley wrote: > > > Finally getting around to reviewing this: > > > > clicky link since rob keeps forgetting :P > > No, I just expect people can look it up themselves. i'm more likely to just ignore the message if i have to commit such effort :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/20060607/de830495/attachment.pgp From vapier at gentoo.org Wed Jun 7 14:00:20 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 13:56:36 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200606071542.58437.rob@landley.net> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606071049.24823.vapier@gentoo.org> <200606071542.58437.rob@landley.net> Message-ID: <200606071700.20892.vapier@gentoo.org> On Wednesday 07 June 2006 15:42, Rob Landley wrote: > On Wednesday 07 June 2006 10:49 am, Mike Frysinger wrote: > > On Tuesday 06 June 2006 18:24, Rob Landley wrote: > > > On Saturday 03 June 2006 2:27 pm, Shaun Jackman wrote: > > > > This patch adds LDFLAGS and LIBRARIES configuration options to > > > > complement the CFLAGS that already exists. Please apply. > > > > > > "Hello, I'd like to register a complaint. Hello miss?" > > > > > > "What do you mean miss?" > > > > > > "I'm terribly sorry, I have a cold..." > > > > > > Has anybody else noticed that on a 2 ghz Pentium M (with TWO MEGABYTES > > > of L2 cache), make help sits there for a full two seconds before > > > dumping the help text? > > > > i'm guessing this has nothing to do with Shaun's post > > It has to do with the fact that the slowdown I'm seeing is due to explicit > > > Sorry, thought it was obvious. except this little rant has nothing to do with the patch at hand considering the default build speed would be completely unchanged Shaun's patch adds user-specified flags which default to nothing ... and if the user throws something in, the make system wouldnt be checking them, simply assuming the user didnt screw anything up -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/20060607/58db5c2f/attachment.pgp From pgf at brightstareng.com Wed Jun 7 14:04:21 2006 From: pgf at brightstareng.com (Paul Fox) Date: Wed Jun 7 14:04:32 2006 Subject: making "test" an ash built-in Message-ID: <28967.1149714261@brightstareng.com> hi -- the help text for CONFIG_TEST currently says that "test" is a builtin command in ash. but it's not, and on slower systems the performance hit is noticeable. i've now implemented this, in a manner very similar to the way i made echo a builtin some time ago -- i moved the guts of coreutils/test.c to a new libbb/bb_test.c, and now call bb_test() from both ash and coreutils/test.c. it seems to work, and running test in a tight shell loop is between 75 and 150 times faster (depending on whether the test conditions are accessing the filesystem or not). this is on a slow ARM with little cache. better machines will show less improvement, i'm sure. the total size hit is around 300 bytes (on x86). any objections if i commit this? diffs below, but for clarity, the diff of the old coreutils/test.c and the new libbb/bb_test.c is shown separately from the rest of the patch. btw, i'm highly tempted to eliminate the CONFIG_ASH_BUILTIN_ECHO and CONFIG_ASH_BUILTIN_TEST config vars, since once the changes have been made to support them, it's essentially free to turn them on. part of the motivation is that the default in the config is 'n' (i think to keep "make allnoconfig" happy?), which means some folks may not be getting the "free" speedup that they should be getting. paul Index: shell/Config.in =================================================================== --- shell/Config.in (revision 15300) +++ shell/Config.in (working copy) @@ -159,6 +159,13 @@ This option recreates the prompt string from the environment variable each time it is displayed. +config CONFIG_ASH_BUILTIN_TEST + bool "Enable builtin version of 'test'" + default n + depends on CONFIG_ASH + help + Enable support for test, built in to ash. + config CONFIG_HUSH bool "hush" default n Index: shell/ash.c =================================================================== --- shell/ash.c (revision 15300) +++ shell/ash.c (working copy) @@ -1225,6 +1225,9 @@ #ifdef CONFIG_ASH_BUILTIN_ECHO static int echocmd(int, char **); #endif +#ifdef CONFIG_ASH_BUILTIN_TEST +static int testcmd(int, char **); +#endif static int execcmd(int, char **); static int exitcmd(int, char **); static int exportcmd(int, char **); @@ -1353,6 +1356,9 @@ { BUILTIN_SPEC_REG "set", setcmd }, { BUILTIN_SPEC_REG "source", dotcmd }, { BUILTIN_SPEC_REG "shift", shiftcmd }, +#ifdef CONFIG_ASH_BUILTIN_TEST + { BUILTIN_REGULAR "test", testcmd }, +#endif { BUILTIN_SPEC_REG "times", timescmd }, { BUILTIN_SPEC_REG "trap", trapcmd }, { BUILTIN_REGULAR "true", truecmd }, @@ -8143,6 +8149,15 @@ return bb_echo(argc, argv); } #endif + +#ifdef CONFIG_ASH_BUILTIN_TEST +static int +testcmd(int argc, char **argv) +{ + return bb_test(argc, argv); +} +#endif + /* memalloc.c */ /* Index: coreutils/Config.in =================================================================== --- coreutils/Config.in (revision 15300) +++ coreutils/Config.in (working copy) @@ -603,8 +603,8 @@ default n help test is used to check file types and compare values, - returning an appropriate exit code. The shells (ash - and bash) have test builtin. + returning an appropriate exit code. The bash shell + has test built in, ash can build it in optionally. config CONFIG_FEATURE_TEST_64 bool "Extend test to 64 bit" Index: libbb/Makefile.in =================================================================== --- libbb/Makefile.in (revision 15300) +++ libbb/Makefile.in (working copy) @@ -35,7 +35,7 @@ getopt_ulflags.c default_error_retval.c wfopen_input.c speed_table.c \ perror_nomsg_and_die.c perror_nomsg.c skip_whitespace.c bb_askpass.c \ warn_ignoring_args.c concat_subpath_file.c vfork_daemon_rexec.c \ - bb_echo.c bb_do_delay.c + bb_echo.c bb_test.c bb_do_delay.c # conditionally compiled objects: LIBBB-$(CONFIG_FEATURE_SHADOWPASSWDS)+=pwd2spwd.c Index: include/libbb.h =================================================================== --- include/libbb.h (revision 15300) +++ include/libbb.h (working copy) @@ -118,6 +118,7 @@ extern void bb_vperror_msg(const char *s, va_list p) __attribute__ ((format (printf, 1, 0))); extern int bb_echo(int argc, char** argv); +extern int bb_test(int argc, char** argv); extern const char *bb_mode_string(int mode); extern int is_directory(const char *name, int followLinks, struct stat *statBuf); [end of patch.] The new contents of coreutils/test.c: /* * test applet implementation for busybox * * 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 "busybox.h" int test_main(int argc, char** argv) { exit(bb_test(argc, argv)); } Here's the diff of old coreutils/test.c and new libbb/bb_test.c: --- coreutils/old.test.c 2006-06-07 09:53:57.000000000 -0400 +++ libbb/bb_test.c 2006-06-07 13:12:40.000000000 -0400 @@ -37,6 +37,7 @@ #include #include #include +#include #include "busybox.h" /* test(1) accepts the following grammar: @@ -183,36 +184,57 @@ static int is_a_group_member(gid_t gid); static void initialize_group_array(void); -int test_main(int argc, char **argv) +static jmp_buf leaving; + +int bb_test(int argc, char **argv) { int res; if (strcmp(bb_applet_name, "[") == 0) { - if (strcmp(argv[--argc], "]")) - bb_error_msg_and_die("missing ]"); + if (strcmp(argv[--argc], "]")) { + bb_error_msg("missing ]"); + return 2; + } argv[argc] = NULL; } if (strcmp(bb_applet_name, "[[") == 0) { - if (strcmp(argv[--argc], "]]")) - bb_error_msg_and_die("missing ]]"); + if (strcmp(argv[--argc], "]]")) { + bb_error_msg("missing ]]"); + return 2; + } argv[argc] = NULL; } + + res = setjmp(leaving); + if (res) + return res; + + /* resetting ngroups is probably unnecessary. it will + * force a new call to getgroups(), which prevents using + * group data fetched during a previous call. but the + * only way the group data could be stale is if there's + * been an intervening call to setgroups(), and this + * isn't likely in the case of a shell. paranoia + * prevails... + */ + ngroups = 0; + /* Implement special cases from POSIX.2, section 4.62.4 */ switch (argc) { case 1: - exit(1); + return 1; case 2: - exit(*argv[1] == '\0'); + return *argv[1] == '\0'; case 3: if (argv[1][0] == '!' && argv[1][1] == '\0') { - exit(!(*argv[2] == '\0')); + return *argv[2] != '\0'; } break; case 4: if (argv[1][0] != '!' || argv[1][1] != '\0') { if (t_lex(argv[2]), t_wp_op && t_wp_op->op_type == BINOP) { t_wp = &argv[1]; - exit(binop() == 0); + return binop() == 0; } } break; @@ -220,7 +242,7 @@ if (argv[1][0] == '!' && argv[1][1] == '\0') { if (t_lex(argv[3]), t_wp_op && t_wp_op->op_type == BINOP) { t_wp = &argv[2]; - exit(!(binop() == 0)); + return binop() != 0; } } break; @@ -232,16 +254,17 @@ if (*t_wp != NULL && *++t_wp != NULL) syntax(*t_wp, "unknown operand"); - return (res); + return res; } static void syntax(const char *op, const char *msg) { if (op && *op) { - bb_error_msg_and_die("%s: %s", op, msg); + bb_error_msg("%s: %s", op, msg); } else { - bb_error_msg_and_die("%s", msg); + bb_error_msg("%s", msg); } + longjmp(leaving, 2); } static arith_t oexpr(enum token n) =--------------------- paul fox, pgf@brightstareng.com From erik at hovland.org Wed Jun 7 14:08:52 2006 From: erik at hovland.org (Erik Hovland) Date: Wed Jun 7 14:08:56 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606071617.09519.rob@landley.net> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070843.46909.farmatito@tiscali.it> <200606071617.09519.rob@landley.net> Message-ID: <20060607210852.GF26185@mage.jpl.nasa.gov> On Wed, Jun 07, 2006 at 04:17:09PM -0400, Rob Landley wrote: > On Wednesday 07 June 2006 2:43 am, Tito wrote: > > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > > > > Hi, > > some comments about the devfsd patch: > > I just marked devfsd as deprecated. It's not going away in 1.2.x, and > probably not in 1.3.x, but I don't plan on it being around forever. > > Just FYI. Thanks. It is still in use in the familiar distribution. But we have a tentative 9 month plan to transition all handhelds to the 2.6 kernel and udev. So I think we are just fine on that schedule. E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request From erik at hovland.org Wed Jun 7 14:12:42 2006 From: erik at hovland.org (Erik Hovland) Date: Wed Jun 7 14:12:45 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606071631.16726.rob@landley.net> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070909.27702.farmatito@tiscali.it> <200606071631.16726.rob@landley.net> Message-ID: <20060607211242.GG26185@mage.jpl.nasa.gov> On Wed, Jun 07, 2006 at 04:31:16PM -0400, Rob Landley wrote: > On Wednesday 07 June 2006 3:09 am, Tito wrote: > > Hi, in the vlock patch: > > > > I can't say due to my limited knowledge if it makes sense > > to have error messages in signal handlers, but nonetheless > > they could be shorter. ;-) > > > > static void release_vt(int signo) > > { > > - if (!o_lock_all) > > - ioctl(vfd, VT_RELDISP, 1); > > - else > > - ioctl(vfd, VT_RELDISP, 0); > > + if (!o_lock_all) { > > + if (ioctl(vfd, VT_RELDISP, 1) < 0) > > + bb_error_msg("failed in attempting to release the display"); > > + } else > > + if (ioctl(vfd, VT_RELDISP, 0) < 0) > > + bb_error_msg("failed in attempting to release the display"); > > } > > It's not Busybox's policy to test if you encountered bad ram during the course > of operation. Will the user not otherwise notice this failure if the console > doesn't unlock? What exactly are they supposed to do about it if it happens? > Is it at all likely to happen in the regular course of operations? (What > would cause this to happen? The ioctl returns an error primarily because the > console might not have been locked in the first place, not because the kernel > can't be trusted to do its job reliably...) > > Could ignoring this error conceivably be any worse than reporting it? It's > not like the program is going to DO anything about it, the error message is > just the program is sticking its tongue out at the user. > > There are lots of errors we don't test for because we ignoring it is no worse > than reporting it. If we can't do anything useful about it and it's not > going to eat your data, is it worth the bytes being pedantic over a "this > should never happen"? This is just the sort of discussion that I was hoping to have by throwing these patches out there. In my day job we find that being pedantic is always the right choice. We want to know that things are going bad as soon as possible. Having read your and Tito's comments, I am definitely of a mind to back out this change at least. Reporting it only belabors reporting a known bad state. Thanks again for the comments. E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request From vapier at gentoo.org Wed Jun 7 14:27:56 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 14:24:13 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606071617.09519.rob@landley.net> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070843.46909.farmatito@tiscali.it> <200606071617.09519.rob@landley.net> Message-ID: <200606071727.57251.vapier@gentoo.org> On Wednesday 07 June 2006 16:17, Rob Landley wrote: > On Wednesday 07 June 2006 2:43 am, Tito wrote: > > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > > > > Hi, > > some comments about the devfsd patch: > > I just marked devfsd as deprecated. It's not going away in 1.2.x, and > probably not in 1.3.x, but I don't plan on it being around forever. it cant really be dropped until support for linux-2.4 is dropped altogether -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/20060607/157cd7e0/attachment.pgp From rob at landley.net Wed Jun 7 14:25:05 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 14:25:05 2006 Subject: [PATCH] fix minor bugs in hdparm and don't block when reading from stdin In-Reply-To: <200606071029.36783.vapier@gentoo.org> References: <200606021533.18348.farmatito@tiscali.it> <200606071029.36783.vapier@gentoo.org> Message-ID: <200606071725.05416.rob@landley.net> On Wednesday 07 June 2006 10:29 am, Mike Frysinger wrote: > On Friday 02 June 2006 09:33, Tito wrote: > > +++ miscutils/hdparm.c 2006-06-02 15:21:51.000000000 +0200 > > @@ -2124,8 +2124,8 @@ > > - USE_FEATURE_HDPARM_GET_IDENTITY(get_IDentity = (c == > > 'I')); - USE_FEATURE_HDPARM_GET_IDENTITY(get_identity = (c > > == 'i')); + USE_FEATURE_HDPARM_GET_IDENTITY(get_IDentity |= > > (c == 'I')); + USE_FEATURE_HDPARM_GET_IDENTITY(get_identity > > |= (c == 'i')); > > merged, thanks > -mike I know I'm a bit behind, but when you merge only part of a patch that was cc'd to me, so that it conflicts with the cleaned up version of the patch in my tree (with an #if ENABLE turned into if (ENABLE) like it should have been in the first place)... Net, it actually slows things down. Just sayin' Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Wed Jun 7 14:26:35 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 14:26:39 2006 Subject: svn 15315 In-Reply-To: <200606071653.31040.rob@landley.net> References: <200606071653.31040.rob@landley.net> Message-ID: <20060607212635.GS8161@aon.at> On Wed, Jun 07, 2006 at 04:53:30PM -0400, Rob Landley wrote: >About the (on linux) comment: I've removed the comment. From rob at landley.net Wed Jun 7 14:29:19 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 14:29:20 2006 Subject: [patch] save ~600B In-Reply-To: <200606071038.06393.vapier@gentoo.org> References: <22035.1149511287@brightstareng.com> <200606071038.06393.vapier@gentoo.org> Message-ID: <200606071729.19438.rob@landley.net> On Wednesday 07 June 2006 10:38 am, Mike Frysinger wrote: > On Monday 05 June 2006 08:41, Paul Fox wrote: > > wharm wrote: > > > personally i am the fan of > > > exit( EXIT_FAILURE ) ; > > > > and "EXIT_FAILURE" is cleverly defined as "1", right? why > > not just "exit(1)"? this keeps it simple, concise, and transparent. > > funny, i find EXIT_FAILURE a lot easier to read ... especially when some > functions return 0 to mean success while others return 0 to mean failure I find it more difficult to read. I've also had to clean up at least one bug in busybox so far (about a year ago, I vaguely remember it was in the archival directory somewhere) caused by somebody returning EXIT_SUCCESS and then going essentially: if(try_thingy()) then {it_worked();} and the logic triggered _backwards_... > -mike Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Wed Jun 7 14:31:05 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 14:31:11 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606071727.57251.vapier@gentoo.org> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070843.46909.farmatito@tiscali.it> <200606071617.09519.rob@landley.net> <200606071727.57251.vapier@gentoo.org> Message-ID: <20060607213105.GT8161@aon.at> On Wed, Jun 07, 2006 at 05:27:56PM -0400, Mike Frysinger wrote: >On Wednesday 07 June 2006 16:17, Rob Landley wrote: >> On Wednesday 07 June 2006 2:43 am, Tito wrote: >> > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: >> > >> > Hi, >> > some comments about the devfsd patch: >> >> I just marked devfsd as deprecated. It's not going away in 1.2.x, and >> probably not in 1.3.x, but I don't plan on it being around forever. > >it cant really be dropped until support for linux-2.4 is dropped altogether Which will not be soon. Along the same lines, why don't we have a CONFIG_OBSOLETE so applets that are scheduled to be obsoleted in the next years can depend on that? The NITPICK stuff really serves no purpose while we could use OBSOLETE right now. Just a thought.. From rob at landley.net Wed Jun 7 14:34:35 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 14:34:39 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <20060607163323.GA2422@aon.at> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606071049.24823.vapier@gentoo.org> <20060607163323.GA2422@aon.at> Message-ID: <200606071734.36095.rob@landley.net> On Wednesday 07 June 2006 12:33 pm, Bernhard Fischer wrote: > On Wed, Jun 07, 2006 at 10:49:24AM -0400, Mike Frysinger wrote: > >On Tuesday 06 June 2006 18:24, Rob Landley wrote: > >> On Saturday 03 June 2006 2:27 pm, Shaun Jackman wrote: > >> > This patch adds LDFLAGS and LIBRARIES configuration options to > >> > complement the CFLAGS that already exists. Please apply. > >> > >> "Hello, I'd like to register a complaint. Hello miss?" > >> > >> "What do you mean miss?" > >> > >> "I'm terribly sorry, I have a cold..." > >> > >> Has anybody else noticed that on a 2 ghz Pentium M (with TWO MEGABYTES > >> of L2 cache), make help sits there for a full two seconds before dumping > >> the help text? > > > >i'm guessing this has nothing to do with Shaun's post > > Most likely, yes. > Also it's fun since a configure script could do exactly this (caching > the settings) over runs. A) We are not having both ./configure and make menuconfig. It's just not happening. B) We already cache .depend, why not .ccflags? As long as it goes in the output directory, life should be good. (If you don't do a distclean between switching compilers in the same output directory, that's pilot error.) > An easy fix for not looking at the gcc-flags for noconfig targets (resp. > notools target since some noconfig targets need hosttools and these may > need to check for flags for the HOSTCC) would be to just not check for > them if ($(MAKECMDGOAL),help) > Whether skipping these works for all versions of make is left as an > exercise for the curious (could be that i did it already in the > buildsys-patch i sent to the list WRT 'compressed_usage broke parallel > builds' -- http://www.busybox.net/lists/busybox/2006-May/021764.html). > > Rob, what about instead fixing the testsuite so it can be run when > building out of tree? :P The last version I worked on ran just fine if you tarred it up and ran it from a completely different directory. People then started to go "oh, we have to run with the original PDP-11 assembly shell from 1971" and I wandered away from the area in sheer disgust. You'll know I've gotten back to it when the first line changes to "#!/bin/bash"... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 14:43:05 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 14:43:11 2006 Subject: [patch] save ~600B In-Reply-To: <20060607165838.GD2422@aon.at> References: <20060604184916.GD8161@aon.at> <20060604201452.GE8161@aon.at> <20060607165838.GD2422@aon.at> Message-ID: <200606071743.05468.rob@landley.net> On Wednesday 07 June 2006 12:58 pm, Bernhard Fischer wrote: > On Sun, Jun 04, 2006 at 10:14:53PM +0200, Bernhard Fischer wrote: > >On Sun, Jun 04, 2006 at 08:49:16PM +0200, Bernhard Fischer wrote: > >>Hi, > >> > >>- use bb_msg_... in more places. > >> > >>While i think that this patch should be ok, i'd be glad if someone could > >>look over it (been staring at it for too long). > >> > >>TIA, > >>Bernhard > > > >updated version 02e > > Since i didn't see any objection (nor a real review of the actual > patch) i'll just go and i apply it later today.. See the earlier email about the 472 messages I collated yesterday. According to the window I have open on my desktop, I made it to line 384 of the patch before I had to go do something else. Big long patch touching 8 gazillion files. Right, reviewing the rest of the darn thing... At some point in the future, gcc's build-at-once mode will grow the ability to merge duplicate strings. And then we'll have to undo all this again. But in the meantime, why not? (Tired. Very tired.) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 14:50:25 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 14:50:32 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <7f45d9390606070908p557ca70di87872f935426b57@mail.gmail.com> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606061825.55170.rob@landley.net> <7f45d9390606070908p557ca70di87872f935426b57@mail.gmail.com> Message-ID: <200606071750.26041.rob@landley.net> On Wednesday 07 June 2006 12:08 pm, Shaun Jackman wrote: > On 6/6/06, Rob Landley wrote: > > Does supplying it as an environment variable work? > > > > LDFLAGS="-Wl,--verbose -Wl,-n -Wl,-O1 -Wl,-t" make > > > > There are such things as wrapper scripts... > > Yes, using an environment variable would work, although it's not > recommended. See below for comments from the make's manual. And cdrecord goes out of its way to complain about using /dev/hdc as the name of the device to record to. Screw 'em both. You can set these things either in environment variables or on the command line. "LDFLAGS=blah make" or "make LDFLAGS=blah" should both work. Moving some of it into CONFIG is about as non-flexible as having to edit the makefile to change the default values. > I'd much > prefer, and it seems far more congruous, to set LDFLAGS in the same > place one sets CFLAGS. I'd prefer if they were both set on the command line, either before or after the invocation of Make. (I keep meaning to test if "make CROSS_COMPILE=prefix-" works for us the way it does for the Linux kernel. I'd have to look up the precedence order of make variable assignments, and I need to go get dinner before doing much more on the computer. Getting punchy...) > It seems pretty arbitrary that CFLAGS can be > set in the configuration process, but LDFLAGS cannot. Removing CFLAGS from the configuration process and updating the README to give examples of how to do it right would make an equal amount of sense, but I haven't wanted to touch the existing setup without a little more warning. Right now menuconfig is used both to select features and to define the build environment, and those two things really shouldn't be tied together like that. (I don't think so anyway. Do you disagree?) Rob -- Never bet against the cheap plastic solution. From stephane.billiart at gmail.com Wed Jun 7 14:56:11 2006 From: stephane.billiart at gmail.com (stephane.billiart@gmail.com) Date: Wed Jun 7 14:56:24 2006 Subject: [patch] fix run_parts Message-ID: <20060607215611.GA32151@localhost.localdomain> The attached patch fix run_parts compilation when CONFIG_GETOPT_LONG is not set, replacing getopt_long with bb_getopt_ulflags. -- St?phane Billiart http://perso.orange.fr/billiart/ -------------- next part -------------- Index: debianutils/run_parts.c =================================================================== --- debianutils/run_parts.c (revision 15327) +++ debianutils/run_parts.c (working copy) @@ -39,13 +39,14 @@ #include #include - +#if ENABLE_FEATURE_RUN_PARTS_LONG_OPTIONS static const struct option runparts_long_options[] = { { "test", 0, NULL, 't' }, { "umask", 1, NULL, 'u' }, { "arg", 1, NULL, 'a' }, { 0, 0, 0, 0 } }; +#endif extern char **environ; @@ -60,8 +61,10 @@ umask(022); - while ((opt = getopt_long (argc, argv, "tu:a:", - runparts_long_options, NULL)) > 0) +#if ENABLE_FEATURE_RUN_PARTS_LONG_OPTIONS + bb_applet_long_options = runparts_long_options; +#endif + while ((opt = bb_getopt_ulflags (argc, argv, "tu:a:")) > 0) { switch (opt) { /* Enable test mode */ From vapier at gentoo.org Wed Jun 7 15:00:50 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed Jun 7 14:57:01 2006 Subject: uClinux changes for init/sysklogd Message-ID: <200606071800.50906.vapier@gentoo.org> Skipped content of type multipart/signed-------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-uclinux.patch.bz2 Type: application/x-bzip2 Size: 14048 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060607/c3e54dd3/busybox-uclinux.patch-0001.bin From rep.nop at aon.at Wed Jun 7 15:03:57 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 15:04:03 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <20060606223458.GB16710@mage.jpl.nasa.gov> References: <20060606223458.GB16710@mage.jpl.nasa.gov> Message-ID: <20060607220357.GU8161@aon.at> On Tue, Jun 06, 2006 at 03:34:58PM -0700, Erik Hovland wrote: >After the very helpful feedback and the continual searching for bugs, I >have expanded my patch associated to various bugs all over busybox. > >This patchset has gotten bigger. So I have taken to splitting them up by >file and annotating them in patch. I hope that is useful. Let me know if >there is some way I can make this easier to go over or help with >acceptance. > >Feel free to address each patch seperately in responding. I would not be >surprised at all if I accidentally introduced regressions. I have not >yet tried running the unit testing. But I have attempted to understand >why each bug is a bug and addressed it according to its severity. > >I appreciate any attention you might give this work. It would be nice if you'd use (GNU)diff's -p if you send a batch >E > > archival/dpkg_deb.c | 6 +++-- we have xchdir() and see the recent discussion about the retval > archival/rpm.c | 3 +- xchdir() > archival/tar.c | 8 +++---- Sounds ok except that perhaps the two memcpy add to the size needlessly, if compared to just one. Didn't look if that's true > console-tools/loadkmap.c | 3 +- a bold return(1) should do > coreutils/chown.c | 4 ++- Sounds ok > e2fsprogs/ext2fs/ext_attr.c | 5 +++- > e2fsprogs/ext2fs/flushb.c | 3 +- > e2fsprogs/ext2fs/mkjournal.c | 3 +- > e2fsprogs/ext2fs/read_bb_file.c | 2 - > e2fsprogs/mke2fs.c | 8 ++++--- > e2fsprogs/tune2fs.c | 4 +-- skipped. > init/init.c | 10 +++++++-- msg is far too long (not sure if checking the ioctl is useful at all there) xchdir() if you really feel like. I'll look at the rest later. Let me note that it would be very nice if you could use diff -p if your diff supports it and also that a size bar.o.orig bar.o would be nice to see how much it adds. > libbb/concat_subpath_file.c | 2 + > libbb/login.c | 5 +++- > libbb/loop.c | 4 ++- > loginutils/getty.c | 9 ++++---- > loginutils/login.c | 15 +++---------- > loginutils/vlock.c | 19 +++++++++++------ > miscutils/crontab.c | 2 - > miscutils/devfsd.c | 14 +++++++------ > networking/ifupdown.c | 12 ----------- > networking/libiproute/iplink.c | 42 ++------------------------------------- > networking/libiproute/iproute.c | 12 ++++++----- > networking/libiproute/iptunnel.c | 2 - > networking/tftp.c | 25 +++++++++++++---------- > networking/udhcp/socket.c | 2 - > networking/zcip.c | 2 - > procps/fuser.c | 3 +- > shell/lash.c | 2 - > shell/msh.c | 6 ++++- > util-linux/fdisk.c | 2 - > util-linux/mdev.c | 3 +- > util-linux/nfsmount.c | 2 - > 33 files changed, 118 insertions(+), 126 deletions(-) From rob at landley.net Wed Jun 7 15:06:32 2006 From: rob at landley.net (Rob Landley) Date: Wed Jun 7 15:06:35 2006 Subject: [PATCH] Include netinet/in.h in libbb.h In-Reply-To: <20060607164847.GC2422@aon.at> References: <7f45d9390606031125n57ae3cadrebb118f19def1e54@mail.gmail.com> <200606061819.12260.rob@landley.net> <20060607164847.GC2422@aon.at> Message-ID: <200606071806.33343.rob@landley.net> On Wednesday 07 June 2006 12:48 pm, Bernhard Fischer wrote: > >In general, it would be nice if applets could just #include one header > > file and all the weird issues that keep coming up about which header > > files apply to which platforms and what order they have to go in in order > > to avoid stomping each other (yes, the recent Red Hat build break) were > > just not an applet's problem. > > I'm not a big fan of catch-it-all private headers, but if you prefer it > that way, i can live. *shrug* I dislike having to fix the same problem in 15 places. Rob -- Never bet against the cheap plastic solution. From rep.nop at aon.at Wed Jun 7 15:19:36 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed Jun 7 15:19:42 2006 Subject: [patch] fix run_parts In-Reply-To: <20060607215611.GA32151@localhost.localdomain> References: <20060607215611.GA32151@localhost.localdomain> Message-ID: <20060607221936.GV8161@aon.at> On Wed, Jun 07, 2006 at 11:56:11PM +0200, stephane.billiart@gmail.com wrote: >The attached patch fix run_parts compilation when CONFIG_GETOPT_LONG is >not set, replacing getopt_long with bb_getopt_ulflags. I'm pretty sure that that patch doesn't work. If you want to help with run_parts, then let me point you to http://busybox.net/lists/busybox/2006-May/021828.html cheers, > >-- >St?phane Billiart http://perso.orange.fr/billiart/ >Index: debianutils/run_parts.c >=================================================================== >--- debianutils/run_parts.c (revision 15327) >+++ debianutils/run_parts.c (working copy) >@@ -39,13 +39,14 @@ > #include > #include > >- >+#if ENABLE_FEATURE_RUN_PARTS_LONG_OPTIONS > static const struct option runparts_long_options[] = { > { "test", 0, NULL, 't' }, > { "umask", 1, NULL, 'u' }, > { "arg", 1, NULL, 'a' }, > { 0, 0, 0, 0 } > }; >+#endif > > extern char **environ; > >@@ -60,8 +61,10 @@ > > umask(022); > >- while ((opt = getopt_long (argc, argv, "tu:a:", >- runparts_long_options, NULL)) > 0) >+#if ENABLE_FEATURE_RUN_PARTS_LONG_OPTIONS >+ bb_applet_long_options = runparts_long_options; >+#endif >+ while ((opt = bb_getopt_ulflags (argc, argv, "tu:a:")) > 0) > { > switch (opt) { > /* Enable test mode */ >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox From natanael.copa at gmail.com Wed Jun 7 15:58:19 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed Jun 7 16:02:04 2006 Subject: making "test" an ash built-in In-Reply-To: <28967.1149714261@brightstareng.com> References: <28967.1149714261@brightstareng.com> Message-ID: <1149721099.15017.146.camel@localhost> On Wed, 2006-06-07 at 17:04 -0400, Paul Fox wrote: > hi -- > > the help text for CONFIG_TEST currently says that "test" is a > builtin command in ash. but it's not, and on slower systems the > performance hit is noticeable. > > i've now implemented this, in a manner very similar to the way i > made echo a builtin some time ago -- i moved the guts of > coreutils/test.c to a new libbb/bb_test.c, and now call bb_test() > from both ash and coreutils/test.c. > > it seems to work, and running test in a tight shell loop is > between 75 and 150 times faster (depending on whether the test > conditions are accessing the filesystem or not). this is on > a slow ARM with little cache. better machines will show less > improvement, i'm sure. > > the total size hit is around 300 bytes (on x86). > > any objections if i commit this? FYI. busybox ash have been unacceptable slow for me. I have eneded using /bin/sh -> dash and entering /bin/ash as shell for root (the autocompletion is nice) which have costed me approx 94kb. I have been using this as a temporary solution until I get time to find out what makes ash slow. (i had a feeling it was related to arthimetics) For me, almost any size increase would be more than welcome (as long as it is below 94kb) if the speed would be good enough so I could drop dash. Someone in LEAF said the same. They also use dash because busybox ash is way too slow, but they miss the autocompletion. I think we calculated that a size increase up to 20kb would be acceptable for bering-uclibc if it improved speed enough to drop dash. my $0.02 If I get a chance, I'll test the patch tomorrow. From sjackman at gmail.com Wed Jun 7 16:48:24 2006 From: sjackman at gmail.com (Shaun Jackman) Date: Wed Jun 7 16:48:28 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200606071750.26041.rob@landley.net> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606061825.55170.rob@landley.net> <7f45d9390606070908p557ca70di87872f935426b57@mail.gmail.com> <200606071750.26041.rob@landley.net> Message-ID: <7f45d9390606071648u7941abddr7b779119467759b1@mail.gmail.com> On 6/7/06, Rob Landley wrote: > I'd prefer if they were both set on the command line, either before or after > the invocation of Make. (I keep meaning to test if > "make CROSS_COMPILE=prefix-" works for us the way it does for the Linux > kernel. I'd have to look up the precedence order of make variable > assignments, and I need to go get dinner before doing much more on the > computer. Getting punchy...) The order of make variable precedence is command line over Makefile over environment. > Right now menuconfig is used both to select features and to define the build > environment, and those two things really shouldn't be tied together like > that. (I don't think so anyway. Do you disagree?) There needs to be some mechanism to configure both features and the build environment. If we want to reserve make config for features alone, let's have Rules.mak include .config.mak if it exists, and allow the user to edit .config.mak and add CFLAGS, LDFLAGS, LDLIBS, and whatever else tickles his or her fancy, there. Cheers, Shaun From pgf at brightstareng.com Wed Jun 7 19:03:38 2006 From: pgf at brightstareng.com (Paul Fox) Date: Wed Jun 7 19:04:00 2006 Subject: making "test" an ash built-in In-Reply-To: natanael.copa's message of Thu, 08 Jun 2006 00:58:19 +0200. <1149721099.15017.146.camel@localhost> Message-ID: <2804.1149732218@brightstareng.com> nathaniel.copa wrote: > > FYI. busybox ash have been unacceptable slow for me. I have eneded > using /bin/sh -> dash and entering /bin/ash as shell for root (the ... > Someone in LEAF said the same. They also use dash because busybox ash is > way too slow, but they miss the autocompletion. I think we calculated i'm a little confused by this, since busybox ash and dash both come from the same origins, and, in fact, vodz has been keeping ash in sync with dash on a fairly regular basis. but maybe they're more different than i thought. how are you measuring the speed difference, and what version of dash are you running? paul =--------------------- paul fox, pgf@brightstareng.com From farmatito at tiscali.it Wed Jun 7 23:05:13 2006 From: farmatito at tiscali.it (Tito) Date: Wed Jun 7 23:06:10 2006 Subject: [PATCH] fix minor bugs in hdparm and don't block when reading from stdin In-Reply-To: <200606071725.05416.rob@landley.net> References: <200606021533.18348.farmatito@tiscali.it> <200606071029.36783.vapier@gentoo.org> <200606071725.05416.rob@landley.net> Message-ID: <200606080805.14218.farmatito@tiscali.it> On Wednesday 7 June 2006 23:25, Rob Landley wrote: > On Wednesday 07 June 2006 10:29 am, Mike Frysinger wrote: > > On Friday 02 June 2006 09:33, Tito wrote: > > > +++ miscutils/hdparm.c 2006-06-02 15:21:51.000000000 +0200 > > > @@ -2124,8 +2124,8 @@ > > > - USE_FEATURE_HDPARM_GET_IDENTITY(get_IDentity = (c == > > > 'I')); - USE_FEATURE_HDPARM_GET_IDENTITY(get_identity = (c > > > == 'i')); + USE_FEATURE_HDPARM_GET_IDENTITY(get_IDentity |= > > > (c == 'I')); + USE_FEATURE_HDPARM_GET_IDENTITY(get_identity > > > |= (c == 'i')); > > > > merged, thanks > > -mike > > I know I'm a bit behind, but when you merge only part of a patch that was cc'd > to me, so that it conflicts with the cleaned up version of the patch in my > tree (with an #if ENABLE turned into if (ENABLE) like it should have been in > the first place)... Net, it actually slows things down. Hi, root@localhost:/dev/pts/2:/root/Desktop/busybox# make CC miscutils/hdparm.o /root/Desktop/busybox/miscutils/hdparm.c: In function ?hdparm_main?: /root/Desktop/busybox/miscutils/hdparm.c:2190: warning: implicit declaration of function ?identify_from_stdin? AR cru miscutils/miscutils.a LINK busybox_unstripped STRIP busybox root@localhost:/dev/pts/2:/root/Desktop/busybox# The if(ENABLE) would better be an #if ENABLE to avoid the above error message please fix it. Thanks and Ciao, Tito > Just sayin' > > Rob From farmatito at tiscali.it Wed Jun 7 23:15:54 2006 From: farmatito at tiscali.it (Tito) Date: Wed Jun 7 23:16:47 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606071617.09519.rob@landley.net> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606070843.46909.farmatito@tiscali.it> <200606071617.09519.rob@landley.net> Message-ID: <200606080815.55145.farmatito@tiscali.it> On Wednesday 7 June 2006 22:17, Rob Landley wrote: > On Wednesday 07 June 2006 2:43 am, Tito wrote: > > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > > > > Hi, > > some comments about the devfsd patch: > > I just marked devfsd as deprecated. It's not going away in 1.2.x, and > probably not in 1.3.x, but I don't plan on it being around forever. > > Just FYI. Please apply the last part of the patch as it fixes a real bug: @@ -1311,9 +1313,9 @@ ????????/* compare_string_array returns i>=0 ?*/ ????????i=compare_string_array(field_names, variable); -???????if ( i > 6 && (i > 1 && gv_info == NULL)) -???????????????????????return (NULL); -???????if( i >= 0 || i <= 3) +???????if (i > 6 || (i > 1 && gv_info == NULL) || i < 0) +???????????????return (NULL); +???????if( i <= 3 ?&& i >= 0 ) ????????{ ????????????????debug_msg_logger(LOG_INFO, "%s: i=%d %s", __FUNCTION__, i ,field_names[i+7]); ????????????????return(field_names[i+7]); Ciao, TIto > Rob From rep.nop at aon.at Thu Jun 8 01:34:59 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Jun 8 01:35:13 2006 Subject: [patch] save ~600B In-Reply-To: <200606071743.05468.rob@landley.net> References: <20060604184916.GD8161@aon.at> <20060604201452.GE8161@aon.at> <20060607165838.GD2422@aon.at> <200606071743.05468.rob@landley.net> Message-ID: <20060608083459.GA20177@aon.at> On Wed, Jun 07, 2006 at 05:43:05PM -0400, Rob Landley wrote: >On Wednesday 07 June 2006 12:58 pm, Bernhard Fischer wrote: >> On Sun, Jun 04, 2006 at 10:14:53PM +0200, Bernhard Fischer wrote: >> >On Sun, Jun 04, 2006 at 08:49:16PM +0200, Bernhard Fischer wrote: >> >>Hi, >> >> >> >>- use bb_msg_... in more places. >> >> >> >>While i think that this patch should be ok, i'd be glad if someone could >> >>look over it (been staring at it for too long). >> >> >> >>TIA, >> >>Bernhard >> > >> >updated version 02e >> >> Since i didn't see any objection (nor a real review of the actual >> patch) i'll just go and i apply it later today.. > >See the earlier email about the 472 messages I collated yesterday. According >to the window I have open on my desktop, I made it to line 384 of the patch >before I had to go do something else. Big long patch touching 8 gazillion >files. Right, reviewing the rest of the darn thing... > >At some point in the future, gcc's build-at-once mode will grow the ability to It may grow that ability or did i miss the discussion of a proposed patch which does teach gcc to do so? >merge duplicate strings. And then we'll have to undo all this again. But in >the meantime, why not? I don't see why we would ever have to undo this. It's a sane thing to do, regardless of a future compiler eventually trying to get this right sometimes in the far, far future. whatever. > >(Tired. Very tired.) From natanael.copa at gmail.com Thu Jun 8 01:33:34 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jun 8 01:37:34 2006 Subject: making "test" an ash built-in In-Reply-To: <2804.1149732218@brightstareng.com> References: <2804.1149732218@brightstareng.com> Message-ID: <1149755614.15017.170.camel@localhost> On Wed, 2006-06-07 at 22:03 -0400, Paul Fox wrote: > nathaniel.copa wrote: > > > > FYI. busybox ash have been unacceptable slow for me. I have eneded > > using /bin/sh -> dash and entering /bin/ash as shell for root (the > ... > > Someone in LEAF said the same. They also use dash because busybox ash is > > way too slow, but they miss the autocompletion. I think we calculated > > i'm a little confused by this, since busybox ash and dash both > come from the same origins, and, in fact, vodz has been keeping > ash in sync with dash on a fairly regular basis. but maybe they're > more different than i thought. > > how are you measuring the speed difference, and what version of dash > are you running? Coldplugging the pcibus (/etc/hostplug/pci.rc) takes 2 minutes and 3.8 seconds using ash and 5.84 seconds using dash. I can tell you that you notice the difference without measure anything. the version is dash-0.5.2.7 I checked it out and the critical code is in /etc/hotplug/pci.agent in function pci_map_modules There is the modules.pcimap (2211 lines here) parsed for every pci device. Scripts are here: http://www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_09_23.tar.gz The patch did no noticeable difference. I had to merge it manually. I have attatched a new patch against current svn (revision 15335). -------------- next part -------------- A non-text attachment was scrubbed... Name: bb-ash-test.patch Type: text/x-patch Size: 27291 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060608/b9702100/bb-ash-test-0001.bin From natanael.copa at gmail.com Thu Jun 8 02:12:09 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jun 8 02:16:01 2006 Subject: making "test" an ash built-in In-Reply-To: <2804.1149732218@brightstareng.com> References: <2804.1149732218@brightstareng.com> Message-ID: <1149757929.15017.178.camel@localhost> On Wed, 2006-06-07 at 22:03 -0400, Paul Fox wrote: > nathaniel.copa wrote: > > > > FYI. busybox ash have been unacceptable slow for me. I have eneded > > using /bin/sh -> dash and entering /bin/ash as shell for root (the > ... > > Someone in LEAF said the same. They also use dash because busybox ash is > > way too slow, but they miss the autocompletion. I think we calculated > > i'm a little confused by this, since busybox ash and dash both > come from the same origins, and, in fact, vodz has been keeping > ash in sync with dash on a fairly regular basis. but maybe they're > more different than i thought. > > how are you measuring the speed difference, and what version of dash > are you running? Try run this in busybox ash and compare with dash: i=0 ; while [ $i -lt 12000 ] ; do i=$(($i+1)); done its the [ $i -lt 12000 ] that makes the difference. If I do: i=0 ; while /usr/bin/test $i -lt 12000 ; do i=$(($i+1)); done Even dash and bash goes slow. (/usr/bin/test comes from coreutils on my system) I believe its the "test" app that needs to be speedier. -- Natanael Copa From natanael.copa at gmail.com Thu Jun 8 04:36:56 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jun 8 04:40:51 2006 Subject: making "test" an ash built-in In-Reply-To: <1149755614.15017.170.camel@localhost> References: <2804.1149732218@brightstareng.com> <1149755614.15017.170.camel@localhost> Message-ID: <1149766616.15017.185.camel@localhost> On Thu, 2006-06-08 at 10:33 +0200, Natanael Copa wrote: > On Wed, 2006-06-07 at 22:03 -0400, Paul Fox wrote: > > nathaniel.copa wrote: > > > > > > FYI. busybox ash have been unacceptable slow for me. I have eneded > > > using /bin/sh -> dash and entering /bin/ash as shell for root (the > > ... > > > Someone in LEAF said the same. They also use dash because busybox ash is > > > way too slow, but they miss the autocompletion. I think we calculated > > > > i'm a little confused by this, since busybox ash and dash both > > come from the same origins, and, in fact, vodz has been keeping > > ash in sync with dash on a fairly regular basis. but maybe they're > > more different than i thought. > > > > how are you measuring the speed difference, and what version of dash > > are you running? ... > The patch did no noticeable difference. I was wrong. The patch was *The* difference. There were missing '[' and '[[' builtins though. This is just incredible good! It means that I can drop dash and use busybox ash only. It means that the LEAF bering people can drop dash and use busybox ash. (should save them approx 20kb and give them autocompletion in addition) I will post an updated patch in a separate mail. -- Natanael Copa From natanael.copa at gmail.com Thu Jun 8 04:54:16 2006 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu Jun 8 04:58:13 2006 Subject: [PATCH] update: making "test" an ash built-in In-Reply-To: <28967.1149714261@brightstareng.com> References: <28967.1149714261@brightstareng.com> Message-ID: <1149767656.15017.199.camel@localhost> On Wed, 2006-06-07 at 17:04 -0400, Paul Fox wrote: > hi -- > > the help text for CONFIG_TEST currently says that "test" is a > builtin command in ash. but it's not, and on slower systems the > performance hit is noticeable. Even on my Pentium D the performance hit was so huge that busybox ash was completely unuseable. > it seems to work, and running test in a tight shell loop is > between 75 and 150 times faster (depending on whether the test > conditions are accessing the filesystem or not). this is on > a slow ARM with little cache. better machines will show less > improvement, i'm sure. The difference was big even on faster computers. > any objections if i commit this? You need builtins for '[' and '[[' too. Please see the attatched update patch. Its agains current svn. The patch below is just for an overview what differs the old coreutils/test.c with the new libbb/bb_test.c. Note that I replaced the rest of the bb_error_msg_and_die with only bb_error_msg. You would not like the entire shell die just because you entered wrong number of params to 'test', '[' or '[['. I would love to see it committed. --- coreutils/test.c 2006-06-08 13:44:52.687869936 +0200 +++ libbb/bb_test.c 2006-06-08 13:27:28.202655824 +0200 @@ -37,6 +37,7 @@ #include #include #include +#include #include "busybox.h" /* test(1) accepts the following grammar: @@ -182,36 +183,49 @@ static int is_a_group_member(gid_t gid); static void initialize_group_array(void); -int test_main(int argc, char **argv) +static jmp_buf leaving; + +int bb_test(const char *closebracket, int argc, char **argv) { int res; - if (strcmp(bb_applet_name, "[") == 0) { - if (strcmp(argv[--argc], "]")) - bb_error_msg_and_die("missing ]"); - argv[argc] = NULL; - } - if (strcmp(bb_applet_name, "[[") == 0) { - if (strcmp(argv[--argc], "]]")) - bb_error_msg_and_die("missing ]]"); + if (closebracket) { + if (strcmp(argv[--argc], closebracket)) { + bb_error_msg("missing %s", closebracket); + return 2; + } argv[argc] = NULL; } + res = setjmp(leaving); + if (res) + return res; + + /* resetting ngroups is probably unnecessary. it will + * force a new call to getgroups(), which prevents using + * group data fetched during a previous call. but the + * only way the group data could be stale is if there's + * been an intervening call to setgroups(), and this + * isn't likely in the case of a shell. paranoia + * prevails... + */ + ngroups = 0; + /* Implement special cases from POSIX.2, section 4.62.4 */ switch (argc) { case 1: - exit(1); + return 1; case 2: - exit(*argv[1] == '\0'); + return *argv[1] == '\0'; case 3: if (argv[1][0] == '!' && argv[1][1] == '\0') { - exit(!(*argv[2] == '\0')); + return *argv[2] != '\0'; } break; case 4: if (argv[1][0] != '!' || argv[1][1] != '\0') { if (t_lex(argv[2]), t_wp_op && t_wp_op->op_type == BINOP) { t_wp = &argv[1]; - exit(binop() == 0); + return binop() == 0; } } break; @@ -219,7 +233,7 @@ if (argv[1][0] == '!' && argv[1][1] == '\0') { if (t_lex(argv[3]), t_wp_op && t_wp_op->op_type == BINOP) { t_wp = &argv[2]; - exit(!(binop() == 0)); + return binop() != 0; } } break; @@ -228,10 +242,11 @@ t_wp = &argv[1]; res = !oexpr(t_lex(*t_wp)); - if (*t_wp != NULL && *++t_wp != NULL) - bb_error_msg_and_die("%s: unknown operand", *t_wp); - - return (res); + if (*t_wp != NULL && *++t_wp != NULL) { + bb_error_msg("%s: unknown operand", *t_wp); + longjmp(leaving, 2); + } + return res; } static arith_t oexpr(enum token n) @@ -269,18 +284,23 @@ arith_t res; if (n == EOI) { - bb_error_msg_and_die("argument expected"); + bb_error_msg("argument expected"); + longjmp(leaving, 2); } if (n == LPAREN) { res = oexpr(t_lex(*++t_wp)); - if (t_lex(*++t_wp) != RPAREN) - bb_error_msg_and_die("closing paren expected"); + if (t_lex(*++t_wp) != RPAREN) { + bb_error_msg("closing paren expected"); + longjmp(leaving, 2); + } return res; } if (t_wp_op && t_wp_op->op_type == UNOP) { /* unary expression */ - if (*++t_wp == NULL) - bb_error_msg_and_die(bb_msg_requires_arg, t_wp_op->op_text); + if (*++t_wp == NULL) { + bb_error_msg(bb_msg_requires_arg, t_wp_op->op_text); + longjmp(leaving, 2); + } switch (n) { case STREZ: return strlen(*t_wp) == 0; @@ -309,8 +329,10 @@ (void) t_lex(*++t_wp); op = t_wp_op; - if ((opnd2 = *++t_wp) == (char *) 0) - bb_error_msg_and_die(bb_msg_requires_arg, op->op_text); + if ((opnd2 = *++t_wp) == (char *) 0) { + bb_error_msg(bb_msg_requires_arg, op->op_text); + longjmp(leaving, 2); + } switch (op->op_num) { case STREQ: @@ -459,12 +481,16 @@ r = strtol(s, &p, 10); #endif - if (errno != 0) - bb_error_msg_and_die("%s: out of range", s); + if (errno != 0) { + bb_error_msg("%s: out of range", s); + longjmp(leaving, 2); + } /* p = bb_skip_whitespace(p); avoid const warning */ - if (*(bb_skip_whitespace(p))) - bb_error_msg_and_die("%s: bad number", s); + if (*(bb_skip_whitespace(p))) { + bb_error_msg("%s: bad number", s); + longjmp(leaving, 2); + } return r; } -- Natanael Copa -------------- next part -------------- A non-text attachment was scrubbed... Name: bb-ash-test-brackets.patch Type: text/x-patch Size: 28122 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20060608/85f4dc84/bb-ash-test-brackets-0001.bin From rob at landley.net Wed Jun 7 17:59:08 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 8 05:15:58 2006 Subject: [PATCH] LDFLAGS configuration In-Reply-To: <200606071700.20892.vapier@gentoo.org> References: <7f45d9390606031127mc9fef6dn99f5fe7d446b82b3@mail.gmail.com> <200606071542.58437.rob@landley.net> <200606071700.20892.vapier@gentoo.org> Message-ID: <200606072059.09199.rob@landley.net> On Wednesday 07 June 2006 5:00 pm, Mike Frysinger wrote: > > It has to do with the fact that the slowdown I'm seeing is due to > > explicit > > > > Sorry, thought it was obvious. > > except this little rant has nothing to do with the patch at hand > considering the default build speed would be completely unchanged This patch was proposed in expectation of adding yet more flags. I really don't care whether or not you agree with me on this one: I don't like it. > Shaun's patch adds user-specified flags which default to nothing ... and if > the user throws something in, the make system wouldnt be checking them, > simply assuming the user didnt screw anything up As I mentioned in an email to Shaun, entangling the configure for the build environment specification with the feature list for busybox is something I've thought about undoing already. For example, the Linux kernel uses CROSS_COMPILE and CFLAGS supplied from the command line (either as environment variables or make arguments). Why is that a bad model? > -mike Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 17:52:19 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 8 05:16:04 2006 Subject: ctype.h stuff, saves ~2kB [was: Re: [PATCH] ed stuff #1] In-Reply-To: <20060607204614.GQ8161@aon.at> References: <20060601193942.GC15547@aon.at> <200606061726.56580.rob@landley.net> <20060607204614.GQ8161@aon.at> Message-ID: <200606072052.20782.rob@landley.net> On Wednesday 07 June 2006 4:46 pm, Bernhard Fischer wrote: > >However, keep in mind this might only be a win on glibc, but not on > > uClibc. > > Yes. Apparently uClibc has less bloated implementations of these. > It's trivial to use the non-bloated for the uclibc case and "ours" for > glibc. I really don't want to go down that road. If we try to de-bloat glibc, we'll eventually wind up rewriting the whole thing. They did it, it's called uClibc. We should only put in a standard library replacement if we can beat uClibc. Anybody choosing glibc over uClibc has already said "we know we could be smaller, and we choose not to be". > >What environments have you _tested_ this in? Building stuff into BusyBox > >that's _only_ a size win against glibc ranks up there with optimizing the > >idle loop in terms of pointless activities... > > Hehe > It's purely a size tweak in case the libc under us has bloated versions > of these, which glibc for whatever reasons seems to have. That's because glibc has bloated versions of everything. Working around _that_ is not our problem. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 17:53:10 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 8 05:16:08 2006 Subject: svn 15195 In-Reply-To: <200606071657.48166.vapier@gentoo.org> References: <200605311714.57260.rob@landley.net> <200606071554.32174.rob@landley.net> <200606071657.48166.vapier@gentoo.org> Message-ID: <200606072053.10984.rob@landley.net> On Wednesday 07 June 2006 4:57 pm, Mike Frysinger wrote: > On Wednesday 07 June 2006 15:54, Rob Landley wrote: > > On Wednesday 07 June 2006 10:17 am, Mike Frysinger wrote: > > > On Wednesday 31 May 2006 17:14, Rob Landley wrote: > > > > Finally getting around to reviewing this: > > > > > > clicky link since rob keeps forgetting :P > > > > No, I just expect people can look it up themselves. > > i'm more likely to just ignore the message if i have to commit such effort > :P -mike Go for it. Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 18:01:49 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 8 05:16:10 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <200606071727.57251.vapier@gentoo.org> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606071617.09519.rob@landley.net> <200606071727.57251.vapier@gentoo.org> Message-ID: <200606072101.50020.rob@landley.net> On Wednesday 07 June 2006 5:27 pm, Mike Frysinger wrote: > On Wednesday 07 June 2006 16:17, Rob Landley wrote: > > On Wednesday 07 June 2006 2:43 am, Tito wrote: > > > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > > > > > > Hi, > > > some comments about the devfsd patch: > > > > I just marked devfsd as deprecated. It's not going away in 1.2.x, and > > probably not in 1.3.x, but I don't plan on it being around forever. > > it cant really be dropped until support for linux-2.4 is dropped altogether Are you saying it's impossible to use a 2.4 kernel without devfs, or are you saying you don't think it's possible for me to remove this from BusyBox if I decide to do so? If you're saying it _shouldn't_ be removed until BusyBox stops supporting 2.4, I'll take that under advisement. > -mike Rob -- Never bet against the cheap plastic solution. From rob at landley.net Wed Jun 7 18:08:47 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 8 05:16:14 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <20060607211242.GG26185@mage.jpl.nasa.gov> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606071631.16726.rob@landley.net> <20060607211242.GG26185@mage.jpl.nasa.gov> Message-ID: <200606072108.47712.rob@landley.net> On Wednesday 07 June 2006 5:12 pm, Erik Hovland wrote: > > It's not Busybox's policy to test if you encountered bad ram during the > > course of operation. Will the user not otherwise notice this failure if > > the console doesn't unlock? What exactly are they supposed to do about > > it if it happens? Is it at all likely to happen in the regular course of > > operations? (What would cause this to happen? The ioctl returns an > > error primarily because the console might not have been locked in the > > first place, not because the kernel can't be trusted to do its job > > reliably...) > > > > Could ignoring this error conceivably be any worse than reporting it? > > It's not like the program is going to DO anything about it, the error > > message is just the program is sticking its tongue out at the user. > > > > There are lots of errors we don't test for because we ignoring it is no > > worse than reporting it. If we can't do anything useful about it and > > it's not going to eat your data, is it worth the bytes being pedantic > > over a "this should never happen"? > > This is just the sort of discussion that I was hoping to have by > throwing these patches out there. In my day job we find that being > pedantic is always the right choice. We want to know that things are > going bad as soon as possible. Busybox is on a budget. We squeeze the most functionality we can out of each byte that we can. Functionality that doesn't pull its weight is forced to walk the plank. (Our build environment can afford sharks with lasers, but the resulting binary is lean and mean, sometimes skeletal. Don't ask me about cursed gold coins it stole from Johnny Depp.) Now I could see some kind of CONFIG_PEDANTIC that optionally checks for certain errors. Possibly the easy way to do that is to have libbb.h #define some kind of maybe_error("blah") that either becomes bb_error_sg() or an empty macro. (And a maybe_error_and_die() that either becomes bb_error_msg_and_die() or just exit().) That might be worthwhile. Dunno... Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jun 8 05:22:10 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 8 05:22:15 2006 Subject: [patch] various bugs and strncpy abuse followup In-Reply-To: <20060607213105.GT8161@aon.at> References: <20060606223458.GB16710@mage.jpl.nasa.gov> <200606071727.57251.vapier@gentoo.org> <20060607213105.GT8161@aon.at> Message-ID: <200606080822.11324.rob@landley.net> On Wednesday 07 June 2006 5:31 pm, Bernhard Fischer wrote: > On Wed, Jun 07, 2006 at 05:27:56PM -0400, Mike Frysinger wrote: > >On Wednesday 07 June 2006 16:17, Rob Landley wrote: > >> On Wednesday 07 June 2006 2:43 am, Tito wrote: > >> > On Wednesday 7 June 2006 00:34, Erik Hovland wrote: > >> > > >> > Hi, > >> > some comments about the devfsd patch: > >> > >> I just marked devfsd as deprecated. It's not going away in 1.2.x, and > >> probably not in 1.3.x, but I don't plan on it being around forever. > > > >it cant really be dropped until support for linux-2.4 is dropped > > altogether > > Which will not be soon. > > Along the same lines, why don't we have a CONFIG_OBSOLETE so applets > that are scheduled to be obsoleted in the next years can depend on that? I'm not against CONFIG_OBSOLETE (although I don't really see the point in it either unless it makes it easier to search for deprecated stuff. But some kind of hint _when_ would be good. For devfs stuff I'm thinking somewhere between 18 and 24 months from now. > The NITPICK stuff really serves no purpose while we could use OBSOLETE > right now. > Just a thought.. NITPICK and OBSOLETE serve very different purposes. The point of NITPICK is clutter: things we have sane defaults for and that you only really want to see if you're micro-managing your configuration, but which most people (especially new users) won't be interested in. Also, I'd like to consolidate the long option removal somehow. And the 64 bit support for things like SUM. I'd like one big switch for these. (I can see a bunch of per-applet switches too, guarded by CONFIG_NITPICK. But individually enabling 64 bit support is like individually enabling long file support, which we don't currently do...) Rob -- Never bet against the cheap plastic solution. From rob at landley.net Thu Jun 8 05:33:07 2006 From: rob at landley.net (Rob Landley) Date: Thu Jun 8 05:33:14 2006 Subject: making "test" an ash built-in In-Reply-To: <28967.1149714261@brightstareng.com> References: <28967.1149714261@brightstareng.com> Message-ID: <200606080833.07705.rob@landley.net> On Wednesday 07 June 2006 5:04 pm, Paul Fox wrote: > the total size hit is around 300 bytes (on x86). > > any objections if i commit this? No objections. I plan to obsolete the current ash code as soon as I can f