From dzo at simtreas.ru Thu Dec 1 00:06:26 2005 From: dzo at simtreas.ru (Vladimir N. Oleynik) Date: Thu Dec 1 00:05:43 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <20051130200834.BAB09353B0C@atlas.denx.de> References: <20051130200834.BAB09353B0C@atlas.denx.de> Message-ID: <438EAF02.4070205@simtreas.ru> Wolfgang, > In message you wrote: > >>Exactly. It sounds like a good approach might be eliminating the >>warnings when the chars are being used as string or character data, > > > char c; > > if (c > ' ') ... > > Does this count as "used as character data"? > > Cases like this will fail when the 8th bit is set... Unless our busybox project contains such code? Show where, it will be immediately corrected. --w vodz From rob at landley.net Thu Dec 1 07:24:22 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 1 07:25:17 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: References: Message-ID: <200512010924.22617.rob@landley.net> On Wednesday 30 November 2005 17:41, Chuck Meade wrote: > Yeah that one can't be warned against by the compiler. It is just an > error -- assuming the user wasn't purposely aiming for this behavior. > > In other words, if they wrote the above code using a signed char, > and did not handle (or prevent) the case where the MSB would get set, > and they are surprised when the comparison gives unexpected results, > then the error is on their part. Ok, so some of the most common _real_ errors aren't caught by this stupid warning (and can't be), so even herculean efforts to clean up the noise wouldn't actually be _useful_. But what _might_ be useful is -funsigned-char added to our makefile. (The argument about this producing more or less efficient code still sounds like handwaving at this point. I'm more concerned about whether or not our code is _right_. We declare unsigned char in a lot of places already, if that affected the binary size I think we would have noticed by now. As for efficiency, either the library has assembly optimized versions of strcmp() and friends, or it doesn't.) *rummage* *rummage*... I just set EXTRA_CFLAGS_OPTIONS to -funsigned-char and did a "make clean && make" and it seems to have built (on ubuntu with gcc 3.3) just fine. I'll try it on gcc 4.0 in a bit and see if it makes a difference to the darn warnings, and if so I'll patch Rules.mak and check it in to see what breaks for other people. I'm going to try to put together a -pre2 for release wednesday the 7th. It probably won't have all the bugs from the list fixed, but I hope to at least have 'em triaged into "must fix for 1.1", "would be nice", and "not a 1.1 issue." > Chuck Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Thu Dec 1 07:28:19 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 1 07:29:30 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <438EAF02.4070205@simtreas.ru> References: <20051130200834.BAB09353B0C@atlas.denx.de> <438EAF02.4070205@simtreas.ru> Message-ID: <200512010928.19380.rob@landley.net> On Thursday 01 December 2005 02:06, Vladimir N. Oleynik wrote: > Wolfgang, > > > In message you wrote: > >>Exactly. It sounds like a good approach might be eliminating the > >>warnings when the chars are being used as string or character data, > > > > char c; > > > > if (c > ' ') ... > > > > Does this count as "used as character data"? > > > > Cases like this will fail when the 8th bit is set... > > Unless our busybox project contains such code? > Show where, it will be immediately corrected. I don't think busybox contains such code. The argument is over the usefulness of the new "unsigned char" warning in gcc 4.0, which is producing a lot of noise. (We had almost eliminated all warnings under gcc 3.3.) The underlying problem is that the signedness of char varying from platform to platform can introduce bugs. Wolfgang gave an example of one such potential bug that the new warning can't catch anyway. I would like to force the signedness one way or the other by adding -funsigned-char to our flags. (Then if people need a signed char somewhere, they can explicitly specify it in the declaration.) That way, we at least have consistent behavior. I'll be testing it (on x86 at least) later this morning... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From piuslor at gmx.ch Thu Dec 1 07:53:19 2005 From: piuslor at gmx.ch (Pius) Date: Thu Dec 1 07:53:50 2005 Subject: Need help in compiling on cygwin References: Message-ID: <001001c5f68f$5def7ea0$b6063810@emea.hpqcorp.net> hello, I try to compile busybox 1.01 on a out-of-the-box cygwin installation. but I am not successful. some errors are here... http://rafb.net/paste/results/ddNEL610.html http://rafb.net/paste/results/gKpMWM43.html I would appreciate tips and hints to get it compiled. I tried with make allyesconfig; make dep; make up to make menuconfig; make dep; make (with selecting only ls(1) as only tool) and anything in between... perhaps I miss a trick, but i could not find anything in the documentation nor on the web or mailing list. (not quite true.. I have changed the user $HOME to a shorter path in /etc/passwd, as there was a discussion about too long path somewhere on the web) thanks dan From floydpink at gmail.com Thu Dec 1 08:14:33 2005 From: floydpink at gmail.com (Jason Schoon) Date: Thu Dec 1 08:22:47 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512010924.22617.rob@landley.net> References: <200512010924.22617.rob@landley.net> Message-ID: <78a54e1b0512010814u6f2ca829x8734d8e30306a7f2@mail.gmail.com> This is the best solution I have heard thus far. This is the path we have always taken on our embedded platforms as well. On 12/1/05, Rob Landley wrote: > > On Wednesday 30 November 2005 17:41, Chuck Meade wrote: > > Yeah that one can't be warned against by the compiler. It is just an > > error -- assuming the user wasn't purposely aiming for this behavior. > > > > In other words, if they wrote the above code using a signed char, > > and did not handle (or prevent) the case where the MSB would get set, > > and they are surprised when the comparison gives unexpected results, > > then the error is on their part. > > Ok, so some of the most common _real_ errors aren't caught by this stupid > warning (and can't be), so even herculean efforts to clean up the noise > wouldn't actually be _useful_. > > But what _might_ be useful is -funsigned-char added to our makefile. (The > argument about this producing more or less efficient code still sounds > like > handwaving at this point. I'm more concerned about whether or not our > code > is _right_. We declare unsigned char in a lot of places already, if that > affected the binary size I think we would have noticed by now. As for > efficiency, either the library has assembly optimized versions of strcmp() > and friends, or it doesn't.) > > *rummage* *rummage*... > > I just set EXTRA_CFLAGS_OPTIONS to -funsigned-char and did a "make clean > && > make" and it seems to have built (on ubuntu with gcc 3.3) just fine. I'll > try it on gcc 4.0 in a bit and see if it makes a difference to the darn > warnings, and if so I'll patch Rules.mak and check it in to see what > breaks > for other people. > > I'm going to try to put together a -pre2 for release wednesday the > 7th. It > probably won't have all the bugs from the list fixed, but I hope to at > least > have 'em triaged into "must fix for 1.1", "would be nice", and "not a 1.1 > issue." > > > Chuck > > Rob > -- > Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. > I do not think it means what you think it means. > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20051201/38369f5c/attachment-0001.html From rob at landley.net Thu Dec 1 09:02:31 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 1 09:03:21 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <78a54e1b0512010814u6f2ca829x8734d8e30306a7f2@mail.gmail.com> References: <200512010924.22617.rob@landley.net> <78a54e1b0512010814u6f2ca829x8734d8e30306a7f2@mail.gmail.com> Message-ID: <200512011102.31369.rob@landley.net> On Thursday 01 December 2005 10:14, Jason Schoon wrote: > > But what _might_ be useful is -funsigned-char added to our makefile. ... > This is the best solution I have heard thus far. This is the path we have > always taken on our embedded platforms as well. Well, I just built it under 4.0.2 and it did at least keep the warnings down to a dull roar. Still rather a lot of them. (Attached.) But nothing broke, so I'm checking it in. (svn 12615) By the way, built with gcc 4.0.2, linked against uClibc (but not statically linked), an "allyesconfig" busybox (with mount NFS support and inetd RPC support disabled because my uClibc doesn't have that enabled) is 926632 bytes. For comparison, the exact same .config, built with gcc 3.3.5 and linked against glibc (but not static) is 963948 bytes. (And yes, that's with the two things that need RPC support switched off). So gcc 4.0 may have some downsides, but it has some upsides too... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. -------------- next part -------------- /busybox/archival/tar.c: In function 'writeTarFile': /busybox/archival/tar.c:466: warning: missing sentinel in function call /busybox/archival/libunarchive/decompress_unzip.c: In function 'inflate_stored': /busybox/archival/libunarchive/decompress_unzip.c:553: warning: pointer targets in passing argument 2 of 'fill_bitbuffer' differ in signedness /busybox/archival/libunarchive/decompress_unzip.c: In function 'inflate_block': /busybox/archival/libunarchive/decompress_unzip.c:668: warning: pointer targets in passing argument 7 of 'huft_build' differ in signedness /busybox/archival/libunarchive/decompress_unzip.c:677: warning: pointer targets in passing argument 7 of 'huft_build' differ in signedness /busybox/archival/libunarchive/decompress_unzip.c:748: warning: pointer targets in passing argument 7 of 'huft_build' differ in signedness /busybox/archival/libunarchive/decompress_unzip.c:816: warning: pointer targets in passing argument 7 of 'huft_build' differ in signedness /busybox/archival/libunarchive/decompress_unzip.c:825: warning: pointer targets in passing argument 7 of 'huft_build' differ in signedness /busybox/archival/libunarchive/get_header_cpio.c: In function 'get_header_cpio': /busybox/archival/libunarchive/get_header_cpio.c:69: warning: pointer targets in passing argument 2 of 'archive_xread_all_eof' differ in signedness /busybox/coreutils/install.c: In function 'install_main': /busybox/coreutils/install.c:120: warning: pointer targets in assignment differ in signedness /busybox/coreutils/install.c:121: warning: pointer targets in assignment differ in signedness /busybox/coreutils/install.c:122: warning: pointer targets in passing argument 2 of 'copy_file' differ in signedness /busybox/coreutils/install.c:125: warning: pointer targets in passing argument 1 of 'chmod' differ in signedness /busybox/coreutils/install.c:131: warning: pointer targets in passing argument 1 of 'lchown' differ in signedness /busybox/coreutils/od.c: In function 'od_main': /busybox/coreutils/od.c:175: warning: pointer targets in passing argument 3 of 'getopt' differ in signedness /busybox/coreutils/od.c:178: warning: pointer targets in passing argument 1 of 'strchr' differ in signedness /busybox/coreutils/od.c:178: warning: pointer targets in assignment differ in signedness /busybox/coreutils/tr.c: In function 'expand': /busybox/coreutils/tr.c:144: warning: pointer targets in passing argument 1 of 'strcat' differ in signedness /busybox/coreutils/tr.c:146: warning: pointer targets in passing argument 1 of 'strcat' differ in signedness /busybox/coreutils/tr.c:159: warning: pointer targets in passing argument 1 of 'strcat' differ in signedness /busybox/coreutils/tr.c: In function 'tr_main': /busybox/coreutils/tr.c:217: warning: pointer targets in assignment differ in signedness /busybox/coreutils/tr.c:246: warning: pointer targets in passing argument 2 of 'expand' differ in signedness /busybox/coreutils/tr.c:248: warning: pointer targets in passing argument 1 of 'complement' differ in signedness /busybox/coreutils/tr.c:252: warning: pointer targets in passing argument 2 of 'expand' differ in signedness /busybox/coreutils/tr.c:253: warning: pointer targets in passing argument 1 of 'map' differ in signedness /busybox/coreutils/tr.c:253: warning: pointer targets in passing argument 3 of 'map' differ in signedness /busybox/coreutils/uudecode.c: In function 'read_base64': /busybox/coreutils/uudecode.c:101: warning: comparison is always false due to limited range of data type /busybox/coreutils/uuencode.c: In function 'uuencode_main': /busybox/coreutils/uuencode.c:133: warning: pointer targets in passing argument 1 of 'uuencode' differ in signedness /busybox/console-tools/loadfont.c: In function 'loadnewfont': /busybox/console-tools/loadfont.c:190: warning: pointer targets in passing argument 2 of 'do_loadtable' differ in signedness /busybox/editors/patch.c: In function 'extract_filename': /busybox/editors/patch.c:82: warning: pointer targets in return differ in signedness /busybox/editors/patch.c: In function 'patch_main': /busybox/editors/patch.c:134: warning: pointer targets in assignment differ in signedness /busybox/editors/patch.c:143: warning: pointer targets in assignment differ in signedness /busybox/editors/vi.c: In function 'vi_main': /busybox/editors/vi.c:350: warning: pointer targets in assignment differ in signedness /busybox/editors/vi.c: In function 'colon': /busybox/editors/vi.c:732: warning: pointer targets in assignment differ in signedness /busybox/editors/vi.c:766: warning: pointer targets in passing argument 1 of 'system' differ in signedness /busybox/editors/vi.c:790: warning: pointer targets in passing argument 1 of 'bb_strlen' differ in signedness /busybox/editors/vi.c:793: warning: pointer targets in passing argument 1 of 'bb_strlen' differ in signedness /busybox/editors/vi.c: In function 'get_input_line': /busybox/editors/vi.c:2401: warning: pointer targets in passing argument 1 of 'write1' differ in signedness /busybox/editors/vi.c: In function 'file_size': /busybox/editors/vi.c:2434: warning: pointer targets in passing argument 1 of 'bb_strlen' differ in signedness /busybox/editors/vi.c: In function 'place_cursor': /busybox/editors/vi.c:2590: warning: pointer targets in passing argument 2 of 'strncat' differ in signedness /busybox/editors/vi.c: In function 'show_status_line': /busybox/editors/vi.c:2679: warning: pointer targets in passing argument 1 of 'bufsum' differ in signedness /busybox/editors/vi.c:2684: warning: pointer targets in passing argument 1 of 'write1' differ in signedness /busybox/editors/vi.c:2687: warning: pointer targets in passing argument 1 of 'bb_strlen' differ in signedness /busybox/editors/vi.c: In function 'refresh': /busybox/editors/vi.c:2941: warning: pointer targets in initialization differ in signedness /busybox/networking/arping.c: In function 'arping_main': /busybox/networking/arping.c:421: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness /busybox/networking/arping.c:442: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness /busybox/networking/arping.c:488: warning: pointer targets in passing argument 6 of 'recvfrom' differ in signedness /busybox/networking/arping.c:496: warning: pointer targets in passing argument 1 of 'recv_pack' differ in signedness /busybox/networking/ether-wake.c:247:3: warning: #warning Need to implement ether_hostton() for uClibc /busybox/networking/httpd.c: In function 'decodeBase64': /busybox/networking/httpd.c:855: warning: pointer targets in initialization differ in signedness /busybox/networking/interface.c: In function 'UNSPEC_sprint': /busybox/networking/interface.c:504: warning: pointer targets in passing argument 1 of 'UNSPEC_print' differ in signedness /busybox/networking/interface.c: In function 'ife_print': /busybox/networking/interface.c:1836: warning: pointer targets in passing argument 1 of 'hw->print' differ in signedness /busybox/networking/ping.c: In function 'sendping': /busybox/networking/ping.c:229: warning: operation on 'ntransmitted' may be undefined /busybox/networking/telnet.c: In function 'handlenetoutput': /busybox/networking/telnet.c:207: warning: pointer targets in initialization differ in signedness /busybox/networking/telnetd.c: In function 'remove_iacs': /busybox/networking/telnetd.c:134: warning: pointer targets in initialization differ in signedness /busybox/networking/traceroute.c:296: warning: 'align' attribute directive ignored /busybox/networking/wget.c: In function 'wget_main': /busybox/networking/wget.c:338: warning: pointer targets in passing argument 1 of 'base64enc' differ in signedness /busybox/networking/wget.c:342: warning: pointer targets in passing argument 1 of 'base64enc' differ in signedness /busybox/networking/zcip.c: In function 'zcip_main': /busybox/networking/zcip.c:346: warning: pointer targets in passing argument 1 of 'seed48' differ in signedness /busybox/networking/libiproute/ipaddress.c: In function 'ipaddr_list_or_flush': /busybox/networking/libiproute/ipaddress.c:460: warning: pointer targets in passing argument 1 of 'rtnl_rtscope_a2n' differ in signedness /busybox/networking/libiproute/ipaddress.c: In function 'ipaddr_modify': /busybox/networking/libiproute/ipaddress.c:719: warning: pointer targets in passing argument 1 of 'rtnl_rtscope_a2n' differ in signedness /busybox/networking/libiproute/iplink.c: In function 'get_address': /busybox/networking/libiproute/iplink.c:197: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness /busybox/networking/libiproute/iplink.c: In function 'parse_address': /busybox/networking/libiproute/iplink.c:214: warning: pointer targets in passing argument 1 of 'll_addr_a2n' differ in signedness /busybox/networking/libiproute/iproute.c: In function 'iproute_modify': /busybox/networking/libiproute/iproute.c:350: warning: pointer targets in passing argument 1 of 'rtnl_rtprot_a2n' differ in signedness /busybox/networking/libiproute/iproute.c: In function 'iproute_list_or_flush': /busybox/networking/libiproute/iproute.c:497: warning: pointer targets in passing argument 1 of 'rtnl_rtprot_a2n' differ in signedness /busybox/networking/libiproute/libnetlink.c: In function 'rtnl_open': /busybox/networking/libiproute/libnetlink.c:52: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness /busybox/networking/libiproute/utils.c: In function 'get_prefix_1': /busybox/networking/libiproute/utils.c:197: warning: pointer targets in passing argument 1 of 'get_integer' differ in signedness /busybox/networking/udhcp/packet.c: In function 'udhcp_get_packet': /busybox/networking/udhcp/packet.c:73: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness /busybox/networking/udhcp/dhcpc.c: In function 'udhcpc_main': /busybox/networking/udhcp/dhcpc.c:235: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /busybox/networking/udhcp/dhcpc.c:247: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /busybox/networking/udhcp/dhcpc.c:262: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /busybox/networking/udhcp/dhcpc.c:279: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /busybox/networking/udhcp/serverpacket.c: In function 'add_bootp_options': /busybox/networking/udhcp/serverpacket.c:101: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /busybox/networking/udhcp/serverpacket.c:103: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /busybox/shell/ash.c: In function 'readtoken1': /busybox/shell/ash.c:10618: warning: 'saveprompt' may be used uninitialized in this function /busybox/shell/ash.c:10193: warning: 'prevsyntax' may be used uninitialized in this function /busybox/shell/hush.c: In function 'update_ifs_map': /busybox/shell/hush.c:2646: warning: pointer targets in passing argument 1 of 'mapset' differ in signedness /busybox/shell/hush.c:2647: warning: pointer targets in passing argument 1 of 'mapset' differ in signedness /busybox/shell/hush.c:2648: warning: pointer targets in passing argument 1 of 'mapset' differ in signedness /busybox/shell/hush.c: In function 'parse_stream_outer': /busybox/shell/hush.c:2663: warning: pointer targets in passing argument 1 of 'mapset' differ in signedness /busybox/shell/lash.c: In function 'busy_loop': /busybox/shell/lash.c:1456: warning: 'inbg' may be used uninitialized in this function /busybox/util-linux/fdisk.c:667: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:668: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:669: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:670: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:671: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:672: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:673: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:674: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:678: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:680: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:681: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:682: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:683: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:684: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:685: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:686: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:687: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1745: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1746: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1747: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1748: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1749: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1750: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1751: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1752: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1753: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1754: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1755: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1756: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1757: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1758: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1759: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1760: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1761: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:1762: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c: In function 'sgi_list_table': /busybox/util-linux/fdisk.c:1913: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c: In function 'sgi_check_bootfile': /busybox/util-linux/fdisk.c:1958: warning: pointer targets in passing argument 2 of 'strncmp' differ in signedness /busybox/util-linux/fdisk.c: In function 'sgi_get_bootfile': /busybox/util-linux/fdisk.c:1969: warning: pointer targets in return differ in signedness /busybox/util-linux/fdisk.c: In function 'create_sgiinfo': /busybox/util-linux/fdisk.c:1995: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /busybox/util-linux/fdisk.c: In function 'sgi_write_table': /busybox/util-linux/fdisk.c:2012: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness /busybox/util-linux/fdisk.c: In function 'create_sgilabel': /busybox/util-linux/fdisk.c:2374: warning: pointer targets in passing argument 1 of 'valid_part_table_flag' differ in signedness /busybox/util-linux/fdisk.c:2394: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness /busybox/util-linux/fdisk.c: In function 'fill_sgiinfo': /busybox/util-linux/fdisk.c:2456: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness /busybox/util-linux/fdisk.c:2457: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness /busybox/util-linux/fdisk.c:2459: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness /busybox/util-linux/fdisk.c: At top level: /busybox/util-linux/fdisk.c:2512: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2513: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2514: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2515: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2516: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2517: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2518: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2519: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2520: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2521: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2522: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2523: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:2525: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c: In function 'create_sunlabel': /busybox/util-linux/fdisk.c:2785: warning: pointer targets in passing argument 1 of 'snprintf' differ in signedness /busybox/util-linux/fdisk.c: At top level: /busybox/util-linux/fdisk.c:3182: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3183: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3184: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3185: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3186: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3187: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3188: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3189: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3190: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3191: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3192: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3193: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3194: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3195: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3196: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3197: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3198: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3199: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3200: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3201: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3202: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3203: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3204: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3205: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3206: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3207: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3208: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3209: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3210: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3211: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3212: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3213: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3214: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3215: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3216: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3217: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3218: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3219: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3220: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3221: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3222: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3223: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3224: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3225: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3226: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3227: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3228: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c:3229: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c: In function 'partition_type': /busybox/util-linux/fdisk.c:3634: warning: pointer targets in return differ in signedness /busybox/util-linux/fdisk.c: In function 'get_partition_table_geometry': /busybox/util-linux/fdisk.c:3935: warning: pointer targets in initialization differ in signedness /busybox/util-linux/fdisk.c: In function 'get_boot': /busybox/util-linux/fdisk.c:4088: warning: pointer targets in passing argument 1 of 'valid_part_table_flag' differ in signedness /busybox/util-linux/fdisk.c:4101: warning: pointer targets in passing argument 1 of 'valid_part_table_flag' differ in signedness /busybox/util-linux/fdisk.c:4153: warning: pointer targets in passing argument 1 of 'valid_part_table_flag' differ in signedness /busybox/util-linux/mkswap.c: In function 'page_ok': /busybox/util-linux/mkswap.c:179: warning: pointer targets in passing argument 1 of 'bit_set' differ in signedness /busybox/util-linux/mkswap.c: In function 'page_bad': /busybox/util-linux/mkswap.c:185: warning: pointer targets in passing argument 1 of 'bit_test_and_clear' differ in signedness /busybox/util-linux/mkswap.c: In function 'mkswap_main': /busybox/util-linux/mkswap.c:389: warning: pointer targets in passing argument 1 of 'bit_test_and_clear' differ in signedness /busybox/e2fsprogs/blkid/probe.c: In function 'probe_swap1': /busybox/e2fsprogs/blkid/probe.c:344: warning: pointer targets in passing argument 3 of 'blkid_set_tag' differ in signedness /busybox/e2fsprogs/blkid/probe.c: In function 'probe_ocfs': /busybox/e2fsprogs/blkid/probe.c:418: warning: pointer targets in passing argument 3 of 'blkid_set_tag' differ in signedness /busybox/e2fsprogs/blkid/probe.c:419: warning: pointer targets in passing argument 3 of 'blkid_set_tag' differ in signedness /busybox/e2fsprogs/blkid/probe.c: In function 'probe_ocfs2': /busybox/e2fsprogs/blkid/probe.c:434: warning: pointer targets in passing argument 3 of 'blkid_set_tag' differ in signedness /busybox/e2fsprogs/ext2fs/ext2fs_inline.c: In function 'ext2fs_find_first_bit_set': /busybox/e2fsprogs/ext2fs/ext2fs_inline.c:181: warning: pointer targets in initialization differ in signedness /busybox/e2fsprogs/mke2fs.c: In function 'PRS': /busybox/e2fsprogs/mke2fs.c:881: warning: pointer targets in passing argument 2 of 'safe_strtoi' differ in signedness /busybox/libbb/loop.c: In function 'set_loop': /busybox/libbb/loop.c:117: warning: pointer targets in passing argument 1 of 'safe_strncpy' differ in signedness /busybox/libbb/loop.c:128: warning: pointer targets in passing argument 2 of 'strcmp' differ in signedness /busybox/libbb/getopt_ulflags.c: In function 'bb_getopt_ulflags': /busybox/libbb/getopt_ulflags.c:314: warning: pointer targets in assignment differ in signedness /busybox/libbb/getopt_ulflags.c:348: warning: pointer targets in assignment differ in signedness /busybox/coreutils/coreutils.a(nohup.o): In function `close_stdout': nohup.c:(.text+0x6a): warning: /bin/sh: /busybox/docs/autodocifier.pl: /usr/bin/perl: bad interpreter: No such file or directory /bin/sh: line 1: pod2text: command not found make[1]: [docs/BusyBox.txt] Error 127 (ignored) /bin/sh: line 1: pod2man: command not found make[1]: [docs/BusyBox.1] Error 127 (ignored) /bin/sh: line 1: pod2html: command not found make[1]: [docs/busybox.net/BusyBox.html] Error 127 (ignored) From jzb at aexorsyst.com Thu Dec 1 12:38:20 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Thu Dec 1 12:41:34 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512011102.31369.rob@landley.net> References: <78a54e1b0512010814u6f2ca829x8734d8e30306a7f2@mail.gmail.com> <200512011102.31369.rob@landley.net> Message-ID: <200512011238.20214.jzb@aexorsyst.com> On Thursday 01 December 2005 09:02, Rob Landley wrote: > On Thursday 01 December 2005 10:14, Jason Schoon wrote: > > > But what _might_ be useful is -funsigned-char added to our makefile. > > ... > > > This is the best solution I have heard thus far. This is the path we > > have always taken on our embedded platforms as well. > > Well, I just built it under 4.0.2 and it did at least keep the warnings > down to a dull roar. Still rather a lot of them. (Attached.) But nothing > broke, so I'm checking it in. (svn 12615) > > By the way, built with gcc 4.0.2, linked against uClibc (but not statically > linked), an "allyesconfig" busybox (with mount NFS support and inetd RPC > support disabled because my uClibc doesn't have that enabled) is 926632 > bytes. For comparison, the exact same .config, built with gcc 3.3.5 and > linked against glibc (but not static) is 963948 bytes. (And yes, that's > with the two things that need RPC support switched off). So gcc 4.0 may > have some downsides, but it has some upsides too... > > Rob So I finally broke down and actually looked at the code...and yes, these are legitimate warnings. When a function is prototyped as int foo(unsigned int x); and it is used as ... int y,z; y = foo(z); ... then z and unsigned int x do in fact differ in signedness. I thought your warnings were limited solely to char vs. unsigned char, but it seems to affect all... I guess you all already knew this, but I'm surprised by the desire to sweep these warnings under the rug. If you simply want to temporarily ignore these warnings so that more potentially serious warnings don't slip by, then I'm all for it, but if you want a long term solution, the code will have to be fixed, because signed != unsigned in a general sense. To permanently hide these warnings is a bad idea. IMHO. I guess I don't believe that these warnings are useless, but it is likely that in this particular code base (busybox), it doesn't matter (currently). However, future code may be affected by this, so I'd vote against it. It might even be better to write a perl or gawk script to replaced the unsigned with signed in the cases where warnings are generated, and retest the code, since the signed is more restrictive...just an idea. -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From rob at landley.net Thu Dec 1 13:32:13 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 1 14:45:00 2005 Subject: Makefile tweak for -lm? Message-ID: <200512011532.14120.rob@landley.net> CONFIG_FEATURE_SORT_BIG needs libm, and right now it's not always automatically including it. (I managed to get a build break from this.) I came up with the following makefile patch via cut and paste. Would someone who knows makefiles tell me what I _should_ have done? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. -------------- next part -------------- A non-text attachment was scrubbed... Name: blah.patch Type: text/x-diff Size: 519 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051201/97a85163/blah.bin From rob at landley.net Thu Dec 1 15:13:59 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 1 15:14:29 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512011238.20214.jzb@aexorsyst.com> References: <200512011102.31369.rob@landley.net> <200512011238.20214.jzb@aexorsyst.com> Message-ID: <200512011713.59792.rob@landley.net> On Thursday 01 December 2005 14:38, John Z. Bohach wrote: > then z and unsigned int x do in fact differ in signedness. I thought your > warnings were limited solely to char vs. unsigned char, but it seems to > affect all... My complaint was that any legitimate warnings were getting buried in the noise of all the char * warnings. The "signedness of int" warnings are a lot more legitimate, because that's a signedness that was always well defined. > I guess you all already knew this, but I'm surprised by the desire to sweep > these warnings under the rug. If you simply want to temporarily ignore > these warnings so that more potentially serious warnings don't slip by, Looking at several of the "signedness of char" warnings, the obvious solution was typecasts to shut the compiler up, which just pollutes the source. > then I'm all for it, but if you want a long term solution, the code will > have to be fixed, because signed != unsigned in a general sense. To > permanently hide these warnings is a bad idea. The compiler never previously generated these warnings and I've yet to see an actual bug uncovered by this, but it was only the char ones I was railing against as actively stupid. Not the short, int, or long ones. > IMHO. I guess I don't > believe that these warnings are useless, but it is likely that in this > particular code base (busybox), it doesn't matter (currently). However, > future code may be affected by this, so I'd vote against it. Vote against what, defining the signedness of char to something consistent? Too late, I checked it in. > It might even > be better to write a perl or gawk script to replaced the unsigned with > signed in the cases where warnings are generated, NO. Automatic changes to shut the compiler up, where a human didn't look at each and every change being made, are not just churn but DANGEROUS churn. I would _protest_ the application of such a patch. > and retest the code, Because obviously none of these are bugs that have shown up in testing so far, so fresh testing will obviously be equally effective in giving us a false sense of security. Something _useful_ to do would be to fill out the test suite so we have serious coverage. (Not necessarily fun, but I take a whack at it every couple of weeks. Big job, but relatively easy to make progress on. The problem is, I generally find esoteric bugs and wander off on tangents fixing them. :) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Thu Dec 1 15:30:23 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 1 15:30:50 2005 Subject: Need help in compiling on cygwin In-Reply-To: <001001c5f68f$5def7ea0$b6063810@emea.hpqcorp.net> References: <001001c5f68f$5def7ea0$b6063810@emea.hpqcorp.net> Message-ID: <200512011730.23411.rob@landley.net> On Thursday 01 December 2005 09:53, Pius wrote: > hello, > > I try to compile busybox 1.01 on a out-of-the-box cygwin installation. but > I am not successful. I don't have cygwin (I don't do windows) but I'll take a look. > some errors are here... Pasting them into the email would have been easier on us. > http://rafb.net/paste/results/ddNEL610.html It's complaining that sockaddr_in isn't defined. We're getting it from sys/socket.h, but apparently cygwin isn't. Did you try an explicit #include towards the top of libbb.h? > http://rafb.net/paste/results/gKpMWM43.html This one's application specific: vi is unhappy. Let's see... We #include , and that _really_ should define SIGIOT. On Linux it seems to be a synonym for SIGABRT, try substituting that one instead and see if it's happy? > I would appreciate tips and hints to get it compiled. I tried with > make allyesconfig; make dep; make Try "make allnoconfig" and add just what you need. You're likely to have problems on a per-applet basis because none of this stuff has ever been tested in your environment, and windows provides a flaky emulation of unix at best. (I'd be amazed if you can get losetup to work, for example. let alone insmod...) > perhaps I miss a trick, but i could not find anything in the documentation > nor on the web or mailing list. I don't think anyone's ever done this before. :) In theory it should work, we've just never tried it... > (not quite true.. I have changed the user $HOME to a shorter path in > /etc/passwd, as there was a discussion about too long path somewhere on the > web) I'm unaware of this being a problem for us. Might be for cygwin... > thanks > > dan Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From aurel at gnuage.org Thu Dec 1 15:58:21 2005 From: aurel at gnuage.org (Aurelien Jacobs) Date: Thu Dec 1 16:25:27 2005 Subject: Makefile tweak for -lm? In-Reply-To: <200512011532.14120.rob@landley.net> References: <200512011532.14120.rob@landley.net> Message-ID: <20051202005821.22ad87ca.aurel@gnuage.org> On Thu, 1 Dec 2005 15:32:13 -0600 Rob Landley wrote: > CONFIG_FEATURE_SORT_BIG needs libm, and right now it's not always > automatically including it. (I managed to get a build break from this.) > > I came up with the following makefile patch via cut and paste. Would someone > who knows makefiles tell me what I _should_ have done? Maybe this should go into Rules.mak and this should be : +ifeq ($(strip $(CONFIG_FEATURE_SORT_BIG)),y) + LIBRARIES += -lm +endif At least, that's what is used for some other libs. Aurel From jzb at aexorsyst.com Thu Dec 1 21:13:26 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Thu Dec 1 21:14:32 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512011713.59792.rob@landley.net> References: <200512011238.20214.jzb@aexorsyst.com> <200512011713.59792.rob@landley.net> Message-ID: <200512012113.26187.jzb@aexorsyst.com> On Thursday 01 December 2005 15:13, Rob Landley wrote: > My complaint was that any legitimate warnings were getting buried in the > noise of all the char * warnings. > > The "signedness of int" warnings are a lot more legitimate, because that's > a signedness that was always well defined. All such warnings are "legitimate." If a function asks you to pass to it a signed parameter, and you pass it an unsigned one, be warned. If its intential, cast it, so its obvious that the type mismatch is intentional. If its not intentional, fix it to match the prototype. You've taken the position that because nothing is obviously broken by sign-mismatched parameters being passed, its okay to do so. It is not okay, even though most of the time you can get away with it, and most of the time compilers don't warn about it. Now, the current situation is that gcc has reached a level of maturity (or the gcc developers had nothing better to do) that allows it to warn about sign mismatches. I applaude that. Yes, C is a weakly-typed language, else such mismatches would cause compile-time errors and your code wouldn't even compile. I admit to being a purist, but damn it, computing requires, nay, demands, perfection. Yes, back-end testing could catch some errors, but if you write clean code to begin with, you won't need to rely so much on the tests. Your points are very valid, if taken in the context of "do we want to allocate resources to implement the _proper_ fix to the sign warning when nothing seems to be broken anyway." And in that context, I agree with you 100%. Note that _proper_ means to me to use either casts if the mismatch is intentional, or fixed code if the type mismatch is not intentional. I mean, if the prototype says "pass me a signed char" than just humor the man and pass him a signed char, and don't squirm about "well a char's signedness has never really been well-defined..." While you are correct, I'd like to point out to the court that your argument is irrelevant to clean code. If you don't like warnings, write clean code. If your argument is it doesn't matter, then fine, we're with you. But grant me that you wouldn't do sign-mismatched parameters on purpose...(at least not without a cast.) And if its not on purpose, than again, I want the compiler warnings, so I can go back and clean my code, because maybe I did miss something... > > It might even > > be better to write a perl or gawk script to replaced the unsigned with > > signed in the cases where warnings are generated, > > NO. There are lots of such warnings. They all need to be looked at and fixed manually in the end. The destination is the same. There's a top-down approach, of starting with the first and going on and on...and than there's the bottom up approach: replace them all let the test suite sort them out. Depending on the circumstances, one approach may be more appropriate than the other. > > Automatic changes to shut the compiler up, where a human didn't look at > each and every change being made, are not just churn but DANGEROUS churn. > I would _protest_ the application of such a patch. You misunderstand. If there are no errors (you claim there are none) with the sign mismatches, then fixing them to be not mismatched will introduce them? Doesn't follow, unless the code relies on coding errors to come up with the correct results. Possible, but not likely. If this code works with the warnings, surely there can't be too much risk in fixing the warnings correctly, to have not sign mismatched parameters? Can there? Yes, I know your answer, but if it is a risk, then I submit its a greater risk to have the sign mismatches present in the first place. Resources resources... > > > and retest the code, > > Because obviously none of these are bugs that have shown up in testing so > far, so fresh testing will obviously be equally effective in giving us a > false sense of security. Can't blame programmers not honoring the prototype on either the compiler or the test suite. Damn it people, honor thy father, mother, and prototype. > Something _useful_ to do would be to fill out the test suite so we have > serious coverage. (Not necessarily fun, but I take a whack at it every > couple of weeks. Big job, but relatively easy to make progress on. The > problem is, I generally find esoteric bugs and wander off on tangents > fixing them. :) I'm quite swamped with a bunch of projects at the moment, but soon, soon I tell you, I will be able to contribute more than just words...I'm cleaning up buildroot, among other things, to be at least self-hosting, and when that's done, I can write some code for busybox. Keep me in mind, and if there's some coding you want to offload later, I'd be happy to help. And by the way, I NEVER mismatch signs on prototypes, except when hardware bit-mapped structures force me to recast bit-fields, but then I ALWAYS cast them, so I know I did it on purpose. And my bain is the miserable "blah blah breaks strict-aliasing rules..." warning which showed up around the gcc-3.3.4 timeframe. Yes, I could turn it off easily, but I've learned to live with it, even though I am quite a huge fan of the silent build (and I don't mean with the .SILENT target), i.e., no warnings, none, not even a makefile warning about overriding rules, though I really can't do anything about that without modifying the 'make' sources...(which I've considered...). --John -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From rep.nop at aon.at Fri Dec 2 00:19:06 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Fri Dec 2 00:17:53 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051202005821.22ad87ca.aurel@gnuage.org> References: <200512011532.14120.rob@landley.net> <20051202005821.22ad87ca.aurel@gnuage.org> Message-ID: <20051202081906.GA24607@aon.at> On Fri, Dec 02, 2005 at 12:58:21AM +0100, Aurelien Jacobs wrote: >On Thu, 1 Dec 2005 15:32:13 -0600 >Rob Landley wrote: > >> CONFIG_FEATURE_SORT_BIG needs libm, and right now it's not always >> automatically including it. (I managed to get a build break from this.) >> >> I came up with the following makefile patch via cut and paste. Would someone >> who knows makefiles tell me what I _should_ have done? > >Maybe this should go into Rules.mak and this should be : I'd set need-libm=y and look at $(need-libm) in Rules.mak. > >+ifeq ($(strip $(CONFIG_FEATURE_SORT_BIG)),y) >+ LIBRARIES += -lm >+endif This would lead to a fairly big block when it's done for all applets which need e.g. libm. From farmatito at tiscali.it Fri Dec 2 04:58:00 2005 From: farmatito at tiscali.it (Tito) Date: Fri Dec 2 04:59:17 2005 Subject: Need help in compiling on cygwin In-Reply-To: <200512011730.23411.rob@landley.net> References: <001001c5f68f$5def7ea0$b6063810@emea.hpqcorp.net> <200512011730.23411.rob@landley.net> Message-ID: <200512021358.00515.farmatito@tiscali.it> On Friday 02 December 2005 00:30, Rob Landley wrote: > On Thursday 01 December 2005 09:53, Pius wrote: > > hello, > > > > I try to compile busybox 1.01 on a out-of-the-box cygwin installation. but > > I am not successful. > > I don't have cygwin (I don't do windows) but I'll take a look. Snip Hi to all, I'm trying the same, just for fun, but with MSYS and MinGW compiler, but I started by trying to make "make menuconfig" work. So far I managed to fix some issues with sys/utsname.h, pdcurses and installed a bison executable. At the moment I'm stuck with some warnings of undefined regex* symbols in zconf.tag.c (I've downloaded and installed a regex lib version for mingw and have the headers, the dll and the *.a file....). Maybe It would be better to try the make allnoconfig way? If there is some interest I can post the error msg, Ciao, Tito From vapier at gentoo.org Fri Dec 2 05:01:22 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Fri Dec 2 05:02:41 2005 Subject: Makefile tweak for -lm? In-Reply-To: <200512011532.14120.rob@landley.net> References: <200512011532.14120.rob@landley.net> Message-ID: <20051202130122.GC9185@toucan.gentoo.org> On Thu, Dec 01, 2005 at 03:32:13PM -0600, Rob Landley wrote: > I came up with the following makefile patch via cut and paste. Would someone > who knows makefiles tell me what I _should_ have done? this should work: needlibm-y := needlibm-$(CONFIG_FEATURE_SORT_BIG) := -lm LIBRARIES += $(needlibm-y) -mike From ranma at tdiedrich.de Fri Dec 2 05:57:12 2005 From: ranma at tdiedrich.de (Tobias Diedrich) Date: Fri Dec 2 05:57:32 2005 Subject: [PATCH] renaming interfaces with ifconfig In-Reply-To: <20051129172402.GA5951@yamamaya.is-a-geek.org> References: <20051129172402.GA5951@yamamaya.is-a-geek.org> Message-ID: <20051202135712.GA22958@yamamaya.is-a-geek.org> Tobias Diedrich wrote: > while I've seen that busybox at least in SVN supports nameif, the > following (slightly hacky) patch to ifconfig would provide the basic > interface renaming functionality with less code. > Also, AFAICS nameif only works for interfaces with a MAC address, > but in my case I'm more interested in renaming tun-Devices to assign > static names to my OpenVPN tunnels. Has anyone looked at this patch yet? Thanks in advance, -- Tobias PGP: http://9ac7e0bc.uguu.de From rushi.lala at gmail.com Fri Dec 2 06:23:01 2005 From: rushi.lala at gmail.com (Rushi Lala) Date: Fri Dec 2 06:24:00 2005 Subject: Eject command Message-ID: Hi All, Busybox documentation says there is a "eject" command included in busybox http://www.busybox.net/downloads/BusyBox.html But i couldn't find eject command in .config or make menuconfig....... , can any one help me with this ?Is there source for it in 1.01 ? If yes what's the easiest way to include it in my build ? Thanks RedSpeed From rob at landley.net Fri Dec 2 07:47:21 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 07:48:50 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512012113.26187.jzb@aexorsyst.com> References: <200512011713.59792.rob@landley.net> <200512012113.26187.jzb@aexorsyst.com> Message-ID: <200512020947.21819.rob@landley.net> On Thursday 01 December 2005 23:13, John Z. Bohach wrote: > On Thursday 01 December 2005 15:13, Rob Landley wrote: > > My complaint was that any legitimate warnings were getting buried in the > > noise of all the char * warnings. > > > > The "signedness of int" warnings are a lot more legitimate, because > > that's a signedness that was always well defined. > > All such warnings are "legitimate." If a function asks you to pass to it a > signed parameter, and you pass it an unsigned one, be warned. If its > intential, cast it, so its obvious that the type mismatch is intentional. No. Period. > If its not intentional, fix it to match the prototype. It does match the prototype. The prototype is "char". The signedness of that was indeterminate. Now it's specifying -funsigned-char. It is now determinate. > You've taken the position that because nothing is obviously broken by > sign-mismatched parameters being passed, its okay to do so. I take the position that gcc has not warned about this for the past 15 years and it was never previously a problem, and this wouldn't be the first warning GCC introduced that had 10 times as much noise as signal. > It is not > okay, even though most of the time you can get away with it, and most of > the time compilers don't warn about it. You are welcome to think anything you want, and I am welcome to put you in my spam filter as I would anything _else_ that produces 10x as much noise as it does signal. > Now, the current situation is that gcc has reached a level of maturity (or > the gcc developers had nothing better to do) that allows it to warn about > sign mismatches. I applaude that. Did I disable the warning? Or did I define the sign of char? > Yes, C is a weakly-typed language, else > such mismatches would cause compile-time errors and your code wouldn't even > compile. If gcc broke the build due to something like this, I would consider it broken and simply wouldn't support it until they fixed it. > I admit to being a purist, but damn it, computing requires, nay, > demands, perfection. The perfect is the enemy of the good. You are now in my spam filter. Go away. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Fri Dec 2 07:57:39 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 07:58:14 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051202081906.GA24607@aon.at> References: <200512011532.14120.rob@landley.net> <20051202005821.22ad87ca.aurel@gnuage.org> <20051202081906.GA24607@aon.at> Message-ID: <200512020957.39502.rob@landley.net> On Friday 02 December 2005 02:19, Bernhard Fischer wrote: > On Fri, Dec 02, 2005 at 12:58:21AM +0100, Aurelien Jacobs wrote: > >On Thu, 1 Dec 2005 15:32:13 -0600 > > > >Rob Landley wrote: > >> CONFIG_FEATURE_SORT_BIG needs libm, and right now it's not always > >> automatically including it. (I managed to get a build break from this.) > >> > >> I came up with the following makefile patch via cut and paste. Would > >> someone who knows makefiles tell me what I _should_ have done? > > > >Maybe this should go into Rules.mak and this should be : > > I'd set need-libm=y and look at $(need-libm) in Rules.mak. Ok. I suspect I should port the existing ones, then... > >+ifeq ($(strip $(CONFIG_FEATURE_SORT_BIG)),y) > >+ LIBRARIES += -lm > >+endif > > This would lead to a fairly big block when it's done for all applets > which need e.g. libm. So far there are two makefiles that do this: miscutils (CONFIG_DC) and editors (CONFIG_FEATURE_AWK_MATH). For me it's not the size, it's the locality. I added a libm dependency without realizing I needed to tweak the makefile, and I'd like it so future such things are easier to spot. We also have a similar situation with libcrypt. In networking we have CONFIG_FEATURE_HTTPD_AUTH_MD5 (although the MD5 applet itself doesn't need this, and I haven't looked into what it's actually doing), and in loginutils we have CONFIG_LOGIN, CONFIG_PASSWD, CONFIG_SU, CONFIG_SULOGIN, and CONFIG_VLOCK. (Possibly all that should be bouncing off some libbb library function.) Hmmm... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From vapier at gentoo.org Fri Dec 2 08:07:26 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Fri Dec 2 08:07:37 2005 Subject: Eject command In-Reply-To: References: Message-ID: <20051202160726.GH9185@toucan.gentoo.org> On Fri, Dec 02, 2005 at 02:23:01PM +0000, Rushi Lala wrote: > But i couldn't find eject command in .config or make menuconfig....... it's in svn but not in the 1.01 release -mike From rob at landley.net Fri Dec 2 08:13:35 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 08:14:23 2005 Subject: Need help in compiling on cygwin In-Reply-To: <200512021358.00515.farmatito@tiscali.it> References: <200512011730.23411.rob@landley.net> <200512021358.00515.farmatito@tiscali.it> Message-ID: <200512021013.35749.rob@landley.net> On Friday 02 December 2005 06:58, Tito wrote: > Snip > Hi to all, > I'm trying the same, just for fun, but with MSYS and MinGW compiler, > but I started by trying to make "make menuconfig" work. > So far I managed to fix some issues with sys/utsname.h, pdcurses and > installed a bison executable. Busybox and uclibc copied all that verbatim from the linux kernel. (I can barely get curses to work under linux, trying it under windows frightens me deeply.) > Maybe It would be better to try the make allnoconfig way? > If there is some interest I can post the error msg, If you've been following the miniconfig stuff, under busybox you can currently do an allnoconfig, append a miniconfig to .config, and then do: yes "" | make oldconfig Eventually we'll upgrade to the new kernel stuff that supports allno.config, but that's a 1.2 issue... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Fri Dec 2 08:15:31 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 08:15:57 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051202130122.GC9185@toucan.gentoo.org> References: <200512011532.14120.rob@landley.net> <20051202130122.GC9185@toucan.gentoo.org> Message-ID: <200512021015.31683.rob@landley.net> On Friday 02 December 2005 07:01, Mike Frysinger wrote: > On Thu, Dec 01, 2005 at 03:32:13PM -0600, Rob Landley wrote: > > I came up with the following makefile patch via cut and paste. Would > > someone who knows makefiles tell me what I _should_ have done? > > this should work: > needlibm-y := > needlibm-$(CONFIG_FEATURE_SORT_BIG) := -lm > LIBRARIES += $(needlibm-y) Okay... (Much blinking and scratching of head ensues...) Ok, I think I understand what it means, but won't it add -lm more than once if more than one applet needs it? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Fri Dec 2 08:17:00 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 08:19:39 2005 Subject: [PATCH] renaming interfaces with ifconfig In-Reply-To: <20051202135712.GA22958@yamamaya.is-a-geek.org> References: <20051129172402.GA5951@yamamaya.is-a-geek.org> <20051202135712.GA22958@yamamaya.is-a-geek.org> Message-ID: <200512021017.00902.rob@landley.net> On Friday 02 December 2005 07:57, Tobias Diedrich wrote: > Tobias Diedrich wrote: > > while I've seen that busybox at least in SVN supports nameif, the > > following (slightly hacky) patch to ifconfig would provide the basic > > interface renaming functionality with less code. > > Also, AFAICS nameif only works for interfaces with a MAC address, > > but in my case I'm more interested in renaming tun-Devices to assign > > static names to my OpenVPN tunnels. > > Has anyone looked at this patch yet? > > Thanks in advance, I've glanced at it. The code looks pretty straightforward. Could you add a patch to usage.h to show how to use it, please? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Fri Dec 2 08:19:03 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 08:20:28 2005 Subject: Eject command In-Reply-To: References: Message-ID: <200512021019.03608.rob@landley.net> On Friday 02 December 2005 08:23, Rushi Lala wrote: > Hi All, > Busybox documentation says there is a "eject" command included in busybox > http://www.busybox.net/downloads/BusyBox.html > > But i couldn't find eject command in .config or make menuconfig....... > , can any one help me with this ?Is there source for it in 1.01 ? If > yes what's the easiest way to include it in my build ? The one on the web is for 1.1.0-pre1. It was added after 1.00, and 1.01 was a bugfix release, not for new features. We're aiming to have 1.1.0 out by new years, and I'm trying to put together a 1.1.0-pre2 for next week. (Which largely involves triage work on bugs.busybox.net...) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From vapier at gentoo.org Fri Dec 2 08:28:29 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Fri Dec 2 08:28:39 2005 Subject: Makefile tweak for -lm? In-Reply-To: <200512021015.31683.rob@landley.net> References: <200512011532.14120.rob@landley.net> <20051202130122.GC9185@toucan.gentoo.org> <200512021015.31683.rob@landley.net> Message-ID: <20051202162829.GI9185@toucan.gentoo.org> On Fri, Dec 02, 2005 at 10:15:31AM -0600, Rob Landley wrote: > On Friday 02 December 2005 07:01, Mike Frysinger wrote: > > On Thu, Dec 01, 2005 at 03:32:13PM -0600, Rob Landley wrote: > > > I came up with the following makefile patch via cut and paste. Would > > > someone who knows makefiles tell me what I _should_ have done? > > > > this should work: > > needlibm-y := > > needlibm-$(CONFIG_FEATURE_SORT_BIG) := -lm > > LIBRARIES += $(needlibm-y) > > Okay... > > (Much blinking and scratching of head ensues...) > > Ok, I think I understand what it means, but won't it add -lm more than once if > more than one applet needs it? if you move the first line to the top, duplicate the second line for every applet, and move the third line to the 'end' (basically after all of the previous settings), then no, it wont add -lm more than once the $(CONFIG_...) will expand to either 'y' or 'n', so: needlibm-y := ... needlibm-$(CONFIG_FEATURE_SORT_BIG) := -lm needlibm-$(CONFIG_APPLET_FOO) := -lm needlibm-$(CONFIG_APPLET_BAR) := -lm ... LIBRARIES += $(needlibm-y) if the .config contains: CONFIG_FEATURE_SORT_BIG=y CONFIG_APPLET_FOO=y CONFIG_APPLET_BAR=n the make foo is expanded to: needlibm-y := ... needlibm-y := -lm needlibm-y := -lm needlibm-n := -lm ... LIBRARIES += $(needlibm-y) and since the := only ever sets, not increments, it isnt an issue ... if the .config contains: CONFIG_FEATURE_SORT_BIG=n CONFIG_APPLET_FOO=n CONFIG_APPLET_BAR=n the make foo is expanded to: needlibm-y := ... needlibm-n := -lm needlibm-n := -lm needlibm-n := -lm ... LIBRARIES += $(needlibm-y) and since we never set needlibm-y again, LIBRARIES will not contain -lm -mike From jzb at aexorsyst.com Fri Dec 2 08:45:55 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Fri Dec 2 08:46:20 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512020947.21819.rob@landley.net> References: <200512012113.26187.jzb@aexorsyst.com> <200512020947.21819.rob@landley.net> Message-ID: <200512020845.55486.jzb@aexorsyst.com> On Friday 02 December 2005 07:47, Rob Landley wrote: > It does match the prototype. The prototype is "char". The signedness of > that was indeterminate. Does not match. Watch: void foo(char x); ... signed char y; foo(y); ... is not the same as: void foo(char x); ... char y; foo(y); ... The "sign" of char y was removed and left to the compiler. Thus any change in the compiler will not cause warnigns or runtime issues. The C language allowed people to write code with indeterminate chars and determinate chars being mixed without warning, as long as it matched the assumptions of the compiler. Now THAT is a compiler bug. But its allowed by the C language, so you can't really blame the compiler. Now they changed it to warn, so what? The warnings should always have been there, and such code should never have been written. Yes, we've all done it, but always knew that wasn't portable code, because the signedness of char was always compiler dependent. Besides, you've got more than just char signed warnings in the text file of errors you posted, and that's when I got involved in the discussion. As I've stated previously, your solution is fine. The only point I'm trying to make is that the signedness of char's must always be explicitly specified in new code that people write in order to avoid this issue in the future. Its not the compiler's fault. > Now it's specifying -funsigned-char. It is now determinate. > > You are now in my spam filter. Why don't you post your compiler grumblings on the gcc mailing list, maybe they'll put you in their spam filter... > Go away. I was never here... -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From gildas.bayard at gmail.com Fri Dec 2 05:58:00 2005 From: gildas.bayard at gmail.com (Gildas Bayard) Date: Fri Dec 2 09:04:28 2005 Subject: "job control turned off" faq incomplete? Message-ID: <634720cc0512020558x15fa8a62v@mail.gmail.com> Hello, I'm fighting for hours with the damn "sh: can't access tty; job control turned off" message at boot. There is a FAQ related to the problem but I think it lacks information. I copied default inittab behaviour from busybox documentation and tried to tweek things in but I have no idea how am I suppose to "run your shell on a normal tty such as tty1 or ttyS0 and everything will work perfectly". I'm using busybox on a PC and want to see the console on the VGA. So my tty is tty0 right? first process run is busybox /sbin/init (well I have an initrd running before) which parses inittab, hence I guess there's something to change here. Could you help me? Gildas From rob at landley.net Fri Dec 2 09:29:37 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 09:34:28 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512012113.26187.jzb@aexorsyst.com> References: <200512011713.59792.rob@landley.net> <200512012113.26187.jzb@aexorsyst.com> Message-ID: <200512021129.38098.rob@landley.net> Alright, I was too lazy to actually edit my spam filter and I've cooled down enough to read the rest of your message. (I still reserve the right to ignore you.) > > > It might even > > > be better to write a perl or gawk script to replaced the unsigned with > > > signed in the cases where warnings are generated, > > > > NO. > > There are lots of such warnings. They all need to be looked at and fixed > manually in the end. There has been a warning in networking/traceroute.c for as long as I can remember. Unfortunately, vodz maintains that applet and every time I poke him about that sort of thing, he gets upset. So it may never get fixed. The warning is this: /home/landley/busybox/busybox/networking/traceroute.c:296: warning: `align' attribute directive ignored It is not actually a warning that _means_ anything. On some platforms, the align directive is needed, and on others the default value is already correct. I only wanted to get rid of it because at one time I had us down to just two warnings and wanted to make a clean sweep of it. Now we've got four new ones in fsck.c and another in uudecode, and perhaps these are meaningful and perhaps they aren't. I like to get the non-meaningful ones to go away so that any real messages aren't buried in the noise. What I object to is the introduction of a new warning that is over 95% noise. A warning that complains about code that's been in use and working for years, and which is not actually raising a valid objection. And this is not a position I'm going to defend to you. There is such a thing as a useless warning: http://groups.google.com/group/linux.kernel/browse_thread/thread/331f881766aa4f09/a6d10fe2e1613f26 http://groups.google.com/group/linux.kernel/browse_thread/thread/754dc7e962794817/6a6adfaa44939718 Keep in mind that gcc 4 broke the build for bash 2.05b. You have to patch bash in order to get it to compile under gcc 4. Why? Because at the end of a {block} bash has an #ifdef that conditionally chops out some code, and it has a label that gotos right before the #ifdef. When the #ifdef is false, the label jumps to the end of the block, and gcc decided "hey, that's something no sane person would ever want to do. Error!". Despite the fact that it's perfectly valid code. (No, not a warning, an error.) The patch I'm applying to make it build, I kid you not, is this: --- bash-2.05b/lib/malloc/malloc.c 2002-06-21 14:16:49.000000000 -0500 +++ new/lib/malloc/malloc.c 2005-10-14 19:30:46.030058320 -0500 @@ -880,6 +880,7 @@ free_return: + do {;} while(0); #ifdef MALLOC_STATS _mstats.nmalloc[nunits]--; _mstats.nfre++; Yes, LIE TO THE COMPILER, and then it builds... It is entirely possible for the gcc guys to break stuff and be stupid. It is, in fact, fairly normal in _any_ project that there will be major thinkos. And a compiler that cries wolf for STUPID REASONS makes it really, really tempting to just switch the darn warnings off. You want to convince me the warnings are valid, show me an actual bug due to a SINGLE ONE of the "signedness of char" warnings. Show me one. > > Automatic changes to shut the compiler up, where a human didn't look at > > each and every change being made, are not just churn but DANGEROUS churn. > > I would _protest_ the application of such a patch. > > You misunderstand. If there are no errors (you claim there are none) with > the sign mismatches, then fixing them to be not mismatched will introduce > them? Yes, it can. > Doesn't follow, unless the code relies on coding errors to come up > with the correct results. No, I mean that even refactoring can accidentally alter behavior, and over the years I've seen what was intended as whitespace changes break stuff. (This is normal, and why you test as you change.) The code relies on the current behavior to come up with its results. Who's to say what's a coding error? Is duff's device a coding error? > Possible, but not likely. If this code works > with the warnings, surely there can't be too much risk in fixing the > warnings correctly, to have not sign mismatched parameters? If by "fix" you mean insert gratuitious typecasts, the reason we're not doing that is it bloats the code to fix things that aren't actual problems. If by "fix" you mean change declarations, this can alter behavior and a human better have looked at it. I could get away with defining char to be unsigned because it varies from platform to platform and in theory we've already tested it both ways. (I expect there will probably be a big or two anyway.) > Can there? > Yes, I know your answer, but if it is a risk, then I submit its a greater > risk to have the sign mismatches present in the first place. What risk? Show me a bug we haven't found. That would be something useful. > > Because obviously none of these are bugs that have shown up in testing so > > far, so fresh testing will obviously be equally effective in giving us a > > false sense of security. > > Can't blame programmers not honoring the prototype on either the compiler > or the test suite. Damn it people, honor thy father, mother, and > prototype. So, you come in to a volunteer project and tell us we're doing it wrong because you know better and your way is so perfect. You forgot to do it in l33t sp33k. > > Something _useful_ to do would be to fill out the test suite so we have > > serious coverage. (Not necessarily fun, but I take a whack at it every > > couple of weeks. Big job, but relatively easy to make progress on. The > > problem is, I generally find esoteric bugs and wander off on tangents > > fixing them. :) > > I'm quite swamped with a bunch of projects at the moment, Aren't we all? http://www.landley.net/code/todo.txt > but soon, soon I > tell you, I will be able to contribute more than just words... My lack of caring achieves dizzying heights, I tell you. > I'm cleaning > up buildroot, among other things, to be at least self-hosting, I gave up on buildroot and implemented an alternative, which I'm trying to get a new release out of this weekend. http://www.landley.net/code/firmware It has been self-hosting in the past, and will be again, but right now User Mode linux-2.6.15-rc4 seems to have introduced a new conflict with the uClibc headers (possibly related to Mazur's headers) and building a static allyesconfig busybox is causing the darn compiler to hang (I haven't narrowed this down yet, busybox is triggering it, it's probably a gcc 4.0 issue, but User Mode Linux and uClibc may also be involved.) Right now I'm focusing on getting an automatically generated partitioned hard drive image that qemu can boot. (I actually have that part working, but the init scripts for the bootable version are in pieces at the moment...) > and when > that's done, I can write some code for busybox. Keep me in mind, and if > there's some coding you want to offload later, I'd be happy to help. Did you see the TODO list that ships in busybox? Did you see the recent calls for people to help triage the 80+ issues in bugs.busybox.net into "must fix for 1.1", "would be nice", and "not a 1.1 issue"? > And > by the way, I NEVER mismatch signs on prototypes, except when hardware > bit-mapped structures force me to recast bit-fields, but then I ALWAYS cast > them, so I know I did it on purpose. Unnecessary typecasts suck. Introducing typecasts to make a compiler warning go away is seldom a good idea, and thinking of them as a form of _documentation_ is just wrong. > And my bain is the miserable "blah > blah breaks strict-aliasing rules..." warning which showed up around the > gcc-3.3.4 timeframe. Yes, I could turn it off easily, but I've learned to > live with it, even though I am quite a huge fan of the silent build (and I > don't mean with the .SILENT target), I'm the guy who was pushing for a silent build under gcc 3.3. You've managed to alienate _me_. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Fri Dec 2 09:40:59 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 09:41:26 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512020845.55486.jzb@aexorsyst.com> References: <200512020947.21819.rob@landley.net> <200512020845.55486.jzb@aexorsyst.com> Message-ID: <200512021140.59184.rob@landley.net> On Friday 02 December 2005 10:45, John Z. Bohach wrote: > On Friday 02 December 2005 07:47, Rob Landley wrote: > > It does match the prototype. The prototype is "char". The signedness of > > that was indeterminate. > > Does not match. Watch: > > void foo(char x); > ... > signed char y; > foo(y); > ... See "the signedness is indeterminate". Signed or unsigned will clash on various platforms as the default moves. > Besides, you've got more than just char signed warnings in the text file of > errors you posted, and that's when I got involved in the discussion. As > I've stated previously, your solution is fine. The int ones I don't mind so much. The char ones are noise. > The only point I'm trying > to make is that the signedness of char's must always be explicitly > specified in new code that people write in order to avoid this issue in the > future. Its not the compiler's fault. > > Now it's specifying -funsigned-char. It is now determinate. > > > > You are now in my spam filter. > > Why don't you post your compiler grumblings on the gcc mailing list, maybe > they'll put you in their spam filter... Because I read large chunks of the gcc source code years ago and I'm NEVER poking at the internals of that thing again if I can help it? I'm already trying to follow linux-kernel, user mode linux (-devel and -user), busybox, and uClibc. These are projects I'm willing to poke at the internals of. If I was going to pick up a compiler and start doing the same, it would be Fabrice Bellard's TCC, not gcc. But right now, I've got way too much on my plate already. I view gcc as a necessary evil, for now. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From jzb at aexorsyst.com Fri Dec 2 09:42:25 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Fri Dec 2 09:42:35 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512021129.38098.rob@landley.net> References: <200512012113.26187.jzb@aexorsyst.com> <200512021129.38098.rob@landley.net> Message-ID: <200512020942.25936.jzb@aexorsyst.com> On Friday 02 December 2005 09:29, Rob Landley wrote: > Alright, I was too lazy to actually edit my spam filter and I've cooled > down enough to read the rest of your message. > > (I still reserve the right to ignore you.) I understand. I'll refrain from philosophical discussions, since their practicality is limited, yet the song with the phrase "...don't let the sound of your own wheels make you crazy..." comes to mind. And it applies to me too... -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From ranma at tdiedrich.de Fri Dec 2 09:44:02 2005 From: ranma at tdiedrich.de (Tobias Diedrich) Date: Fri Dec 2 09:44:20 2005 Subject: [PATCH] renaming interfaces with ifconfig In-Reply-To: <200512021017.00902.rob@landley.net> References: <20051129172402.GA5951@yamamaya.is-a-geek.org> <20051202135712.GA22958@yamamaya.is-a-geek.org> <200512021017.00902.rob@landley.net> Message-ID: <20051202174402.GB28830@yamamaya.is-a-geek.org> Rob Landley wrote: > I've glanced at it. The code looks pretty straightforward. > > Could you add a patch to usage.h to show how to use it, please? Sure. Index: include/usage.h =================================================================== --- include/usage.h (revision 12643) +++ include/usage.h (working copy) @@ -1222,6 +1222,11 @@ #else # define USAGE_IPV6(a) #endif +#ifdef CONFIG_FEATURE_IFCONFIG_NAME +# define USAGE_IFCONFIG_NAME(a) a +#else +# define USAGE_IFCONFIG_NAME(a) +#endif #define ifconfig_trivial_usage \ USAGE_IFCONFIG_OPT_A("[-a]") " [
]" @@ -1233,6 +1238,7 @@ "\t[[-]broadcast [
]] [[-]pointopoint [
]]\n" \ "\t[netmask
] [dstaddr
]\n" \ USAGE_SIOCSKEEPALIVE("\t[outfill ] [keepalive ]\n") \ + USAGE_IFCONFIG_NAME("\t[name ]\n") \ "\t" USAGE_IFCONFIG_HW("[hw ether
] ") \ "[metric ] [mtu ]\n" \ "\t[[-]trailers] [[-]arp] [[-]allmulti]\n" \ Index: networking/ifconfig.c =================================================================== --- networking/ifconfig.c (revision 12643) +++ networking/ifconfig.c (working copy) @@ -134,6 +134,11 @@ #define A_HOSTNAME 0 #define A_BROADCAST 0 #endif +#ifdef CONFIG_FEATURE_IFCONFIG_NAME +#define A_IFNAME 0xc0 /* Set if it is new ifname. */ +#else +#define A_IFNAME 0 +#endif /* * These defines are for dealing with the A_CAST_TYPE field. @@ -164,6 +169,7 @@ #define ARG_DSTADDR (A_ARG_REQ | A_CAST_HOST_COPY_RESOLVE) #define ARG_NETMASK (A_ARG_REQ | A_CAST_HOST_COPY_RESOLVE | A_NETMASK) #define ARG_BROADCAST (A_ARG_REQ | A_CAST_HOST_COPY_RESOLVE | A_SET_AFTER | A_BROADCAST) +#define ARG_IFNAME (A_ARG_REQ | A_IFNAME) #define ARG_HW (A_ARG_REQ | A_CAST_HOST_COPY_IN_ETHER) #define ARG_POINTOPOINT (A_ARG_REQ | A_CAST_HOST_COPY_RESOLVE | A_SET_AFTER) #define ARG_KEEPALIVE (A_ARG_REQ | A_CAST_CHAR_PTR) @@ -203,6 +209,9 @@ {"SIOCSIFDSTADDR", SIOCSIFDSTADDR, ifreq_offsetof(ifr_dstaddr)}, {"SIOCSIFNETMASK", SIOCSIFNETMASK, ifreq_offsetof(ifr_netmask)}, {"SIOCSIFBRDADDR", SIOCSIFBRDADDR, ifreq_offsetof(ifr_broadaddr)}, +#ifdef CONFIG_FEATURE_IFCONFIG_NAME + {"SIOCSIFNAME", SIOCSIFNAME, ifreq_offsetof(ifr_newname)}, +#endif #ifdef CONFIG_FEATURE_IFCONFIG_HW {"SIOCSIFHWADDR", SIOCSIFHWADDR, ifreq_offsetof(ifr_hwaddr)}, #endif @@ -233,6 +242,9 @@ {"dstaddr", N_ARG, ARG_DSTADDR, 0}, {"netmask", N_ARG, ARG_NETMASK, 0}, {"broadcast", N_ARG | M_CLR, ARG_BROADCAST, IFF_BROADCAST}, +#ifdef CONFIG_FEATURE_IFCONFIG_NAME + {"name", N_ARG | M_CLR, ARG_IFNAME, 0}, +#endif #ifdef CONFIG_FEATURE_IFCONFIG_HW {"hw", N_ARG, ARG_HW, 0}, #endif @@ -479,6 +491,9 @@ #endif memcpy((((char *) (&ifr)) + a1op->ifr_offset), p, sizeof(struct sockaddr)); + } else if ((mask & A_IFNAME) == A_IFNAME && A_IFNAME) { + safe_strncpy(ifr.ifr_newname, *argv, IFNAMSIZ); + mask = 0; } else { unsigned long i = strtoul(*argv, NULL, 0); Index: networking/Config.in =================================================================== --- networking/Config.in (revision 12643) +++ networking/Config.in (working copy) @@ -181,6 +181,15 @@ Setting this will make ifconfig attempt to find the broadcast automatically if the value '+' is used. +config CONFIG_FEATURE_IFCONFIG_NAME + bool " Allow renaming of interfaces with option \"name\"" + default n + depends on CONFIG_IFCONFIG + help + Renames the specified interface. For interfaces with MAC-Addresses + nameif is probably the better tool, but this option is smaller and + should work with any interface. + config CONFIG_IFUPDOWN bool "ifupdown" default n -- Tobias PGP: http://9ac7e0bc.uguu.de From rob at landley.net Fri Dec 2 09:49:35 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 09:49:59 2005 Subject: By the way... Message-ID: <200512021149.35970.rob@landley.net> Any opinions on the new linksys rounters using 2 megs flash and 8 megs ram? http://www.linuxdevices.com/news/NS4729641740.html I'm pretty sure we can squeeze linux into that, but I haven't messed around with the guts of their system. (I know Erik has...) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Fri Dec 2 10:28:31 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 10:28:50 2005 Subject: [PATCH] Applet installation - 2nd take In-Reply-To: <200511022150.53885.yann.morin.1998@anciens.enib.fr> References: <200511022150.53885.yann.morin.1998@anciens.enib.fr> Message-ID: <200512021228.31839.rob@landley.net> On Wednesday 02 November 2005 14:50, Yann E. MORIN wrote: > Hi all! > > Applets installation patch re-diffed against current trunk (rev 12116). Finally checked this sucker in (svn 12647), let me know if the version that's in there passes muster? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From jmarbach at quelisid.com Fri Dec 2 10:58:17 2005 From: jmarbach at quelisid.com (Julien MARBACH) Date: Fri Dec 2 11:19:02 2005 Subject: crond problem Message-ID: <43909949.3070200@quelisid.com> Hello, I'm trying to use the crond of busybox 1.0. I've searched the list archives for instrucions about how to solve my problem but I found nothing clear. Here is the problem : I've a startup script that launches crond and set the crontabs $ cat /etc/rcS.d/S40crond #!/bin/sh #Setting up the cron daemon confguration mkdir -p /var/spool/cron/crontabs # Copying the crontab file /usr/bin/crontab /etc/crontab /usr/sbin/crond Here is my crontab file : $ cat /etc/crontab #SHELL=/bin/sh #PATH=/sbin:/bin:/usr/sbin:/usr/bin #MAILTO=root #HOME=/ # run-parts 01 * * * * root /bin/run-parts /etc/cron.hourly 02 4 * * * root /bin/run-parts /etc/cron.daily 22 4 * * 0 root /bin/run-parts /etc/cron.weekly 42 4 1 * * root /bin/run-parts /etc/cron.monthly And here the hourly script : $ cat /etc/cron.hourly/syslog_backup_script #!/bin/sh cat /var/log/messages > /var/log/messages.bak echo -n "" > /var/log/messages Here is what i can see in syslog : Jan 1 02:00:18 (none) syslog.info -- MARK -- Jan 1 02:01:01 (none) kern.notice crond[944]: USER root pid 1123 cmd root /bin/run-parts /etc/cron.hourly Jan 1 02:20:18 (none) syslog.info -- MARK -- Jan 1 02:40:18 (none) syslog.info -- MARK -- Jan 1 03:00:18 (none) syslog.info -- MARK -- Jan 1 03:01:01 (none) kern.notice crond[944]: USER root pid 1124 cmd root /bin/run-parts /etc/cron.hourly Jan 1 03:20:18 (none) syslog.info -- MARK -- Jan 1 03:40:18 (none) syslog.info -- MARK -- Jan 1 04:00:18 (none) syslog.info -- MARK -- Jan 1 04:01:01 (none) kern.notice crond[944]: USER root pid 1125 cmd root /bin/run-parts /etc/cron.hourly Jan 1 04:02:01 (none) kern.notice crond[944]: USER root pid 1126 cmd root /bin/run-parts /etc/cron.daily Jan 1 04:20:18 (none) syslog.info -- MARK -- Jan 1 04:40:18 (none) syslog.info -- MARK -- Jan 1 04:42:01 (none) kern.notice crond[944]: USER root pid 1127 cmd root /bin/run-parts /etc/cron.monthly Jan 1 05:00:18 (none) syslog.info -- MARK -- Jan 1 05:01:01 (none) kern.notice crond[944]: USER root pid 1128 cmd root /bin/run-parts /etc/cron.hourly Jan 1 05:20:18 (none) syslog.info -- MARK -- Jan 1 05:40:18 (none) syslog.info -- MARK -- Jan 1 06:00:18 (none) syslog.info -- MARK -- Jan 1 06:01:01 (none) kern.notice crond[944]: USER root pid 1129 cmd root /bin/run-parts /etc/cron.hourly Jan 1 06:20:18 (none) syslog.info -- MARK -- Jan 1 06:40:18 (none) syslog.info -- MARK -- Jan 1 07:00:18 (none) syslog.info -- MARK -- Jan 1 07:01:01 (none) kern.notice crond[944]: USER root pid 1130 cmd root /bin/run-parts /etc/cron.hourly Jan 1 07:20:18 (none) syslog.info -- MARK -- Jan 1 07:40:18 (none) syslog.info -- MARK -- As you can see in syslog, cron seems to have executed the scripts but in fact it has done nothing... Do you have any idea of what happens here? Thanks Julien From rep.nop at aon.at Fri Dec 2 12:10:02 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Fri Dec 2 12:09:23 2005 Subject: Makefile tweak for -lm? In-Reply-To: <200512021015.31683.rob@landley.net> References: <200512011532.14120.rob@landley.net> <20051202130122.GC9185@toucan.gentoo.org> <200512021015.31683.rob@landley.net> Message-ID: <20051202201002.GH7230@aon.at> Rob, On Fri, Dec 02, 2005 at 10:15:31AM -0600, Rob Landley wrote: >On Friday 02 December 2005 07:01, Mike Frysinger wrote: >> On Thu, Dec 01, 2005 at 03:32:13PM -0600, Rob Landley wrote: >> > I came up with the following makefile patch via cut and paste. Would >> > someone who knows makefiles tell me what I _should_ have done? >> >> this should work: Makefile.in: >> needlibm-y := >> needlibm-$(CONFIG_FEATURE_SORT_BIG) := -lm Rules.mak: >> LIBRARIES += $(needlibm-y) > >Okay... > >(Much blinking and scratching of head ensues...) > >Ok, I think I understand what it means, but won't it add -lm more than once if >more than one applet needs it? No, you should only end with one -lm as every previous assignment is overwritten, not appended. (:= != +=) If you are concerned about the order of the libs, just reorder them in Rules.mak. Something like this after the LIBRARIES are all set would force correct ordering, but shouldn't be needed if you put a comment on top of adding libm that it ought to be one of the last libs. LIBRARIES := $(filter-out -lm,$(LIBRARIES)) -lm hth, Bernhard From jakelly at shtc.net Fri Dec 2 13:16:58 2005 From: jakelly at shtc.net (John Kelly) Date: Fri Dec 2 13:24:39 2005 Subject: "job control turned off" faq incomplete? In-Reply-To: <634720cc0512020558x15fa8a62v@mail.gmail.com> References: <634720cc0512020558x15fa8a62v@mail.gmail.com> Message-ID: <96e1p1p03hj6b20qnqa042fjck76ig4aco@4ax.com> On Fri, 02 Dec 2005 14:58:00 +0100, Gildas Bayard wrote: >I'm fighting for hours with the damn "sh: can't access tty; job >control turned off" message at boot. >Could you help me? After disabling devfs in my busybox config, I never saw that problem again. But I use a static dev, so maybe this won't help you. From cgales at gmail.com Fri Dec 2 17:00:39 2005 From: cgales at gmail.com (Chuck Gales) Date: Fri Dec 2 18:14:12 2005 Subject: "job control turned off" faq incomplete? In-Reply-To: <96e1p1p03hj6b20qnqa042fjck76ig4aco@4ax.com> References: <634720cc0512020558x15fa8a62v@mail.gmail.com> <96e1p1p03hj6b20qnqa042fjck76ig4aco@4ax.com> Message-ID: <3c09ea2e0512021700i3e9b9d54k9843f2c032266b9e@mail.gmail.com> On 12/2/05, John Kelly wrote: > On Fri, 02 Dec 2005 14:58:00 +0100, Gildas Bayard > wrote: > > >I'm fighting for hours with the damn "sh: can't access tty; job > >control turned off" message at boot. > > >Could you help me? > > After disabling devfs in my busybox config, I never saw that problem > again. But I use a static dev, so maybe this won't help you. > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > Try using the following with devfs: tts/0::respawn:/sbin/getty -i -L tts/0 9600 vt100 From rob at landley.net Fri Dec 2 19:39:04 2005 From: rob at landley.net (Rob Landley) Date: Fri Dec 2 19:39:16 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051202162829.GI9185@toucan.gentoo.org> References: <200512011532.14120.rob@landley.net> <200512021015.31683.rob@landley.net> <20051202162829.GI9185@toucan.gentoo.org> Message-ID: <200512022139.05018.rob@landley.net> On Friday 02 December 2005 10:28, Mike Frysinger wrote: > if you move the first line to the top, duplicate the second line for > every applet, and move the third line to the 'end' (basically after > all of the previous settings), then no, it wont add -lm more than once Ok, so you're talking about having specific mentions of CONFIG_FEATURE_BLAH not in the Makefile snippet for the blah/ subdirectory, but in Rules.mak? I'd really, really, really rather not have specific applet mentions outside of the directory for that applet, if we can avoid it. > the make foo is expanded to: > needlibm-y := > ... > needlibm-y := -lm > needlibm-y := -lm > needlibm-n := -lm > ... > LIBRARIES += $(needlibm-y) > and since the := only ever sets, not increments, it isnt an issue ... The old problem I always have with makefiles is "what order does this happen in". How do I know that LIBRARIES += $(needlibm-y) will be evaluated after needlibm-y gets set in all the places it needs to be? Is there an obvious place in the top level makefile to stick LIBRARIES += $(needlibm-y), after all the sub-makefiles have been #included? I'll check... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From vapier at gentoo.org Fri Dec 2 20:17:26 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Fri Dec 2 20:17:32 2005 Subject: Makefile tweak for -lm? In-Reply-To: <200512022139.05018.rob@landley.net> References: <200512011532.14120.rob@landley.net> <200512021015.31683.rob@landley.net> <20051202162829.GI9185@toucan.gentoo.org> <200512022139.05018.rob@landley.net> Message-ID: <20051203041726.GD2240@toucan.gentoo.org> On Fri, Dec 02, 2005 at 09:39:04PM -0600, Rob Landley wrote: > On Friday 02 December 2005 10:28, Mike Frysinger wrote: > > if you move the first line to the top, duplicate the second line for > > every applet, and move the third line to the 'end' (basically after > > all of the previous settings), then no, it wont add -lm more than once > > Ok, so you're talking about having specific mentions of CONFIG_FEATURE_BLAH > not in the Makefile snippet for the blah/ subdirectory, but in Rules.mak? > > I'd really, really, really rather not have specific applet mentions outside of > the directory for that applet, if we can avoid it. *shrug* however you wanna play it ;) > > the make foo is expanded to: > > needlibm-y := > > ... > > needlibm-y := -lm > > needlibm-y := -lm > > needlibm-n := -lm > > ... > > LIBRARIES += $(needlibm-y) > > and since the := only ever sets, not increments, it isnt an issue ... > > The old problem I always have with makefiles is "what order does this happen > in". How do I know that LIBRARIES += $(needlibm-y) will be evaluated after > needlibm-y gets set in all the places it needs to be? thats what := means versus = when you do := make will evaluate the stuff right then ... but if you use =, the variable wont be evaluated until it's actually needed a1 = $(b) a2 := $(b) b = c all: @echo a1: $(a1) a2: $(a2) the output here will be: a1: c a2: -mike From wharms at bfs.de Sat Dec 3 02:12:24 2005 From: wharms at bfs.de (walter harms) Date: Sat Dec 3 02:12:56 2005 Subject: By the way... In-Reply-To: <200512021149.35970.rob@landley.net> References: <200512021149.35970.rob@landley.net> Message-ID: <43916F88.70101@bfs.de> hi rob, so far i know linksys is a mips system. they have a working linux dist for linksys systems. i do not know if for that particular type. perhaps you can add a sections like "linux embedded dist" to busybox.net. re, walter Rob Landley wrote: > Any opinions on the new linksys rounters using 2 megs flash and 8 megs ram? > http://www.linuxdevices.com/news/NS4729641740.html > > I'm pretty sure we can squeeze linux into that, but I haven't messed around > with the guts of their system. (I know Erik has...) > > Rob From lists at zelow.no Sat Dec 3 02:35:34 2005 From: lists at zelow.no (Thomas Lundquist) Date: Sat Dec 3 02:35:48 2005 Subject: By the way... In-Reply-To: <200512021149.35970.rob@landley.net> References: <200512021149.35970.rob@landley.net> Message-ID: <20051203103534.GA6723@zelow.no> On Fri, Dec 02, 2005 at 11:49:35AM -0600, Rob Landley wrote: > > Any opinions on the new linksys rounters using 2 megs flash and 8 megs ram? > http://www.linuxdevices.com/news/NS4729641740.html > > I'm pretty sure we can squeeze linux into that, but I haven't messed around > with the guts of their system. (I know Erik has...) I know it is possible to squeeze a pretty featureful Linux distro on 2M flash and 8M RAM at least. Thomas. From yann.morin.1998 at anciens.enib.fr Sat Dec 3 06:23:59 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sat Dec 3 06:05:32 2005 Subject: [PATCH] Applet installation - 2nd take In-Reply-To: <200512021228.31839.rob@landley.net> References: <200511022150.53885.yann.morin.1998@anciens.enib.fr> <200512021228.31839.rob@landley.net> Message-ID: <200512031523.59393.yann.morin.1998@anciens.enib.fr> Hello Rob! On Friday 02 December 2005 192, Rob Landley wrote: > On Wednesday 02 November 2005 14:50, Yann E. MORIN wrote: > > Applets installation patch re-diffed against current trunk (rev 12116). > Finally checked this sucker in (svn 12647), let me know if the version that's > in there passes muster? Woopsss.. You missed three files... Complementary patch attached. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?---.----------------: X AGAINST | /e\ There is no | | web: ymorin.free.fr | SETI@home 3808 | / \ HTML MAIL | """ conspiracy. | ?---------------------?----------------?------------------?--------------------? -------------- next part -------------- A non-text attachment was scrubbed... Name: busybos-svn.12656-applet-install.patch.bz2 Type: application/x-bzip2 Size: 1089 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051203/7d024302/busybos-svn.12656-applet-install.patch.bin From yann.morin.1998 at anciens.enib.fr Sat Dec 3 06:25:06 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sat Dec 3 06:06:20 2005 Subject: modutils update (modprobe and config) In-Reply-To: <200511272319.43303.yann.morin.1998@anciens.enib.fr> References: <200511272319.43303.yann.morin.1998@anciens.enib.fr> Message-ID: <200512031525.06096.yann.morin.1998@anciens.enib.fr> Hello all! On Sunday 27 November 2005 231, Yann E. MORIN wrote: > Here am I with my modutils update. Hmmm. No one dared look at this? 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 rory.vieira at coolview.nl Sat Dec 3 08:21:01 2005 From: rory.vieira at coolview.nl (Rory Vieira) Date: Sat Dec 3 08:49:56 2005 Subject: "job control turned off" faq incomplete? In-Reply-To: <634720cc0512020558x15fa8a62v@mail.gmail.com> Message-ID: <006101c5f825$8d57d830$0b01a8c0@pluto> Gildas, I noticed that as long as my rootfs is readonly I got the message. So the top two lines in my inittab were 1. Mount /proc 2. Remount root readwrite... It comes back when I explicitly remove the second line... Ps, I only have one console which is on tty0... Hope this helps, Rory From farmatito at tiscali.it Sun Dec 4 05:15:43 2005 From: farmatito at tiscali.it (Tito) Date: Sun Dec 4 05:18:10 2005 Subject: Latest svn revision 12662 compilation broken Message-ID: <200512041415.43580.farmatito@tiscali.it> Hi to all, I'm trying to compile the latest bb svn revision 12662, but it seems to be broken. The error message i get is: root@localhost:/dev/pts/3:/root/Desktop/busybox# make make -C /root/Desktop/busybox \ top_srcdir=/root/Desktop/busybox \ top_builddir=/root/Desktop/busybox \ KBUILD_SRC=/root/Desktop/busybox \ -f /root/Desktop/busybox/Makefile _all make[1]: Entering directory `/root/Desktop/busybox' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/bb_mkdep /root/Desktop/busybox/scripts/bb_mkdep.c scripts/bb_mkdep -c include/config.h -c include/bb_config.h \ -I /root/Desktop/busybox/include /root/Desktop/busybox > .depend.tmp mv .depend.tmp .depend gcc -I/root/Desktop/busybox/include -I/root/Desktop/busybox/include -I/root/Desktop/busybox/libbb -funsigned-char -Wall -Wstrict-prototypes -Wshadow -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=0 -falign-jumps=0 -falign-loops=0 -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG -c -o /root/Desktop/busybox/applets/applets.o /root/Desktop/busybox/applets/applets.c In file included from /root/Desktop/busybox/applets/applets.c:48: /root/Desktop/busybox/include/applets.h:677: error: 'tr_main' undeclared here (not in a function) /root/Desktop/busybox/include/applets.h:740: error: 'watchdog_main' undeclared here (not in a function) make[1]: *** [/root/Desktop/busybox/applets/applets.o] Error 1 make[1]: Leaving directory `/root/Desktop/busybox' make: *** [_all] Error 2 So far I've tried a fresh svn co svn://busybox.net/trunk/busybox but nothing changed. By looking at applets.h I couldn't see any obvious problem. Let me know if you need more info about .config or other stuff. Ciao, Tito From farmatito at tiscali.it Sun Dec 4 05:22:52 2005 From: farmatito at tiscali.it (Tito) Date: Sun Dec 4 05:26:37 2005 Subject: Latest svn revision 12662 compilation broken addendum Message-ID: <200512041422.52098.farmatito@tiscali.it> Hi to all, BTW the error goes away if tr and watchdog are selected. Tested with: make allnoconfig make menuconfig select mktemp, tr, watchdog. make -> ok select mktemp make -> ko Ciao, Tito From farmatito at tiscali.it Sun Dec 4 06:17:14 2005 From: farmatito at tiscali.it (Tito) Date: Sun Dec 4 06:18:45 2005 Subject: [PATCH] mktemp size optimization proposal Message-ID: <200512041517.15070.farmatito@tiscali.it> Hi, This is a size optimization for mktemp I've written just for fun. I have a little doubts about this lines void (*Action)(char *template) =(void*) mkstemp; and if(flags & 1) Action = (void *)mkdtemp; as they look a little hazardous to me and are done just by instinct. The patch is tested and seems to work. Size optimization is : text data bss dec hex filename 107 0 0 107 6b mktemp.o 99 0 0 99 63 mktemp.o The patch also has better error messages when template is bad. Comments are welcome as there is something to learn for me. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: mktemp.patch Type: text/x-diff Size: 825 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051204/8e15410b/mktemp.bin From rob at landley.net Sun Dec 4 09:53:27 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 4 09:54:16 2005 Subject: By the way... In-Reply-To: <43916F88.70101@bfs.de> References: <200512021149.35970.rob@landley.net> <43916F88.70101@bfs.de> Message-ID: <200512041153.27678.rob@landley.net> On Saturday 03 December 2005 04:12, walter harms wrote: > hi rob, > so far i know linksys is a mips system. I thought it was arm, but haven't personally played with it. > they have a working linux dist for linksys systems. They have several. Until recently, linksys boxes were based on Linux. But their most recent generation of hardware has half as much memory and half as much flash as previous versions, and they went with vxworks instead to fit in the smaller footprint. (The link I gave mentions some of this...) > i do not know if for that particular type. > perhaps you can add a sections like "linux embedded dist" to busybox.net. Ask Erik, he used to track this kind of thing when he had more time. (I believe his wife was using a modified linksys router with a distro he put together, but this is secondhand and a while ago...) > re, > walter Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 4 10:07:27 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 4 10:07:58 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051203041726.GD2240@toucan.gentoo.org> References: <200512011532.14120.rob@landley.net> <200512022139.05018.rob@landley.net> <20051203041726.GD2240@toucan.gentoo.org> Message-ID: <200512041207.28112.rob@landley.net> On Friday 02 December 2005 22:17, Mike Frysinger wrote: > > The old problem I always have with makefiles is "what order does this > > happen in". How do I know that LIBRARIES += $(needlibm-y) will be > > evaluated after needlibm-y gets set in all the places it needs to be? > > thats what := means versus = > > when you do := make will evaluate the stuff right then ... but if you > use =, the variable wont be evaluated until it's actually needed > > a1 = $(b) > a2 := $(b) > b = c > all: > @echo a1: $(a1) a2: $(a2) > > the output here will be: > a1: c a2: Oh. That makes much more sense. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 4 10:08:33 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 4 10:09:01 2005 Subject: modutils update (modprobe and config) In-Reply-To: <200512031525.06096.yann.morin.1998@anciens.enib.fr> References: <200511272319.43303.yann.morin.1998@anciens.enib.fr> <200512031525.06096.yann.morin.1998@anciens.enib.fr> Message-ID: <200512041208.34097.rob@landley.net> On Saturday 03 December 2005 08:25, Yann E. MORIN wrote: > Hello all! > > On Sunday 27 November 2005 231, Yann E. MORIN wrote: > > Here am I with my modutils update. > > Hmmm. No one dared look at this? I have it in my to-do list. :) I'm trying to get a firmware linux release out today, but I'll try to give it a whack first thing tomorrow... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 4 10:13:02 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 4 10:13:15 2005 Subject: "job control turned off" faq incomplete? In-Reply-To: <006101c5f825$8d57d830$0b01a8c0@pluto> References: <006101c5f825$8d57d830$0b01a8c0@pluto> Message-ID: <200512041213.02709.rob@landley.net> On Saturday 03 December 2005 10:21, Rory Vieira wrote: > Gildas, > > I noticed that as long as my rootfs is readonly I got the message. > So the top two lines in my inittab were > 1. Mount /proc > 2. Remount root readwrite... > > It comes back when I explicitly remove the second line... > Ps, I only have one console which is on tty0... > Hope this helps, Lemme guess: /dev is on your read-only root filesystem, thus tty0 is read only, so it can't do things like chown it to belong to whoever just logged in? That can have funky side effects, and is another reason to use udev on tmpfs. (My dumb little script to populate /dev from /sys is attached. I have a version of this ported to C and a quick and dirty spec for a config file format for it that Solar and I worked out in IRC one evening, but it's 1.2 material.) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. -------------- next part -------------- A non-text attachment was scrubbed... Name: setupdev.sh Type: application/x-shellscript Size: 413 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051204/bc302e50/setupdev.bin From rob at landley.net Sun Dec 4 11:01:42 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 4 11:03:10 2005 Subject: The design of mdev (mini-udev for busybox). Message-ID: <200512041301.42740.rob@landley.net> By the way, for those of you curious, the basic idea behind mdev is to do a stripped down udev for busybox. My TODO entry about this reads: mdev Basic merge. Config file regex support username:group (string, not just uid:gid) zap cmp local_errno bb_xasprintf(); add dir/ add shellout syntaxes: symlink -> symlink dir/ (and dir| dir=) thing uid:gid 777 /dev/initctl - a named pipe? Is the "" escaping useful here? (Spaces?) And translating that for everybody else: I have some existing C code (a simple C port of the shell script posted last message). The "zap cmp, local_errno, bb_xasprintf()" bits are just about that code being busyboxified. There are two modes for mdev. One scans /sys and creates devices for everything it finds. (That'll be "mdev -s".) The second is called from hotplug and looks at the environment variables to see what new device just cropped up/went away, and adds or removes it. (That's mdev with no arguments.) Both need to wash its action through the config file. Why a config file? Because we have to specify ownership and permissions on newly created devices. The config file needs to be as sparse as possible and easy to parse with a small amount of code, but we do need one. A basic device entry looks like: devname uid:gid permissions So for example: tty3 0:0 600 It dumps everything in the same directory (no devfs-style loop/0 nonsense), and works based on the names the kernel gives stuff. The goal here is to be _simple_. It'll need some kind of regex support to allow a single rule to match tty[0-9]* or hd[a-z][0-9]*. For each device, rules are scanned top to bottom and we stop at the first hit, so you can specify a tty3 and then a default tty[0-9]*. This is the minimum we need. Anything beyond this should be a CONFIG_FEATURE. If we're feeling posh, we should look up UID:GID in /etc/passwd and /etc/group so we can use names rather than just numbers. That's probably a configurable feature. Since mdev will generally be run on an empty tmpfs (and may in fact mount tmpfs itself), we may also need to create a few directories (pts, shm) and named pipes (initctl) and such in there. The config file can specify these things (with ownership and permission) by appending the characters from "ls -F". For example: shm/ 0:0 1777 # Yes, setting the sticky bit needs to be supported. initctl| 0:0 600 And for symlinks, we use " -> " again just like ls does, so: cdrom -> hdc Non-device lines like these would only be matched on the initial scan (-s), not when looking for a description of a new device. And that's a second configurable feature: the user could also mount tmpfs from a shell script and do that setup before calling "mdev -s". It is nice to have it all together in one config file, though. In future we might also need a shellout syntax, and I suggest: hdc 0:24 660 $/etc/mdev/mkhdc.sh # create symlink, call dbus, etc. pts/ 0:0 755 $mount -t devpts /dev/pts /dev/pts It'll automatically inherit all those nifty environment variables. (We can synthesize one: MDEV_SYSFS which is the path to the sysfs entry we're servicing. That way the cold boot scanning case can cope.) Ordinarily we don't distinguish between char and block devices, but if a need to do this does crop up I suppose could always append @b or @c, so for example a catch-all rule for otherwise unspecified block devices could be: .*@b 0:0 600 Anyway, this is what I'm thinking about. Comments? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 4 11:08:52 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 4 11:09:18 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512041415.43580.farmatito@tiscali.it> References: <200512041415.43580.farmatito@tiscali.it> Message-ID: <200512041308.53084.rob@landley.net> On Sunday 04 December 2005 07:15, Tito wrote: > Hi to all, > I'm trying to compile the latest bb svn revision 12662, > but it seems to be broken. > The error message i get is: > root@localhost:/dev/pts/3:/root/Desktop/busybox# make > make -C /root/Desktop/busybox \ > top_srcdir=/root/Desktop/busybox \ > top_builddir=/root/Desktop/busybox \ > KBUILD_SRC=/root/Desktop/busybox \ > -f /root/Desktop/busybox/Makefile _all > make[1]: Entering directory `/root/Desktop/busybox' > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/bb_mkdep > /root/Desktop/busybox/scripts/bb_mkdep.c scripts/bb_mkdep -c > include/config.h -c include/bb_config.h \ > -I /root/Desktop/busybox/include /root/Desktop/busybox > > .depend.tmp mv .depend.tmp .depend > gcc -I/root/Desktop/busybox/include -I/root/Desktop/busybox/include > -I/root/Desktop/busybox/libbb -funsigned-char -Wall -Wstrict-prototypes > -Wshadow -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=0 > -falign-jumps=0 -falign-loops=0 -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG > -c -o /root/Desktop/busybox/applets/applets.o > /root/Desktop/busybox/applets/applets.c In file included from > /root/Desktop/busybox/applets/applets.c:48: > /root/Desktop/busybox/include/applets.h:677: error: 'tr_main' undeclared Line 677 is the middle of these three: #ifdef CONFIG_TR APPLET(tr, tr_main, _BB_DIR_USR_BIN, _BB_SUID_NEVER) #endif So that line shouldn't even be hit unless CONFIG_TR is set... > here (not in a function) /root/Desktop/busybox/include/applets.h:740: > error: 'watchdog_main' undeclared here (not in a function) make[1]: *** Same with CONFIG_WATCHDOG... > So far I've tried a fresh svn co svn://busybox.net/trunk/busybox > but nothing changed. > By looking at applets.h I couldn't see any obvious problem. Me neither. I'm building make allnoconfig, make allyesconfig, and make allbaseconfig. (Er, "allbareconfig". I get that wrong every time. But it built.) > Let me know if you need more info about .config or other stuff. Yes, please attach a copy of your .config. I have no _idea_ what's wrong... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From won_fang at yahoo.com.au Sun Dec 4 12:24:48 2005 From: won_fang at yahoo.com.au (David Seikel) Date: Sun Dec 4 12:31:43 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <200512041301.42740.rob@landley.net> References: <200512041301.42740.rob@landley.net> Message-ID: <20051205062448.76d7cb27@cluster.meeting.humbug.org.au> On Sun, 4 Dec 2005 13:01:42 -0600 Rob Landley wrote: > Anyway, this is what I'm thinking about. Comments? I would add one more thing, probably for the initial -s scan. Create empty directories and empty files - /path/to/directory/ 0:0 600 /path/to/file 0:0 600 Oh, and add ordinary links - /path/to/link -> /path/to/file Creating non existing directories as it goes. The initial / separates these from the device entries in the config file, and the trailing / separates directories from files. I have experimented with this sort of thing for My Linux, and found that it helped to keep the size of my initrd down. The extra code and config file used less bytes than actual directory entries on the ram disk. Actually, I went one step further, I added the contents of short text files with \n and \t expansion to the config file. Don't know if that should be included though, as it makes parsing the config file harder. Default owner, group, and permissions helped keep the config file size down to. I suspect this will not add much to mdev, as you have most of the needed code already. -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051205/e56aa944/attachment.pgp From solar at gentoo.org Sun Dec 4 12:29:04 2005 From: solar at gentoo.org (Ned Ludd) Date: Sun Dec 4 12:37:41 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <200512041301.42740.rob@landley.net> References: <200512041301.42740.rob@landley.net> Message-ID: <1133728144.16817.113.camel@localhost> On Sun, 2005-12-04 at 13:01 -0600, Rob Landley wrote: > By the way, for those of you curious, the basic idea behind mdev is to do a > stripped down udev for busybox. My TODO entry about this reads: > > mdev > Basic merge. > Config file > regex support > username:group (string, not just uid:gid) > zap cmp > local_errno > bb_xasprintf(); > add dir/ > add shellout > syntaxes: > symlink -> symlink > dir/ (and dir| dir=) > thing uid:gid 777 > /dev/initctl - a named pipe? > Is the "" escaping useful here? (Spaces?) > > And translating that for everybody else: > > I have some existing C code (a simple C port of the shell script posted last > message). The "zap cmp, local_errno, bb_xasprintf()" bits are just about > that code being busyboxified. > > There are two modes for mdev. One scans /sys and creates devices for > everything it finds. (That'll be "mdev -s".) The second is called from > hotplug and looks at the environment variables to see what new device just > cropped up/went away, and adds or removes it. (That's mdev with no > arguments.) Both need to wash its action through the config file. > > Why a config file? Because we have to specify ownership and permissions on > newly created devices. The config file needs to be as sparse as possible and > easy to parse with a small amount of code, but we do need one. > > A basic device entry looks like: > devname uid:gid permissions > > So for example: > tty3 0:0 600 > > It dumps everything in the same directory (no devfs-style loop/0 nonsense), > and works based on the names the kernel gives stuff. The goal here is to be > _simple_. It'll need some kind of regex support to allow a single rule to > match tty[0-9]* or hd[a-z][0-9]*. For each device, rules are scanned top to > bottom and we stop at the first hit, so you can specify a tty3 and then a > default tty[0-9]*. > > This is the minimum we need. Anything beyond this should be a CONFIG_FEATURE. > > If we're feeling posh, we should look up UID:GID in /etc/passwd and /etc/group > so we can use names rather than just numbers. That's probably a configurable > feature. > > Since mdev will generally be run on an empty tmpfs (and may in fact mount > tmpfs itself), we may also need to create a few directories (pts, shm) and > named pipes (initctl) and such in there. The config file can specify these > things (with ownership and permission) by appending the characters from "ls > -F". For example: > > shm/ 0:0 1777 # Yes, setting the sticky bit needs to be supported. > initctl| 0:0 600 > > And for symlinks, we use " -> " again just like ls does, so: > cdrom -> hdc > > Non-device lines like these would only be matched on the initial scan (-s), > not when looking for a description of a new device. And that's a second > configurable feature: the user could also mount tmpfs from a shell script and > do that setup before calling "mdev -s". It is nice to have it all together > in one config file, though. > > In future we might also need a shellout syntax, and I suggest: > > hdc 0:24 660 $/etc/mdev/mkhdc.sh # create symlink, call dbus, etc. > pts/ 0:0 755 $mount -t devpts /dev/pts /dev/pts > > It'll automatically inherit all those nifty environment variables. (We can > synthesize one: MDEV_SYSFS which is the path to the sysfs entry we're > servicing. That way the cold boot scanning case can cope.) > > Ordinarily we don't distinguish between char and block devices, but if a need > to do this does crop up I suppose could always append @b or @c, so for > example a catch-all rule for otherwise unspecified block devices could be: > .*@b 0:0 600 > > Anyway, this is what I'm thinking about. Comments? I think you just about covered the needs of what mdev should do and how it should function. But then you already know I'm a fan :) -- Ned Ludd Gentoo Linux From rob at landley.net Sun Dec 4 13:35:30 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 4 13:37:37 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <20051205062448.76d7cb27@cluster.meeting.humbug.org.au> References: <200512041301.42740.rob@landley.net> <20051205062448.76d7cb27@cluster.meeting.humbug.org.au> Message-ID: <200512041535.31005.rob@landley.net> On Sunday 04 December 2005 14:24, David Seikel wrote: > On Sun, 4 Dec 2005 13:01:42 -0600 Rob Landley wrote: > > Anyway, this is what I'm thinking about. Comments? > > I would add one more thing, probably for the initial -s scan. Create > empty directories and empty files - > > /path/to/directory/ 0:0 600 > /path/to/file 0:0 600 A) When we don't specify the type, we assume it's a device, not a file. Files would have to be tagged just like any other device type. B) The paths are assumed to be relative to the dev directory. (Which doesn't _have_ to be /dev, presumably you can run it from initramfs on /mnt/dev before doing a switch_root into /mnt.) For both of these, what's your proposed use case? (What empty files or directories outside of /dev would you want to create?) Keep in mind that there is such a thing as an init script. Even if mdev is mounting tmpfs on /tmp, you can still have the init script do stuff afterwards. I'm not trying to get this sucker to replace init scripts, I'm only thinking of adding the ability to create directories and such to make it so all the /dev configuration is in one place. I'm not 100% certain it's worth it, and it would _definititely_ be a compile-time option to _not_ add that bloat. > Oh, and add ordinary links - > > /path/to/link -> /path/to/file Again, the absolute paths are for...? The catchall is shellout capability. Right after this device is created, run this script. (If you want to get picky you can create it with permissions 000, and then rename it before doing a chmod to something people can use.) > Creating non existing directories as it goes. The initial / separates > these from the device entries in the config file, A) Suddenly the config file has to know whether you're operating on /dev or on /mnt/dev, which I was trying to avoid. B) Why should an absolute path indicate the _type_ of the file? (When this is otherwise indicated by a _trailing_ character that would not ordinarily occur in a file?) I glossed over "quoting and escaping" ye olde filename. Not sure it's worth it. Leaning towards "not", actually... > and the trailing / separates directories from files. That was already in the initial design. > I have experimented with this sort of thing for My Linux, and found > that it helped to keep the size of my initrd down. The extra code and > config file used less bytes than actual directory entries on the ram > disk. Ram disk or initramfs? This is for initramfs, where the directory entries are in a gzipped cpio archive, which is fairly efficient. > Actually, I went one step further, I added the contents of short > text files with \n and \t expansion to the config file. Don't know if > that should be included though, as it makes parsing the config file > harder. I'm not worried about parsing difficulty so much as "not going there" because there is such a thing as an init script. This isn't replacing that. "mkdir -p" is a perfectly acceptable way of scripting directory creation... > Default owner, group, and permissions helped keep the config file size > down to. Yeah, hence the ".* 0:0 600" entry at the end of the file. I suppose I could hardwire in a default if nothing matches... > I suspect this will not add much to mdev, as you have most of the > needed code already. I'm not convinced it's an improvement over having an init script. Keep in mind I'm redoing bbsh to be actually useful during 1.2 as well. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From farmatito at tiscali.it Sun Dec 4 13:55:13 2005 From: farmatito at tiscali.it (Tito) Date: Sun Dec 4 13:56:49 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512041308.53084.rob@landley.net> References: <200512041415.43580.farmatito@tiscali.it> <200512041308.53084.rob@landley.net> Message-ID: <200512042255.13142.farmatito@tiscali.it> On Sunday 04 December 2005 20:08, Rob Landley wrote: > On Sunday 04 December 2005 07:15, Tito wrote: snip > > /root/Desktop/busybox/applets/applets.c In file included from > > /root/Desktop/busybox/applets/applets.c:48: > > /root/Desktop/busybox/include/applets.h:677: error: 'tr_main' undeclared snip > Me neither. I'm building make allnoconfig, make allyesconfig, and make > allbaseconfig. (Er, "allbareconfig". I get that wrong every time. But it > built.) > > > Let me know if you need more info about .config or other stuff. > > Yes, please attach a copy of your .config. I have no _idea_ what's wrong... Here is it. This thing is driving me mad!!! Ciao, Tito > Rob -------------- next part -------------- # # Automatically generated make config: don't edit # HAVE_DOT_CONFIG=y # # General Configuration # CONFIG_FEATURE_BUFFERS_USE_MALLOC=y # CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set # CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set # CONFIG_FEATURE_VERBOSE_USAGE is not set # CONFIG_FEATURE_INSTALLER is not set # CONFIG_LOCALE_SUPPORT is not set # CONFIG_FEATURE_DEVFS is not set # CONFIG_FEATURE_DEVPTS is not set # CONFIG_FEATURE_CLEAN_UP is not set # CONFIG_FEATURE_SUID is not set # CONFIG_FEATURE_SUID_CONFIG is not set # CONFIG_FEATURE_SUID_CONFIG_QUIET is not set # CONFIG_SELINUX is not set # # Build Options # # CONFIG_STATIC is not set # CONFIG_LFS is not set # USING_CROSS_COMPILER is not set CROSS_COMPILER_PREFIX="" EXTRA_CFLAGS_OPTIONS="" # # Installation Options # # CONFIG_INSTALL_NO_USR is not set PREFIX="./_install" # # Archival Utilities # # CONFIG_AR is not set # CONFIG_FEATURE_AR_LONG_FILENAMES is not set # CONFIG_BUNZIP2 is not set # CONFIG_CPIO is not set # CONFIG_DPKG is not set # CONFIG_DPKG_DEB is not set # CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set # CONFIG_GUNZIP is not set # CONFIG_FEATURE_GUNZIP_UNCOMPRESS is not set # CONFIG_GZIP is not set # CONFIG_RPM2CPIO is not set # CONFIG_RPM is not set # CONFIG_TAR is not set # CONFIG_FEATURE_TAR_CREATE is not set # CONFIG_FEATURE_TAR_BZIP2 is not set # CONFIG_FEATURE_TAR_FROM is not set # CONFIG_FEATURE_TAR_GZIP is not set # CONFIG_FEATURE_TAR_COMPRESS is not set # CONFIG_FEATURE_TAR_OLDGNU_COMPATABILITY is not set # CONFIG_FEATURE_TAR_GNU_EXTENSIONS is not set # CONFIG_FEATURE_TAR_LONG_OPTIONS is not set # CONFIG_UNCOMPRESS is not set # CONFIG_UNZIP is not set # CONFIG_FEATURE_UNARCHIVE_TAPE is not set # CONFIG_FEATURE_DEB_TAR_GZ is not set # CONFIG_FEATURE_DEB_TAR_BZ2 is not set # # Coreutils # # CONFIG_BASENAME is not set # CONFIG_CAL is not set # CONFIG_CAT is not set # CONFIG_CHGRP is not set # CONFIG_CHMOD is not set # CONFIG_CHOWN is not set # CONFIG_CHROOT is not set # CONFIG_CMP is not set # CONFIG_COMM is not set # CONFIG_CP is not set # CONFIG_CUT is not set # CONFIG_DATE is not set # CONFIG_FEATURE_DATE_ISOFMT is not set # CONFIG_DD is not set # CONFIG_DF is not set # CONFIG_DIRNAME is not set # CONFIG_DOS2UNIX is not set # CONFIG_UNIX2DOS is not set # CONFIG_DU is not set # CONFIG_FEATURE_DU_DEFALT_BLOCKSIZE_1K is not set # CONFIG_ECHO is not set # CONFIG_FEATURE_FANCY_ECHO is not set # CONFIG_ENV is not set # CONFIG_EXPR is not set # CONFIG_FALSE is not set # CONFIG_FOLD is not set # CONFIG_HEAD is not set # CONFIG_FEATURE_FANCY_HEAD is not set # CONFIG_HOSTID is not set # CONFIG_ID is not set # CONFIG_INSTALL is not set # CONFIG_LENGTH is not set # CONFIG_LN is not set # CONFIG_LOGNAME is not set # CONFIG_LS is not set # CONFIG_FEATURE_LS_FILETYPES is not set # CONFIG_FEATURE_LS_FOLLOWLINKS is not set # CONFIG_FEATURE_LS_RECURSIVE is not set # CONFIG_FEATURE_LS_SORTFILES is not set # CONFIG_FEATURE_LS_TIMESTAMPS is not set # CONFIG_FEATURE_LS_USERNAME is not set # CONFIG_FEATURE_LS_COLOR is not set # CONFIG_FEATURE_LS_COLOR_IS_DEFAULT is not set # CONFIG_MD5SUM is not set # CONFIG_MKDIR is not set # CONFIG_MKFIFO is not set # CONFIG_MKNOD is not set # CONFIG_MV is not set # CONFIG_NICE is not set # CONFIG_NOHUP is not set # CONFIG_OD is not set # CONFIG_PRINTENV is not set # CONFIG_PRINTF is not set # CONFIG_PWD is not set # CONFIG_REALPATH is not set # CONFIG_RM is not set # CONFIG_RMDIR is not set # CONFIG_SEQ is not set # CONFIG_SHA1SUM is not set # CONFIG_SLEEP is not set # CONFIG_FEATURE_FANCY_SLEEP is not set # CONFIG_SORT is not set # CONFIG_FEATURE_SORT_BIG is not set # CONFIG_STAT is not set # CONFIG_FEATURE_STAT_FORMAT is not set # CONFIG_STTY is not set # CONFIG_SUM is not set # CONFIG_SYNC is not set # CONFIG_TAIL is not set # CONFIG_FEATURE_FANCY_TAIL is not set # CONFIG_TEE is not set # CONFIG_FEATURE_TEE_USE_BLOCK_IO is not set # CONFIG_TEST is not set # CONFIG_FEATURE_TEST_64 is not set # CONFIG_TOUCH is not set # CONFIG_TR is not set # CONFIG_FEATURE_TR_CLASSES is not set # CONFIG_FEATURE_TR_EQUIV is not set # CONFIG_TRUE is not set # CONFIG_TTY is not set # CONFIG_UNAME is not set # CONFIG_UNIQ is not set # CONFIG_USLEEP is not set # CONFIG_UUDECODE is not set # CONFIG_UUENCODE is not set # CONFIG_WATCH is not set # CONFIG_WC is not set # CONFIG_WHO is not set # CONFIG_WHOAMI is not set # CONFIG_YES is not set # CONFIG_FEATURE_PRESERVE_HARDLINKS is not set # CONFIG_FEATURE_AUTOWIDTH is not set # CONFIG_FEATURE_HUMAN_READABLE is not set # CONFIG_FEATURE_MD5_SHA1_SUM_CHECK is not set # # Console Utilities # # CONFIG_CHVT is not set # CONFIG_CLEAR is not set # CONFIG_DEALLOCVT is not set # CONFIG_DUMPKMAP is not set # CONFIG_LOADFONT is not set # CONFIG_LOADKMAP is not set # CONFIG_OPENVT is not set # CONFIG_RESET is not set # CONFIG_SETCONSOLE is not set # CONFIG_SETKEYCODES is not set # # Debian Utilities # CONFIG_MKTEMP=y # CONFIG_PIPE_PROGRESS is not set # CONFIG_READLINK is not set # CONFIG_FEATURE_READLINK_FOLLOW is not set # CONFIG_RUN_PARTS is not set # CONFIG_START_STOP_DAEMON is not set # CONFIG_WHICH is not set # # Linux Ext2 FS Progs # # CONFIG_CHATTR is not set # CONFIG_E2FSCK is not set # CONFIG_FSCK is not set # CONFIG_LSATTR is not set # CONFIG_MKE2FS is not set # CONFIG_TUNE2FS is not set # CONFIG_E2LABEL is not set # CONFIG_FINDFS is not set # # Editors # # CONFIG_AWK is not set # CONFIG_FEATURE_AWK_MATH is not set # CONFIG_PATCH is not set # CONFIG_SED is not set # CONFIG_VI is not set # CONFIG_FEATURE_VI_COLON is not set # CONFIG_FEATURE_VI_YANKMARK is not set # CONFIG_FEATURE_VI_SEARCH is not set # CONFIG_FEATURE_VI_USE_SIGNALS is not set # CONFIG_FEATURE_VI_DOT_CMD is not set # CONFIG_FEATURE_VI_READONLY is not set # CONFIG_FEATURE_VI_SETOPTS is not set # CONFIG_FEATURE_VI_SET is not set # CONFIG_FEATURE_VI_WIN_RESIZE is not set # CONFIG_FEATURE_VI_OPTIMIZE_CURSOR is not set # # Finding Utilities # # CONFIG_FIND is not set # CONFIG_FEATURE_FIND_MTIME is not set # CONFIG_FEATURE_FIND_PERM is not set # CONFIG_FEATURE_FIND_TYPE is not set # CONFIG_FEATURE_FIND_XDEV is not set # CONFIG_FEATURE_FIND_NEWER is not set # CONFIG_FEATURE_FIND_INUM is not set # CONFIG_FEATURE_FIND_EXEC is not set # CONFIG_GREP is not set # CONFIG_FEATURE_GREP_EGREP_ALIAS is not set # CONFIG_FEATURE_GREP_FGREP_ALIAS is not set # CONFIG_FEATURE_GREP_CONTEXT is not set # CONFIG_XARGS is not set # CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION is not set # CONFIG_FEATURE_XARGS_SUPPORT_QUOTES is not set # CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT is not set # CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM is not set # # Init Utilities # # CONFIG_INIT is not set # CONFIG_FEATURE_USE_INITTAB is not set # CONFIG_FEATURE_INITRD is not set # CONFIG_FEATURE_INIT_COREDUMPS is not set # CONFIG_FEATURE_INIT_SCTTY is not set # CONFIG_FEATURE_EXTRA_QUIET is not set # CONFIG_HALT is not set # CONFIG_MESG is not set # CONFIG_POWEROFF is not set # CONFIG_REBOOT is not set # # Login/Password Management Utilities # # CONFIG_USE_BB_PWD_GRP is not set # CONFIG_ADDGROUP is not set # CONFIG_DELGROUP is not set # CONFIG_ADDUSER is not set # CONFIG_DELUSER is not set # CONFIG_GETTY is not set # CONFIG_FEATURE_UTMP is not set # CONFIG_FEATURE_WTMP is not set # CONFIG_LOGIN is not set # CONFIG_FEATURE_SECURETTY is not set # CONFIG_PASSWD is not set # CONFIG_SU is not set # CONFIG_SULOGIN is not set # CONFIG_VLOCK is not set # CONFIG_FEATURE_SHADOWPASSWDS is not set # CONFIG_USE_BB_SHADOW is not set # # Miscellaneous Utilities # # CONFIG_ADJTIMEX is not set # CONFIG_BBCONFIG is not set # CONFIG_CROND is not set # CONFIG_FEATURE_CROND_CALL_SENDMAIL is not set # CONFIG_CRONTAB is not set # CONFIG_DC is not set # CONFIG_DEVFSD is not set # CONFIG_DEVFSD_MODLOAD is not set # CONFIG_DEVFSD_FG_NP is not set # CONFIG_DEVFSD_VERBOSE is not set # CONFIG_EJECT is not set # CONFIG_LAST is not set # CONFIG_LESS is not set # CONFIG_FEATURE_LESS_BRACKETS is not set # CONFIG_FEATURE_LESS_FLAGS is not set # CONFIG_FEATURE_LESS_FLAGCS is not set # CONFIG_FEATURE_LESS_MARKS is not set # CONFIG_FEATURE_LESS_REGEXP is not set # CONFIG_HDPARM is not set # CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set # CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set # CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set # CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set # CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set # CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set # CONFIG_MAKEDEVS is not set # CONFIG_FEATURE_MAKEDEVS_LEAF is not set # CONFIG_FEATURE_MAKEDEVS_TABLE is not set # CONFIG_MOUNTPOINT is not set # CONFIG_MT is not set # BB_APPLET_RUNLEVEL is not set # CONFIG_RX is not set # CONFIG_STRINGS is not set # CONFIG_SETSID is not set # CONFIG_TIME is not set # CONFIG_WATCHDOG is not set # # Linux Module Utilities # # CONFIG_INSMOD is not set # CONFIG_FEATURE_2_4_MODULES is not set # CONFIG_FEATURE_2_6_MODULES is not set # CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set # CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS is not set # CONFIG_FEATURE_INSMOD_LOADINKMEM is not set # CONFIG_FEATURE_INSMOD_LOAD_MAP is not set # CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set # CONFIG_LSMOD is not set # CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT is not set # CONFIG_FEATURE_QUERY_MODULE_INTERFACE is not set # CONFIG_MODPROBE is not set # CONFIG_MODPROBE_MULTIPLE_OPTIONS is not set # CONFIG_RMMOD is not set # CONFIG_FEATURE_CHECK_TAINTED_MODULE is not set # # Networking Utilities # # CONFIG_FEATURE_IPV6 is not set # CONFIG_ARPING is not set # CONFIG_ETHER_WAKE is not set # CONFIG_FAKEIDENTD is not set # CONFIG_FTPGET is not set # CONFIG_FTPPUT is not set # CONFIG_HOSTNAME is not set # CONFIG_HTTPD is not set # CONFIG_FEATURE_HTTPD_USAGE_FROM_INETD_ONLY is not set # CONFIG_FEATURE_HTTPD_BASIC_AUTH is not set # CONFIG_FEATURE_HTTPD_AUTH_MD5 is not set # CONFIG_FEATURE_HTTPD_RELOAD_CONFIG_SIGHUP is not set # CONFIG_FEATURE_HTTPD_SETUID is not set # CONFIG_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES is not set # CONFIG_FEATURE_HTTPD_CGI is not set # CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV is not set # CONFIG_FEATURE_HTTPD_ENCODE_URL_STR is not set # CONFIG_IFCONFIG is not set # CONFIG_FEATURE_IFCONFIG_STATUS is not set # CONFIG_FEATURE_IFCONFIG_SLIP is not set # CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ is not set # CONFIG_FEATURE_IFCONFIG_HW is not set # CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS is not set # CONFIG_IFUPDOWN is not set # CONFIG_FEATURE_IFUPDOWN_IP is not set # CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN is not set # CONFIG_FEATURE_IFUPDOWN_IPV4 is not set # CONFIG_FEATURE_IFUPDOWN_IPV6 is not set # CONFIG_FEATURE_IFUPDOWN_IPX is not set # CONFIG_FEATURE_IFUPDOWN_MAPPING is not set # CONFIG_INETD is not set # CONFIG_FEATURE_INETD_SUPPORT_BILTIN_ECHO is not set # CONFIG_FEATURE_INETD_SUPPORT_BILTIN_DISCARD is not set # CONFIG_FEATURE_INETD_SUPPORT_BILTIN_TIME is not set # CONFIG_FEATURE_INETD_SUPPORT_BILTIN_DAYTIME is not set # CONFIG_FEATURE_INETD_SUPPORT_BILTIN_CHARGEN is not set # CONFIG_FEATURE_INETD_RPC is not set # CONFIG_IP is not set # CONFIG_FEATURE_IP_ADDRESS is not set # CONFIG_FEATURE_IP_LINK is not set # CONFIG_FEATURE_IP_ROUTE is not set # CONFIG_FEATURE_IP_TUNNEL is not set # CONFIG_IPCALC is not set # CONFIG_FEATURE_IPCALC_FANCY is not set # CONFIG_IPADDR is not set # CONFIG_IPLINK is not set # CONFIG_IPROUTE is not set # CONFIG_IPTUNNEL is not set # CONFIG_NAMEIF is not set # CONFIG_NC is not set # CONFIG_NC_GAPING_SECURITY_HOLE is not set # CONFIG_NETSTAT is not set # CONFIG_NSLOOKUP is not set # CONFIG_PING is not set # CONFIG_FEATURE_FANCY_PING is not set # CONFIG_PING6 is not set # CONFIG_FEATURE_FANCY_PING6 is not set # CONFIG_ROUTE is not set # CONFIG_TELNET is not set # CONFIG_FEATURE_TELNET_TTYPE is not set # CONFIG_FEATURE_TELNET_AUTOLOGIN is not set # CONFIG_TELNETD is not set # CONFIG_FEATURE_TELNETD_INETD is not set # CONFIG_TFTP is not set # CONFIG_FEATURE_TFTP_GET is not set # CONFIG_FEATURE_TFTP_PUT is not set # CONFIG_FEATURE_TFTP_BLOCKSIZE is not set # CONFIG_FEATURE_TFTP_DEBUG is not set # CONFIG_TRACEROUTE is not set # CONFIG_FEATURE_TRACEROUTE_VERBOSE is not set # CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE is not set # CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set # CONFIG_VCONFIG is not set # CONFIG_WGET is not set # CONFIG_FEATURE_WGET_STATUSBAR is not set # CONFIG_FEATURE_WGET_AUTHENTICATION is not set # CONFIG_FEATURE_WGET_IP6_LITERAL is not set # # udhcp Server/Client # # CONFIG_UDHCPD is not set # CONFIG_UDHCPC is not set # CONFIG_DUMPLEASES is not set # CONFIG_FEATURE_UDHCP_SYSLOG is not set # CONFIG_FEATURE_UDHCP_DEBUG is not set # CONFIG_ZCIP is not set # # Process Utilities # # CONFIG_FREE is not set # CONFIG_FUSER is not set # CONFIG_KILL is not set # CONFIG_KILLALL is not set # CONFIG_PIDOF is not set # CONFIG_FEATURE_PIDOF_SINGLE is not set # CONFIG_FEATURE_PIDOF_OMIT is not set # CONFIG_PS is not set # CONFIG_FEATURE_PS_WIDE is not set # CONFIG_RENICE is not set # CONFIG_BB_SYSCTL is not set # CONFIG_TOP is not set # CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE is not set # CONFIG_UPTIME is not set # # Shells # # CONFIG_FEATURE_SH_IS_ASH is not set # CONFIG_FEATURE_SH_IS_HUSH is not set # CONFIG_FEATURE_SH_IS_LASH is not set # CONFIG_FEATURE_SH_IS_MSH is not set CONFIG_FEATURE_SH_IS_NONE=y # CONFIG_ASH is not set # CONFIG_ASH_JOB_CONTROL is not set # CONFIG_ASH_READ_NCHARS is not set # CONFIG_ASH_READ_TIMEOUT is not set # CONFIG_ASH_ALIAS is not set # CONFIG_ASH_MATH_SUPPORT is not set # CONFIG_ASH_MATH_SUPPORT_64 is not set # CONFIG_ASH_GETOPTS is not set # CONFIG_ASH_CMDCMD is not set # CONFIG_ASH_BUILTIN_ECHO is not set # CONFIG_ASH_MAIL is not set # CONFIG_ASH_OPTIMIZE_FOR_SIZE is not set # CONFIG_ASH_RANDOM_SUPPORT is not set # CONFIG_ASH_EXPAND_PRMT is not set # CONFIG_HUSH is not set # CONFIG_LASH is not set # CONFIG_MSH is not set # CONFIG_FEATURE_SH_EXTRA_QUIET is not set # CONFIG_FEATURE_SH_STANDALONE_SHELL is not set # CONFIG_FEATURE_COMMAND_EDITING is not set # CONFIG_FEATURE_COMMAND_EDITING_VI is not set CONFIG_FEATURE_COMMAND_HISTORY=0 # CONFIG_FEATURE_COMMAND_SAVEHISTORY is not set # CONFIG_FEATURE_COMMAND_TAB_COMPLETION is not set # CONFIG_FEATURE_COMMAND_USERNAME_COMPLETION is not set # CONFIG_FEATURE_SH_FANCY_PROMPT is not set # # System Logging Utilities # # CONFIG_SYSLOGD is not set # CONFIG_FEATURE_ROTATE_LOGFILE is not set # CONFIG_FEATURE_REMOTE_LOG is not set # CONFIG_FEATURE_IPC_SYSLOG is not set CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0 # CONFIG_LOGREAD is not set # CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set # CONFIG_KLOGD is not set # CONFIG_LOGGER is not set # # Linux System Utilities # # CONFIG_DMESG is not set # CONFIG_FBSET is not set # CONFIG_FEATURE_FBSET_FANCY is not set # CONFIG_FEATURE_FBSET_READMODE is not set # CONFIG_FDFLUSH is not set # CONFIG_FDFORMAT is not set # CONFIG_FDISK is not set # FDISK_SUPPORT_LARGE_DISKS is not set # CONFIG_FEATURE_FDISK_WRITABLE is not set # CONFIG_FEATURE_AIX_LABEL is not set # CONFIG_FEATURE_SGI_LABEL is not set # CONFIG_FEATURE_SUN_LABEL is not set # CONFIG_FEATURE_OSF_LABEL is not set # CONFIG_FEATURE_FDISK_ADVANCED is not set # CONFIG_FREERAMDISK is not set # CONFIG_FSCK_MINIX is not set # CONFIG_MKFS_MINIX is not set # CONFIG_FEATURE_MINIX2 is not set # CONFIG_GETOPT is not set # CONFIG_HEXDUMP is not set # CONFIG_HWCLOCK is not set # CONFIG_FEATURE_HWCLOCK_LONGOPTIONS is not set # CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS is not set # CONFIG_IPCRM is not set # CONFIG_IPCS is not set # CONFIG_LOSETUP is not set # CONFIG_MKSWAP is not set # CONFIG_MORE is not set # CONFIG_FEATURE_USE_TERMIOS is not set # CONFIG_PIVOT_ROOT is not set # CONFIG_SWITCH_ROOT is not set # CONFIG_RDATE is not set # CONFIG_READPROFILE is not set # CONFIG_SWAPONOFF is not set # CONFIG_MOUNT is not set # CONFIG_FEATURE_MOUNT_NFS is not set # CONFIG_UMOUNT is not set # CONFIG_FEATURE_MOUNT_LOOP is not set # CONFIG_FEATURE_MTAB_SUPPORT is not set # # Debugging Options # # CONFIG_DEBUG is not set # CONFIG_NO_DEBUG_LIB is not set # CONFIG_DMALLOC is not set # CONFIG_EFENCE is not set From won_fang at yahoo.com.au Sun Dec 4 14:14:41 2005 From: won_fang at yahoo.com.au (David Seikel) Date: Sun Dec 4 14:13:34 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <200512041535.31005.rob@landley.net> References: <200512041301.42740.rob@landley.net> <20051205062448.76d7cb27@cluster.meeting.humbug.org.au> <200512041535.31005.rob@landley.net> Message-ID: <20051205081441.6486ec3f@cluster.meeting.humbug.org.au> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051205/b68c118f/attachment.pgp From yann.morin.1998 at anciens.enib.fr Sun Dec 4 14:27:37 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun Dec 4 14:26:49 2005 Subject: modutils update (modprobe and config) In-Reply-To: <200512041208.34097.rob@landley.net> References: <200511272319.43303.yann.morin.1998@anciens.enib.fr> <200512031525.06096.yann.morin.1998@anciens.enib.fr> <200512041208.34097.rob@landley.net> Message-ID: <200512042327.37303.yann.morin.1998@anciens.enib.fr> Hello Rob! All, On Sunday 04 December 2005 190, Rob Landley wrote: > > On Sunday 27 November 2005 231, Yann E. MORIN wrote: > > > Here am I with my modutils update. > I have it in my to-do list. :) OK! I hope you won't choke on all that work you're putting up together! :-) > I'm trying to get a firmware linux release out today, but I'll try to give it > a whack first thing tomorrow... I must definitely go and see what you're doin' wrt firmware linux. By the name it sounds appealing. Plus I might need something like this in a near future. 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 sreekant_kodela at yahoo.com Mon Dec 5 03:09:41 2005 From: sreekant_kodela at yahoo.com (sreekant kodela) Date: Mon Dec 5 03:11:41 2005 Subject: A set of scripts to make a live cd from your main setup. Message-ID: <20051205110941.1827.qmail@web32506.mail.mud.yahoo.com> Hi folks After trial/error, help from everyone and leaching/poaching code from everywhere I finally managed to make a set of scripts to automate the live cd creation from your main host linux. It works atlease for me. I am sure there are a million ways to improve it. Please have a look and advise. http://microdrive.sourceforge.net/ Thanks sreekant __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From sreekant_kodela at yahoo.com Mon Dec 5 07:11:13 2005 From: sreekant_kodela at yahoo.com (sreekant kodela) Date: Mon Dec 5 07:11:49 2005 Subject: A set of scripts to make a live cd from your main setup. In-Reply-To: <439436F9.1020403@bfs.de> Message-ID: <20051205151113.4838.qmail@web32512.mail.mud.yahoo.com> Hi Walter This set of scripts are to make more than a boot floppy. It is to allow searching for cd, mounting cd based links for a live system etc. Infact I only found out about qemu few days ago. Once installed, I tested my livecd many a times. Would have saved loads of time during development Doh : I am hoping to make this live cd making scripts to be easily modifiable and maintainable. The current version 0.1a is fully functional and makes a bootable/functional live cd. Ta sreekant -- walter harms wrote: > hi sreekant, > busybox has a script to create a bootfloppy. > maybe you like to use it to create your cd image ? > i was playing with that idea but never got forward > due to the lack of time. > > re, > walter > > > ps: are you aware of qemu ? > > sreekant kodela wrote: > > Hi folks > > > > After trial/error, help from everyone and > > leaching/poaching code from everywhere I finally > > managed to make a set of scripts to automate the > live > > cd creation from your main host linux. > > > > It works atlease for me. I am sure there are a > million > > ways to improve it. > > > > Please have a look and advise. > > > > http://microdrive.sourceforge.net/ > > > > Thanks > > sreekant > > > > > > > > __________________________________ > > Start your day with Yahoo! - Make it your home > page! > > http://www.yahoo.com/r/hs > > _______________________________________________ > > busybox mailing list > > busybox@busybox.net > > > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > > > > > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From rob at landley.net Sun Dec 4 16:02:24 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 08:01:43 2005 Subject: modutils update (modprobe and config) In-Reply-To: <200512042327.37303.yann.morin.1998@anciens.enib.fr> References: <200511272319.43303.yann.morin.1998@anciens.enib.fr> <200512041208.34097.rob@landley.net> <200512042327.37303.yann.morin.1998@anciens.enib.fr> Message-ID: <200512041802.24256.rob@landley.net> On Sunday 04 December 2005 16:27, Yann E. MORIN wrote: > Hello Rob! > All, > > On Sunday 04 December 2005 190, Rob Landley wrote: > > > On Sunday 27 November 2005 231, Yann E. MORIN wrote: > > > > Here am I with my modutils update. > > > > I have it in my to-do list. :) > > OK! I hope you won't choke on all that work you're putting up together! :-) As soon as I get firmware 0.9 out, I intend to get back to busybox. I'm on a plane thursday and I want a -pre2 candidate out before then. > > I'm trying to get a firmware linux release out today, but I'll try to > > give it a whack first thing tomorrow... > > I must definitely go and see what you're doin' wrt firmware linux. By the > name it sounds appealing. Plus I might need something like this in a near > future. There's a somewhat stale release linked from the web page. I refactored a lot of the code to make it easier to build an installer over the past couple of days, and have been trying to get everything to build again since. (Then I need to finish the installer.) Long night, I expect... > Regards, > Yann E. MORIN. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 4 17:40:23 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 08:01:55 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <20051205081441.6486ec3f@cluster.meeting.humbug.org.au> References: <200512041301.42740.rob@landley.net> <200512041535.31005.rob@landley.net> <20051205081441.6486ec3f@cluster.meeting.humbug.org.au> Message-ID: <200512041940.23951.rob@landley.net> On Sunday 04 December 2005 16:14, David Seikel wrote: > > For both of these, what's your proposed use case? (What empty files > > or directories outside of /dev would you want to create?) > > I have attached what I currently use in My Linux. I ask for a use case, you give me code. Rummage, rummage, rummage... Having looked about your code, I believe I can say with some authority that you really, truly, _deeply_ need to look into initramfs. You can have all that crud in the gzipped cpio archive built into the kernel image, and the kernel will extract it for you on boot. > It doesn't do udev or hotplug type stuff, but does create /dev entries. CONFIG_MAKEDEVS? > It is a busybox > module. I intend to turn this into a combined create things at boot / > create filesystem structure for installing thing. Yes, all things are > currently hard coded into the code. Sounds deeply uninteresting to me. What does this have to do with busybox? > > > Creating non existing directories as it goes. The initial / > > > separates these from the device entries in the config file, > > > > A) Suddenly the config file has to know whether you're operating > > on /dev or on /mnt/dev, which I was trying to avoid. > > /mnt/dev? > > I'm not sure exactly how mdev was going to work, but for instance > cd'ing to /dev first, then create what's in the config file, relative > paths will automatically end up relative to /dev, and absolute paths > will automatically end up absolute. Sure. That's a side effect I don't see a major downside of leaving alone. But why are absolute paths interesting? > With that sort of arrangement, > there is no having to know where you are operating, and no having to > interpret the beginning of the name. I wasn't planning on having the code care. This config file belongs to root: the user does something stupid they get to keep the pieces. > > > I have experimented with this sort of thing for My Linux, and found > > > that it helped to keep the size of my initrd down. The extra code > > > and config file used less bytes than actual directory entries on > > > the ram disk. > > > > Ram disk or initramfs? This is for initramfs, where the directory > > entries are in a gzipped cpio archive, which is fairly efficient. > > Ramdisk. As I said, my experiments with the attached code showed that > it was worth it. This is still sounding totally unrelated to mdev. Sounds like you want to use or extend makedevs. Or use initramfs. > > I'm not convinced it's an improvement over having an init script. > > It's a case of every byte counts, and if you don't add it to mdev, I'll > just be replicating a portion of the mdev code in my mkrootfs.c. My deep and abiding lack of caring truly cannot be expressed in words. You're already talking about something hardwired, and I'm talking about efficient generic infrastructure. The only reason _I_ care about putting anything other than device nodes into /dev is that the tmpfs mount means it starts empty, so something has to populate it and it traditionally has a couple of subdirectories in there that we might as well handle. > I just saw a chance to condense very similar code into one. Since mdev > will likely already have the great majority of the code needed to do > what I want, I don't see the point of reinventing the wheel when only > a very small extension of what you are doing will do the job. It's possible that what I'm doing will be useful to you. I hope so. Creating files, however, is something mdev is highly unlikely to do (except via shellout) because there's no sane way to specify the contents. I'd suggest getting initramfs to populate a subdirectory with your stuff and then either living in initramfs or doing a cp -r to the final root. > > Keep in mind I'm redoing bbsh to be actually useful during 1.2 as > > well. > > That I am eagerly looking forward to. Should help to reduce my own > code a bit to. Won't be until after New Year's. I'm hoping to get my firmware 0.9 release out tonight (caffeine will be involved) and attack the web bug list tomorrow to put together a -pre2 for wednesday. Plans and what actually happens aren't always on speaking terms around here, of course... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 5 08:42:20 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 08:46:09 2005 Subject: A set of scripts to make a live cd from your main setup. In-Reply-To: <20051205151113.4838.qmail@web32512.mail.mud.yahoo.com> References: <20051205151113.4838.qmail@web32512.mail.mud.yahoo.com> Message-ID: <200512051042.20341.rob@landley.net> On Monday 05 December 2005 09:11, sreekant kodela wrote: > Hi Walter > > This set of scripts are to make more than a boot > floppy. It is to allow searching for cd, mounting cd > based links for a live system etc. Is this dynamic (based on /sys) or static nodes? > Infact I only found out about qemu few days ago. Once > installed, I tested my livecd many a times. Would have > saved loads of time during development Doh : qemu is highly cool, isn't it? I have a script that makes a partitioned hard drive image you can boot with qemu. It'll be in the next release of Firmware Linux (which was _supposed_ to be yesterday, and should be later today...) http://www.landley.net/code/firmware The last bootable CD I made was based off a 2.88 floppy image, but the next one should be based off of the hard drive image... > I am hoping to make this live cd making scripts to be > easily modifiable and maintainable. Yay rah cool. Boot floppies are obsolete, boot cd's are the new way of doing this. > The current version 0.1a is fully functional and makes > a bootable/functional live cd. > > Ta > sreekant > > -- walter harms wrote: > > hi sreekant, > > busybox has a script to create a bootfloppy. We have a script to create a boot floppy? Where? Ah, examples/bootfloppy. Never saw that before. Cool... I'm focusing on getting FWL 0.9 out today, and then jumping on the 1.1-pre2 buglist, but at the very least we can link to your page from the FAQ (once I get a chance to play with it). Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rory.vieira at coolview.nl Mon Dec 5 09:32:52 2005 From: rory.vieira at coolview.nl (Rory Vieira) Date: Mon Dec 5 09:33:21 2005 Subject: "job control turned off" faq incomplete? In-Reply-To: <200512041213.02709.rob@landley.net> Message-ID: <00d701c5f9c1$ec0126f0$0b01a8c0@pluto> Rob, > > I noticed that as long as my rootfs is readonly I got the > message. So > > the top two lines in my inittab were > > 1. Mount /proc > > 2. Remount root readwrite... > > > Lemme guess: /dev is on your read-only root filesystem, thus > tty0 is read > only, so it can't do things like chown it to belong to > whoever just logged > in? Exactly :) > That can have funky side effects, and is another reason to > use udev on tmpfs. > (My dumb little script to populate /dev from /sys is > attached. I have a > version of this ported to C and a quick and dirty spec for a > config file > format for it that Solar and I worked out in IRC one evening, > but it's 1.2 material.) The script looks great. But doesn't this mean we need to mount /sys first?!? Cheers, Rory From pgf at brightstareng.com Mon Dec 5 09:50:12 2005 From: pgf at brightstareng.com (Paul Fox) Date: Mon Dec 5 09:50:34 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: rob's message of Sun, 04 Dec 2005 19:40:23 -0600. <200512041940.23951.rob@landley.net> Message-ID: <28445.1133805012@brightstareng.com> > Rummage, rummage, rummage... > > Having looked about your code, I believe I can say with some authority that > you really, truly, _deeply_ need to look into initramfs. You can have all > that crud in the gzipped cpio archive built into the kernel image, and the > kernel will extract it for you on boot. can someone tell me why cpio was chosen for this? wouldn't tar be just as useful, and lower cost in "oh-no-not-another-required-tool" terms? we're using the excellent inittar patches from: http://www.escape.de/users/outback/linux/index_en.html for this purpose. (and we have 2.6 patches if anyone's interested.) having no more need for creating an initrd is nice at build time (no need to be root), and at runtime: instead of setting up an initrd, and then needing tmpfs in addition, the tarball goes right into tmpfs, which gets mounted directly as root. i realize initramfs solves a slightly different problem than this, but i'm baffled by the cpio choice. paul =--------------------- paul fox, pgf@brightstareng.com From rory.vieira at coolview.nl Mon Dec 5 09:41:32 2005 From: rory.vieira at coolview.nl (Rory Vieira) Date: Mon Dec 5 10:02:54 2005 Subject: BusyBox/inittab weirdness Message-ID: <00d801c5f9c3$21c7fa60$0b01a8c0@pluto> Hi, I stumbled on this without even knowing it... I compiled BusyBox with almost all options enabled (including init). It also includes 'standalone shell'... Now my inittab start off like: ------------------------------- ::sysinit:echo "Starting up Linux `uname -r`..." null::sysinit:/bin/mount -n -t proc proc /proc null::sysinit:/bin/mount -n -o remount,rw /dev/root / null::sysinit:/bin/busybox --install -s ------------------------------- Now my rootfs is extremely empty. It only includes busybox, inittab, fstab and rcS... What I don't understand it this: The first line shows 'echo' and 'uname' without a path specification. The second line though is '/bin/mount'! Obviously I needed to make the 'mount', 'sh', and 'init' links beforehand. Why do I need to do this for mount etc, but not with echo or uname? I can understand the echo (builtin), but not the uname. If I change the second line to just 'mount...' it claims it can find mount at all... I'm very confused here... Hope someone has a clear answer for this one... Cheers, Rory Vieira From ihno at suse.de Mon Dec 5 10:16:51 2005 From: ihno at suse.de (Ihno Krumreich) Date: Mon Dec 5 10:19:05 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200511300748.12503.jzb@aexorsyst.com> References: <200511291632.05325.rob@landley.net> <200511292029.33680.jzb@aexorsyst.com> <20051130092537.GA1011@wotan.suse.de> <200511300748.12503.jzb@aexorsyst.com> Message-ID: <20051205181651.GB3821@wotan.suse.de> hi, attached is a patch to remove some of signed warnings. The code was compiled with a gcc 4.1.0. Regards Ihno On Wed, Nov 30, 2005 at 07:48:12AM -0800, John Z. Bohach wrote: > On Wednesday 30 November 2005 01:25, Ihno Krumreich wrote: > > On Tue, Nov 29, 2005 at 08:29:33PM -0800, John Z. Bohach wrote: > > > > I agree. Be very careful about eliminating warnings. Signed vs. > > > unsigned generates machine code with/without sign extensions, and thus > > > generates very different code. You can run into situations where -1 is > > > greater than 127 if a signed/unsigned char comparison isn't right. To > > > make things more more fun, not all compilers treat signed/usigned > > > promotions the same in C, and whether that's a compiler bug or > > > implementation-dependent feature of C, I forget...what I do remember is > > > the hideous runtime debug of such machine code on the rare occasion that > > > it matters...anyways, I digress. Just be careful. Couldn't such code be > > > fixed to actually use casts to eliminate the warnings? > > > > If you fix it _never_ use casts! There are _very_ rare cases where a cast > > is really needed to avoid these massages. In all other cases you are just > > hiding the possible bugs (especially if the compiler changes behaviour or > > the code is compiled by a new compiler). > > I am not aware how a single cast can introduce bugs. There are predefined > promotion rules in the C standard that control what happens when two items of > differing types are used in the same statement, and those promotion rules are > implicit, but they happen anyway. Now I've seen bugs etc. when relying on > implicit promotion rules that surface when switching compilers, or buggy > compilers have issues, but I far prefer an explicit cast so at least you can > see that the type mismatch was intentional. But I do agree that you should > write code to not need casts in the first place, yet sometimes that is > unavoidable. > > As for Rob's current quandry, I think he's got it under control. If the > warnings surfaced because of a compiler switch, perhaps there is a way to > turn off those warnings with a '-Wno-sign-compare' option to gcc...but I > don't know how to limit that just to chars... > > -- > ### Any similarity between my views and the truth is completely ### > ### coincidental, except that they are endorsed by NO ONE ### > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox -- Best regards/Mit freundlichen Gr??en Ihno Krumreich "Never trust a computer you can lift." -- Ihno Krumreich ihno@suse.de SUSE LINUX Products GmbH Projectmanager S390 & zSeries Maxfeldstr. 5 +49-911-74053-439 D-90409 N?rnberg http://www.suse.de -------------- next part -------------- Index: scripts/config/confdata.c =================================================================== --- scripts/config/confdata.c (revision 12662) +++ scripts/config/confdata.c (working copy) @@ -23,10 +23,10 @@ NULL, }; -static char *conf_expand_value(const signed char *in) +static char *conf_expand_value(const char *in) { struct symbol *sym; - const signed char *src; + const char *src; static char res_value[SYMBOL_MAXLENGTH]; char *dst, name[SYMBOL_MAXLENGTH]; Index: scripts/config/conf.c =================================================================== --- scripts/config/conf.c (revision 12662) +++ scripts/config/conf.c (working copy) @@ -31,14 +31,14 @@ static int indent = 1; static int valid_stdin = 1; static int conf_cnt; -static signed char line[128]; +static char line[128]; static struct menu *rootEntry; static char nohelp_text[] = "Sorry, no help available for this option yet.\n"; -static void strip(signed char *str) +static void strip(char *str) { - signed char *p = str; + char *p = str; int l; while ((isspace(*p))) Index: networking/libiproute/utils.c =================================================================== --- networking/libiproute/utils.c (revision 12662) +++ networking/libiproute/utils.c (working copy) @@ -168,7 +168,7 @@ int get_prefix_1(inet_prefix * dst, char *arg, int family) { int err; - unsigned plen; + int plen; char *slash; memset(dst, 0, sizeof(*dst)); Index: networking/libiproute/iplink.c =================================================================== --- networking/libiproute/iplink.c (revision 12662) +++ networking/libiproute/iplink.c (working copy) @@ -166,7 +166,7 @@ { struct ifreq ifr; struct sockaddr_ll me; - int alen; + socklen_t alen; int s; s = socket(PF_PACKET, SOCK_DGRAM, 0); @@ -206,7 +206,7 @@ static int parse_address(char *dev, int hatype, int halen, char *lla, struct ifreq *ifr) { - int alen; + socklen_t alen; memset(ifr, 0, sizeof(*ifr)); strcpy(ifr->ifr_name, dev); Index: networking/libiproute/libnetlink.c =================================================================== --- networking/libiproute/libnetlink.c (revision 12662) +++ networking/libiproute/libnetlink.c (working copy) @@ -30,7 +30,7 @@ int rtnl_open(struct rtnl_handle *rth, unsigned subscriptions) { - int addr_len; + socklen_t addr_len; memset(rth, 0, sizeof(rth)); From rpjday at mindspring.com Mon Dec 5 10:38:39 2005 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon Dec 5 10:44:14 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <20051205181651.GB3821@wotan.suse.de> References: <200511291632.05325.rob@landley.net> <200511292029.33680.jzb@aexorsyst.com> <20051130092537.GA1011@wotan.suse.de> <200511300748.12503.jzb@aexorsyst.com> <20051205181651.GB3821@wotan.suse.de> Message-ID: On Mon, 5 Dec 2005, Ihno Krumreich wrote: > hi, > > attached is a patch to remove some of signed warnings. > The code was compiled with a gcc 4.1.0. technically, there is no gcc-4.1.0, is there? i assume you're referring to a release candidate snapshot, yes? rday From rob at landley.net Mon Dec 5 11:08:42 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 11:10:50 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <28445.1133805012@brightstareng.com> References: <28445.1133805012@brightstareng.com> Message-ID: <200512051308.42507.rob@landley.net> On Monday 05 December 2005 11:50, Paul Fox wrote: > > Rummage, rummage, rummage... > > > > Having looked about your code, I believe I can say with some authority > > that you really, truly, _deeply_ need to look into initramfs. You can > > have all that crud in the gzipped cpio archive built into the kernel > > image, and the kernel will extract it for you on boot. > > can someone tell me why cpio was chosen for this? wouldn't tar be > just as useful, and lower cost in "oh-no-not-another-required-tool" terms? The actual flame war (in december, 2001) started here: http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html And spawned a second thread (specifically on tar vs cpio) here: http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html I'd definitely recommend reading all of both threads. The choice of cpio happened because A) Al Viro vetoed tar in the kernel, calling it "ugly as hell", B) Al Viro wrote the code implementing cpio. (LWN did its usual excellent job summarizing: http://lwn.net/Articles/14776/ But didn't focus on tar vs cpio specifically.) The things to realise specifically on tar vs cpio are: 1) The cpio format is simpler for the kernel to parse. Internally, tar is a bit of a hack with gnu extensions and such. Basically, this is a complete spec for the cpio format the kernel uses, in 112 (mostly english) lines, from the kernel source browser: http://sosdg.org/~coywolf/lxr/source/Documentation/early-userspace/buffer-format.txt And you can't do that with tar. :( 2) cpio actually predates tar, it's been part of unix from the AT&T days, and it's the archive format used internally by Red Hat's Package Manager (RPM). We already have extract support for it in busybox (or we couldn't do RPM), we just never bothered to add create support. (And we don't need to because the kernel made a tool to do it, although we probably should.) So saying "oh no, not another tool!" is kinda silly since this predates System V and any system that uses RPM is likely to have cpio installed on general principles. You just never noticed. (By the way, Red Hat also uses cpio for its device driver disks. I first encountered cpio when I was assigned to create a red hat device driver disk for 7.0 and I ran "file" on the file in there and it went "gzipped cpio archive" and I went "what the...?" This was over five years ago...) > we're using the excellent inittar patches from: > http://www.escape.de/users/outback/linux/index_en.html > for this purpose. (and we have 2.6 patches if anyone's interested.) > having no more need for creating an initrd is nice at build time > (no need to be root), and at runtime: instead of setting up an > initrd, and then needing tmpfs in addition, the tarball goes > right into tmpfs, which gets mounted directly as root. Did you read my initramfs documentation? http://sosdg.org/~coywolf/lxr/source/Documentation/filesystems/ramfs-rootfs-initramfs.txt You don't need to be root for the kernel to build a cpio archive for you during the kernel build. In fact you don't even need cpio installed on the system. The kernel's usr/gen_init_cpio.c is entirely self-contained. The kernel's built-in boot time extractor is also (obviously) entirely self-contained, so what the actual format is would be more or less irrelevant. They could have invented their own, but chose to go with the simplest existing standard. (And the "technically best choice" was not the same as "most popular".) So your external patch's entire reason for existing is because you want to use a different format for the kernel's internal data storage. (Out of curiosity, is there a patch for using "zip"?) > i realize initramfs solves a slightly different problem than this, Not really. You're re-inventing the wheel. The text file format gen_init_cpio accepts was created exactly so you _wouldn't_ have to be root to create a cpio archive, yet could still specify ownership and permissions on all the files and directories and device nodes and so on the archive should contain. My initramfs documentation gives an example of how to use it... > but i'm baffled by the cpio choice. It's smaller and simpler, it's a standard that's actually older than tar, and Al Viro put his foot down when tar was suggested, calling it "ugly as hell": http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html So what if it's not what the GNU guys standardized on? Linux ain't part of the gnu project. I admit that the command line syntax of the standard cpio utility sucks _mightily_. For example, the syntax to extract the cpio archive created by the linux kernel build is: cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames Which is just too intuitive for words. But the kernel's built-in tools have a _much_ better user interface. The text file format gen_init_cpio takes is pretty straightforward. Here's the actual one I'm using for my initramfs: dir /dev 755 0 0 nod /dev/console 644 0 0 c 5 1 nod /dev/loop0 600 0 0 b 7 0 dir /bin 755 1000 1000 slink /bin/sh busybox 777 0 0 dir /proc 755 0 0 dir /sys 755 0 0 dir /mnt 755 0 0 file /init initramfs/init.sh 755 0 0 file /bin/busybox initramfs/busybox 755 0 0 And glancing at it, I've got the ownership on my bin directory wrong. :) If you run "usr/gen_init_cpio" after the kernel build it'll dump a usage message telling you the format of this file, and the kernel also has a "scripts/gen_initramfs_list.sh" to do it for you. (Which is how my ownership got wrong in the above example script, I suspect. Hasn't caused an actual problem, but I need to fix it...) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From sreekant_kodela at yahoo.com Mon Dec 5 11:31:07 2005 From: sreekant_kodela at yahoo.com (sreekant kodela) Date: Mon Dec 5 11:31:30 2005 Subject: A set of scripts to make a live cd from your main setup. In-Reply-To: <200512051042.20341.rob@landley.net> Message-ID: <20051205193107.15408.qmail@web32506.mail.mud.yahoo.com> Hi Rob > Is this dynamic (based on /sys) or static nodes? > I am not sure what that means! Basically /etc/rc.d/mountcd searches the oldstyle /dev/hdc etc, devfs style /dev/cdroms/cdrom? etc and finds the cd then mounts it as /cdrom. Then the /etc/rc.d/links script links /cdrom/zz/lib/* to /lib/ and /cdrom/zz/bin/* to /bin/ and /cdrom/zz/usr to /usr etc. Finally it also can run ldconfig. For storing the kernel modules on cdrom, I created /lib/modules/KERNEL_VERSION on live root and /cdrom/zz/lib/modules/KERNEL_VERSION is mount -o bind'ed to /lib/modules... So that the depmod and modprobe doesn't moan they are links. Basically I am hoping to make a live cd that is easily customizable in that you can put all your added software on cdtree/zz and it will be available at run time. Also next step would be to add a script during making the live cd that will load a text file, parse it to get the network details of each live cd. This should make, generating a bunch of live cd's each with individual ip addresses and hostnames. > > qemu is highly cool, isn't it? > Indeed. I actually installed win2k on to a 1gb file under linux. Very satisfying to be able to lie to windows and if anything, it runs almost as fast as win2k machines at work, even in emulation !!!! Ta sree __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From rob at landley.net Mon Dec 5 11:57:37 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 11:58:09 2005 Subject: BusyBox/inittab weirdness In-Reply-To: <00d801c5f9c3$21c7fa60$0b01a8c0@pluto> References: <00d801c5f9c3$21c7fa60$0b01a8c0@pluto> Message-ID: <200512051357.37937.rob@landley.net> On Monday 05 December 2005 11:41, Rory Vieira wrote: > Hi, > > I stumbled on this without even knowing it... > > I compiled BusyBox with almost all options enabled (including init). > It also includes 'standalone shell'... > > Now my inittab start off like: > ------------------------------- > > ::sysinit:echo "Starting up Linux `uname -r`..." > > null::sysinit:/bin/mount -n -t proc proc /proc > null::sysinit:/bin/mount -n -o remount,rw /dev/root / > null::sysinit:/bin/busybox --install -s Meaning the console they're attached to is /dev/null. > The first line shows 'echo' and 'uname' without a path specification. Did you give an absolute path to either one? > The second line though is '/bin/mount'! _You_ gave an absolute path to mount. > Obviously I needed to make the 'mount', 'sh', and 'init' links beforehand. > Why do I need to do this for mount etc, but not with echo or uname? Why did you specify an absolute path for them, but not for echo and uname? > I can understand the echo (builtin), but not the uname. Look at your code. > If I change the second line to just 'mount...' it claims it can find mount > at all... I have no idea what your $PATH is set to. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 5 12:22:32 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 12:23:14 2005 Subject: "job control turned off" faq incomplete? In-Reply-To: <00d701c5f9c1$ec0126f0$0b01a8c0@pluto> References: <00d701c5f9c1$ec0126f0$0b01a8c0@pluto> Message-ID: <200512051422.33190.rob@landley.net> On Monday 05 December 2005 11:32, Rory Vieira wrote: > > That can have funky side effects, and is another reason to > > use udev on tmpfs. > > (My dumb little script to populate /dev from /sys is > > attached. I have a > > version of this ported to C and a quick and dirty spec for a > > config file > > format for it that Solar and I worked out in IRC one evening, > > but it's 1.2 material.) > > The script looks great. But doesn't this mean we need to mount /sys > first?!? Yeah, my initramfs does that for me. You can add that to the start of the script if you want. (Consider it GPL.) I suppose I should add that to my mdev todo list. Make sure /sys is mounted... (Hmmm... Probably just document the requirement that /sys and /dev be mounted before running mdev? I don't think I want to glue _two_ mounts into mdev. And that implies that all the symlink and directory creation belongs in whatever script mounts /sys and /dev. Which means a scalable bbsh is important, which was already a high-profile todo item of mine for 1.2...) I'll have to come up with an example initscript for this. (In fact, I'm thinking of coming up with an example initramfs setup for busybox 1.2, complete with initramfs.txt for the cpio.gz to be generated from by the kernel build. It'll need a working switch_root, mdev, init.sh, bbsh, and busybox and uclibc .config files...) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 5 12:23:50 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 12:24:55 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <20051205181651.GB3821@wotan.suse.de> References: <200511291632.05325.rob@landley.net> <200511300748.12503.jzb@aexorsyst.com> <20051205181651.GB3821@wotan.suse.de> Message-ID: <200512051423.50576.rob@landley.net> On Monday 05 December 2005 12:16, Ihno Krumreich wrote: > hi, > > attached is a patch to remove some of signed warnings. > The code was compiled with a gcc 4.1.0. > > Regards Cool. Did you look at it to figure out why they specified signed in the first place? (You have to go out of your way to say "signed", I'm wondering why they did that.) The switch to socklen_t I'm pretty comfortable with. The rest I'd like somebody to say "yeah, I read through the code and this is what they actually meant"... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From pgf at brightstareng.com Mon Dec 5 12:27:58 2005 From: pgf at brightstareng.com (Paul Fox) Date: Mon Dec 5 12:28:06 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: rob's message of Mon, 05 Dec 2005 13:08:42 -0600. <200512051308.42507.rob@landley.net> Message-ID: <32228.1133814478@brightstareng.com> hi rob -- thanks for the detailed response. > > can someone tell me why cpio was chosen for this? wouldn't tar be > > just as useful, and lower cost in "oh-no-not-another-required-tool" terms? > > The actual flame war (in december, 2001) started here: > http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html > > And spawned a second thread (specifically on tar vs cpio) here: > http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html > > I'd definitely recommend reading all of both threads. thanks. no emotions there, eh? :-) > 1) The cpio format is simpler for the kernel to parse. Internally, tar is a > bit of a hack with gnu extensions and such. i'll take your word for it. i haven't looked at the kernel's cpio parser. the inittar.c from the page i referenced isn't exactly rocket science, but i can certainly imagine simpler code. > 2) cpio actually predates tar, it's been part of unix from the AT&T days... oh, i certainly knew that. 20 years ago (5 years after starting to work at AT&T) i used to think "why the hell did they invent tar? cpio is perfectly adequate." and i still move directories using cpio sometimes. but now the number of people and tools that can deal with the two formats is clearly weighted to tar. > So saying "oh no, not another tool!" is kinda silly since this predates System > V and any system that uses RPM is likely to have cpio installed on general > principles. You just never noticed. (By the way, Red Hat also uses cpio for sure, it's not big thing, but every time you add a tool to a build system you add something else that needs to be cataloged, packaged, documented, understood by all the developers, etc. it's not like it's zero overhead. but i take your point. > > having no more need for creating an initrd is nice at build time > > (no need to be root), and at runtime: instead of setting up an > > initrd, and then needing tmpfs in addition, the tarball goes > > right into tmpfs, which gets mounted directly as root. > > Did you read my initramfs documentation? > http://sosdg.org/~coywolf/lxr/source/Documentation/filesystems/ramfs-rootfs-initramfs.txt i hadn't seen that -- thanks for the pointer. > > You don't need to be root for the kernel to build a cpio archive for you > during the kernel build. yes, i knew that. i was comparing the need for root access against the previous initrd mechanism, where one usually had to create a real filesystem on a loopback mount in order to create the initrd image. (yes, yes, i know: qemu is cool, and solves this problem. :-) > In fact you don't even need cpio installed on the > system. this i didn't know. > > So your external patch's entire reason for existing is because you want to use > a different format for the kernel's internal data storage. (Out of > curiosity, is there a patch for using "zip"?) no -- just tar, optionally gzipped or bzipp2ed. > > > i realize initramfs solves a slightly different problem than this, > > Not really. You're re-inventing the wheel. The text file format well, i don't think the inittar patches are _completely_ re-inventing the wheel (they're not mine, btw -- sorry if i gave that impression. we're using them, and have contributed a couple of fixes, but i take no credit). (and please read to the end before rebutting -- i'm not trying to dis initramfs. :-) for one, inittar works with 2.4 kernels -- initramfs is 2.6-only? second, the root filesystem created is in a tmpfs, which as you know is a somewhat different beast than a ramfs. once our embedded system is booted with the tmpfs-mounted root that came from the tarball, that's it. no remounting, no pivot-rooting, no extra /tmp filesystem to mount. i like simple. third, the tar archive isn't built-in to the kernel -- it's glued on, like an initrd. i can build a single bare kernel, and separately build several root filesystems for it (as tarballs), and glue them together with mkimage on an as-needed basis. if i've already glued them together, i can even unglue them, add to the tarball (since tarballs are essentially cat'table) and reglue it, allowing different combinations of root files pretty simply. very easy to deal with from a packaging and scripting perspective. if initramfs is always populated as part of a kernel build, it makes it hard to swap roots, doesn't it? and requiring the members of the elements of the initial filesystem to all live under the kernel source directory (is that necessary if you want to use gen_init_cpio?) seems a bit restrictive. all this is why it feels like the two mechanisms are solving somewhat different problems. but remember, i'm mostly comparing to initrd-based systems, which is what we (like most others) were doing before we found the inittar patches -- initramfs may be useable in some of these ways as well. i'm just ignorant of it. anyway, thanks for the education on initramfs. paul =--------------------- paul fox, pgf@brightstareng.com From farmatito at tiscali.it Mon Dec 5 13:37:52 2005 From: farmatito at tiscali.it (Tito) Date: Mon Dec 5 13:41:54 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512041308.53084.rob@landley.net> References: <200512041415.43580.farmatito@tiscali.it> <200512041308.53084.rob@landley.net> Message-ID: <200512052237.52536.farmatito@tiscali.it> On Sunday 04 December 2005 20:08, Rob Landley wrote: > On Sunday 04 December 2005 07:15, Tito wrote: > > Hi to all, > > I'm trying to compile the latest bb svn revision 12662, > > but it seems to be broken. > > The error message i get is: > > root@localhost:/dev/pts/3:/root/Desktop/busybox# make > > make -C /root/Desktop/busybox \ > > top_srcdir=/root/Desktop/busybox \ > > top_builddir=/root/Desktop/busybox \ > > KBUILD_SRC=/root/Desktop/busybox \ > > -f /root/Desktop/busybox/Makefile _all > > make[1]: Entering directory `/root/Desktop/busybox' > > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/bb_mkdep > > /root/Desktop/busybox/scripts/bb_mkdep.c scripts/bb_mkdep -c > > include/config.h -c include/bb_config.h \ > > -I /root/Desktop/busybox/include /root/Desktop/busybox > > > .depend.tmp mv .depend.tmp .depend > > gcc -I/root/Desktop/busybox/include -I/root/Desktop/busybox/include > > -I/root/Desktop/busybox/libbb -funsigned-char -Wall -Wstrict-prototypes > > -Wshadow -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=0 > > -falign-jumps=0 -falign-loops=0 -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG > > -c -o /root/Desktop/busybox/applets/applets.o > > /root/Desktop/busybox/applets/applets.c In file included from > > /root/Desktop/busybox/applets/applets.c:48: > > /root/Desktop/busybox/include/applets.h:677: error: 'tr_main' undeclared > > Line 677 is the middle of these three: > > #ifdef CONFIG_TR > APPLET(tr, tr_main, _BB_DIR_USR_BIN, _BB_SUID_NEVER) > #endif > > So that line shouldn't even be hit unless CONFIG_TR is set... > > > here (not in a function) /root/Desktop/busybox/include/applets.h:740: > > error: 'watchdog_main' undeclared here (not in a function) make[1]: *** > > Same with CONFIG_WATCHDOG... > > > So far I've tried a fresh svn co svn://busybox.net/trunk/busybox > > but nothing changed. > > By looking at applets.h I couldn't see any obvious problem. > > Me neither. I'm building make allnoconfig, make allyesconfig, and make > allbaseconfig. (Er, "allbareconfig". I get that wrong every time. But it > built.) > > > Let me know if you need more info about .config or other stuff. > > Yes, please attach a copy of your .config. I have no _idea_ what's wrong... > > Rob Hi, things are going weird. I've tried also busybox-1.01, but i get almost the same error: In file included from /root/Desktop/busybox-1.01/busybox-1.01/applets/applets.c:48: /root/Desktop/busybox-1.01/busybox-1.01/include/applets.h:551: error: 'sysctl_main' undeclared here (not in a function) /root/Desktop/busybox-1.01/busybox-1.01/include/applets.h:587: error: 'tr_main' undeclared here (not in a function) /root/Desktop/busybox-1.01/busybox-1.01/include/applets.h:647: error: 'watchdog_main' undeclared here (not in a function) make: *** [/root/Desktop/busybox-1.01/busybox-1.01/applets/applets.o] Error 1 The question now for me is: is my system somehow broken? Maybe it is, but other sources compile fine (Kernel, some apps, some of my own progs). Some hints?? Ciao, Tito From rep.nop at aon.at Mon Dec 5 14:08:50 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon Dec 5 14:10:24 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512052237.52536.farmatito@tiscali.it> References: <200512041415.43580.farmatito@tiscali.it> <200512041308.53084.rob@landley.net> <200512052237.52536.farmatito@tiscali.it> Message-ID: <20051205220849.GK7230@aon.at> On Mon, Dec 05, 2005 at 10:37:52PM +0100, Tito wrote: >On Sunday 04 December 2005 20:08, Rob Landley wrote: >> On Sunday 04 December 2005 07:15, Tito wrote: >> > Hi to all, >> > I'm trying to compile the latest bb svn revision 12662, >> > but it seems to be broken. >> > The error message i get is: >> > root@localhost:/dev/pts/3:/root/Desktop/busybox# make >> > make -C /root/Desktop/busybox \ >> > top_srcdir=/root/Desktop/busybox \ >> > top_builddir=/root/Desktop/busybox \ >> > KBUILD_SRC=/root/Desktop/busybox \ >> > -f /root/Desktop/busybox/Makefile _all >> > make[1]: Entering directory `/root/Desktop/busybox' >> > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/bb_mkdep >> > /root/Desktop/busybox/scripts/bb_mkdep.c scripts/bb_mkdep -c >> > include/config.h -c include/bb_config.h \ >> > -I /root/Desktop/busybox/include /root/Desktop/busybox > >> > .depend.tmp mv .depend.tmp .depend >> > gcc -I/root/Desktop/busybox/include -I/root/Desktop/busybox/include >> > -I/root/Desktop/busybox/libbb -funsigned-char -Wall -Wstrict-prototypes >> > -Wshadow -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=0 >> > -falign-jumps=0 -falign-loops=0 -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG >> > -c -o /root/Desktop/busybox/applets/applets.o >> > /root/Desktop/busybox/applets/applets.c In file included from >> > /root/Desktop/busybox/applets/applets.c:48: >> > /root/Desktop/busybox/include/applets.h:677: error: 'tr_main' undeclared >> >> Line 677 is the middle of these three: >> >> #ifdef CONFIG_TR >> APPLET(tr, tr_main, _BB_DIR_USR_BIN, _BB_SUID_NEVER) >> #endif >> >> So that line shouldn't even be hit unless CONFIG_TR is set... >> >> > here (not in a function) /root/Desktop/busybox/include/applets.h:740: >> > error: 'watchdog_main' undeclared here (not in a function) make[1]: *** >> >> Same with CONFIG_WATCHDOG... >> >> > So far I've tried a fresh svn co svn://busybox.net/trunk/busybox >> > but nothing changed. >> > By looking at applets.h I couldn't see any obvious problem. >> >> Me neither. I'm building make allnoconfig, make allyesconfig, and make >> allbaseconfig. (Er, "allbareconfig". I get that wrong every time. But it >> built.) >> >> > Let me know if you need more info about .config or other stuff. >> >> Yes, please attach a copy of your .config. I have no _idea_ what's wrong... >> >> Rob > >Hi, >things are going weird. >I've tried also busybox-1.01, but i get almost the same error: > >In file included from /root/Desktop/busybox-1.01/busybox-1.01/applets/applets.c:48: >/root/Desktop/busybox-1.01/busybox-1.01/include/applets.h:551: error: 'sysctl_main' undeclared here (not in a function) >/root/Desktop/busybox-1.01/busybox-1.01/include/applets.h:587: error: 'tr_main' undeclared here (not in a function) >/root/Desktop/busybox-1.01/busybox-1.01/include/applets.h:647: error: 'watchdog_main' undeclared here (not in a function) could that be the config namespace biting again? BB_CONFIG_TR vs. the tokenring stuff, just as a very wild guess. Do you see anything suspicious in the preprocessor-output of applets.c? >make: *** [/root/Desktop/busybox-1.01/busybox-1.01/applets/applets.o] Error 1 > >The question now for me is: >is my system somehow broken? >Maybe it is, but other sources compile fine (Kernel, some apps, some of my own progs). >Some hints?? > >Ciao, >Tito From farmatito at tiscali.it Mon Dec 5 14:20:19 2005 From: farmatito at tiscali.it (Tito) Date: Mon Dec 5 14:23:49 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <20051205220849.GK7230@aon.at> References: <200512041415.43580.farmatito@tiscali.it> <200512052237.52536.farmatito@tiscali.it> <20051205220849.GK7230@aon.at> Message-ID: <200512052320.19345.farmatito@tiscali.it> On Monday 05 December 2005 23:08, Bernhard Fischer wrote: > On Mon, Dec 05, 2005 at 10:37:52PM +0100, Tito wrote: > >On Sunday 04 December 2005 20:08, Rob Landley wrote: > >> On Sunday 04 December 2005 07:15, Tito wrote: snip > > could that be the config namespace biting again? > > BB_CONFIG_TR vs. the tokenring stuff, just as a very wild guess. > > Do you see anything suspicious in the preprocessor-output of applets.c? Hi, I can take a look at it, but only if you explain me briefly how to do it as my gcc-fu is not so big. BTW i've discovered that ubuntu installed two compilers, none of which I can remove without removing most of the other packages: gcc 3.3.6 gcc 4.0.1 this is the one used (at least the gcc symlinks point to it) Another possible cause for this trouble is that I use my own kernel-headers package created with make-kpkg from vanilla 2.6.14.3 kernel. Thanks in advance for your time and help Ciao, Tito > >make: *** [/root/Desktop/busybox-1.01/busybox-1.01/applets/applets.o] Error 1 > > > >The question now for me is: > >is my system somehow broken? > >Maybe it is, but other sources compile fine (Kernel, some apps, some of my own progs). > >Some hints?? > > > >Ciao, > >Tito > From rob at landley.net Mon Dec 5 13:21:23 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 15:04:04 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <32228.1133814478@brightstareng.com> References: <32228.1133814478@brightstareng.com> Message-ID: <200512051521.23992.rob@landley.net> On Monday 05 December 2005 14:27, Paul Fox wrote: > > I'd definitely recommend reading all of both threads. > > thanks. no emotions there, eh? :-) Al Viro was involved. Nuff said. :) > > Did you read my initramfs documentation? > > http://sosdg.org/~coywolf/lxr/source/Documentation/filesystems/ramfs-roo > >tfs-initramfs.txt > > i hadn't seen that -- thanks for the pointer. Since you're something like the fifth person to bring this up since I wrote that, I just added a section to it: http://seclists.org/lists/linux-kernel/2005/Dec/1146.html > > You don't need to be root for the kernel to build a cpio archive for you > > during the kernel build. > > yes, i knew that. i was comparing the need for root access against > the previous initrd mechanism, where one usually had to create a real > filesystem on a loopback mount in order to create the initrd image. > (yes, yes, i know: qemu is cool, and solves this problem. :-) I use User Mode Linux myself, both because qemu is an external package dependency and because with UML you don't need to make a root filesystem. Just build in hostfs and then borrow the parent's filesystem: The miniconfig: CONFIG_MODE_SKAS=y CONFIG_BINFMT_ELF=y CONFIG_HOSTFS=y CONFIG_SWAP=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_FUTEX=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_LBD=y CONFIG_STDERR_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_BLK_DEV_UBD=y CONFIG_BLK_DEV_LOOP=y CONFIG_EXT2_FS=y CONFIG_DNOTIFY=y CONFIG_PROC_FS=y CONFIG_SYSFS=y CONFIG_TMPFS=y The command line: ./linux rootfstype=hostfs rw init=/bin/sh > > In fact you don't even need cpio installed on the > > system. > > this i didn't know. > > > So your external patch's entire reason for existing is because you want > > to use a different format for the kernel's internal data storage. (Out > > of curiosity, is there a patch for using "zip"?) > > no -- just tar, optionally gzipped or bzipp2ed. gzip is built into the kernel. I offered my bunzip2 patch to the linux kernel guys but unfortunately I'd have to modify the make file to make it work, and you know how I am with makefiles... Besides, the current winner is lzma. (Which we _really_ should add to busybox in 1.2.) > for one, inittar works with 2.4 kernels -- initramfs is 2.6-only? Point. > second, the root filesystem created is in a tmpfs, which as you > know is a somewhat different beast than a ramfs. I'm under the vague impression that rootfs can be tmpfs, but perhaps that's still an external patch. (A patch for this was submitted back in August. I don't remember if it was merged or not, I haven't looked...) > once our > embedded system is booted with the tmpfs-mounted root that came > from the tarball, that's it. no remounting, no pivot-rooting, no > extra /tmp filesystem to mount. i like simple. Yup, lots of people do that with the cpio initramfs. > third, the tar archive isn't built-in to the kernel -- it's glued > on, like an initrd. I consider that a downside, but I'd like to point out that you still have the option to do that with initramfs. If you build in initrd support but feed it an initramfs image, it'll autodetect the type. (I remember this from reading the code, I' haven't actually tried it...) > if > i've already glued them together, i can even unglue them, add to > the tarball (since tarballs are essentially cat'table) and reglue > it, allowing different combinations of root files pretty simply. Working out how to do this for initramfs has been on my todo list for a while. Unfortunately, it involves tracing through the kernel's makefiles to see where the TMPPIGGY part is. (See "me and makefiles", above. It's not that I can't do it, it just doesn't bubble to the top of my todo list unless it's blocking something else I want/need to do...) > very easy to deal with from a packaging and scripting > perspective. if initramfs is always populated as part of a > kernel build, it makes it hard to swap roots, doesn't it? Not really. What I did is build the kernel, then swap out the initramfs.txt target and rebuild. It doesn't have to recompile everything, just regenerate the cpio archive and re-link. Thus for my firmware system, I can make the installer executable and the firmware executable from the same User Mode Linux compile. > and > requiring the members of the elements of the initial filesystem > to all live under the kernel source directory (is that necessary > if you want to use gen_init_cpio?) seems a bit restrictive. It doesn't, that's just where I put it. You can point CONFIG_INITRAMFS_SOURCE to anything. Feed it an absolute path, etc. By the way, if you build out of tree (O=../blah) then the default directory it'll look for this stuff in will be the _build_ directory, not the source directory. (You can fix that with a symlink if it's not what you want.) > all this is why it feels like the two mechanisms are solving > somewhat different problems. but remember, i'm mostly comparing > to initrd-based systems, which is what we (like most others) were > doing before we found the inittar patches -- initramfs may be > useable in some of these ways as well. i'm just ignorant of it. Initramfs is very different from initrd, and it sounds like the only thing it doesn't already do that you want is the TMPFS mount for rootfs. (And I was pretty sure that had already been merged, I'm just not finding the config option for it right now...) Possibly if you select CONFIG_TMPFS then rootfs will automatically be tmpfs, and thus there's no separate config option. That sounds familiar. (Doesn't mean it's _right_...) > anyway, thanks for the education on initramfs. Glad I could help. :) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 5 15:11:00 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 15:16:29 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512052237.52536.farmatito@tiscali.it> References: <200512041415.43580.farmatito@tiscali.it> <200512041308.53084.rob@landley.net> <200512052237.52536.farmatito@tiscali.it> Message-ID: <200512051711.00702.rob@landley.net> On Monday 05 December 2005 15:37, Tito wrote: > > > Let me know if you need more info about .config or other stuff. > > > > Yes, please attach a copy of your .config. I have no _idea_ what's > > wrong... > > > > Rob > > Hi, > things are going weird. > I've tried also busybox-1.01, but i get almost the same error: Oh, I forgot to say: I tried your .config and it built for me just fine. Haven't checked out a fresh snapshot, but svn diff didn't show anything interesting between my tree and -curent... > The question now for me is: > is my system somehow broken? Sounds like it. Are you using anything like ccache? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 5 15:17:31 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 15:22:07 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <20051205220849.GK7230@aon.at> References: <200512041415.43580.farmatito@tiscali.it> <200512052237.52536.farmatito@tiscali.it> <20051205220849.GK7230@aon.at> Message-ID: <200512051717.31994.rob@landley.net> On Monday 05 December 2005 16:08, Bernhard Fischer wrote: > could that be the config namespace biting again? > > BB_CONFIG_TR vs. the tokenring stuff, just as a very wild guess. > > Do you see anything suspicious in the preprocessor-output of applets.c? Huh. That is a thought... One of the reasons I wanted to move everything over to ENABLE_. Kernel headers that pollute the namespace like that are broken. Grep your /usr/include for that stuff and see if it's in there somewhere... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 5 15:19:18 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 15:22:12 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512052320.19345.farmatito@tiscali.it> References: <200512041415.43580.farmatito@tiscali.it> <20051205220849.GK7230@aon.at> <200512052320.19345.farmatito@tiscali.it> Message-ID: <200512051719.18329.rob@landley.net> On Monday 05 December 2005 16:20, Tito wrote: > Another possible cause for this trouble is that I use my own kernel-headers > package created with make-kpkg from vanilla 2.6.14.3 kernel. That's probably it. Where's make-kpkg? Have you tried mazur's kernel headers? (Yeah, 2.6.12 is the most recent one but last I heard he plans a 2.6.15 not too long after the 2.6.15 release.) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From pgf at brightstareng.com Mon Dec 5 15:26:22 2005 From: pgf at brightstareng.com (Paul Fox) Date: Mon Dec 5 15:26:34 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: rob's message of Mon, 05 Dec 2005 15:21:23 -0600. <200512051521.23992.rob@landley.net> Message-ID: <3832.1133825182@brightstareng.com> > > yes, i knew that. i was comparing the need for root access against > > the previous initrd mechanism, where one usually had to create a real > > filesystem on a loopback mount in order to create the initrd image. > > (yes, yes, i know: qemu is cool, and solves this problem. :-) > > I use User Mode Linux myself, both because qemu is an external package > dependency and because with UML you don't need to make a root filesystem. > Just build in hostfs and then borrow the parent's filesystem: ah cool. thanks. > > > > > So your external patch's entire reason for existing is because you want > > > to use a different format for the kernel's internal data storage. (Out > > > of curiosity, is there a patch for using "zip"?) > > > > no -- just tar, optionally gzipped or bzipp2ed. > > gzip is built into the kernel. I offered my bunzip2 patch to the linux kernel yes -- inittar use the builtin gzip, but an add-on bunzip2. > > third, the tar archive isn't built-in to the kernel -- it's glued > > on, like an initrd. > > I consider that a downside, but I'd like to point out that you still have the > option to do that with initramfs. If you build in initrd support but feed it > an initramfs image, it'll autodetect the type. (I remember this from reading ah. good again. > > if > > i've already glued them together, i can even unglue them, add to > > the tarball (since tarballs are essentially cat'table) and reglue > > it, allowing different combinations of root files pretty simply. > > Working out how to do this for initramfs has been on my todo list for a while. > Unfortunately, it involves tracing through the kernel's makefiles to see > where the TMPPIGGY part is. (See "me and makefiles", above. It's not that I > can't do it, it just doesn't bubble to the top of my todo list unless it's > blocking something else I want/need to do...) > > > very easy to deal with from a packaging and scripting > > perspective. if initramfs is always populated as part of a > > kernel build, it makes it hard to swap roots, doesn't it? > > Not really. What I did is build the kernel, then swap out the initramfs.txt > target and rebuild. It doesn't have to recompile everything, just regenerate > the cpio archive and re-link. Thus for my firmware system, I can make the > installer executable and the firmware executable from the same User Mode > Linux compile. for our product purposes, we want the flexibility (i didn't say we're doing it yet :-) to actually do this in the field -- pull a kernel/root combo out of flash, pull off the tarball, add more tarball to it, and reflash. currently i can do that with pretty minimal tools. i'd rather not need make or a linker. :-) > > and > > requiring the members of the elements of the initial filesystem > > to all live under the kernel source directory (is that necessary > > if you want to use gen_init_cpio?) seems a bit restrictive. > > It doesn't, that's just where I put it. You can point CONFIG_INITRAMFS_SOURCE > to anything. Feed it an absolute path, etc. i see. i think i got that impression from your doc page: "Note that those two example "file" entries expect to find files named "init.sh" and "busybox" in a directory called "initramfs", under the linux-2.6.* directory." presumably i should have followed the pointer in the next sentence to get the complete answer. :-) > > all this is why it feels like the two mechanisms are solving > > somewhat different problems. but remember, i'm mostly comparing > > to initrd-based systems, which is what we (like most others) were > > doing before we found the inittar patches -- initramfs may be > > useable in some of these ways as well. i'm just ignorant of it. > > Initramfs is very different from initrd, and it sounds like > the only thing it doesn't already do that you want is the > TMPFS mount for rootfs. (And I was pretty sure that had plus the need for a linker to rebuild. and 2.4 kernel support. other than that, you're right -- they're identical. ;-) anyway, now i'm truly enlightened. now let's get back to busybox... paul =--------------------- paul fox, pgf@brightstareng.com From rob at landley.net Mon Dec 5 19:30:20 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 5 19:31:10 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <3832.1133825182@brightstareng.com> References: <3832.1133825182@brightstareng.com> Message-ID: <200512052130.20973.rob@landley.net> On Monday 05 December 2005 17:26, Paul Fox wrote: > > It doesn't, that's just where I put it. You can point > > CONFIG_INITRAMFS_SOURCE to anything. Feed it an absolute path, etc. > > i see. i think i got that impression from your doc page: > "Note that those two example "file" entries expect to find > files named "init.sh" and "busybox" in a directory called > "initramfs", under the linux-2.6.* directory." My example does, yes. > presumably i should have followed the pointer in the next sentence > to get the complete answer. :-) I haven't really played with it that much. My example is what I do. That said, you'd be amazed what you can do with a directory symlink... > > > all this is why it feels like the two mechanisms are solving > > > somewhat different problems. but remember, i'm mostly comparing > > > to initrd-based systems, which is what we (like most others) were > > > doing before we found the inittar patches -- initramfs may be > > > useable in some of these ways as well. i'm just ignorant of it. > > > > Initramfs is very different from initrd, and it sounds like > > the only thing it doesn't already do that you want is the > > TMPFS mount for rootfs. (And I was pretty sure that had > > plus the need for a linker to rebuild. and 2.4 kernel support. other > than that, you're right -- they're identical. ;-) I strongly suspect you can rebuild without the linker, even if you're not using the external initrd-style version. I just haven't bothered to work out how yet. Keep in mind I once took apart and reassembled an rpm with "cpio" and "dd" because I needed to fix a path in it, and my first experience with a debugger was to hack a friend's game binary to give him unlimited gold in "Betrayal at Krondor" (tracing back from where it updated the mcga screen ram to draw the current gold amount, back through a dozen or so different jump points that were probably functionsI didn't have source to, to find a memory location in this strange format I had to puzzle out and which I would years later learn is how floating point numbers are stored in memory...) Swapping out a section of an elf binary via shell script? Not intimidating. :) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From jzb at aexorsyst.com Mon Dec 5 22:18:24 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Mon Dec 5 22:20:01 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? Message-ID: <200512052218.24283.jzb@aexorsyst.com> This is post in case anyone uses buildroot... In many instances of shared library installation, I notice that the authors of the package/{package_x}/{package_x}.mk file really like to render their shared libraries useless. If you'd like to destroy your system, or build an otherwise useless one, see what happens when you `strip --strip-unneeded` on a shared library. I'm not sure if its worth patching, as I'm not certain of the future of buildroot, but the $(STRIP) --strip-unneeded ... incantation is used in numerous buildroot/package .mk files...most inappropriately on shared libraries (.so's). Just an FYI... -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From jakelly at shtc.net Mon Dec 5 22:32:40 2005 From: jakelly at shtc.net (John Kelly) Date: Mon Dec 5 22:34:01 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512052218.24283.jzb@aexorsyst.com> References: <200512052218.24283.jzb@aexorsyst.com> Message-ID: <0vbap1disn1hdovgsqu39lfjsplcpdd81b@4ax.com> On Mon, 05 Dec 2005 22:18:24 -0800, John Z Bohach wrote: >If you'd like to destroy your system, or build an otherwise useless one, see >what happens when you `strip --strip-unneeded` on a shared library. > >I'm not sure if its worth patching, as I'm not certain of the future of >buildroot, but the $(STRIP) --strip-unneeded ... incantation is used in >numerous buildroot/package .mk files...most inappropriately on shared >libraries (.so's). Buildroot uses strip -x on my uclibc shared library and it works fine. I don't see a problem. From jzb at aexorsyst.com Mon Dec 5 22:57:37 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Mon Dec 5 22:58:17 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <0vbap1disn1hdovgsqu39lfjsplcpdd81b@4ax.com> References: <200512052218.24283.jzb@aexorsyst.com> <0vbap1disn1hdovgsqu39lfjsplcpdd81b@4ax.com> Message-ID: <200512052257.37281.jzb@aexorsyst.com> On Monday 05 December 2005 22:32, John Kelly wrote: > On Mon, 05 Dec 2005 22:18:24 -0800, John Z Bohach > > wrote: > >If you'd like to destroy your system, or build an otherwise useless one, > > see what happens when you `strip --strip-unneeded` on a shared library. > > > >I'm not sure if its worth patching, as I'm not certain of the future of > >buildroot, but the $(STRIP) --strip-unneeded ... incantation is used in > >numerous buildroot/package .mk files...most inappropriately on shared > >libraries (.so's). > > Buildroot uses strip -x on my uclibc shared library and it works fine. > I don't see a problem. > Okay...here's an idea: `strip --strip-unneeded /lib/libuClibc*` What have you got to lose? But you may see a problem afterwards... P.S.: You might want to consult the strip manpage and see if there's a slight difference between the -x and the --strip-unneeded options... Do note that my original post refers to '--strip-unneeded'... > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From rep.nop at aon.at Tue Dec 6 00:12:07 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Dec 6 00:10:49 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512052320.19345.farmatito@tiscali.it> References: <200512041415.43580.farmatito@tiscali.it> <200512052237.52536.farmatito@tiscali.it> <20051205220849.GK7230@aon.at> <200512052320.19345.farmatito@tiscali.it> Message-ID: <20051206081207.GA12749@aon.at> On Mon, Dec 05, 2005 at 11:20:19PM +0100, Tito wrote: >On Monday 05 December 2005 23:08, Bernhard Fischer wrote: >> On Mon, Dec 05, 2005 at 10:37:52PM +0100, Tito wrote: >> >On Sunday 04 December 2005 20:08, Rob Landley wrote: >> >> On Sunday 04 December 2005 07:15, Tito wrote: >snip >> >> could that be the config namespace biting again? >> >> BB_CONFIG_TR vs. the tokenring stuff, just as a very wild guess. >> >> Do you see anything suspicious in the preprocessor-output of applets.c? >Hi, >I can take a look at it, but only if you explain me briefly gcc -c appletc/applets.c -E > appl.E and look at appl.E to see why watchdog, sysctl, tr is pulled in. >how to do it as my gcc-fu is not so big. > >BTW i've discovered that ubuntu installed two compilers, none of which I can remove >without removing most of the other packages: > >gcc 3.3.6 >gcc 4.0.1 this is the one used (at least the gcc symlinks point to it) > >Another possible cause for this trouble is that I use my own kernel-headers package >created with make-kpkg from vanilla 2.6.14.3 kernel. From ihno at suse.de Tue Dec 6 00:55:24 2005 From: ihno at suse.de (Ihno Krumreich) Date: Tue Dec 6 00:55:47 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: References: <200511291632.05325.rob@landley.net> <200511292029.33680.jzb@aexorsyst.com> <20051130092537.GA1011@wotan.suse.de> <200511300748.12503.jzb@aexorsyst.com> <20051205181651.GB3821@wotan.suse.de> Message-ID: <20051206085524.GE26919@wotan.suse.de> On Mon, Dec 05, 2005 at 01:38:39PM -0500, Robert P. J. Day wrote: > On Mon, 5 Dec 2005, Ihno Krumreich wrote: > > > hi, > > > > attached is a patch to remove some of signed warnings. > > The code was compiled with a gcc 4.1.0. > > technically, there is no gcc-4.1.0, is there? i assume you're > referring to a release candidate snapshot, yes? Yes. Ihno -- Best regards/Mit freundlichen Gr??en Ihno Krumreich "Never trust a computer you can lift." -- Ihno Krumreich ihno@suse.de SUSE LINUX Products GmbH Projectmanager S390 & zSeries Maxfeldstr. 5 +49-911-74053-439 D-90409 N?rnberg http://www.suse.de From ihno at suse.de Tue Dec 6 01:00:56 2005 From: ihno at suse.de (Ihno Krumreich) Date: Tue Dec 6 01:01:08 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512051423.50576.rob@landley.net> References: <200511291632.05325.rob@landley.net> <200511300748.12503.jzb@aexorsyst.com> <20051205181651.GB3821@wotan.suse.de> <200512051423.50576.rob@landley.net> Message-ID: <20051206090056.GF26919@wotan.suse.de> On Mon, Dec 05, 2005 at 02:23:50PM -0600, Rob Landley wrote: > On Monday 05 December 2005 12:16, Ihno Krumreich wrote: > > hi, > > > > attached is a patch to remove some of signed warnings. > > The code was compiled with a gcc 4.1.0. > > > > Regards > > Cool. > > Did you look at it to figure out why they specified signed in the first place? > (You have to go out of your way to say "signed", I'm wondering why they did > that.) in conf.c and confdata.c I can see no reason. The scope of the variables is local and no other obvious reason. > > The switch to socklen_t I'm pretty comfortable with. The rest I'd like > somebody to say "yeah, I read through the code and this is what they actually > meant"... On the other code parts I have seen only assigments and the compares where "equal" or "not equal". Ihno "Never trust a computer you can lift." -- Ihno Krumreich ihno@suse.de SUSE LINUX Products GmbH Projectmanager S390 & zSeries Maxfeldstr. 5 +49-911-74053-439 D-90409 N?rnberg http://www.suse.de From rep.nop at aon.at Tue Dec 6 01:05:54 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Dec 6 01:12:00 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512051717.31994.rob@landley.net> References: <200512041415.43580.farmatito@tiscali.it> <200512052237.52536.farmatito@tiscali.it> <20051205220849.GK7230@aon.at> <200512051717.31994.rob@landley.net> Message-ID: <20051206090554.GB12749@aon.at> On Mon, Dec 05, 2005 at 05:17:31PM -0600, Rob Landley wrote: >On Monday 05 December 2005 16:08, Bernhard Fischer wrote: > >> could that be the config namespace biting again? >> >> BB_CONFIG_TR vs. the tokenring stuff, just as a very wild guess. >> >> Do you see anything suspicious in the preprocessor-output of applets.c? > >Huh. That is a thought... > >One of the reasons I wanted to move everything over to ENABLE_. > >Kernel headers that pollute the namespace like that are broken. Grep Do you have an opinion on when we can switch the config namespace over to BB_CONFIG_*? IIRC you wanted to wait until we opened the busybox-1_1-branch and only then switch trunk to BB_CONFIG, yes? PS: erik did already switch sysctl to BB_CONFIG, i'd prefer to do the same for watchdog and tr for the 1.1 release(-candidate).. From won_fang at yahoo.com.au Tue Dec 6 01:24:14 2005 From: won_fang at yahoo.com.au (David Seikel) Date: Tue Dec 6 01:23:20 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <200512052130.20973.rob@landley.net> References: <3832.1133825182@brightstareng.com> <200512052130.20973.rob@landley.net> Message-ID: <20051206192414.17af11bb@cluster.meeting.humbug.org.au> Most enlightening. When I finally get around to doing more work on My Linux, I will give initramfs another go. Paul Fox had most of the same objections that I had to it. On the other hand, for an installer, what goes into mdev plus the extra stuff I wanted to go in still seem like a very good idea to me. I shall wait and see. It's not like I was gonna be able to get back to My Linux any time soon. -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051206/17192286/attachment.pgp From ps.m at gmx.net Tue Dec 6 01:25:27 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Tue Dec 6 01:28:13 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512052257.37281.jzb@aexorsyst.com> Message-ID: On Mon, 5 Dec 2005, John Z. Bohach wrote: > On Monday 05 December 2005 22:32, John Kelly wrote: > > On Mon, 05 Dec 2005 22:18:24 -0800, John Z Bohach > > > > wrote: > > >If you'd like to destroy your system, or build an otherwise useless one, > > > see what happens when you `strip --strip-unneeded` on a shared library. > > > > > >I'm not sure if its worth patching, as I'm not certain of the future of > > >buildroot, but the $(STRIP) --strip-unneeded ... incantation is used in > > >numerous buildroot/package .mk files...most inappropriately on shared > > >libraries (.so's). > > > > Buildroot uses strip -x on my uclibc shared library and it works fine. > > I don't see a problem. > > > > Okay...here's an idea: > > `strip --strip-unneeded /lib/libuClibc*` are you sure you used the correct strip (it is that you render your libs useless, if you use the host strip against the cross-compiled libs) Peter > > What have you got to lose? But you may see a problem afterwards... > > P.S.: You might want to consult the strip manpage and see if there's a slight > difference between the -x and the --strip-unneeded options... > > Do note that my original post refers to '--strip-unneeded'... > > > > > _______________________________________________ > > busybox mailing list > > busybox@busybox.net > > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From ps.m at gmx.net Tue Dec 6 01:34:16 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Tue Dec 6 01:35:09 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <0vbap1disn1hdovgsqu39lfjsplcpdd81b@4ax.com> Message-ID: On Tue, 6 Dec 2005, John Kelly wrote: > On Mon, 05 Dec 2005 22:18:24 -0800, John Z Bohach > wrote: > > >If you'd like to destroy your system, or build an otherwise useless one, see > >what happens when you `strip --strip-unneeded` on a shared library. > > > >I'm not sure if its worth patching, as I'm not certain of the future of > >buildroot, but the $(STRIP) --strip-unneeded ... incantation is used in > >numerous buildroot/package .mk files...most inappropriately on shared > >libraries (.so's). > > Buildroot uses strip -x on my uclibc shared library and it works fine. > I don't see a problem. uClibc's objects are stripped (mostly) like that: $(STRIP) -x -R .note -R .comment the shared libs are not stripped iirc Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From rep.nop at aon.at Tue Dec 6 02:46:34 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Dec 6 02:52:59 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512011102.31369.rob@landley.net> References: <200512010924.22617.rob@landley.net> <78a54e1b0512010814u6f2ca829x8734d8e30306a7f2@mail.gmail.com> <200512011102.31369.rob@landley.net> Message-ID: <20051206104634.GC12749@aon.at> On Thu, Dec 01, 2005 at 11:02:31AM -0600, Rob Landley wrote: >/busybox/archival/tar.c: In function 'writeTarFile': >/busybox/archival/tar.c:466: warning: missing sentinel in function call that 0 should be NULL. >/busybox/coreutils/coreutils.a(nohup.o): In function `close_stdout': >nohup.c:(.text+0x6a): warning: >/bin/sh: /busybox/docs/autodocifier.pl: /usr/bin/perl: bad interpreter: No such file or directory What warning was there for nohup::close_stdout() ? From solar at gentoo.org Tue Dec 6 04:06:09 2005 From: solar at gentoo.org (Ned Ludd) Date: Tue Dec 6 04:07:19 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512052218.24283.jzb@aexorsyst.com> References: <200512052218.24283.jzb@aexorsyst.com> Message-ID: <1133870770.27874.27.camel@localhost> On Mon, 2005-12-05 at 22:18 -0800, John Z. Bohach wrote: > This is post in case anyone uses buildroot... > > In many instances of shared library installation, I notice that the authors of > the package/{package_x}/{package_x}.mk file really like to render their > shared libraries useless. > > If you'd like to destroy your system, or build an otherwise useless one, see > what happens when you `strip --strip-unneeded` on a shared library. Actually this is quite safe to do in fact nearly every single in a recent build of mine only out of 816 shared objects only 13 were not additionally stripped with --strip-unneeded. You will also find that most every major distributions also uses --strip-unneeded by default, often mixed with split debug info and this works for well over a million users uclibc & glibc. By useless perhaps we are to assume you mean harder to debug? From farmatito at tiscali.it Tue Dec 6 04:55:20 2005 From: farmatito at tiscali.it (Tito) Date: Tue Dec 6 04:56:46 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <200512051711.00702.rob@landley.net> References: <200512041415.43580.farmatito@tiscali.it> <200512052237.52536.farmatito@tiscali.it> <200512051711.00702.rob@landley.net> Message-ID: <200512061355.20264.farmatito@tiscali.it> On Tuesday 06 December 2005 00:11, you wrote: > On Monday 05 December 2005 15:37, Tito wrote: > > > > > Let me know if you need more info about .config or other stuff. > > > > > > Yes, please attach a copy of your .config. I have no _idea_ what's > > > wrong... > > > > > > Rob > > > > Hi, > > things are going weird. > > I've tried also busybox-1.01, but i get almost the same error: > > Oh, I forgot to say: > > I tried your .config and it built for me just fine. Haven't checked out a > fresh snapshot, but svn diff didn't show anything interesting between my tree > and -curent... So, I'm pretty sure that the reason are my custom 2.6.14.3 kernel-headers. In fact grepping for CONFIG_TR and CONFIG_WATCHDOG returns a lot of matches, and by changing CONFIG_TR to ENABLE_TR and CONFIG_WATCHDOG to ENABLE_WATCHDOG everything compiles fine again. Maybe it would be a good idea to move at least this two to ENABLE_* before the next release as there could be other users that have the latest kernel headers. Maybe we could create a little script to detect other clashes, I will take a look at it and in case post the script and the results. > > The question now for me is: > > is my system somehow broken? > > Sounds like it. > > Are you using anything like ccache? No. > Rob Ciao, Tito From farmatito at tiscali.it Tue Dec 6 06:49:11 2005 From: farmatito at tiscali.it (Tito) Date: Tue Dec 6 06:54:59 2005 Subject: Kernel headers trouble Message-ID: <200512061549.11232.farmatito@tiscali.it> Hi, I put thogether a simple script (attached) to check clashes in kernel headers. Usage is: check_kernel_headers.sh [-v] PATH_TO_applets.h PATH_TO_KERNEL_HEADERS_DIR Options: -v Be verbose The result when running it against my kernel headers (2.6.14.3) created with make-kpkg are: root@localhost:/dev/pts/0:/root/Desktop/busybox/include# ./check_kernel_headers.sh -v applets.h /usr/src/kernel-headers Pass 1 CONFIG_TR conflicts with kernel headers /usr/src/kernel-headers/include/linux/autoconf.h:1482:#define CONFIG_TR 1 /usr/src/kernel-headers/include/config/tr.h:1:#define CONFIG_TR 1 CONFIG_WATCHDOG conflicts with kernel headers /usr/src/kernel-headers/include/linux/autoconf.h:1975:#define CONFIG_WATCHDOG 1 /usr/src/kernel-headers/include/config/watchdog.h:1:#define CONFIG_WATCHDOG 1 Pass 2 Pass 3 Pass 4 So it seems a good idea to change CONFIG_TR and CONFIG_WATCHDOG to CONFIG_BB_* before the next release. Rob, if you want I can try to make a patch for it Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: check_kernel_headers.sh Type: application/x-shellscript Size: 1922 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051206/9e1f7a84/check_kernel_headers-0001.bin From jzb at aexorsyst.com Tue Dec 6 07:51:46 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Tue Dec 6 07:52:13 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: References: Message-ID: <200512060751.46463.jzb@aexorsyst.com> On Tuesday 06 December 2005 01:25, Peter S. Mazinger wrote: > are you sure you used the correct strip (it is that you render your libs > useless, if you use the host strip against the cross-compiled libs) > > Peter Sorry, I thought this would be more obvious. I don't want to start a big long thread, so specifically, in buildroot/packages/Makefile.in, we have: STRIP=$(TARGET_CROSS)strip --remove-section=.comment --remove-section=.note which is fine. But then later, specific package makefiles do this: package/ncurses.mk: -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libncurses.so.$(NCURSES_VER) and package/berkelybd.mk -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* which is not fine, because all symbol information from the libraries is now removed, and whenever a linker tries linking against thusly stripped libraries, you get "undefined symbol..." errors. Just an FYI, and a learning point. --john P.S.: freetype, directfb, libpng, libsys, and more all suffer from this, so whatever the thinking was, it was contagious... -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From vapier at gentoo.org Tue Dec 6 08:13:17 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Dec 6 08:23:20 2005 Subject: Kernel headers trouble In-Reply-To: <200512061549.11232.farmatito@tiscali.it> References: <200512061549.11232.farmatito@tiscali.it> Message-ID: <20051206161317.GB9632@toucan.gentoo.org> On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: > I put thogether a simple script (attached) to check clashes in kernel headers. so why havent we just done a global sed 's:CONFIG_:BB_CONFIG_:g' yet ? -mike From vapier at gentoo.org Tue Dec 6 08:19:31 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Dec 6 08:24:14 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512060751.46463.jzb@aexorsyst.com> References: <200512060751.46463.jzb@aexorsyst.com> Message-ID: <20051206161931.GD9632@toucan.gentoo.org> On Tue, Dec 06, 2005 at 07:51:46AM -0800, John Z. Bohach wrote: > On Tuesday 06 December 2005 01:25, Peter S. Mazinger wrote: > > are you sure you used the correct strip (it is that you render your libs > > useless, if you use the host strip against the cross-compiled libs) > > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > which is not fine, because all symbol information from the libraries is now > removed, and whenever a linker tries linking against thusly stripped > libraries, you get "undefined symbol..." errors. cant say ive had this issue before and as solar pointed out, we've been using --strip-unneeded on *all* shared libraries for quite a long time now without any linking issues -mike From pgf at brightstareng.com Tue Dec 6 08:44:56 2005 From: pgf at brightstareng.com (Paul Fox) Date: Tue Dec 6 08:45:12 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: vapier's message of Tue, 06 Dec 2005 16:19:31 +0000. <20051206161931.GD9632@toucan.gentoo.org> Message-ID: <13980.1133887496@brightstareng.com> > > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > > > which is not fine, because all symbol information from the libraries is now > > removed, and whenever a linker tries linking against thusly stripped > > libraries, you get "undefined symbol..." errors. > > cant say ive had this issue before and as solar pointed out, we've been > using --strip-unneeded on *all* shared libraries for quite a long time > now without any linking issues we use --strip-unneeded too, and it's fine. but it's fine for runtime. is it perhaps the case that libraries stripped like that can no longer be used in development? paul =--------------------- paul fox, pgf@brightstareng.com From jzb at aexorsyst.com Tue Dec 6 09:20:01 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Tue Dec 6 09:21:24 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <13980.1133887496@brightstareng.com> References: <13980.1133887496@brightstareng.com> Message-ID: <200512060920.01212.jzb@aexorsyst.com> On Tuesday 06 December 2005 08:44, Paul Fox wrote: > > > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > > > > > which is not fine, because all symbol information from the libraries > > > is now removed, and whenever a linker tries linking against thusly > > > stripped libraries, you get "undefined symbol..." errors. > > > > cant say ive had this issue before and as solar pointed out, we've been > > using --strip-unneeded on *all* shared libraries for quite a long time > > now without any linking issues > > we use --strip-unneeded too, and it's fine. but it's fine for > runtime. is it perhaps the case that libraries stripped like > that can no longer be used in development? > BINGO. Executables that have been linked have addresses hardwired where the symbols were. The library code didn't change, but '$(LD) ... -l{somelib} ...etc' won't find the symbols, and you'll get undefined symbol errors. The most obvious side effect of this is try running a 'make menuconfig' of buildroot in a self-hosted environment, i.e. one created by buildroot. Since lib/libncurses*so* is stripped of symbols, you'll get undefined symbol "libgettext_...' errors, etc. > paul > =--------------------- > paul fox, pgf@brightstareng.com > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox -- ### Any similarity between my views and the truth is completely ### ### coincidental, except that they are endorsed by NO ONE ### From vapier at gentoo.org Tue Dec 6 10:10:10 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Dec 6 10:11:32 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <13980.1133887496@brightstareng.com> References: <20051206161931.GD9632@toucan.gentoo.org> <13980.1133887496@brightstareng.com> Message-ID: <20051206181010.GE9632@toucan.gentoo.org> On Tue, Dec 06, 2005 at 11:44:56AM -0500, Paul Fox wrote: > > > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > > > > > which is not fine, because all symbol information from the libraries is now > > > removed, and whenever a linker tries linking against thusly stripped > > > libraries, you get "undefined symbol..." errors. > > > > cant say ive had this issue before and as solar pointed out, we've been > > using --strip-unneeded on *all* shared libraries for quite a long time > > now without any linking issues > > we use --strip-unneeded too, and it's fine. but it's fine for > runtime. is it perhaps the case that libraries stripped like > that can no longer be used in development? no, because we're using it in Gentoo that means every single Gentoo user has every single shared library stripped with --strip-unneeded i have yet to see a bug reported where someone was unable to link against a library ... and since it's Gentoo, everytime a package is installed, it's compiled and linked on every system -mike From vapier at gentoo.org Tue Dec 6 10:21:40 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Dec 6 10:22:37 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512060920.01212.jzb@aexorsyst.com> References: <13980.1133887496@brightstareng.com> <200512060920.01212.jzb@aexorsyst.com> Message-ID: <20051206182140.GG9632@toucan.gentoo.org> On Tue, Dec 06, 2005 at 09:20:01AM -0800, John Z. Bohach wrote: > On Tuesday 06 December 2005 08:44, Paul Fox wrote: > > we use --strip-unneeded too, and it's fine. but it's fine for > > runtime. is it perhaps the case that libraries stripped like > > that can no longer be used in development? > > BINGO. Executables that have been linked have addresses hardwired where the > symbols were. no, that isnt how linking works executables store a list of all needed external symbols and a list of all needed libraries for example: $ echo 'int foo() { return 123; }' > libfoo.c $ gcc -fPIC -shared -s libfoo.c -o libfoo.so $ strip --strip-unneeded libfoo.so $ readelf -s libfoo.so | grep foo 16: 0000000000000678 11 FUNC GLOBAL DEFAULT 10 foo $ cat << EOF > striptest.c #include extern int foo(void); int main() { printf("%i\n", foo()); return 0; } EOF $ gcc striptest.c -L. -Wl,-rpath,. -lfoo -o striptest $ readelf -a striptest | grep foo 0x0000000000000001 (NEEDED) Shared library: [libfoo.so] 7: 0000000000000000 11 FUNC GLOBAL DEFAULT UND foo $ ./striptest 123 seems to me it worked just fine -mike From jzb at aexorsyst.com Tue Dec 6 10:48:59 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Tue Dec 6 10:49:48 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <20051206181010.GE9632@toucan.gentoo.org> References: <20051206161931.GD9632@toucan.gentoo.org> <13980.1133887496@brightstareng.com> <20051206181010.GE9632@toucan.gentoo.org> Message-ID: <200512061048.59423.jzb@aexorsyst.com> On Tuesday 06 December 2005 10:10, Mike Frysinger wrote: > On Tue, Dec 06, 2005 at 11:44:56AM -0500, Paul Fox wrote: > > > > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > > > > > > > which is not fine, because all symbol information from the libraries > > > > is now removed, and whenever a linker tries linking against thusly > > > > stripped libraries, you get "undefined symbol..." errors. > > > > > > cant say ive had this issue before and as solar pointed out, we've > > > been using --strip-unneeded on *all* shared libraries for quite a long > > > time now without any linking issues > > > > we use --strip-unneeded too, and it's fine. but it's fine for > > runtime. is it perhaps the case that libraries stripped like > > that can no longer be used in development? > > no, because we're using it in Gentoo > > that means every single Gentoo user has every single shared library > stripped with --strip-unneeded > > i have yet to see a bug reported where someone was unable to link > against a library ... and since it's Gentoo, everytime a package is > installed, it's compiled and linked on every system > -mike Can't speak to gentoo, but I can tell you what I've observed myself when trying to build buildroot in a development environment built by buildroot. Once I commented out the 'strip'-ing of ncurses, berkelydb, etc., things like perl, 'make menuconfig' of buildroot itself, etc. all work. Otherwise, "undefined symbol ..." error. LFS chapter 5 comments on stripping static libraries: http://www.linuxfromscratch.org/lfs/view/stable/chapter05/stripping.html says don't do it. and also in Ch.6 it comments on --strip-all on all libraries: http://www.linuxfromscratch.org/lfs/view/stable/chapter06/strippingagain.html and specifically does '--strip-debug' on the libraries instead. Looking closely, however, there is no reference to 'strip-unneeded' on the libraries themselves (just binaries). This, combined with my own observed behavior, leads me to believe that the --strip-unneeded option on shared libraries is the root cause of the 'undefined symbol...' errors when linking against the shared libraries. I guess its possible that somehow the --strip-unneeded option to strip is broken under buildroot, but it doesn't seem likely. I run: $ nm libdb-4.3.so and get: nm: libdb-4.3.so: no symbols after its been '--strip-unneeded'-ed. Seems like the right root cause, unless 'strip' is broken?! If I run 'nm' on a not '--strip-unneeded'-ed version of libdb, or any other library, I get all the symbols, and linking is fine. Otherwise, link-time 'undefined symbol' errors. So if nobody else sees this behavior, then I'm really confused... Could someone else please try a 'strip --strip-unneeded' on a lib*.so, and see if you can still link against it afterwards, and what 'nm lib*.so' produces? Is this unique to buildroot devel. envs. only? (P.S.: I ran all this natively in a devel. env. created by buildroot...) --john From rob at landley.net Tue Dec 6 10:59:41 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 11:04:45 2005 Subject: The design of mdev (mini-udev for busybox). In-Reply-To: <20051206192414.17af11bb@cluster.meeting.humbug.org.au> References: <3832.1133825182@brightstareng.com> <200512052130.20973.rob@landley.net> <20051206192414.17af11bb@cluster.meeting.humbug.org.au> Message-ID: <200512061259.42116.rob@landley.net> On Tuesday 06 December 2005 03:24, David Seikel wrote: > Most enlightening. When I finally get around to doing more work on My > Linux, I will give initramfs another go. Paul Fox had most of the same > objections that I had to it. > > On the other hand, for an installer, what goes into mdev plus the extra > stuff I wanted to go in still seem like a very good idea to me. I > shall wait and see. It's not like I was gonna be able to get back to > My Linux any time soon. It seems to me that expanding miscutils/makedevs.c to do what you want might be a better idea. The directory creation functionality was fallout from having mdev mount /tmp automatically, and it's been pointed out that it depends on both /tmp and /sys, and at that point these should probably be documented prerequisites. And if you do the mount before you do the mdev, then you can do the mkdir and such before. However, making makedevs and mdev able to work off of the same config file is a possibility. I'm all for making what you want to do as easy and efficient as possible, I'm just not quite sure the best way to go about it just yet... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 11:00:23 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 11:08:14 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512052218.24283.jzb@aexorsyst.com> References: <200512052218.24283.jzb@aexorsyst.com> Message-ID: <200512061300.23594.rob@landley.net> On Tuesday 06 December 2005 00:18, John Z. Bohach wrote: > This is post in case anyone uses buildroot... The buildroot list is uclibc@uclibc.org. :) (Until such time as Eric chooses to fork off a dedicated uclibc list, that is...) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 11:01:59 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 11:16:28 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512052257.37281.jzb@aexorsyst.com> References: <200512052218.24283.jzb@aexorsyst.com> <0vbap1disn1hdovgsqu39lfjsplcpdd81b@4ax.com> <200512052257.37281.jzb@aexorsyst.com> Message-ID: <200512061301.59378.rob@landley.net> On Tuesday 06 December 2005 00:57, John Z. Bohach wrote: > Okay...here's an idea: > > `strip --strip-unneeded /lib/libuClibc*` See, if "unneeded" is actually needed, I'd personally call that a strip bug. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 11:05:07 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 11:16:41 2005 Subject: Kernel headers trouble In-Reply-To: <20051206161317.GB9632@toucan.gentoo.org> References: <200512061549.11232.farmatito@tiscali.it> <20051206161317.GB9632@toucan.gentoo.org> Message-ID: <200512061305.07987.rob@landley.net> On Tuesday 06 December 2005 10:13, Mike Frysinger wrote: > On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: > > I put thogether a simple script (attached) to check clashes in kernel > > headers. > > so why havent we just done a global sed 's:CONFIG_:BB_CONFIG_:g' yet ? > -mike 1) In my case, I'm trying to migrate the CONFIG_ symbols to ENABLE_ symbols. I wouldn't be against some other prefix if it was shorter to type. (BB_ works for me. We've already got _FEATURE_ on most of the ones that aren't applets.) 2) I'm also calling the CONFIG_ stuff leaking into normal #include space a kernel header bug, since polluting the namespace like that is pretty sucky. Most headers don't do that. The ones that do are broken. At the very least, they should put one or more _ on the front of those. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From vapier at gentoo.org Tue Dec 6 11:10:57 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Dec 6 11:22:54 2005 Subject: Kernel headers trouble In-Reply-To: <200512061305.07987.rob@landley.net> References: <200512061549.11232.farmatito@tiscali.it> <20051206161317.GB9632@toucan.gentoo.org> <200512061305.07987.rob@landley.net> Message-ID: <200512061410.57177.vapier@gentoo.org> On Tuesday 06 December 2005 14:05, Rob Landley wrote: > On Tuesday 06 December 2005 10:13, Mike Frysinger wrote: > > On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: > > > I put thogether a simple script (attached) to check clashes in kernel > > > headers. > > > > so why havent we just done a global sed 's:CONFIG_:BB_CONFIG_:g' yet ? > > 1) In my case, I'm trying to migrate the CONFIG_ symbols to ENABLE_ > symbols. I wouldn't be against some other prefix if it was shorter to type. > (BB_ works for me. We've already got _FEATURE_ on most of the ones that > aren't applets.) so you're planning on replacing all CONFIG_ symbols with ENABLE_ ? > 2) I'm also calling the CONFIG_ stuff leaking into normal #include space a > kernel header bug, since polluting the namespace like that is pretty sucky. > Most headers don't do that. The ones that do are broken. At the very > least, they should put one or more _ on the front of those. certainly, but it's not something that will ever change -mike From rob at landley.net Tue Dec 6 11:13:07 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 11:23:04 2005 Subject: Latest svn revision 12662 compilation broken In-Reply-To: <20051206090554.GB12749@aon.at> References: <200512041415.43580.farmatito@tiscali.it> <200512051717.31994.rob@landley.net> <20051206090554.GB12749@aon.at> Message-ID: <200512061313.07819.rob@landley.net> On Tuesday 06 December 2005 03:05, Bernhard Fischer wrote: > On Mon, Dec 05, 2005 at 05:17:31PM -0600, Rob Landley wrote: > >On Monday 05 December 2005 16:08, Bernhard Fischer wrote: > >> could that be the config namespace biting again? > >> > >> BB_CONFIG_TR vs. the tokenring stuff, just as a very wild guess. > >> > >> Do you see anything suspicious in the preprocessor-output of applets.c? > > > >Huh. That is a thought... > > > >One of the reasons I wanted to move everything over to ENABLE_. > > > >Kernel headers that pollute the namespace like that are broken. Grep > > Do you have an opinion on when we can switch the config namespace over > to BB_CONFIG_*? It's one of the first things queued up for 1.2, and I'd like to yank the CONFIG_ versions entirely (they still need to be generated, but shouldn't be #included) in favor of the ENABLE versions. We could switch over right now: #ifdef CONFIG_ simply becomes #if ENABLE_, and #ifndef CONFIG_ becomes #if !ENABLE_, so there there's nothing the CONFIG versions can do that the ENABLE versions can't. But doing it piecemeal means we examine the uses of them as we switch, which is a definite plus. > IIRC you wanted to wait until we opened the > busybox-1_1-branch and only then switch trunk to BB_CONFIG, yes? Um, I don't want to hold up 1.1.0 for this yes. That's shipping new year's, and we need at least two weeks of a -pre2 out before then. > PS: erik did already switch sysctl to BB_CONFIG, i'd prefer to do the > same for watchdog and tr for the 1.1 release(-candidate).. Why don't you switch just those two over to ENABLE_? It at least gets the current problem resolved. Some people have brought up the possibility of ENABLE_ having clashes with inclusion in other code, but we don't excape every single function name we've got because of this possibility. Improperly sanitized kernel headers polluting the namespace with CONFIG_ symbols is a _bug_, and you only want to run just so far away from bugs before you face them down and brain them with a crowbar. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 11:08:02 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 11:23:21 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512060920.01212.jzb@aexorsyst.com> References: <13980.1133887496@brightstareng.com> <200512060920.01212.jzb@aexorsyst.com> Message-ID: <200512061308.03006.rob@landley.net> On Tuesday 06 December 2005 11:20, John Z. Bohach wrote: > > we use --strip-unneeded too, and it's fine. but it's fine for > > runtime. is it perhaps the case that libraries stripped like > > that can no longer be used in development? > > BINGO. Executables that have been linked have addresses hardwired where > the symbols were. The library code didn't change, but '$(LD) ... > -l{somelib} ...etc' won't find the symbols, and you'll get undefined symbol > errors. How can there be enough information to resolve the symbol at runtime, but not enough information to resolve the symbol at compile time? Runtime dynamic linking is still doing a lookup by name on the symbol, last I checked. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From jzb at aexorsyst.com Tue Dec 6 11:12:19 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Tue Dec 6 11:23:51 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512061308.03006.rob@landley.net> References: <13980.1133887496@brightstareng.com> <200512060920.01212.jzb@aexorsyst.com> <200512061308.03006.rob@landley.net> Message-ID: <200512061112.19981.jzb@aexorsyst.com> On Tuesday 06 December 2005 11:08, Rob Landley wrote: > On Tuesday 06 December 2005 11:20, John Z. Bohach wrote: > > > we use --strip-unneeded too, and it's fine. but it's fine for > > > runtime. is it perhaps the case that libraries stripped like > > > that can no longer be used in development? > > > > BINGO. Executables that have been linked have addresses hardwired where > > the symbols were. The library code didn't change, but '$(LD) ... > > -l{somelib} ...etc' won't find the symbols, and you'll get undefined > > symbol errors. > > How can there be enough information to resolve the symbol at runtime, but > not enough information to resolve the symbol at compile time? Runtime > dynamic linking is still doing a lookup by name on the symbol, last I > checked. > > Rob Haven't gotten to runtime for those specific packages involved in the 'undefined symbol' errors. Can't get past linking... From rob at landley.net Tue Dec 6 11:24:15 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 11:24:26 2005 Subject: Kernel headers trouble In-Reply-To: <200512061549.11232.farmatito@tiscali.it> References: <200512061549.11232.farmatito@tiscali.it> Message-ID: <200512061324.16064.rob@landley.net> On Tuesday 06 December 2005 08:49, Tito wrote: > So it seems a good idea to change CONFIG_TR and CONFIG_WATCHDOG to > CONFIG_BB_* before the next release. > Rob, if you want I can try to make a patch for it Sounds like the way to go for 1.1. Have at. > Ciao, > Tito Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From robin.farine at terminus.org Tue Dec 6 11:29:29 2005 From: robin.farine at terminus.org (Robin Farine) Date: Tue Dec 6 11:35:50 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512061048.59423.jzb@aexorsyst.com> References: <20051206161931.GD9632@toucan.gentoo.org> <20051206181010.GE9632@toucan.gentoo.org> <200512061048.59423.jzb@aexorsyst.com> Message-ID: <200512062029.29150.rfarine@tilia.local> On Tuesday December 6 2005 19:48, John Z. Bohach wrote: > I guess its possible that somehow the --strip-unneeded option to > strip is broken under buildroot, but it doesn't seem likely. I > run: > > $ nm libdb-4.3.so > > and get: > > nm: libdb-4.3.so: no symbols > What matters for linking against an ELF shared library are the ".dynsym" and ".dynstr" sections which are *not* stripped, whatever the option strip is passed, or it means that there is a huge bug in your binutils. Use "nm -D libdb-4.3.so" instead. > after its been '--strip-unneeded'-ed. Seems like the right root > cause, unless 'strip' is broken?! Are you sure you are not linking against a stripped archive library? Plain object files would suffer from 'strip --strip-unneeded'. Robin From jzb at aexorsyst.com Tue Dec 6 11:46:08 2005 From: jzb at aexorsyst.com (John Z. Bohach) Date: Tue Dec 6 11:53:13 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <20051206182140.GG9632@toucan.gentoo.org> References: <13980.1133887496@brightstareng.com> <200512060920.01212.jzb@aexorsyst.com> <20051206182140.GG9632@toucan.gentoo.org> Message-ID: <200512061146.08526.jzb@aexorsyst.com> On Tuesday 06 December 2005 10:21, Mike Frysinger wrote: > On Tue, Dec 06, 2005 at 09:20:01AM -0800, John Z. Bohach wrote: > > On Tuesday 06 December 2005 08:44, Paul Fox wrote: > > > we use --strip-unneeded too, and it's fine. but it's fine for > > > runtime. is it perhaps the case that libraries stripped like > > > that can no longer be used in development? > > > > BINGO. Executables that have been linked have addresses hardwired where > > the symbols were. > > no, that isnt how linking works > > executables store a list of all needed external symbols and a list of > all needed libraries > > for example: > $ echo 'int foo() { return 123; }' > libfoo.c > $ gcc -fPIC -shared -s libfoo.c -o libfoo.so > $ strip --strip-unneeded libfoo.so > $ readelf -s libfoo.so | grep foo > 16: 0000000000000678 11 FUNC GLOBAL DEFAULT 10 foo > > $ cat << EOF > striptest.c > #include > extern int foo(void); > int main() { printf("%i\n", foo()); return 0; } > EOF > $ gcc striptest.c -L. -Wl,-rpath,. -lfoo -o striptest > $ readelf -a striptest | grep foo > 0x0000000000000001 (NEEDED) Shared library: [libfoo.so] > 7: 0000000000000000 11 FUNC GLOBAL DEFAULT UND foo > $ ./striptest > 123 >1 > seems to me it worked just fine > -mike Well, thanks for the comments. What you all are saying is true, I'll focus in on the cross-toolchain, which is what its looking like, since STRIP gets defined as i486-linux-strip in my buildroot...What I do know is that if I don't STRIP the shared libs, then all is fine even for the cross-toolchain. Thanks again... (P.S.: stripping --strip-unneeded natively is working fine, so I guess its just the cross-toolchain stripper that causes problems for me). From ps.m at gmx.net Tue Dec 6 12:02:11 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Tue Dec 6 12:10:58 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512061048.59423.jzb@aexorsyst.com> Message-ID: On Tue, 6 Dec 2005, John Z. Bohach wrote: > On Tuesday 06 December 2005 10:10, Mike Frysinger wrote: > > On Tue, Dec 06, 2005 at 11:44:56AM -0500, Paul Fox wrote: > > > > > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > > > > > > > > > which is not fine, because all symbol information from the libraries > > > > > is now removed, and whenever a linker tries linking against thusly > > > > > stripped libraries, you get "undefined symbol..." errors. > > > > > > > > cant say ive had this issue before and as solar pointed out, we've > > > > been using --strip-unneeded on *all* shared libraries for quite a long > > > > time now without any linking issues > > > > > > we use --strip-unneeded too, and it's fine. but it's fine for > > > runtime. is it perhaps the case that libraries stripped like > > > that can no longer be used in development? > > > > no, because we're using it in Gentoo > > > > that means every single Gentoo user has every single shared library > > stripped with --strip-unneeded > > > > i have yet to see a bug reported where someone was unable to link > > against a library ... and since it's Gentoo, everytime a package is > > installed, it's compiled and linked on every system > > -mike > > Can't speak to gentoo, but I can tell you what I've observed myself when > trying to build buildroot in a development environment built by buildroot. > Once I commented out the 'strip'-ing of ncurses, berkelydb, etc., things like > perl, 'make menuconfig' of buildroot itself, etc. all work. Otherwise, > "undefined symbol ..." error. LFS chapter 5 comments on stripping static > libraries: > > http://www.linuxfromscratch.org/lfs/view/stable/chapter05/stripping.html > > says don't do it. > > and also in Ch.6 it comments on --strip-all on all libraries: > > http://www.linuxfromscratch.org/lfs/view/stable/chapter06/strippingagain.html > > and specifically does '--strip-debug' on the libraries instead. Looking > closely, however, there is no reference to 'strip-unneeded' on the libraries > themselves (just binaries). > > This, combined with my own observed behavior, leads me to believe that the > --strip-unneeded option on shared libraries is the root cause of the > 'undefined symbol...' errors when linking against the shared libraries. > > I guess its possible that somehow the --strip-unneeded option to strip is > broken under buildroot, but it doesn't seem likely. I run: > > $ nm libdb-4.3.so why not try nm -D --defined-only libdb-4.3.so ? > > and get: > > nm: libdb-4.3.so: no symbols > > after its been '--strip-unneeded'-ed. Seems like the right root cause, unless > 'strip' is broken?! > > If I run 'nm' on a not '--strip-unneeded'-ed version of libdb, or any other > library, I get all the symbols, and linking is fine. Otherwise, link-time > 'undefined symbol' errors. > > So if nobody else sees this behavior, then I'm really confused... > > Could someone else please try a 'strip --strip-unneeded' on a lib*.so, and > see if you can still link against it afterwards, and what 'nm lib*.so' > produces? Is this unique to buildroot devel. envs. only? > > (P.S.: I ran all this natively in a devel. env. created by buildroot...) > > --john > > > -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From ps.m at gmx.net Tue Dec 6 12:04:22 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Tue Dec 6 12:11:39 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512060920.01212.jzb@aexorsyst.com> Message-ID: On Tue, 6 Dec 2005, John Z. Bohach wrote: > On Tuesday 06 December 2005 08:44, Paul Fox wrote: > > > > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > > > > > > > which is not fine, because all symbol information from the libraries > > > > is now removed, and whenever a linker tries linking against thusly > > > > stripped libraries, you get "undefined symbol..." errors. > > > > > > cant say ive had this issue before and as solar pointed out, we've been > > > using --strip-unneeded on *all* shared libraries for quite a long time > > > now without any linking issues > > > > we use --strip-unneeded too, and it's fine. but it's fine for > > runtime. is it perhaps the case that libraries stripped like > > that can no longer be used in development? > > > > BINGO. Executables that have been linked have addresses hardwired where the > symbols were. The library code didn't change, but '$(LD) ... -l{somelib} > ...etc' won't find the symbols, and you'll get undefined symbol errors. > > The most obvious side effect of this is try running a 'make menuconfig' of > buildroot in a self-hosted environment, i.e. one created by buildroot. Since > lib/libncurses*so* is stripped of symbols, you'll get undefined symbol > "libgettext_...' errors, etc. if you look close, then you'll see that this one does not have to do anything w/ ncurses (looks like gettext missing) Peter > > > > paul > > =--------------------- > > paul fox, pgf@brightstareng.com > > _______________________________________________ > > busybox mailing list > > busybox@busybox.net > > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From ps.m at gmx.net Tue Dec 6 12:06:22 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Tue Dec 6 12:15:36 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512060751.46463.jzb@aexorsyst.com> Message-ID: On Tue, 6 Dec 2005, John Z. Bohach wrote: > On Tuesday 06 December 2005 01:25, Peter S. Mazinger wrote: > > are you sure you used the correct strip (it is that you render your libs > > useless, if you use the host strip against the cross-compiled libs) > > > > Peter > > Sorry, I thought this would be more obvious. I don't want to start a big long > thread, so specifically, in buildroot/packages/Makefile.in, we have: > > STRIP=$(TARGET_CROSS)strip --remove-section=.comment --remove-section=.note > > which is fine. But then later, specific package makefiles do this: generally yes, .note should be stripped only if it is unallocated > > package/ncurses.mk: > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libncurses.so.$(NCURSES_VER) > > and package/berkelybd.mk > -$(STRIP) --strip-unneeded $(TARGET_DIR)/lib/libdb*so* > > which is not fine, because all symbol information from the libraries is now > removed, and whenever a linker tries linking against thusly stripped > libraries, you get "undefined symbol..." errors. list those undefined ones... Peter > > Just an FYI, and a learning point. > > --john > > P.S.: freetype, directfb, libpng, libsys, and more all suffer from this, so > whatever the thinking was, it was contagious... > -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From rep.nop at aon.at Tue Dec 6 12:08:29 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Dec 6 12:15:49 2005 Subject: Kernel headers trouble In-Reply-To: <200512061305.07987.rob@landley.net> References: <200512061549.11232.farmatito@tiscali.it> <20051206161317.GB9632@toucan.gentoo.org> <200512061305.07987.rob@landley.net> Message-ID: <20051206200829.GL7230@aon.at> On Tue, Dec 06, 2005 at 01:05:07PM -0600, Rob Landley wrote: >On Tuesday 06 December 2005 10:13, Mike Frysinger wrote: >> On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: >> > I put thogether a simple script (attached) to check clashes in kernel >> > headers. >> >> so why havent we just done a global sed 's:CONFIG_:BB_CONFIG_:g' yet ? >> -mike > >1) In my case, I'm trying to migrate the CONFIG_ symbols to ENABLE_ symbols. >I wouldn't be against some other prefix if it was shorter to type. (BB_ >works for me. We've already got _FEATURE_ on most of the ones that aren't >applets.) Rob, we are talking about *{,/*/}Config.in where we need BB_CONFIG as opposed to the CONFIG_ we have now. mkdep then will generate ENABLE_ out of the BB_CONFIG_ kconfig, see? Nothing is holding us back to just s/CONFIG_/BB_CONFIG_/g right now, just touching the three aforementioned applets is the minimum we should do in the very near future (tito volunteered to do this earlier today). > >2) I'm also calling the CONFIG_ stuff leaking into normal #include space a >kernel header bug, since polluting the namespace like that is pretty sucky. >Most headers don't do that. The ones that do are broken. At the very least, >they should put one or more _ on the front of those. > >Rob >-- >Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. >I do not think it means what you think it means. >_______________________________________________ >busybox mailing list >busybox@busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox > From vapier at gentoo.org Tue Dec 6 12:10:50 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Dec 6 12:15:57 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512062029.29150.rfarine@tilia.local> References: <20051206161931.GD9632@toucan.gentoo.org> <20051206181010.GE9632@toucan.gentoo.org> <200512061048.59423.jzb@aexorsyst.com> <200512062029.29150.rfarine@tilia.local> Message-ID: <20051206201050.GA9689@toucan.gentoo.org> On Tue, Dec 06, 2005 at 08:29:29PM +0100, Robin Farine wrote: > On Tuesday December 6 2005 19:48, John Z. Bohach wrote: > > > I guess its possible that somehow the --strip-unneeded option to > > strip is broken under buildroot, but it doesn't seem likely. I > > run: > > > > $ nm libdb-4.3.so > > > > and get: > > > > nm: libdb-4.3.so: no symbols > > > > What matters for linking against an ELF shared library are the > ".dynsym" and ".dynstr" sections which are *not* stripped, whatever > the option strip is passed, or it means that there is a huge bug in > your binutils. Use "nm -D libdb-4.3.so" instead. indeed personally i use `readelf -s libdb-4.3.so` myself -mike From farmatito at tiscali.it Tue Dec 6 12:53:11 2005 From: farmatito at tiscali.it (Tito) Date: Tue Dec 6 13:02:57 2005 Subject: [PATCH] move CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* Message-ID: <200512062153.11743.farmatito@tiscali.it> Hi, this patch moves CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* so that there are no more conflicts with some kernel headers. It is tested and works fine for me. Please apply if you don't have a better solution. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: enable.patch Type: text/x-diff Size: 6021 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051206/b34209e1/enable.bin From vapier at gentoo.org Tue Dec 6 13:18:28 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Tue Dec 6 13:34:37 2005 Subject: [buildroot] $(STRIP) --strip-unneeded on a SHARED library...WHY? In-Reply-To: <200512061048.59423.jzb@aexorsyst.com> References: <20051206161931.GD9632@toucan.gentoo.org> <20051206181010.GE9632@toucan.gentoo.org> <200512061048.59423.jzb@aexorsyst.com> Message-ID: <200512061618.28561.vapier@gentoo.org> On Tuesday 06 December 2005 13:48, John Z. Bohach wrote: > LFS chapter 5 comments on stripping static libraries: > > http://www.linuxfromscratch.org/lfs/view/stable/chapter05/stripping.html > > says don't do it. what does that have to do with this thread ? this thread is about *shared* libraries, not static ones ... i never commented on static libraries let alone say that --strip-unneeded was safe on them -mike From rep.nop at aon.at Tue Dec 6 13:32:01 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Tue Dec 6 13:38:42 2005 Subject: Kernel headers trouble In-Reply-To: <200512061549.11232.farmatito@tiscali.it> References: <200512061549.11232.farmatito@tiscali.it> Message-ID: <20051206213201.GA3237@aon.at> On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: >CONFIG_TR conflicts with kernel headers > >/usr/src/kernel-headers/include/linux/autoconf.h:1482:#define CONFIG_TR 1 > /usr/src/kernel-headers/include/config/tr.h:1:#define CONFIG_TR 1 > >CONFIG_WATCHDOG conflicts with kernel headers > >/usr/src/kernel-headers/include/linux/autoconf.h:1975:#define CONFIG_WATCHDOG 1 >/usr/src/kernel-headers/include/config/watchdog.h:1:#define CONFIG_WATCHDOG 1 >So it seems a good idea to change CONFIG_TR and CONFIG_WATCHDOG to CONFIG_BB_* >before the next release. >Rob, if you want I can try to make a patch for it Would something like the attached work for you (untested) - switch from CONFIG_ to BB_CONFIG to avoid kconfig namespace pollution with the kernel. -------------- next part -------------- diff -X /home/cow/src/excl -ruNp bb.en.oorig/coreutils/Config.in bb.en/coreutils/Config.in --- bb.en.oorig/coreutils/Config.in 2005-10-09 20:30:45.000000000 +0200 +++ bb.en/coreutils/Config.in 2005-12-06 22:18:33.000000000 +0100 @@ -540,7 +540,7 @@ config CONFIG_TOUCH touch is used to create or change the access and/or modification timestamp of specified files. -config CONFIG_TR +config BB_CONFIG_TR bool "tr" default n help diff -X /home/cow/src/excl -ruNp bb.en.oorig/coreutils/Makefile.in bb.en/coreutils/Makefile.in --- bb.en.oorig/coreutils/Makefile.in 2005-09-24 11:25:33.000000000 +0200 +++ bb.en/coreutils/Makefile.in 2005-12-06 22:18:33.000000000 +0100 @@ -67,7 +67,7 @@ COREUTILS-$(CONFIG_TAIL) += tail.o COREUTILS-$(CONFIG_TEE) += tee.o COREUTILS-$(CONFIG_TEST) += test.o COREUTILS-$(CONFIG_TOUCH) += touch.o -COREUTILS-$(CONFIG_TR) += tr.o +COREUTILS-$(BB_CONFIG_TR) += tr.o COREUTILS-$(CONFIG_TRUE) += true.o COREUTILS-$(CONFIG_TTY) += tty.o COREUTILS-$(CONFIG_UNAME) += uname.o diff -X /home/cow/src/excl -ruNp bb.en.oorig/debian/config-deb bb.en/debian/config-deb --- bb.en.oorig/debian/config-deb 2005-09-20 22:30:07.000000000 +0200 +++ bb.en/debian/config-deb 2005-12-06 22:18:33.000000000 +0100 @@ -125,7 +125,7 @@ CONFIG_FEATURE_FANCY_TAIL=y # CONFIG_TEE is not set CONFIG_TEST=y CONFIG_TOUCH=y -CONFIG_TR=y +BB_CONFIG_TR=y CONFIG_TRUE=y CONFIG_TTY=y CONFIG_UNAME=y @@ -249,7 +249,7 @@ CONFIG_REBOOT=y # CONFIG_MT is not set # CONFIG_STRINGS is not set # CONFIG_TIME is not set -# CONFIG_WATCHDOG is not set +# BB_CONFIG_WATCHDOG is not set # # Linux Module Utilities diff -X /home/cow/src/excl -ruNp bb.en.oorig/debian/config-floppy-udeb-linux bb.en/debian/config-floppy-udeb-linux --- bb.en.oorig/debian/config-floppy-udeb-linux 2005-09-20 22:30:07.000000000 +0200 +++ bb.en/debian/config-floppy-udeb-linux 2005-12-06 22:18:33.000000000 +0100 @@ -107,7 +107,7 @@ CONFIG_TEST=y # test (forced enabled for use with shell) # # CONFIG_TOUCH is not set -# CONFIG_TR is not set +# BB_CONFIG_TR is not set # CONFIG_TRUE is not set # CONFIG_TTY is not set # CONFIG_UNAME is not set @@ -213,7 +213,7 @@ CONFIG_USE_BB_PWD_GRP=y # CONFIG_MT is not set # CONFIG_STRINGS is not set # CONFIG_TIME is not set -# CONFIG_WATCHDOG is not set +# BB_CONFIG_WATCHDOG is not set # # Linux Module Utilities diff -X /home/cow/src/excl -ruNp bb.en.oorig/debian/config-static bb.en/debian/config-static --- bb.en.oorig/debian/config-static 2005-09-20 22:30:07.000000000 +0200 +++ bb.en/debian/config-static 2005-12-06 22:18:33.000000000 +0100 @@ -140,7 +140,7 @@ CONFIG_TEST=y # test (forced enabled for use with shell) # CONFIG_TOUCH=y -CONFIG_TR=y +BB_CONFIG_TR=y CONFIG_TRUE=y CONFIG_TTY=y CONFIG_UNAME=y @@ -287,7 +287,7 @@ CONFIG_MAKEDEVS=y CONFIG_MT=y CONFIG_STRINGS=y CONFIG_TIME=y -CONFIG_WATCHDOG=y +BB_CONFIG_WATCHDOG=y # # Linux Module Utilities diff -X /home/cow/src/excl -ruNp bb.en.oorig/debian/config-udeb bb.en/debian/config-udeb --- bb.en.oorig/debian/config-udeb 2005-09-20 22:30:07.000000000 +0200 +++ bb.en/debian/config-udeb 2005-12-06 22:18:33.000000000 +0100 @@ -128,7 +128,7 @@ CONFIG_TEST=y # test (forced enabled for use with shell) # CONFIG_TOUCH=y -CONFIG_TR=y +BB_CONFIG_TR=y CONFIG_TRUE=y # CONFIG_TTY is not set CONFIG_UNAME=y @@ -252,7 +252,7 @@ CONFIG_USE_BB_PWD_GRP=y # CONFIG_MT is not set # CONFIG_STRINGS is not set # CONFIG_TIME is not set -# CONFIG_WATCHDOG is not set +# BB_CONFIG_WATCHDOG is not set # # Linux Module Utilities diff -X /home/cow/src/excl -ruNp bb.en.oorig/debian/config-udeb-linux bb.en/debian/config-udeb-linux --- bb.en.oorig/debian/config-udeb-linux 2005-09-20 22:30:07.000000000 +0200 +++ bb.en/debian/config-udeb-linux 2005-12-06 22:18:33.000000000 +0100 @@ -128,7 +128,7 @@ CONFIG_TEST=y # test (forced enabled for use with shell) # CONFIG_TOUCH=y -CONFIG_TR=y +BB_CONFIG_TR=y CONFIG_TRUE=y # CONFIG_TTY is not set CONFIG_UNAME=y @@ -252,7 +252,7 @@ CONFIG_USE_BB_PWD_GRP=y # CONFIG_MT is not set # CONFIG_STRINGS is not set # CONFIG_TIME is not set -# CONFIG_WATCHDOG is not set +# BB_CONFIG_WATCHDOG is not set # # Linux Module Utilities diff -X /home/cow/src/excl -ruNp bb.en.oorig/include/applets.h bb.en/include/applets.h --- bb.en.oorig/include/applets.h 2005-10-29 13:07:35.000000000 +0200 +++ bb.en/include/applets.h 2005-12-06 22:20:16.000000000 +0100 @@ -637,7 +637,7 @@ #ifdef CONFIG_SYNC APPLET(sync, sync_main, _BB_DIR_BIN, _BB_SUID_NEVER) #endif -#ifdef CONFIG_BB_SYSCTL +#ifdef BB_CONFIG_SYSCTL APPLET(sysctl, sysctl_main, _BB_DIR_SBIN, _BB_SUID_NEVER) #endif #ifdef CONFIG_SYSLOGD @@ -673,7 +673,7 @@ #ifdef CONFIG_TOUCH APPLET(touch, touch_main, _BB_DIR_BIN, _BB_SUID_NEVER) #endif -#ifdef CONFIG_TR +#ifdef BB_CONFIG_TR APPLET(tr, tr_main, _BB_DIR_USR_BIN, _BB_SUID_NEVER) #endif #ifdef CONFIG_TRACEROUTE @@ -736,7 +736,7 @@ #ifdef CONFIG_WATCH APPLET(watch, watch_main, _BB_DIR_BIN, _BB_SUID_NEVER) #endif -#ifdef CONFIG_WATCHDOG +#ifdef BB_CONFIG_WATCHDOG APPLET(watchdog, watchdog_main, _BB_DIR_SBIN, _BB_SUID_NEVER) #endif #ifdef CONFIG_WC diff -X /home/cow/src/excl -ruNp bb.en.oorig/miscutils/Config.in bb.en/miscutils/Config.in --- bb.en.oorig/miscutils/Config.in 2005-10-29 13:07:35.000000000 +0200 +++ bb.en/miscutils/Config.in 2005-12-06 22:18:33.000000000 +0100 @@ -291,7 +291,7 @@ config CONFIG_TIME When the command finishes, time writes a message to standard output giving timing statistics about this program run. -config CONFIG_WATCHDOG +config BB_CONFIG_WATCHDOG bool "watchdog" default n help diff -X /home/cow/src/excl -ruNp bb.en.oorig/miscutils/Makefile.in bb.en/miscutils/Makefile.in --- bb.en.oorig/miscutils/Makefile.in 2005-10-29 13:07:35.000000000 +0200 +++ bb.en/miscutils/Makefile.in 2005-12-06 22:18:33.000000000 +0100 @@ -29,7 +29,7 @@ MISCUTILS-$(CONFIG_RX) += rx.o MISCUTILS-$(CONFIG_SETSID) += setsid.o MISCUTILS-$(CONFIG_STRINGS) += strings.o MISCUTILS-$(CONFIG_TIME) += time.o -MISCUTILS-$(CONFIG_WATCHDOG) += watchdog.o +MISCUTILS-$(BB_CONFIG_WATCHDOG) += watchdog.o libraries-y+=$(MISCUTILS_DIR)$(MISCUTILS_AR) diff -X /home/cow/src/excl -ruNp bb.en.oorig/procps/Config.in bb.en/procps/Config.in --- bb.en.oorig/procps/Config.in 2005-10-28 19:35:16.000000000 +0200 +++ bb.en/procps/Config.in 2005-12-06 22:20:39.000000000 +0100 @@ -83,7 +83,7 @@ config CONFIG_RENICE Renice alters the scheduling priority of one or more running processes. -config CONFIG_BB_SYSCTL +config BB_CONFIG_SYSCTL bool "sysctl" default n help diff -X /home/cow/src/excl -ruNp bb.en.oorig/procps/Makefile.in bb.en/procps/Makefile.in --- bb.en.oorig/procps/Makefile.in 2005-10-28 19:35:16.000000000 +0200 +++ bb.en/procps/Makefile.in 2005-12-06 22:20:28.000000000 +0100 @@ -16,7 +16,7 @@ PROCPS-$(CONFIG_KILL) += kill.o PROCPS-$(CONFIG_PIDOF) += pidof.o PROCPS-$(CONFIG_PS) += ps.o PROCPS-$(CONFIG_RENICE) += renice.o -PROCPS-$(CONFIG_BB_SYSCTL) += sysctl.o +PROCPS-$(BB_CONFIG_SYSCTL) += sysctl.o PROCPS-$(CONFIG_TOP) += top.o PROCPS-$(CONFIG_UPTIME) += uptime.o PROCPS-$(CONFIG_FUSER) += fuser.o diff -X /home/cow/src/excl -ruNp bb.en.oorig/sysdeps/linux/defconfig bb.en/sysdeps/linux/defconfig --- bb.en.oorig/sysdeps/linux/defconfig 2005-10-09 20:30:46.000000000 +0200 +++ bb.en/sysdeps/linux/defconfig 2005-12-06 22:20:53.000000000 +0100 @@ -134,7 +134,7 @@ CONFIG_TEST=y # test (forced enabled for use with shell) # CONFIG_TOUCH=y -CONFIG_TR=y +BB_CONFIG_TR=y CONFIG_TRUE=y CONFIG_TTY=y CONFIG_UNAME=y @@ -267,7 +267,7 @@ CONFIG_REBOOT=y # CONFIG_RX is not set CONFIG_STRINGS=y CONFIG_TIME=y -# CONFIG_WATCHDOG is not set +# BB_CONFIG_WATCHDOG is not set # # Linux Module Utilities @@ -334,7 +334,7 @@ CONFIG_PS=y # CONFIG_RENICE is not set # CONFIG_TOP is not set CONFIG_UPTIME=y -# CONFIG_BB_SYSCTL is not set +# BB_CONFIG_SYSCTL is not set # # Another Bourne-like Shell From farmatito at tiscali.it Tue Dec 6 14:11:10 2005 From: farmatito at tiscali.it (Tito) Date: Tue Dec 6 14:12:44 2005 Subject: Kernel headers trouble In-Reply-To: <20051206213201.GA3237@aon.at> References: <200512061549.11232.farmatito@tiscali.it> <20051206213201.GA3237@aon.at> Message-ID: <200512062311.10822.farmatito@tiscali.it> On Tuesday 06 December 2005 22:32, Bernhard Fischer wrote: > On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: > > >CONFIG_TR conflicts with kernel headers > > > >/usr/src/kernel-headers/include/linux/autoconf.h:1482:#define CONFIG_TR 1 > > /usr/src/kernel-headers/include/config/tr.h:1:#define CONFIG_TR 1 > > > >CONFIG_WATCHDOG conflicts with kernel headers > > > >/usr/src/kernel-headers/include/linux/autoconf.h:1975:#define CONFIG_WATCHDOG 1 > >/usr/src/kernel-headers/include/config/watchdog.h:1:#define CONFIG_WATCHDOG 1 > > >So it seems a good idea to change CONFIG_TR and CONFIG_WATCHDOG to CONFIG_BB_* > >before the next release. > >Rob, if you want I can try to make a patch for it > > Would something like the attached work for you (untested) Hi, I think yes, it is about the same as i did but with another prefix ( BB_CONFIG vs ENABLE_). Let Rob decide which one he likes better. Ciao, Tito > > - switch from CONFIG_ to BB_CONFIG to avoid kconfig namespace pollution > with the kernel. > From rob at landley.net Tue Dec 6 14:32:19 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 14:33:41 2005 Subject: Kernel headers trouble In-Reply-To: <20051206200829.GL7230@aon.at> References: <200512061549.11232.farmatito@tiscali.it> <200512061305.07987.rob@landley.net> <20051206200829.GL7230@aon.at> Message-ID: <200512061632.19951.rob@landley.net> On Tuesday 06 December 2005 14:08, Bernhard Fischer wrote: > On Tue, Dec 06, 2005 at 01:05:07PM -0600, Rob Landley wrote: > >On Tuesday 06 December 2005 10:13, Mike Frysinger wrote: > >> On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: > >> > I put thogether a simple script (attached) to check clashes in kernel > >> > headers. > >> > >> so why havent we just done a global sed 's:CONFIG_:BB_CONFIG_:g' yet ? > >> -mike > > > >1) In my case, I'm trying to migrate the CONFIG_ symbols to ENABLE_ > > symbols. I wouldn't be against some other prefix if it was shorter to > > type. (BB_ works for me. We've already got _FEATURE_ on most of the > > ones that aren't applets.) > > Rob, we are talking about *{,/*/}Config.in where we need BB_CONFIG as > opposed to the CONFIG_ we have now. _We_ aren't broken. Their kernel headers are. (Admittedly it's a common mistake we could avoid. But the bug isn't ours.) > mkdep then will generate ENABLE_ out of the BB_CONFIG_ kconfig, see? mkdep doesn't generate ENABLE. The makefile generates ENABLE via sed. CONFIG and ENABLE are different _kinds_ of symbols. ENABLE is always present and its value says what it is. CONFIG's value is irrelevant, its presence is what is tested for. > Nothing is holding us back to just s/CONFIG_/BB_CONFIG_/g right now, > just touching the three aforementioned applets is the minimum we should > do in the very near future (tito volunteered to do this earlier today). Actually, tito volunteered to switch them over to ENABLE, which seems the thing to do. CONFIG_TR, CONFIG_WATCHDOG, and what was the third? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 14:36:01 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 14:40:54 2005 Subject: [PATCH] move CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* In-Reply-To: <200512062153.11743.farmatito@tiscali.it> References: <200512062153.11743.farmatito@tiscali.it> Message-ID: <200512061636.01589.rob@landley.net> On Tuesday 06 December 2005 14:53, Tito wrote: > Hi, > this patch moves CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* > so that there are no more conflicts with some kernel headers. > It is tested and works fine for me. Sigh. See the previous email about ENABLE symbols being different kinds of symbols. This patch is conceptually wrong. And in any case, the configuration part doesn't have any problem with it, the problem is that your kernel headers are leaking and polluting the standard namespace in highly inadvisable ways. Busybox only needs to work around it in the C code, not in kconfig or the makefiles. > Please apply if you don't have a better solution. I'll do it right, give me a few minutes... > Ciao, > Tito Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 14:48:56 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 14:49:11 2005 Subject: [PATCH] move CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* In-Reply-To: <200512062153.11743.farmatito@tiscali.it> References: <200512062153.11743.farmatito@tiscali.it> Message-ID: <200512061648.56647.rob@landley.net> On Tuesday 06 December 2005 14:53, Tito wrote: > Hi, > this patch moves CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* > so that there are no more conflicts with some kernel headers. > It is tested and works fine for me. In fact, going back to your original post the only problem I'm seeing is in applets.h, which seems to be the only relevant file your patch is changing. The thing is, if the CONFIG_ leaking was affecting kconfig and the makefiles, then TR and WATCHDOG would simply have been silently switched on. Instead, it's only affecting C code that #includes the polluted headers. And the only instance of that you patched is applets.h. I checked in a possible fix (12707). Does that work for you now? (If not, I need a better understanding of the problem.) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 14:54:35 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 14:54:54 2005 Subject: Kernel headers trouble In-Reply-To: <200512061410.57177.vapier@gentoo.org> References: <200512061549.11232.farmatito@tiscali.it> <200512061305.07987.rob@landley.net> <200512061410.57177.vapier@gentoo.org> Message-ID: <200512061654.35486.rob@landley.net> On Tuesday 06 December 2005 13:10, Mike Frysinger wrote: > On Tuesday 06 December 2005 14:05, Rob Landley wrote: > > On Tuesday 06 December 2005 10:13, Mike Frysinger wrote: > > > On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote: > > > > I put thogether a simple script (attached) to check clashes in kernel > > > > headers. > > > > > > so why havent we just done a global sed 's:CONFIG_:BB_CONFIG_:g' yet ? > > > > 1) In my case, I'm trying to migrate the CONFIG_ symbols to ENABLE_ > > symbols. I wouldn't be against some other prefix if it was shorter to > > type. (BB_ works for me. We've already got _FEATURE_ on most of the ones > > that aren't applets.) > > so you're planning on replacing all CONFIG_ symbols with ENABLE_ ? In the C code for 1.2, yeah. The ENABLE symbols can be used in the preprocessor #tests or they can be tested in normal C code with if() and optimized out. The CONFIG symbols are _only_ useful to the preprocessor, because when they're undefined C blows chunks. They'll still be CONFIG in kconfig because that produces different semantics (defined or undefined) and it would be a big job to rewrite it rather than converting at build time. (And I'm leaving them alone in the makefiles because I don't do makefiles enough to convert to different semantics, and polluted header files don't affect make anyway.) Because of the different semantics, converting them right isn't a simple matter of a sed invocation. (It could be done with sed, but that wouldn't let us properly take avantage of the new semantics.) I'd like the C code to stop including config.h eventually. > > 2) I'm also calling the CONFIG_ stuff leaking into normal #include space > > a kernel header bug, since polluting the namespace like that is pretty > > sucky. Most headers don't do that. The ones that do are broken. At the > > very least, they should put one or more _ on the front of those. > > certainly, but it's not something that will ever change The switchover to ENABLE to should fix it, but that's a side effect of a change with other advantages. As far as Tito can tell, CONFIG_TR and CONFIG_WATCHDOG are the only two with conflicts right now, so they can move over first. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 14:59:47 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 15:00:13 2005 Subject: Kernel headers trouble In-Reply-To: <20051206213201.GA3237@aon.at> References: <200512061549.11232.farmatito@tiscali.it> <20051206213201.GA3237@aon.at> Message-ID: <200512061659.48171.rob@landley.net> On Tuesday 06 December 2005 15:32, Bernhard Fischer wrote: > >So it seems a good idea to change CONFIG_TR and CONFIG_WATCHDOG to > > CONFIG_BB_* before the next release. > >Rob, if you want I can try to make a patch for it > > Would something like the attached work for you (untested) This is an acceptable fallback if the patch I checked in doesn't fix it. In theory, the only problem is in C code, and if C code is using ENABLE_ then life is good. The makefiles and kconfig shouldn't be impacted if the kernel headers contain pink flamingoes in a conga line. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From farmatito at tiscali.it Tue Dec 6 15:05:13 2005 From: farmatito at tiscali.it (Tito) Date: Tue Dec 6 15:06:29 2005 Subject: [PATCH] move CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* In-Reply-To: <200512061648.56647.rob@landley.net> References: <200512062153.11743.farmatito@tiscali.it> <200512061648.56647.rob@landley.net> Message-ID: <200512070005.13183.farmatito@tiscali.it> On Tuesday 06 December 2005 23:48, Rob Landley wrote: > On Tuesday 06 December 2005 14:53, Tito wrote: > > Hi, > > this patch moves CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* > > so that there are no more conflicts with some kernel headers. > > It is tested and works fine for me. > > In fact, going back to your original post the only problem I'm seeing is in > applets.h, which seems to be the only relevant file your patch is changing. > > The thing is, if the CONFIG_ leaking was affecting kconfig and the makefiles, > then TR and WATCHDOG would simply have been silently switched on. Instead, > it's only affecting C code that #includes the polluted headers. And the only > instance of that you patched is applets.h. > > I checked in a possible fix (12707). Does that work for you now? (If not, I > need a better understanding of the problem.) Yes, works fine, thanks. I didn't understand how the bb_config.h stuff works, now i know better..... Ciao, Tito > Rob From rob at landley.net Tue Dec 6 15:05:58 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 15:06:34 2005 Subject: Kernel headers trouble In-Reply-To: <200512062311.10822.farmatito@tiscali.it> References: <200512061549.11232.farmatito@tiscali.it> <20051206213201.GA3237@aon.at> <200512062311.10822.farmatito@tiscali.it> Message-ID: <200512061705.58585.rob@landley.net> On Tuesday 06 December 2005 16:11, Tito wrote: > > Would something like the attached work for you (untested) > > Hi, > I think yes, it is about the same as i did but with another prefix ( > BB_CONFIG vs ENABLE_). Let Rob decide which one he likes better. It's not a question of aesthetics. The problem is that CONFIG_ says the symbol has a certain type of semantics, and ENABLE_ says it has a different type of semantics. CONFIG symbols are either #defined to y, or #undefined. ENABLE symbols are always defined, to either 1 or 0. They get used in different ways. #ifdef ENABLE_BLAH will always be true. if(CONFIG_FEATURE_BLAH && othertest) thingy(); will break the build if the feature is switched off. Renaming a CONFIG_ symbol to ENABLE_ without changing its semantics is wrong. Renaming CONFIG to BB_CONFIG breaks the pattern but doesn't actually violate it. (It makes me wince because you have have to learn that BB_CONFIG works like CONFIG. It's ok because it's still within the realm of the easily guessable, but I'd rather it be uniformly obvious than make them guess in the first place.) > Ciao, > Tito Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From torus0 at gmail.com Tue Dec 6 14:40:17 2005 From: torus0 at gmail.com (Chien-Yu Chen) Date: Tue Dec 6 15:11:21 2005 Subject: route in busybox Message-ID: hi! I was wondering if there is a way to do route, where the destination is not resolved, while leaving others as IP because I have a need to get IP for the default route... if I just do "route" to search for default, I'll get a name for gateway, not IP if I do "route -n", then I get 0.0.0.0 for default... thanks for all the comment chen From rob at landley.net Tue Dec 6 15:09:48 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 15:11:29 2005 Subject: [PATCH] move CONFIG_TR and CONFIG_WATCHDOG to ENABLE_* In-Reply-To: <200512070005.13183.farmatito@tiscali.it> References: <200512062153.11743.farmatito@tiscali.it> <200512061648.56647.rob@landley.net> <200512070005.13183.farmatito@tiscali.it> Message-ID: <200512061709.48877.rob@landley.net> On Tuesday 06 December 2005 17:05, Tito wrote: > > I checked in a possible fix (12707). Does that work for you now? (If > > not, I need a better understanding of the problem.) > > Yes, works fine, thanks. > I didn't understand how the bb_config.h stuff works, > now i know better..... Possibly we need a design.txt under docs with this kind of design notes. Also a few hints on how to write small code, and a few obvious low hanging fruit when attempting to busyboxify an existing applet. (Of course I lean towards just writing a clean minimalistic implementation based on a clear idea of what it should do. Optimizing after the fact is usually harder than starting small and staying there.) > Ciao, > Tito > > > Rob Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Tue Dec 6 16:51:44 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 16:53:53 2005 Subject: route in busybox In-Reply-To: References: Message-ID: <200512061851.44567.rob@landley.net> On Tuesday 06 December 2005 16:40, Chien-Yu Chen wrote: > hi! > > I was wondering if there is a way to do route, where the destination > is not resolved, while leaving others as IP > > because I have a need to get IP for the default route... > > if I just do "route" to search for default, I'll get a name for gateway, > not IP > > if I do "route -n", then I get 0.0.0.0 for default... > thanks for all the comment The busybox and non-busybox route commands are giving me the same result: landley@driftwood:~/busybox/busybox$ ./busybox route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth1 landley@driftwood:~/busybox/busybox$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth1 What exactly are you trying to do again? (And what version of busybox are you using?) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From torus0 at gmail.com Tue Dec 6 19:40:31 2005 From: torus0 at gmail.com (Chien-Yu Chen) Date: Tue Dec 6 19:40:51 2005 Subject: route in busybox In-Reply-To: <200512061851.44567.rob@landley.net> References: <200512061851.44567.rob@landley.net> Message-ID: thanks for replying on most systems (non-busybox) ---------------------- bash-2.05b$ /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0 loopback localhost 255.0.0.0 UG 0 0 0 lo default 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0 -------------------------- the default route is to an IP.. with busybox (I am using v1.01, this was from compiling buildroot) if the gateway to the default route has a name associated, when I do route, I'll get default name_to_IP if I do route -n, I'll get 0.0.0.0 IP_address I am trying to use vpnc, a vpn client.... In my school environment, once I get an IP with udhcpc, I'll get an internal IP, with default route to an internal gw..... now I'll run vpnc (with universal tunneling device), and set up the default gw to the IP I got from vpnc... however, before I set up the new default gw, I need the IP of the old gw, so that I can add a -host rule to the routing table for the VPN server.... hm...not sure if I made this clear enough.... chen On 12/7/05, Rob Landley wrote: > On Tuesday 06 December 2005 16:40, Chien-Yu Chen wrote: > > hi! > > > > I was wondering if there is a way to do route, where the destination > > is not resolved, while leaving others as IP > > > > because I have a need to get IP for the default route... > > > > if I just do "route" to search for default, I'll get a name for gateway, > > not IP > > > > if I do "route -n", then I get 0.0.0.0 for default... > > thanks for all the comment > > The busybox and non-busybox route commands are giving me the same result: > > landley@driftwood:~/busybox/busybox$ ./busybox route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 > 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth1 > landley@driftwood:~/busybox/busybox$ route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 > 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth1 > > What exactly are you trying to do again? (And what version of busybox are you > using?) From rob at landley.net Tue Dec 6 19:54:41 2005 From: rob at landley.net (Rob Landley) Date: Tue Dec 6 19:54:53 2005 Subject: route in busybox In-Reply-To: References: <200512061851.44567.rob@landley.net> Message-ID: <200512062154.41324.rob@landley.net> On Tuesday 06 December 2005 21:40, Chien-Yu Chen wrote: > thanks for replying > > on most systems (non-busybox) > > ---------------------- > bash-2.05b$ /sbin/route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface 192.168.0.0 * 255.255.255.0 U 0 0 > 0 wlan0 loopback localhost 255.0.0.0 UG 0 0 > 0 lo default 192.168.0.1 0.0.0.0 UG 0 0 > 0 wlan0 -------------------------- Looks saneish. > with busybox (I am using v1.01, this was from compiling buildroot) > > if the gateway to the default route has a name associated, when I do route, > I'll get > > default name_to_IP > > if I do route -n, I'll get > 0.0.0.0 IP_address Do you have /proc mounted? > however, before I set up the new default gw, I need the IP of the old > gw, so that I can add a -host rule to the routing table for the VPN > server.... > > hm...not sure if I made this clear enough.... It's a little fuzzy. First check for /proc. We're looking at /proc/net/route, and if it's not they're we're going to dump an empty list. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rory.vieira at coolview.nl Wed Dec 7 10:06:30 2005 From: rory.vieira at coolview.nl (Rory Vieira) Date: Wed Dec 7 10:06:40 2005 Subject: BusyBox/inittab weirdness In-Reply-To: <200512051357.37937.rob@landley.net> Message-ID: <028d01c5fb58$f30e6d70$0b01a8c0@pluto> Rob, > > Now my inittab start off like: > > ------------------------------- > > > > ::sysinit:echo "Starting up Linux `uname -r`..." > > null::sysinit:/bin/mount -n -t proc proc /proc > > ... > Meaning the console they're attached to is /dev/null. The second line, yes. But as I am omitting the whole thing on line 1, I don't know where that's pointing to. If I remember correctly from the manual, it should be /dev/console (or the current active console) > > The first line shows 'echo' and 'uname' without a path > specification. > > Did you give an absolute path to either one? Nope. > > The second line though is '/bin/mount'! > > _You_ gave an absolute path to mount. Yes I did :) > > Obviously I needed to make the 'mount', 'sh', and 'init' links > > beforehand. Why do I need to do this for mount etc, but not > with echo > > or uname? > > Why did you specify an absolute path for them, but not for > echo and uname? Well, that's what I'm trying to find out *grin* I'm not sure... The first line was copied from my cd-linux project and seemed to work without any hassle. > > If I change the second line to just 'mount...' it claims it > can find mount at all... > > I have no idea what your $PATH is set to. Well, as it is inittab we're talking about... I assume nothing or /bin:/sbin. I really don't know as I haven't set a path yet... The line '::sysinit:echo...' is in fact the first line. I'm setting the path in /etc/rc.d/rcS but that is still a few lines lower in my inittab. In this case I think the obvious question would be: What is BusyBox' default path setting? PS I read that whole thread about the tar/cpio thing. It was extremely interesting to read (even for my level). Now somewhere I read the line about how to use cpio to 'extract' the archive. Any chance you know how to create it using cpio? I'm actually thinking of giving initramfs a try. Until now I have created static images that were initrd's. I've even got as far as to utilize the pivot_root/chroot stuff and got it working too. But it's a pain in the neck, and hard to understand for that matter... I have the idea (or it least hope so) that initramfs is more suitable for my needs. Now my mini initrd simply created a tmpfs, which I fill by extracting a tar file from cd, and pivot to it, so I can clear the memory used by the initrd. I hope this whole step will not be nessesary at all... Cheers, Rory From rob at landley.net Wed Dec 7 12:09:51 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 12:10:16 2005 Subject: BusyBox/inittab weirdness In-Reply-To: <028d01c5fb58$f30e6d70$0b01a8c0@pluto> References: <028d01c5fb58$f30e6d70$0b01a8c0@pluto> Message-ID: <200512071409.51861.rob@landley.net> On Wednesday 07 December 2005 12:06, Rory Vieira wrote: > The second line, yes. But as I am omitting the whole thing on > line 1, I don't know where that's pointing to. If I remember > correctly from the manual, it should be /dev/console (or the > current active console) I read the source code pretty throughly when I was doing my init rewrite, but I don't know if what I remember is what it was doing or what I changed it to do because what it was doing was stupid. I need to dig that back up, or redo it. > > > The first line shows 'echo' and 'uname' without a path > > specification. > > > > Did you give an absolute path to either one? > > Nope. Ok, so when you specify a path in inittab, init shows this path. When you don't specify a path in inittab, init doesn't show a path. Where's the problem again? > > > Obviously I needed to make the 'mount', 'sh', and 'init' links > > > beforehand. Why do I need to do this for mount etc, but not > > > > with echo > > > > > or uname? > > > > Why did you specify an absolute path for them, but not for > > echo and uname? > > Well, that's what I'm trying to find out *grin* You made the inittab file... > > > If I change the second line to just 'mount...' it claims it > > > > can find mount at all... > > > > I have no idea what your $PATH is set to. > > Well, as it is inittab we're talking about... I assume nothing or > /bin:/sbin. I really don't know as I haven't set a path yet... If $PATH is blank, bash will suppose some deeply stupid defaults that, strangely enough, gcc refuses to work with. details: The default path provided by bash (2.05b, anyway), if PATH is unset when you run bash, is: /usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:. Note the "." at the end of the path. If the current directory is in the path anywhere, the gcc component "collect2" will refuse to search the $PATH when looking for "ld", and will thus generally ever find it. It doesn't explain _why_ it can't find ld, it just decides it knows better than the user and silently skips searching the path based on a dislike of one of its components. There is no error message, other than "can't find ld". The fix is simply: export PATH=/bin:/sbin:/usr/bin:/usr/sbin But finding that _out_ involves spending an evening tracing your way through gcc and collect2. And you wonder why my opinion of the Free Software Foundation's code is something less than abject worship? > The line '::sysinit:echo...' is in fact the first line. I'm setting > the path in /etc/rc.d/rcS but that is still a few lines lower in my > inittab. > > In this case I think the obvious question would be: > What is BusyBox' default path setting? Let's see, busybox has libbb/setup_environment.c with DEFAULT_LOGIN_PATH and DEFAULT_ROOT_LOGIN_PATH. So naturally, with such a clean mechanism in place, the various applets which merely have "busybox" painted on the side don't use it. Things like udhcp, ifupdown, and ash all set their own path from a hardwired list. (Largely the same list, actually, but separate copies thereof.) init/init.c also ignores busybox's mechanism, but it at least uses _PATH_STDPATH, which is some kind of standard I vaguely remember looking up a year and change ago when I was poking init. It's posix or some such, and I believe it's in your system header files. > PS I read that whole thread about the tar/cpio thing. It was extremely > interesting to read (even for my level). Now somewhere I read the line > about how to use cpio to 'extract' the archive. Any chance you know > how to create it using cpio? Um, I've done it, but not recently. You can more or less reverse the cpio extract line I gave. if you can't get it to work poke me and I'll take a whack at it, but giving you a divinitive answer involves putting together a quick little "hello world" style initramfs directory, making the cpio.gz, copying that file into the linux build, and actually testing that it does indeed boot properly with that. Thats a good 15 to 20 minutes of work, and most of it involves reading the man pages and trying out what they say. I usually just let the kernel build the sucker for me anyway, since that's so easy. (Just point the initramfs generator at a directory and it'll build the cpio archive from that. No need to use an archiver when there's one built into the kernel compilation...) > I'm actually thinking of giving initramfs > a try. Until now I have created static images that were initrd's. I've > even got as far as to utilize the pivot_root/chroot stuff and got it > working too. With initramfs you have to use switch_root, for reasons I explained in the initramfs docs I sent the kernel guys (It's in 2.6.15-rc1 and up). > But it's a pain in the neck, and hard to understand for > that matter... I have the idea (or it least hope so) that initramfs is > more suitable for my needs. It's pretty cool. Feel free to ask me questions and I'll try to answer them, but read the docs first. > Now my mini initrd simply created a tmpfs, which I fill by extracting a > tar file from cd, and pivot to it, so I can clear the memory used by the > initrd. I hope this whole step will not be nessesary at all... Yup. It's generally pretty straightforward. My firmware-linux build is already doing this, by the way. "http://www.landley.net/code/firmware". I'd hoped to get a new version up this past weekend, but haven't yet due to spiky design issues that aren't responding well to being glossed over. Currently aiming for tonight... :) > Cheers, > Rory Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Wed Dec 7 14:00:09 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 14:00:31 2005 Subject: Darn broken bug tracking system. Message-ID: <200512071600.09462.rob@landley.net> Ok, I have the most recent 50 bugs, but if click on the "how many" field and tell it to show me 999, it shows me 0-0 of 0. With no other changes. MARVELOUS bug system. (And it's all cookies and hidden form entries, so I can't try tweaking the URL to work around the bugs, or bookmark a link if I ever get it to work.) Could somebody please post a list of all 89 current outstanding open busybox bugs to the list so I can triage them before my plane trip tomorrow? I can call the suckers up by number, once I have the list of numbers. But the bug system's sorting and searching infrastructure is too broken for me to be _able_ to make it work. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Wed Dec 7 14:05:55 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 14:06:20 2005 Subject: Darn broken bug tracking system. In-Reply-To: <200512071600.09462.rob@landley.net> References: <200512071600.09462.rob@landley.net> Message-ID: <200512071605.56269.rob@landley.net> On Wednesday 07 December 2005 16:00, Rob Landley wrote: Ok, that's just pathological: APPLICATION ERROR #203 A number was expected for per_page. Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section. The per_page field not currently an entry field, it's the cached value from the previous page and not editable. I just hit the "next" link and got an application error. MARVELOUS piece of code. Immensely useful... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Wed Dec 7 14:27:05 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 14:28:03 2005 Subject: Darn broken bug tracking system. In-Reply-To: <200512071605.56269.rob@landley.net> References: <200512071600.09462.rob@landley.net> <200512071605.56269.rob@landley.net> Message-ID: <200512071627.05935.rob@landley.net> And, after finally beating a list out of the bug system (do not enter _anything_ in the filters. Touching the filters at _all_ leads to an empty list, and it _remembers_ this breakage even if you hit "back", reload, close the tab and re-type the URL at a fresh one...), I finally got my list of bugs, and made a dumb little script to wget them all. The result? Some of the files look like this:

Access Denied.

[ Click here to proceed ]
I have no idea why. No explanation, no nothing. Apparently, the bug system not only hates konqueror, it doesn't like wget either. Luckily the problem seems to be intermittent so I _think_ I've got them all downloaded now. As huge piles of XHTML I have to laboriously chop useful information out of, but it's something. (Yes, I saw the "export list as CSV". That's not the same as being able to get it to work.) You wonder why I've been putting this off? Are you guys seriously telling me this thing is _not_ breaking left and right for you? Or do you just not use it much? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Wed Dec 7 14:56:47 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 14:57:33 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <20051206104634.GC12749@aon.at> References: <200512011102.31369.rob@landley.net> <20051206104634.GC12749@aon.at> Message-ID: <200512071656.48168.rob@landley.net> On Tuesday 06 December 2005 04:46, Bernhard Fischer wrote: > On Thu, Dec 01, 2005 at 11:02:31AM -0600, Rob Landley wrote: > >/busybox/archival/tar.c: In function 'writeTarFile': > >/busybox/archival/tar.c:466: warning: missing sentinel in function call > > that 0 should be NULL. > > >/busybox/coreutils/coreutils.a(nohup.o): In function `close_stdout': > >nohup.c:(.text+0x6a): warning: > >/bin/sh: /busybox/docs/autodocifier.pl: /usr/bin/perl: bad interpreter: No > > such file or directory > > What warning was there for nohup::close_stdout() ? That's exactly what the compiler spit out. (Printing out an empty warning like that sometimes causes gcc 4.0.2 to hang if you attempt a static link.) Bug 531 has a much better output, done by somebody who wasn't using gcc 4.0.2, apparently. :) http://bugs.busybox.net/view.php?id=531 I'm triaging the bug list, and when I finish triaging them I'll fix lots and lots of them. I already fixed #550. No, I didn't close it out. I'm going to post a list of the ones I fixed and the svn commit (in the case of 550, it was 12711) and let whoever can get the bug system to work for them close it out. Most of these aren't hard to fix. What's _hard_ is dealing with the #*%(&@(&% bug system. Probably get dinner first... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From pgf at brightstareng.com Wed Dec 7 15:37:06 2005 From: pgf at brightstareng.com (Paul Fox) Date: Wed Dec 7 15:38:17 2005 Subject: Darn broken bug tracking system. In-Reply-To: rob's message of Wed, 07 Dec 2005 16:00:09 -0600. <200512071600.09462.rob@landley.net> Message-ID: <5075.1133998626@brightstareng.com> > Ok, I have the most recent 50 bugs, but if click on the "how many" field and > tell it to show me 999, it shows me 0-0 of 0. With no other changes. > MARVELOUS bug system. (And it's all cookies and hidden form entries, so I > can't try tweaking the URL to work around the bugs, or bookmark a link if I > ever get it to work.) for others who have trouble with the bug system (i'm pretty sure rob has a copy), there's a a script i wrote (i call it "busybug") which lets you do some primitive access directly from the command line. i posted it to the list a while ago, and i don't seem to have made any changes since then. it's attached to this message here: http://www.busybox.net/lists/busybox/2005-July/015025.html it has a lot fewer buttons and fields than the real bug system, which is good: you'll be less tempted to try and use them. ;-) it uses elinks to do http fetching, so you'll need to have that installed. i looked at switching it to wget, but for some reason i can't remember, it was easier to leave it alone. (i think it was just that elinks gives screen rendering that wget doesn't provide.) "busybug list" gives a complete list of unresolved busybox bugs. "busybug 43" gives the description for #43, somewhat obfuscated by elinks adornment. "busybug -a 43" lists the available file attachments, lets you choose one if there's more than one, and then lets you either save it or display it. this is usually better than trying to cut and paste from the bug system screen. i'm afraid busybug doesn't help with searching, unless "busybug list | grep foo" counts as searching. paul =--------------------- paul fox, pgf@brightstareng.com From rob at landley.net Wed Dec 7 16:18:38 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 16:19:03 2005 Subject: Darn broken bug tracking system. In-Reply-To: <5075.1133998626@brightstareng.com> References: <5075.1133998626@brightstareng.com> Message-ID: <200512071818.39081.rob@landley.net> On Wednesday 07 December 2005 17:37, Paul Fox wrote: > i'm afraid busybug doesn't help with searching, unless > "busybug list | grep foo" counts as searching. I finally defeated the sucker in single combat and got the info I needed out of it. Currently triaging. Here's how far I made it before going to dinner. :) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. -------------- next part -------------- Closed: 550 MAP_SHARED in insmod causes problems in uClinux svn 12711 (me, today) 529 Syntax (macro definition) error stops build svn 12715 (me, today) 498 mount loop device support broken This one's wasn't our bug in the first place. He had devfs support enabled, which breaks stuff. 494 ash prompt corruption svn 11650 (vodz, 2005-09-26) 568 vi displays inserted text incorrectly. svn 11477 (pgf, 2005-09-16) 406 1.01 won't build with shadow passwords disabled Not a problem in 1.1 Fix this (or confirm already fixed): 585 gzip enters infinite busy loop when decompressing a corrupted file bb_full_read() is evil. 496 Gunzip do not report correclty when uncompressing a corrupted gz file Similar to 585. 577 Two minor format string problems in ln (private) 576 inetd does not set argv[0] 549 Wrong SUID handling when invoking busybox binary directly Definitely fix, but the patch is wrong. The busybox multiplexer needs suid, but check_suid should be called when it runs the real applet. 547 tar archive corruption when packing unreadable files Two fixes: get the error code right and check access _before_ writing the header. 543 switch_root fails Sigh, my fault. Check in the right version. 534 "mount -t auto " broken You _allowed_ to specify "-t auto"? Who knew? 531 Several link errors when creating flat executable file Yeah. Fix this. 530 Build of telnet.c fails with older compilers Check. 488 init does not reap zombies when running actions Fixit. 486 busybox wget prepends a '/' to ftp URL's pathname, unlike GNU wget Check. 485 ftpget fetches 0 bytes if ftp server does not support SIZE command Check, but we _really_ need to unify the wget/ftpget implementation in 1.2. 468 rmmod does not report failure Fixit. 467 rmmod does not handle -w and -f flags Ditto. 461 PATCH: route accept bit netmask (x.x.x.x/netmask) Okay. 449 Uninitialized variable in hush shell Okay. 428 Extra space character (0x20) is added to last string option Fixit. 421 httpd applet in non-inet mode creates zombies Ok. 415 vlock accepts any passwd when using shadow Fixit. 410 memory leak in coreutils/md5_sha1_sum.c Ok. 408 tar.c and init.c error - small patch probably already fixed, but make sure. 403 "ifup -a" seems to ignore up/down/pre-up/pre-down in /etc/network/interfaces 402 httpd in inetd mode: POST from IE (6) ends up in 'cannot display page' 395 GNU/kFreeBSD support 394 cp doesn't exit with an error if there isn't enough space left on device 389 Please modify "logread" in Busybox so that it flushes its output 379 Control-C (SIGINT) is ignored or creates zombie processes 373 bb_askpass doesn't flush stdin 362 insmod chatter 356 Answering ARP with invalid response when queried by firewall 355 ZyXEL Kernel /BusyBox GPL violation? 354 Link fails with CONFIG_FEATURE_MOUNT_LOOP 347 tar: Decompression failed returns exit status 0 even error happened 324 start-stop-daemon failed to start up syslogd 316 CONFIG_ symbol collision with linux 2.4 kernel autoconf.h 310 chmod & chown mixup of permissions with symlinks 309 ping -s n localhost , with n smaller then 6 results in wrong timing results 304 sometimes rmmod is unable to remove modules 282 The mount atime and diratime options set all the mount flags 281 mount -at mounts all the file systems, not just those of type 280 [PATCH] Kill annoying log messages in udhcp-client 279 [PATCH] On-demand net module loading fails with CONFIG_FEATURE_IFUPDOWN_IP 278 [PATCH] on-demand module loading fails with 2.6.X 277 Added IPv6 support for tftp and telnet client and a few more new features for both clients (see below) 276 Linux 2.6 module autoloading breaks when support for 2.4 modules is disabled 272 modprobe does not process parameters 251 broadcast address isn't recalculated if ifconfig of a network address with a non-standard netmask 250 gzipping N files produces N-1 bad gz files 249 constify patch 243 cp clone special files instead of copying from them, for example /dev/null 241 Statusbar not working in stdout output mode for wget 238 RPM uses MMAP which may not be portable. 230 pre-emptible 2.6 kernels cannot use busybox "insmod". 228 chown on symlink 225 Implement support for -S and -b flags to `ln' binary. 224 Add --reverse option to run-parts 190 add proper CGI support to the busybox httpd 186 HTTP responses contain LF instead of CRLF; CGI protocol violation 180 ping output is buffered 169 "tar" with a directory argument doesn't extract the directory recursively 154 Possible problem with ARP implementation 145 Fix strange behavior when issue df with pseudo root device(/dev/root). 136 expr get weird results with long numbers 125 Compile Busybox without MMU failed. 112 awk system() returns 256 multipled value 106 Allow Syslog Remote Connections 85 BusyBox 1,0 ftpput and source file path names 77 uuencode do not work correctly for standart uuencoding (not base64) 76 Defined header CONFIG_FEATURE_DEVPTS from config.h doesn't take effect in telnetd.c Category: would be nice. 102 problem with large fdisk partitions Description: System: Familiar Linux 0.8.1 snapshot, running on an iPAQ 3955. Running Busybox's fdisk on a 1GB SD card creates a valid partition table, but putting a filesystem > 256MB on any partition results in Busybox's fdisk being unable to read the partition table (tested for ext2, ext3, reiserfs). Likwise, if the card is formatted on a desktop with regular GNU fdisk, Busybox's fdisk can't read the partition table, which shows up fine in GNU fdisk. The upshot is that the partitions with filesystems can't be mounted via Busybox. Any partitions created that are < 256MB are automounted and work normally, although df -h gives incorrect information. Additional Information The desktop testing system uses a SanDisk ImageMate reader/writer, and runs Debian "sarge" release. The exact size threshold may not be correct: I didn't try to pin down where the change occurs, but I had difficulties with partitions of 1GB, 750MB, and 640MB, so it's possible the threshold is at 512MB. Reply: The current busybox fdisk needs to be thrown out and replaced, for reasons discussed on the list. Patching this problem would be nice, but it needs a complete rewrite in 1.2 so fixing the current code is not my highest priority. 58 Compiling ash.c with DEBUG defined generates link error A) Don't do that then. B) I intend to reimplement the shell situation in 1.2. 465 [PATCH] Options to nc for setting DiffServ DSCP and VLAN user-priority It's a new feature, but small. 436 Duplicate messages suppressing make sure it's configurable... new features: 505 Add support for one applet being setuid for only some users A) New features we haven't started on should hold off until 1.2. B) This would be sudo, no? 115 ifenslave Later. 18 Could not compile vi.c as Standalone A) I really don't care. B) make standalone, queued up for 1.2 for all applets. 478 Three patches to Busybox 1.01 New features. Maybe the ping -f one is relevant to 1.1... 407 Debian's update-alternatives new feature. 132 Implement fork using longjmp New feature, and quite possibly a libc issue. 158 libbb, export it and callable from c program. This is queued for 1.2. No. 455 inetd may leak sockets Inetd is vodz's responsibility. He did a large gratuitous shuffle of the code after this bug was entered, apparently to make it bigger. I had this flamewar already. I'm not touching it. Not my problem. Bug vodz. 14 ZipIt wireless IM device using Busybox-1.00-pre1 Why is this in the bug system? What am I supposed to do about it? This is not a bug in busybox, this is a bug in ZipIt. From jakelly at shtc.net Wed Dec 7 15:49:34 2005 From: jakelly at shtc.net (John Kelly) Date: Wed Dec 7 17:23:01 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512071656.48168.rob@landley.net> References: <200512011102.31369.rob@landley.net> <20051206104634.GC12749@aon.at> <200512071656.48168.rob@landley.net> Message-ID: On Wed, 07 Dec 2005 16:56:47 -0600, Rob Landley wrote: >What's _hard_ is dealing with the #*%(&@(&% bug system. It is poor. I wonder why not use bugzilla. From rob at landley.net Wed Dec 7 20:08:29 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 20:09:26 2005 Subject: What's with the name-calling, vodz? Message-ID: <200512072208.29384.rob@landley.net> Having confirmed that I've never touched libbb/compare_string_array.c, I can only assume the following: > r12690 | vodz | 2005-12-06 06:00:39 -0600 (Tue, 06 Dec 2005) | 1 line > Changed paths: > M /trunk/busybox/include/libbb.h > M /trunk/busybox/miscutils/devfsd.c > M /trunk/busybox/networking/libiproute/ipaddress.c > M /trunk/busybox/networking/libiproute/iproute.c > > restore compare_string_array new interface (make broken by landley) refers to the -funsigned-char change? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Wed Dec 7 22:33:37 2005 From: rob at landley.net (Rob Landley) Date: Wed Dec 7 22:34:02 2005 Subject: Bug triage. Message-ID: <200512080033.37822.rob@landley.net> Ok, I've scored through the bug list, closed a few and sorted the rest. I'll take a whack at confirming and fixing these this weekend. Rob These bugs either are closed or should be: ------------------------------------------ 550 MAP_SHARED in insmod causes problems in uClinux svn 12711 (me, today) 529 Syntax (macro definition) error stops build svn 12715 (me, today) 498 mount loop device support broken This one's wasn't our bug in the first place. He had devfs support enabled, which breaks stuff. 494 ash prompt corruption svn 11650 (vodz, 2005-09-26) 568 vi displays inserted text incorrectly. svn 11477 (pgf, 2005-09-16) 406 1.01 won't build with shadow passwords disabled Not a problem in 1.1 #356 Answering ARP with invalid response when queried by firewall # Busybox doesn't do ethernet bridging or respond to arp requests, those are # functions of the kernel networking stack. #354 Link fails with CONFIG_FEATURE_MOUNT_LOOP # The mount rewrite did away with this. #316 CONFIG_ symbol collision with linux 2.4 kernel autoconf.h # Already fixed. #250 gzipping N files produces N-1 bad gz files # That got fixed! #243 cp clone special files instead of copying from them, for example /dev/null # svn 12100 #238 RPM uses MMAP which may not be portable. # Says who? #230 pre-emptible 2.6 kernels cannot use busybox "insmod". # If kernel preemptibility makes a difference, it ain't us. # 85 BusyBox 1,0 ftpput and source file path names # svn 12184 # 77 uuencode do not work correctly for standart uuencoding (not base64) # Fixed long ago, just not closed out... ----------------------------------------- I think these are fixed, need to confirm: ----------------------------------------- 394 cp doesn't exit with an error if there isn't enough space left on device 304 sometimes rmmod is unable to remove modules It's the - vs _ problem again. 282 The mount atime and diratime options set all the mount flags Obsoleted by mount rewrite, I think. ------------------------------------------------------- We should probably fix this (or confirm already fixed): ------------------------------------------------------- 585 gzip enters infinite busy loop when decompressing a corrupted file bb_full_read() is evil. 496 Gunzip do not report correclty when uncompressing a corrupted gz file Similar to 585. 577 Two minor format string problems in ln (private) 576 inetd does not set argv[0] 549 Wrong SUID handling when invoking busybox binary directly Definitely fix, but the patch is wrong. The busybox multiplexer needs suid, but check_suid should be called when it runs the real applet. 547 tar archive corruption when packing unreadable files Two fixes: get the error code right and check access _before_ writing the header. 543 switch_root fails Sigh, my fault. Check in the right version. 534 "mount -t auto " broken You _allowed_ to specify "-t auto"? Who knew? 531 Several link errors when creating flat executable file Yeah. Fix this. 530 Build of telnet.c fails with older compilers Check. 488 init does not reap zombies when running actions Fixit. 486 busybox wget prepends a '/' to ftp URL's pathname, unlike GNU wget Check. 485 ftpget fetches 0 bytes if ftp server does not support SIZE command Check, but we _really_ need to unify the wget/ftpget implementation in 1.2. 468 rmmod does not report failure Fixit. 467 rmmod does not handle -w and -f flags Ditto. 461 PATCH: route accept bit netmask (x.x.x.x/netmask) Okay. 449 Uninitialized variable in hush shell Okay. 428 Extra space character (0x20) is added to last string option Fixit. 421 httpd applet in non-inet mode creates zombies Ok. 415 vlock accepts any passwd when using shadow Fixit. 410 memory leak in coreutils/md5_sha1_sum.c Ok. 408 tar.c and init.c error - small patch probably already fixed, but make sure. 389 Please modify "logread" in Busybox so that it flushes its output Ok. 373 bb_askpass doesn't flush stdin Simple enough. 362 insmod chatter Agreed. Remember to update usage.h 347 tar: Decompression failed returns exit status 0 even error happened Yup. 324 start-stop-daemon failed to start up syslogd I don't use this one bug I'll take a look... 310 chmod & chown mixup of permissions with symlinks Yup. 309 ping -s n localhost , with n smaller then 6 results in wrong timing results yeah, fix that. (ping -s 1 192.168.1.1) 281 mount -at mounts all the file systems, not just those of type Ok. 280 [PATCH] Kill annoying log messages in udhcp-client Ok. 279 [PATCH] On-demand net module loading fails with CONFIG_FEATURE_IFUPDOWN_IP Ok. 278 [PATCH] on-demand module loading fails with 2.6.X Ok. 277 Added IPv6 support for tftp and telnet client and a few more new features for both clients (see below) If it #configs out cleanly, sure. 276 Linux 2.6 module autoloading breaks when support for 2.4 modules is disabled Ok. 272 modprobe does not process parameters We should make sure this works. Parameters processing got redone... 251 broadcast address isn't recalculated if ifconfig of a network address with a non-standard netmask Ok. (Closer look would be good.) 249 constify patch Ok. (Might already have been done?) 241 Statusbar not working in stdout output mode for wget Ok. 228 chown on symlink Take a look at this. Probably the same as 310. 225 Implement support for -S and -b flags to `ln' binary. Ok. 180 ping output is buffered Ok. 169 "tar" with a directory argument doesn't extract the directory recursively Yes, although this one's actual work. 145 Fix strange behavior when issue df with pseudo root device(/dev/root). I'll give it a whack, sure. 136 expr get weird results with long numbers Possibly a #config option for long long? 112 awk system() returns 256 multipled value Confirm and fixit. 106 Allow Syslog Remote Connections Make sure it's a #config 76 Defined header CONFIG_FEATURE_DEVPTS from config.h doesn't take effect in telnetd.c Ok. ---------------------------------------------------------------------------- Category: would be nice, but I'm unlikely to personally fix it anytime soon, nor would I hold up the release for this. ---------------------------------------------------------------------------- 102 problem with large fdisk partitions Description: System: Familiar Linux 0.8.1 snapshot, running on an iPAQ 3955. Running Busybox's fdisk on a 1GB SD card creates a valid partition table, but putting a filesystem > 256MB on any partition results in Busybox's fdisk being unable to read the partition table (tested for ext2, ext3, reiserfs). Likwise, if the card is formatted on a desktop with regular GNU fdisk, Busybox's fdisk can't read the partition table, which shows up fine in GNU fdisk. The upshot is that the partitions with filesystems can't be mounted via Busybox. Any partitions created that are < 256MB are automounted and work normally, although df -h gives incorrect information. Additional Information The desktop testing system uses a SanDisk ImageMate reader/writer, and runs Debian "sarge" release. The exact size threshold may not be correct: I didn't try to pin down where the change occurs, but I had difficulties with partitions of 1GB, 750MB, and 640MB, so it's possible the threshold is at 512MB. Reply: The current busybox fdisk needs to be thrown out and replaced, for reasons discussed on the list. Patching this problem would be nice, but it needs a complete rewrite in 1.2 so fixing the current code is not my highest priority. 58 Compiling ash.c with DEBUG defined generates link error A) Don't do that then. B) I intend to reimplement the shell situation in 1.2. 465 [PATCH] Options to nc for setting DiffServ DSCP and VLAN user-priority It's a new feature, but small. 436 Duplicate messages suppressing make sure it's configurable... 403 "ifup -a" seems to ignore up/down/pre-up/pre-down in /etc/network/interfaces I don't use this, so can't easily test it. Sounds like a $PATH problem, 421 httpd applet in non-inet mode creates zombies Sounds easy enough, but vodz would complain if somebody else did it. 402 httpd in inetd mode: POST from IE (6) ends up in 'cannot display page' IE expects the server to wait for _it_ to close the connection. Especially in http 1.1 mode. Use the same timeout you would for the start of the connection. 190 add proper CGI support to the busybox httpd Still vodz's playground. 186 HTTP responses contain LF instead of CRLF; CGI protocol violation 379 Control-C (SIGINT) is ignored or creates zombie processes Init needs an overhaul in 1.2. This is unlikely to bite too many people between now and then. 125 Compile Busybox without MMU failed. Maybe. The workaround is just to disable the failing applets, and it might be a uClibc issue. It's also a bit vague what exactly they're asking us to _do_ about this... --------------------------- new features, hold for 1.2: --------------------------- 505 Add support for one applet being setuid for only some users A) New features we haven't started on should hold off until 1.2. B) This would be sudo, no? 115 ifenslave Later. 18 Could not compile vi.c as Standalone A) I really don't care. B) "make standalone" is queued up for 1.2 for all applets, obsoletes this. 478 Three patches to Busybox 1.01 New features. Maybe the ping -f one is relevant to 1.1... 407 Debian's update-alternatives new feature. 132 Implement fork using longjmp New feature, and quite possibly a libc issue. 158 libbb, export it and callable from c program. This is queued for 1.2. 395 GNU/kFreeBSD support A) New feature, 1.2 material at best.. B) Why should we care? (What the heck is kbsd-gnu?) C) glibc-specific. uClibc and newlib? D) Wrong way to do this, we need infrastructure for newlib, uClinux, etc. 224 Add --reverse option to run-parts -ENOPATCH 455 inetd may leak sockets Inetd is vodz's responsibility. He did a large gratuitous shuffle of the code after this bug was entered, apparently to make it bigger. I had this flamewar already. I'm not touching it. Not my problem. Bug vodz. ------------------------------------------------------------------------ Why are these in the bug system? What are we supposed to do about them? ------------------------------------------------------------------------ 14 ZipIt wireless IM device using Busybox-1.00-pre1 Why is this in the bug system? What am I supposed to do about it? This is not a bug in busybox, this is a bug in ZipIt. 355 ZyXEL Kernel /BusyBox GPL violation? Again: we fix this how? (Put it in the hall of shame?) 154 Possible problem with ARP implementation Another "the kernel does ARP, not busybox" issue... -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From yann.morin.1998 at anciens.enib.fr Wed Dec 7 23:55:17 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Wed Dec 7 23:56:03 2005 Subject: Bug triage. In-Reply-To: <200512080033.37822.rob@landley.net> References: <200512080033.37822.rob@landley.net> Message-ID: <1134028517.4397e6e5d1388@imp5-g19.free.fr> Hello Rob, All, Quoting Rob Landley : > 428 Extra space character (0x20) is added to last string option > Fixit. This shall be fixed with my latest modprobe update. > 362 insmod chatter > Agreed. Remember to update usage.h I'll do it tonight. (GMT+0100) > 276 Linux 2.6 module autoloading breaks when support for 2.4 modules is > disabled > Ok. What does your 'Ok' means? Already fixed, or should be fixed? If not yet done, I'll do it tonight. > 272 modprobe does not process parameters > We should make sure this works. Parameters processing got redone... Yep, it should work now. > --------------------------- > new features, hold for 1.2: > --------------------------- May I add a ledman command? More and more SOHO routers, PDAs... use LEDs as status feedback. What about including this simple enough command as an applet for BusyBox? If accepted, I jump in for it. Regards, Yann E. MORIN. -- Yann E. MORIN Roaming in the world... From marc.leeman at gmail.com Wed Dec 7 23:54:13 2005 From: marc.leeman at gmail.com (Marc Leeman) Date: Thu Dec 8 00:40:43 2005 Subject: [gmail] Re: route in busybox In-Reply-To: <200512061851.44567.rob@landley.net> References: <200512061851.44567.rob@landley.net> Message-ID: <20051208075413.GB25754@scorpius.homelinux.org> > The busybox and non-busybox route commands are giving me the same result: Same here, we're using 2 networks with each redundant RJ45 connectors and the busybox route and ifconfig work as expected (for years already). -- greetz, marc Crais I want you to find the fattest target you can. Government house, missile site, McDonald's, whatever. Crichton - Thanks for Sharing scorpius.homelinux.org 2.6.13.2 #1 Fri Sep 23 07:23:21 CEST 2005 GNU/Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://busybox.net/lists/busybox/attachments/20051208/49db7cae/attachment.pgp From rep.nop at aon.at Thu Dec 8 05:26:18 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Dec 8 05:27:30 2005 Subject: What's with the name-calling, vodz? In-Reply-To: <200512072208.29384.rob@landley.net> References: <200512072208.29384.rob@landley.net> Message-ID: <20051208132618.GB3237@aon.at> On Wed, Dec 07, 2005 at 10:08:29PM -0600, Rob Landley wrote: >Having confirmed that I've never touched libbb/compare_string_array.c, I can >only assume the following: > >> r12690 | vodz | 2005-12-06 06:00:39 -0600 (Tue, 06 Dec 2005) | 1 line >> Changed paths: >> M /trunk/busybox/include/libbb.h >> M /trunk/busybox/miscutils/devfsd.c >> M /trunk/busybox/networking/libiproute/ipaddress.c >> M /trunk/busybox/networking/libiproute/iproute.c >> >> restore compare_string_array new interface (make broken by landley) > >refers to the -funsigned-char change? No. see svn log include/libbb.h -r 12581:12582 svn diff include/libbb.h -r 12581:12582 Apparently you (accidentally) reverted the prototype of compare_string_array back to char, which broke the build (at least for me). From rep.nop at aon.at Thu Dec 8 05:42:42 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Dec 8 05:41:59 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <200512071656.48168.rob@landley.net> References: <200512011102.31369.rob@landley.net> <20051206104634.GC12749@aon.at> <200512071656.48168.rob@landley.net> Message-ID: <20051208134242.GC3237@aon.at> On Wed, Dec 07, 2005 at 04:56:47PM -0600, Rob Landley wrote: >On Tuesday 06 December 2005 04:46, Bernhard Fischer wrote: >> On Thu, Dec 01, 2005 at 11:02:31AM -0600, Rob Landley wrote: >> >/busybox/coreutils/coreutils.a(nohup.o): In function `close_stdout': >> >nohup.c:(.text+0x6a): warning: >> >/bin/sh: /busybox/docs/autodocifier.pl: /usr/bin/perl: bad interpreter: No >> > such file or directory >> >> What warning was there for nohup::close_stdout() ? > >That's exactly what the compiler spit out. (Printing out an empty warning >like that sometimes causes gcc 4.0.2 to hang if you attempt a static link.) > >Bug 531 has a much better output, done by somebody who wasn't using gcc 4.0.2, >apparently. :) > >http://bugs.busybox.net/view.php?id=531 IIRC it's ok for nohup regardless of whether it counts either both or one of narrow and wide there, so that should be harmless. I was seeing these undefined references to __isnan and __isinf too when building with i386-linux-uclibc- with a somewhat current uClibc. From hilse at web.de Thu Dec 8 05:36:05 2005 From: hilse at web.de (Hans-Werner Hilse) Date: Thu Dec 8 06:33:00 2005 Subject: route in busybox In-Reply-To: References: <200512061851.44567.rob@landley.net> Message-ID: <2996.134.76.61.248.1134048965.squirrel@gabriel.sub.uni-goettingen.de> Hi, > if I do route -n, I'll get > 0.0.0.0 IP_address This is easy to parse: DEFAULT_GATEWAY=$( /sbin/route -n | awk '/^0.0.0.0/ { print $2; }' ) (obviously I'm using awk here... You might substitute this by grep/sed. > In my school environment, once I get an IP with udhcpc, I'll get an > internal IP, with default route to an internal gw..... If using DHCP, make shure your client doesn't reset the routes after you maipulated them. > now I'll run vpnc (with universal tunneling device), and set up the > default gw to the IP I got from vpnc... > > however, before I set up the new default gw, I need the IP of the old > gw, so that I can add a -host rule to the routing table for the VPN > server.... See above for my suggestion. You'd set up a second line like /sbin/route add -host $VPN_GATEWAY gw $DEFAULT_GATEWAY to actually set that route. -hwh From rob at landley.net Thu Dec 8 08:11:41 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 8 08:20:33 2005 Subject: Bug triage. In-Reply-To: <1134028517.4397e6e5d1388@imp5-g19.free.fr> References: <200512080033.37822.rob@landley.net> <1134028517.4397e6e5d1388@imp5-g19.free.fr> Message-ID: <200512081011.41178.rob@landley.net> On Thursday 08 December 2005 01:55, Yann E. MORIN wrote: > Hello Rob, > All, > > Quoting Rob Landley : > > 428 Extra space character (0x20) is added to last string option > > Fixit. > > This shall be fixed with my latest modprobe update. > > > 362 insmod chatter > > Agreed. Remember to update usage.h > > I'll do it tonight. (GMT+0100) The ones you don't get to I'll take a whack at this weekend. Mention which ones of these you fix on your SVN checkin comment and I'll knock them off the list. > > 276 Linux 2.6 module autoloading breaks when support for 2.4 modules is > > disabled > > Ok. > > What does your 'Ok' means? Already fixed, or should be fixed? > If not yet done, I'll do it tonight. Means should be fixed. I categorized the list in chunks: the first chunk is "already fixed" (the commented out ones are bugs I closed out, the non-commented out ones are the ones I didn't yet). The second chunk is "we should fix this for 1.1". The third chunk is "it would be nice to fix this for 1.1, but if it doesn't get fixed I'll live." The rest are hold for 1.2, bad idea, not an actual bug, etc. > > 272 modprobe does not process parameters > > We should make sure this works. Parameters processing got redone... > > Yep, it should work now. Pull up the bug and read the long description before closing these out, sometimes it has specific tests. > > --------------------------- > > new features, hold for 1.2: > > --------------------------- > > May I add a ledman command? More and more SOHO routers, PDAs... use LEDs as > status feedback. What about including this simple enough command as an > applet for BusyBox? > If accepted, I jump in for it. And LED control command? Sounds right up busybox's alley. If it's small and simple and #configs out cleanly, sure why not. But I'm not holding up the release for it, so get it in quick. :) > Regards, > Yann E. MORIN. Rob (And now, I have to catch a plane. Queue Kermit: "With that tongue? No way.") -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Thu Dec 8 08:15:40 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 8 08:21:55 2005 Subject: Bug triage. In-Reply-To: <200512080033.37822.rob@landley.net> References: <200512080033.37822.rob@landley.net> Message-ID: <200512081015.40526.rob@landley.net> On Thursday 08 December 2005 00:33, Rob Landley wrote: > 136 expr get weird results with long numbers > Possibly a #config option for long long? Make that a global #config option. We have several applets that do long long math if we give them a config option. We should unify that under one #config option, because if you need it in one place you need it everywhere, and maybe we can unify the code a bit in 1.2. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Thu Dec 8 08:21:12 2005 From: rob at landley.net (Rob Landley) Date: Thu Dec 8 08:39:49 2005 Subject: Proof positive the "signedness of char *" warning is useless. In-Reply-To: <20051208134242.GC3237@aon.at> References: <200512071656.48168.rob@landley.net> <20051208134242.GC3237@aon.at> Message-ID: <200512081021.12615.rob@landley.net> On Thursday 08 December 2005 07:42, Bernhard Fischer wrote: > On Wed, Dec 07, 2005 at 04:56:47PM -0600, Rob Landley wrote: > >On Tuesday 06 December 2005 04:46, Bernhard Fischer wrote: > >> On Thu, Dec 01, 2005 at 11:02:31AM -0600, Rob Landley wrote: > >> >/busybox/coreutils/coreutils.a(nohup.o): In function `close_stdout': > >> >nohup.c:(.text+0x6a): warning: > >> >/bin/sh: /busybox/docs/autodocifier.pl: /usr/bin/perl: bad interpreter: > >> > No such file or directory > >> > >> What warning was there for nohup::close_stdout() ? > > > >That's exactly what the compiler spit out. (Printing out an empty warning > >like that sometimes causes gcc 4.0.2 to hang if you attempt a static > > link.) > > > >Bug 531 has a much better output, done by somebody who wasn't using gcc > > 4.0.2, apparently. :) > > > >http://bugs.busybox.net/view.php?id=531 > > IIRC it's ok for nohup regardless of whether it counts either both or > one of narrow and wide there, so that should be harmless. I have a reproduction sequence where attempting to spit out the empty version of this warning hangs a static build under gcc 4.0.2. (This is clearly a gcc bug, but "harmless" is a bit strong in this case...) > I was seeing these undefined references to __isnan and __isinf too when > building with i386-linux-uclibc- with a somewhat current uClibc. I think that's either a uClibc floating point issue or we need a clearer guard around floating point support somewhere. I've got it queued up to look at this weekend. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From torus0 at gmail.com Thu Dec 8 09:44:12 2005 From: torus0 at gmail.com (Chien-Yu Chen) Date: Thu Dec 8 09:46:23 2005 Subject: [gmail] Re: route in busybox In-Reply-To: <20051208075413.GB25754@scorpius.homelinux.org> References: <200512061851.44567.rob@landley.net> <20051208075413.GB25754@scorpius.homelinux.org> Message-ID: this would work too...the program I am using has the word "default" hard coded in... just need to change that to 0.0.0.0 now...but thanks for every one.. chen From yann.morin.1998 at anciens.enib.fr Thu Dec 8 10:54:04 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Thu Dec 8 10:55:19 2005 Subject: Bug triage. In-Reply-To: <200512081011.41178.rob@landley.net> References: <200512080033.37822.rob@landley.net> <1134028517.4397e6e5d1388@imp5-g19.free.fr> <200512081011.41178.rob@landley.net> Message-ID: <200512081954.04344.yann.morin.1998@anciens.enib.fr> Hello all! Rob, On Thursday 08 December 2005 171, Rob Landley wrote: > The ones you don't get to I'll take a whack at this weekend. Mention which > ones of these you fix on your SVN checkin comment and I'll knock them off the > list. Do I have svn write access? If so, I didn't ask for, did I? Anyway, I won't do any commit, because I don't (yet?) deserve write access to svn. My work's going to the list. > > > 272 modprobe does not process parameters > > > We should make sure this works. Parameters processing got redone... > > Yep, it should work now. > Pull up the bug and read the long description before closing these out, > sometimes it has specific tests. Right. > > May I add a ledman command? More and more SOHO routers, PDAs... use LEDs as > > status feedback. What about including this simple enough command as an > > applet for BusyBox? > And LED control command? Sounds right up busybox's alley. If it's small and > simple and #configs out cleanly, sure why not. > But I'm not holding up the release for it, so get it in quick. :) I was thinking of bb-1.2, anyway. Don't hold your breath! :-) > (And now, I have to catch a plane. Queue Kermit: "With that tongue? No > way.") Had a nice fly? 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 Thu Dec 8 16:42:52 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu Dec 8 16:41:13 2005 Subject: Makefile tweak for -lm? In-Reply-To: <200512041207.28112.rob@landley.net> References: <200512011532.14120.rob@landley.net> <200512022139.05018.rob@landley.net> <20051203041726.GD2240@toucan.gentoo.org> <200512041207.28112.rob@landley.net> Message-ID: <20051209004252.GE3237@aon.at> On Sun, Dec 04, 2005 at 12:07:27PM -0600, Rob Landley wrote: >On Friday 02 December 2005 22:17, Mike Frysinger wrote: >> > The old problem I always have with makefiles is "what order does this >> > happen in". How do I know that LIBRARIES += $(needlibm-y) will be >> > evaluated after needlibm-y gets set in all the places it needs to be? >> >> thats what := means versus = >> >> when you do := make will evaluate the stuff right then ... but if you >> use =, the variable wont be evaluated until it's actually needed >> >> a1 = $(b) >> a2 := $(b) >> b = c >> all: >> @echo a1: $(a1) a2: $(a2) >> >> the output here will be: >> a1: c a2: > >Oh. > >That makes much more sense. I will ci the attached patch tomorrow unless somebody objects. This fixes the undefined references (from sort_big) of __isnan and __isinf i was seeing and is listed in bug #531. Didn't look at the warning from uClibs about __fpending yet, but i'm under the impression that for static linking the msg in link_warning() is empty and shouldn't (?) be emitted in this case. -------------- next part -------------- Index: Rules.mak =================================================================== --- Rules.mak (revision 12766) +++ Rules.mak (working copy) @@ -146,6 +146,8 @@ OPTIMIZATIONS:=$(OPTIMIZATION) -fomit-fr # prone to casual user adjustment. # +LIBRARIES:= + ifeq ($(strip $(CONFIG_LFS)),y) # For large file summit support CFLAGS+=-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 @@ -153,10 +155,10 @@ endif ifeq ($(strip $(CONFIG_DMALLOC)),y) # For testing mem leaks with dmalloc CFLAGS+=-DDMALLOC - LIBRARIES:=-ldmalloc + LIBRARIES+=-ldmalloc else ifeq ($(strip $(CONFIG_EFENCE)),y) - LIBRARIES:=-lefence + LIBRARIES+=-lefence endif endif ifeq ($(strip $(CONFIG_DEBUG)),y) @@ -176,6 +178,10 @@ ifeq ($(strip $(CONFIG_SELINUX)),y) LIBRARIES += -lselinux endif +ifeq ($(strip $(need-libm-y)),y) + LIBRARIES += -lm +endif + ifeq ($(strip $(PREFIX)),) PREFIX:=`pwd`/_install endif Index: coreutils/Makefile.in =================================================================== --- coreutils/Makefile.in (revision 12766) +++ coreutils/Makefile.in (working copy) @@ -83,6 +83,8 @@ COREUTILS-$(CONFIG_YES) += yes.o libraries-y+=$(COREUTILS_DIR)$(COREUTILS_AR) +need-libm-$(CONFIG_FEATURE_SORT_BIG) := y + $(COREUTILS_DIR)$(COREUTILS_AR): $(patsubst %,$(COREUTILS_DIR)%, $(COREUTILS-y)) $(AR) $(ARFLAGS) $@ $(patsubst %,$(COREUTILS_DIR)%, $(COREUTILS-y)) Index: miscutils/Makefile.in =================================================================== --- miscutils/Makefile.in (revision 12766) +++ miscutils/Makefile.in (working copy) @@ -33,12 +33,7 @@ MISCUTILS-$(CONFIG_WATCHDOG) += watch libraries-y+=$(MISCUTILS_DIR)$(MISCUTILS_AR) -needlibm-y:= -needlibm-$(CONFIG_DC) := y - -ifeq ($(needlibm-y),y) - LIBRARIES += -lm -endif +need-libm-$(CONFIG_DC) := y $(MISCUTILS_DIR)$(MISCUTILS_AR): $(patsubst %,$(MISCUTILS_DIR)%, $(MISCUTILS-y)) $(AR) $(ARFLAGS) $@ $(patsubst %,$(MISCUTILS_DIR)%, $(MISCUTILS-y)) Index: Makefile =================================================================== --- Makefile (revision 12766) +++ Makefile (working copy) @@ -207,6 +207,7 @@ all: busybox busybox.links doc # In this section, we need .config -include $(top_builddir)/.config.cmd include $(patsubst %,%/Makefile.in, $(SRC_DIRS)) +include $(top_srcdir)/Rules.mak -include $(top_builddir)/.depend endif # ifneq ($(strip $(HAVE_DOT_CONFIG)),y) Index: editors/Makefile.in =================================================================== --- editors/Makefile.in (revision 12766) +++ editors/Makefile.in (working copy) @@ -20,12 +20,7 @@ EDITOR_OBJ:= $(patsubst %.c,$(EDITOR_DIR libraries-y+=$(EDITOR_DIR)$(EDITOR_AR) -needlibm-y:= -needlibm-$(CONFIG_FEATURE_AWK_MATH) := y - -ifeq ($(needlibm-y),y) - LIBRARIES += -lm -endif +need-libm-$(CONFIG_FEATURE_AWK_MATH) := y $(EDITOR_DIR)$(EDITOR_AR): $(patsubst %,$(EDITOR_DIR)%, $(EDITOR-y)) $(AR) $(ARFLAGS) $@ $(patsubst %,$(EDITOR_DIR)%, $(EDITOR-y)) From Mark.Jessee at gdcanada.com Thu Dec 8 17:07:05 2005 From: Mark.Jessee at gdcanada.com (Jessee, Mark) Date: Thu Dec 8 17:30:41 2005 Subject: read-only root fs with Busybox? Message-ID: <1125D9E6416F00489EA977418E764B4FE4FAB0@CGYSVW100.gdcan.com> Hi, I'm attempting to setup a read-only root filesystem on a Compact Flash card. I'm using the GRUB bootloader and am passing 'root=/dev/hda1 ro' to the kernel boot. This seems to do what I want. However I also need to be able to login via telnet to make some configuration changes (requiring write access). When I try to remount the root fs read-write, the mount command complains that '/' or '/dev/hda1' aren't in my /etc/fstab (which they aren't). Currently my /etc/fstab contains: # /etc/fstab # none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 tmpfs /var tmpfs size=25% 0 0 On my target 'cat /proc/mounts' returns: rootfs / rootfs rw 0 0 /dev/root / ext2 ro 0 0 none /proc proc rw,nodiratime 0 0 none /sys sysfs rw 0 0 none /dev/pts devpts rw 0 0 tmpfs /var tmpfs rw 0 0 I'm unsure about a few things ... Do I need to add an entry in /etc/fstab for '/' to allow the mount command to work properly? Does this work alongside the GRUB parameters? Or does adding an entry for '/' in /etc/fstab with the 'ro' option mean I no longer need to pass 'ro' in GRUB? Why does 'cat /proc/mounts' give 2 entries for '/' with 'rootfs' being 'rw'? Any tips on the correct configuration for a read-only root fs with support for remounting read-write? Thanks alot, Mark The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20051208/b26c526e/attachment.htm From vapier at gentoo.org Thu Dec 8 17:32:06 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Thu Dec 8 17:32:20 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051209004252.GE3237@aon.at> References: <200512011532.14120.rob@landley.net> <200512022139.05018.rob@landley.net> <20051203041726.GD2240@toucan.gentoo.org> <200512041207.28112.rob@landley.net> <20051209004252.GE3237@aon.at> Message-ID: <20051209013206.GA14483@toucan.gentoo.org> On Fri, Dec 09, 2005 at 01:42:52AM +0100, Bernhard Fischer wrote: > I will ci the attached patch tomorrow unless somebody objects. why dont you use the simpler form i suggested Rules.mak: LIBRARIES := need-libm-y := LIBRARIES += $(need-libm-y) coreutils/Makefile.in / miscutils/Makefile.in / etc... need-libm-$(APPLET) := -lm -mike From k at kcomputing.com Thu Dec 8 19:26:53 2005 From: k at kcomputing.com (Kevin P. Dankwardt) Date: Thu Dec 8 20:25:22 2005 Subject: read-only root fs with Busybox? In-Reply-To: <1125D9E6416F00489EA977418E764B4FE4FAB0@CGYSVW100.gdcan.com> Message-ID: In my experience, mount only complains about /etc/fstab if you leave off either the device file or the mount point. Did you try: mount /dev/hda1 / -oremount,rw or did you just do either: mount / -oremount,rw or: mount /dev/hda1 -oremount,rw -kevin dankwardt -----Original Message----- From: busybox-bounces@busybox.net [mailto:busybox-bounces@busybox.net]On Behalf Of Jessee, Mark Sent: Thursday, December 08, 2005 7:07 PM To: busybox@busybox.net Subject: read-only root fs with Busybox? Hi, I'm attempting to setup a read-only root filesystem on a Compact Flash card. I'm using the GRUB bootloader and am passing 'root=/dev/hda1 ro' to the kernel boot. This seems to do what I want. However I also need to be able to login via telnet to make some configuration changes (requiring write access). When I try to remount the root fs read-write, the mount command complains that '/' or '/dev/hda1' aren't in my /etc/fstab (which they aren't). Currently my /etc/fstab contains: # /etc/fstab # none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 tmpfs /var tmpfs size=25% 0 0 On my target 'cat /proc/mounts' returns: rootfs / rootfs rw 0 0 /dev/root / ext2 ro 0 0 none /proc proc rw,nodiratime 0 0 none /sys sysfs rw 0 0 none /dev/pts devpts rw 0 0 tmpfs /var tmpfs rw 0 0 I'm unsure about a few things ... Do I need to add an entry in /etc/fstab for '/' to allow the mount command to work properly? Does this work alongside the GRUB parameters? Or does adding an entry for '/' in /etc/fstab with the 'ro' option mean I no longer need to pass 'ro' in GRUB? Why does 'cat /proc/mounts' give 2 entries for '/' with 'rootfs' being 'rw'? Any tips on the correct configuration for a read-only root fs with support for remounting read-write? Thanks alot, Mark The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. From rgetz at blackfin.uclinux.org Thu Dec 8 21:43:15 2005 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Thu Dec 8 21:44:05 2005 Subject: [Patch] for review - msh (add function support) Message-ID: <6.1.1.1.0.20051209001943.01ec1620@ptg1.spd.analog.com> In order to make oprofile (and other desktop shell scripts) work on uClinux, Shuo Kang wrote a small patch for msh (which can be applied to the older version of busybox that lives in uClinux-dist) which allows recursive function calls. It still includes a bit of debug support that would not be in a final version, but should be OK for review purposes. It is currently living in our cvs at: http://cvs.blackfin.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-dist/bfin_patch/msh_patch/?cvsroot=uclinux533 msh.c | 268 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 254 insertions(+), 14 deletions(-) The difference between busybox-cvs, and busybox-uClinux is pretty small, so I wouldn't think there would be alot of issues reviewing and providing feedback if people are interested. I would assume this is too late for 1.1, but would be OK for 1.2? When is svn "open" again for patches for 1.2? Thanks -Robin From gordon at sedsystems.ca Fri Dec 9 09:21:29 2005 From: gordon at sedsystems.ca (Robert Gordon) Date: Fri Dec 9 09:44:03 2005 Subject: ifconfig with non-standard netmask doesn't get applied Message-ID: <4399BD19.4000205@sedsystems.ca> I am trying to setup networking with a non-standard netmask to configure a subnet with 512 addresses. ifconfig eth0 137.158.27.158 netmask 255.255.254.0 But after the command runs, checking the config shows: # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:09:F7:FF:FF:E9 inet addr:137.158.27.158 Bcast:137.158.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:39 The netmask does not match the value from command. Once the OS finishes booting, if I perform: #ifconfig eth0 netmask 255.255.254.0 #ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:09:F7:FF:FF:E9 inet addr:137.158.27.158 Bcast:137.158.255.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:39 Now the correct netmask is set. This is running on a cirrus-linux kernel (2.4.21) with busybox 1.00 The ifconfig command is run from the startup /etc/rc.sysinit script. The only bug I can find that may be related is 251 but that relates to the broadcast address not being recalculated (which is also wrong here). Any suggestions on what may be causing this, or should I be looking deeper in the cirrus-linux network stack? Rob From floydpink at gmail.com Fri Dec 9 11:30:57 2005 From: floydpink at gmail.com (Jason Schoon) Date: Fri Dec 9 11:35:36 2005 Subject: ifconfig with non-standard netmask doesn't get applied In-Reply-To: <4399BD19.4000205@sedsystems.ca> References: <4399BD19.4000205@sedsystems.ca> Message-ID: <78a54e1b0512091130u7a9e435ehf1afd153924581dd@mail.gmail.com> What happens if once the system is up and running, you manually run "ifconfig eth0 137.158.27.158 netmask 255.255.254.0"? If that misbehaves again once the system is up, I would look into the parsing used by ifconfig. If it works, I would say look elsewhere. On 12/9/05, Robert Gordon wrote: > > I am trying to setup networking with a non-standard netmask to configure > a subnet with 512 addresses. > > ifconfig eth0 137.158.27.158 netmask 255.255.254.0 > > But after the command runs, checking the config shows: > > # ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 00:09:F7:FF:FF:E9 > inet addr:137.158.27.158 Bcast:137.158.255.255 Mask: > 255.255.0.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Interrupt:39 > > The netmask does not match the value from command. > Once the OS finishes booting, if I perform: > > #ifconfig eth0 netmask 255.255.254.0 > #ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 00:09:F7:FF:FF:E9 > inet addr:137.158.27.158 Bcast:137.158.255.255 > Mask:255.255.254.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Interrupt:39 > > Now the correct netmask is set. This is running on a cirrus-linux kernel > (2.4.21) with busybox 1.00 The ifconfig command is run from the startup > /etc/rc.sysinit script. > > The only bug I can find that may be related is 251 but that relates to > the broadcast address not being recalculated (which is also wrong here). > > Any suggestions on what may be causing this, or should I be looking > deeper in the cirrus-linux network stack? > > Rob > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20051209/92bba1fe/attachment-0001.htm From gordon at sedsystems.ca Fri Dec 9 12:56:33 2005 From: gordon at sedsystems.ca (Robert Gordon) Date: Fri Dec 9 13:08:14 2005 Subject: ifconfig with non-standard netmask doesn't get applied In-Reply-To: <78a54e1b0512091130u7a9e435ehf1afd153924581dd@mail.gmail.com> References: <4399BD19.4000205@sedsystems.ca> <78a54e1b0512091130u7a9e435ehf1afd153924581dd@mail.gmail.com> Message-ID: <4399EF81.2070203@sedsystems.ca> Good point. It works when I do it from the command line. And trying other settings (IP and mask) from the command line continue to work too. I tried repeating the ifconfig command in rc.sysinit so it runs twice, in case it was an initialization issue, but that didn't help. The problem occurs with both class C and class B addresses using smaller subnet masks. Looks like I need to look elsewhere. Rob Jason Schoon wrote: > What happens if once the system is up and running, you manually run > "ifconfig eth0 137.158.27.158 netmask > 255.255.254.0 "? If that misbehaves again once > the system is up, I would look into the parsing used by ifconfig. If it > works, I would say look elsewhere. > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > From yann.morin.1998 at anciens.enib.fr Fri Dec 9 15:50:23 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Fri Dec 9 15:51:05 2005 Subject: Bug triage. In-Reply-To: <200512080033.37822.rob@landley.net> References: <200512080033.37822.rob@landley.net> Message-ID: <200512100050.24274.yann.morin.1998@anciens.enib.fr> Hello All! Rob, On Thursday 08 December 2005 073, Rob Landley wrote: > 304 sometimes rmmod is unable to remove modules > It's the - vs _ problem again. --> Fixed by revision 12546. > 468 rmmod does not report failure --> Patch attached. Easy. This is the patch from the bug system rediffed against rev 12789. => busybox-0000468-rmmod-syscall.patch.bz2 > 467 rmmod does not handle -w and -f flags --> Fixed in revision 12551. > 362 insmod chatter --> Patch attached. Trivial. There was (IMHO) no need to update usage.h, as it already specifies both quiet and verbose options. This is the patch from the bug system rediffed against rev 12789. => busybox-0000362-insmod-chatter.patch.bz2 > 276 Linux 2.6 module autoloading breaks when support for 2.4 modules is > disabled > 272 modprobe does not process parameters --> Patch attached. Heavy. The attached patch about modprobe rework solves these two issues. Note that it still relies on my MODPROBE_MULTIPLE_OPTIONS. Rediffed against rev 12789. => busybox-modprobe.patch.bz2 --> Patch attached. Easy. Another patch is attached that reworks the config options order and dependencies. Note that some options were used by either rmmod, insmod, lsmod or modprobe, but were available only when insmod was selected. Against rev 12789. => busybox-modutils-config-reworked.patch.bz2 Note that all these patches are not dependent one on the other, and so can be applied independently. I will be unavailable for the WE until late Sunday (moving a friend). Best 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: busybox-0000362-insmod-chatter.patch.bz2 Type: application/x-bzip2 Size: 305 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051210/9ef36c65/busybox-0000362-insmod-chatter.patch.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-0000468-rmmod-syscall.patch.bz2 Type: application/x-bzip2 Size: 432 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051210/9ef36c65/busybox-0000468-rmmod-syscall.patch.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-modprobe.patch.bz2 Type: application/x-bzip2 Size: 8466 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051210/9ef36c65/busybox-modprobe.patch.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-modutils-config-reworked.patch.bz2 Type: application/x-bzip2 Size: 1625 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051210/9ef36c65/busybox-modutils-config-reworked.patch.bin From staneja at packetdesign.com Fri Dec 9 22:52:00 2005 From: staneja at packetdesign.com (Siddharth Taneja) Date: Fri Dec 9 23:49:02 2005 Subject: rcS shell? Message-ID: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> Hi, I would like to know what the default shell used by rcS is when BB is used with the BB_INIT and BB_LINUXRC option. I have some lines of script like- PLATFORM =`customscript -p` if [ $PLATFORM = "myplat"] ; then # do some stuff fi I have a custom initrd and use BB with it. If I put these lines in rcS and use BB with the above two options (BB_INIT and BB_LINUXRC) (and default shell as msh -provided by BB)everything works fine. But if I use BB without these options and put these lines in the linuxrc file (with the default shell being msh -provided by BB) it spits out synatx error. Also I see that the PATH variable is not setup correctly in this scenario. Can someone help me out with this? Thanks Siddharth From steven.scholz at imc-berlin.de Sat Dec 10 02:41:20 2005 From: steven.scholz at imc-berlin.de (Steven Scholz) Date: Sat Dec 10 03:13:58 2005 Subject: Problems with output to console Message-ID: <439AB0D0.4040801@imc-berlin.de> Hi all, I have two different ARM based boards (different CPUs, both Linux 2.6.14) running BusyBox v1.00. I want a little application (started by a script that is started by inittab) to output stuff using printf() on my serial console. foobar.c is int main (void) { printf("Hello World (printf)!\n"); return 0; } My /etc/inittab has ::sysinit:/opt/imc/start_imc ::askfirst:-/bin/sh On one board I see the output. This one has /dev/ttySMX0 (204,41) as serial console. On the other board I do _not_ see the output. This has /dev/ttyS0 (4,64) as serial console. When I start foobar directly in inittab it works on both. When I create a link "ln -s /dev/ttySMX0 /dev/ttyS0" on the first board, then I cant see the output there anymore. Could someone please explain to me what's going on here. Cheers, Steven From farmatito at tiscali.it Sat Dec 10 04:40:42 2005 From: farmatito at tiscali.it (Tito) Date: Sat Dec 10 04:44:11 2005 Subject: rcS shell? In-Reply-To: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> References: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> Message-ID: <200512101340.42562.farmatito@tiscali.it> On Saturday 10 December 2005 07:52, Siddharth Taneja wrote: > Hi, > > I would like to know what the default shell used by rcS is when BB is used > with the BB_INIT and BB_LINUXRC option. I have some lines of script like- > PLATFORM =`customscript -p` > if [ $PLATFORM = "myplat"] ; then > # do some stuff > fi Hi, try if [ "$PLATFORM" = "myplat"]; then or maybe if test "$PLATFORM" = "myplat"; then Hope it helps. Ciao, Tito > I have a custom initrd and use BB with it. If I put these lines in rcS and > use BB with the above two options (BB_INIT and BB_LINUXRC) (and default > shell as msh -provided by BB)everything works fine. > > But if I use BB without these options and put these lines in the linuxrc > file (with the default shell being msh -provided by BB) it spits out > synatx error. Also I see that the PATH variable is not setup correctly in > this scenario. > > Can someone help me out with this? > > Thanks > > Siddharth > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > From farmatito at tiscali.it Sat Dec 10 04:58:07 2005 From: farmatito at tiscali.it (Tito) Date: Sat Dec 10 04:58:29 2005 Subject: Problems with output to console In-Reply-To: <439AB0D0.4040801@imc-berlin.de> References: <439AB0D0.4040801@imc-berlin.de> Message-ID: <200512101358.07270.farmatito@tiscali.it> On Saturday 10 December 2005 11:41, Steven Scholz wrote: > Hi all, > > I have two different ARM based boards (different CPUs, both Linux > 2.6.14) running BusyBox v1.00. > > I want a little application (started by a script that is started by > inittab) to output stuff using printf() on my serial console. > > foobar.c is > int main (void) > { > printf("Hello World (printf)!\n"); > return 0; > } Hi, Just my 0.02 ?. Maybe something like: int main(void) { FILE *out; if((out = fopen(" /dev/ttyS0", "r+")) == NULL) return 1; fprintf(out, "test\n"); fclose(out); return 0; } could be a workaround. But sure there is a better way..... Ciao, Tito > My /etc/inittab has > > ::sysinit:/opt/imc/start_imc > ::askfirst:-/bin/sh > > On one board I see the output. This one has /dev/ttySMX0 (204,41) as > serial console. On the other board I do _not_ see the output. This has > /dev/ttyS0 (4,64) as serial console. > > When I start foobar directly in inittab it works on both. > > When I create a link "ln -s /dev/ttySMX0 /dev/ttyS0" on the first board, > then I cant see the output there anymore. > > Could someone please explain to me what's going on here. > > Cheers, > > Steven > > > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > From mv at inv.cz Sat Dec 10 04:50:54 2005 From: mv at inv.cz (Martin Volf) Date: Sat Dec 10 05:01:58 2005 Subject: rcS shell? In-Reply-To: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> References: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> Message-ID: <439ACF2E.4080104@inv.cz> Siddharth Taneja wrote: > Hi, > > I would like to know what the default shell used by rcS is when BB is used > with the BB_INIT and BB_LINUXRC option. I have some lines of script like- > PLATFORM =`customscript -p` > if [ $PLATFORM = "myplat"] ; then Hello, I would try to add the space before the ] if [ $PLATFORM = "myplat" ]; then -- Martin From steven.scholz at imc-berlin.de Sat Dec 10 05:27:31 2005 From: steven.scholz at imc-berlin.de (Steven Scholz) Date: Sat Dec 10 05:27:53 2005 Subject: Problems with output to console In-Reply-To: <200512101358.07270.farmatito@tiscali.it> References: <439AB0D0.4040801@imc-berlin.de> <200512101358.07270.farmatito@tiscali.it> Message-ID: <439AD7C3.2050603@imc-berlin.de> Tito wrote: > On Saturday 10 December 2005 11:41, Steven Scholz wrote: > >>Hi all, >> >>I have two different ARM based boards (different CPUs, both Linux >>2.6.14) running BusyBox v1.00. >> >>I want a little application (started by a script that is started by >>inittab) to output stuff using printf() on my serial console. >> >>foobar.c is >>int main (void) >>{ >> printf("Hello World (printf)!\n"); >> return 0; >>} > > Hi, Just my 0.02 ?. In 0.01 ? would be enough. Though you need 0.02 US$! ;-) > Maybe something like: > > int main(void) > { > FILE *out; > > if((out = fopen(" /dev/ttyS0", "r+")) == NULL) > return 1; > fprintf(out, "test\n"); > fclose(out); > return 0; > } > > could be a workaround. > But sure there is a better way..... I am sure as well. But I am not only looking for a workaround. I want to understand the problem. And as you might have guessed, I need this for debug outputs for my application (which is of course a tiny little bit more complicated than foobar.c ...) So what happens, if I telnet into a closed box, kill the running application and start it again? Right. Debug output is sent to serial console, which I dont have then ... ;-) So "stdout" is what I want. And "stdout" should be ttyS0 when started from inittab (or from scripts that were started from inittab) started... -- Steven From steven.scholz at imc-berlin.de Sat Dec 10 05:28:47 2005 From: steven.scholz at imc-berlin.de (Steven Scholz) Date: Sat Dec 10 05:29:03 2005 Subject: rcS shell? In-Reply-To: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> References: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> Message-ID: <439AD80F.1050404@imc-berlin.de> Siddharth Taneja wrote: > Hi, > > I would like to know what the default shell used by rcS is when BB is used > with the BB_INIT and BB_LINUXRC option. I have some lines of script like- > PLATFORM =`customscript -p` > if [ $PLATFORM = "myplat"] ; then > # do some stuff > fi > > I have a custom initrd and use BB with it. If I put these lines in rcS and > use BB with the above two options (BB_INIT and BB_LINUXRC) (and default > shell as msh -provided by BB)everything works fine. > > But if I use BB without these options and put these lines in the linuxrc > file (with the default shell being msh -provided by BB) it spits out > synatx error. Maybe because of the missing space! Try if [ $PLATFORM = "myplat" ] ; then -- Steven From vapier at gentoo.org Sat Dec 10 07:04:10 2005 From: vapier at gentoo.org (Mike Frysinger) Date: Sat Dec 10 07:11:17 2005 Subject: rcS shell? In-Reply-To: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> References: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> Message-ID: <20051210150410.GC9505@toucan.gentoo.org> On Fri, Dec 09, 2005 at 10:52:00PM -0800, Siddharth Taneja wrote: > PLATFORM =`customscript -p` the space after the var name is illegal PLATFORM=`customscript -p` > if [ $PLATFORM = "myplat"] ; then everyone else already pointed out the space you're missing here however, you should also quote $PLATFORM because if it contains spaces, it will trigger errors too if [ "$PLATFORM" = "myplat" ] ; then -mike From rep.nop at aon.at Sat Dec 10 09:16:41 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat Dec 10 09:16:47 2005 Subject: ifconfig with non-standard netmask doesn't get applied In-Reply-To: <4399EF81.2070203@sedsystems.ca> References: <4399BD19.4000205@sedsystems.ca> <78a54e1b0512091130u7a9e435ehf1afd153924581dd@mail.gmail.com> <4399EF81.2070203@sedsystems.ca> Message-ID: <20051210171641.GA7707@aon.at> On Fri, Dec 09, 2005 at 02:56:33PM -0600, Robert Gordon wrote: >Good point. >It works when I do it from the command line. And trying other settings >(IP and mask) from the command line continue to work too. Just out of curiousity.. how did you configure ifconfig.. grep FEATURE_IFCONFIG .config ? > >I tried repeating the ifconfig command in rc.sysinit so it runs twice, >in case it was an initialization issue, but that didn't help. > >The problem occurs with both class C and class B addresses using smaller >subnet masks. > >Looks like I need to look elsewhere. From staneja at packetdesign.com Sat Dec 10 11:12:19 2005 From: staneja at packetdesign.com (Siddharth Taneja) Date: Sat Dec 10 11:12:40 2005 Subject: rcS shell? In-Reply-To: <20051210150410.GC9505@toucan.gentoo.org> References: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> <20051210150410.GC9505@toucan.gentoo.org> Message-ID: <58595.24.6.213.161.1134241939.squirrel@webmail.packetdesign.com> > On Fri, Dec 09, 2005 at 10:52:00PM -0800, Siddharth Taneja wrote: >> PLATFORM =`customscript -p` > > the space after the var name is illegal > PLATFORM=`customscript -p` > >> if [ $PLATFORM = "myplat"] ; then > > everyone else already pointed out the space you're missing here > > however, you should also quote $PLATFORM because if it contains spaces, > it will trigger errors too > if [ "$PLATFORM" = "myplat" ] ; then > -mike > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > Hi All, Thanks for the reply. The code that I wrote here was just an example code and I am sure that the original code is syntactically correct. But the problem is that the *same* code which was running fine for years through rcS with BB_INIT and BB_LINUXRC options (BB default shell msh) does not work when it is put in linuxrc ( BB is not configured with BB_INIT and BB_LINUXRC optins and the defalt shell is still msh). This is the reason why I am wondering if a script executed through rcS uses a different setting (like some other shell) with the proper enviornment setup while with linuxrc it is not so. Thanks Siddharth From bug1 at iinet.net.au Sat Dec 10 14:53:28 2005 From: bug1 at iinet.net.au (Glenn L. McGrath) Date: Sat Dec 10 14:55:08 2005 Subject: mark obsolete usage of fold Message-ID: <20051211095328.7b6fb7a0.bug1@iinet.net.au> Attached is a patch sets a feature to allow 'fold -40' type arguments to fail, this behaviour is obsolete even in susv2. Im sure some scripts (e.g. configure) are still using it, so its usefull to support it. The patch doesnt change default behaviour. Its really just to start to organise things so we can one day have a global setting to choose what posix standard to compile to. Its been a long time since i committed anything, i expect to be more active in the future... Glenn -------------- next part -------------- A non-text attachment was scrubbed... Name: fold.diff Type: text/x-patch Size: 1294 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051211/f8abbf39/fold.bin From bug1 at iinet.net.au Sat Dec 10 16:31:18 2005 From: bug1 at iinet.net.au (Glenn L. McGrath) Date: Sat Dec 10 16:33:31 2005 Subject: numeric arguments in head, SuSv2 vs SuSv3 Message-ID: <20051211113118.7cff4453.bug1@iinet.net.au> This patch notes the difference between SuSv2 and SuSv3, head -2 shouldnt work in SuSv3. Similarly to the last patch, it doesnt change default behavour, just gets things in place for when we may want to have a global config option. Glenn -------------- next part -------------- A non-text attachment was scrubbed... Name: head.diff Type: text/x-patch Size: 1051 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051211/fc7d9e2c/head.bin From rob at landley.net Sat Dec 10 20:35:11 2005 From: rob at landley.net (Rob Landley) Date: Sat Dec 10 20:38:02 2005 Subject: Bug triage. In-Reply-To: <200512081954.04344.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512081011.41178.rob@landley.net> <200512081954.04344.yann.morin.1998@anciens.enib.fr> Message-ID: <200512102235.11429.rob@landley.net> On Thursday 08 December 2005 12:54, Yann E. MORIN wrote: > Hello all! > Rob, > > On Thursday 08 December 2005 171, Rob Landley wrote: > > The ones you don't get to I'll take a whack at this weekend. Mention > > which ones of these you fix on your SVN checkin comment and I'll knock > > them off the list. > > Do I have svn write access? If so, I didn't ask for, did I? You have to ask Erik Andersen for it. He's the official maintainer, and I don't have root access to the busybox.net server (and have never administered an svn repository anyway). > Anyway, I won't do any commit, because I don't (yet?) deserve write access > to svn. My work's going to the list. Ok. I'm back from Pittsburgh and mostly recovered (which means I slept late and then spent the day reading "Tainted Trail" by Wen Spencer, but have now finished it and don't have book 3). > > > May I add a ledman command? More and more SOHO routers, PDAs... use > > > LEDs as status feedback. What about including this simple enough > > > command as an applet for BusyBox? > > > > And LED control command? Sounds right up busybox's alley. If it's small > > and simple and #configs out cleanly, sure why not. > > But I'm not holding up the release for it, so get it in quick. :) > > I was thinking of bb-1.2, anyway. Don't hold your breath! :-) Life is good. :) > > (And now, I have to catch a plane. Queue Kermit: "With that tongue? No > > way.") > > Had a nice fly? There's an old saying, "a journey of 1000 miles has a stopover in Atlanta", at least if you're flying Delta. All four planes I was on were delayed in one way or another. But I had a nice time, yes... > Regards, > Yann E. MORIN. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sat Dec 10 20:41:08 2005 From: rob at landley.net (Rob Landley) Date: Sat Dec 10 20:43:17 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051209004252.GE3237@aon.at> References: <200512011532.14120.rob@landley.net> <200512041207.28112.rob@landley.net> <20051209004252.GE3237@aon.at> Message-ID: <200512102241.08203.rob@landley.net> On Thursday 08 December 2005 18:42, Bernhard Fischer wrote: > This fixes the undefined references (from sort_big) of __isnan and > __isinf i was seeing and is listed in bug #531. Works for me. > Didn't look at the warning from uClibs about __fpending yet, but i'm > under the impression that for static linking the msg in link_warning() > is empty and shouldn't (?) be emitted in this case. The empty warning is (confusingly) emitted by gcc 4.0.2, and in certain circumstances gcc will hang instead of emitting the warning. (Actually, I think ld or collect2 is what's doing the hanging, but...) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sat Dec 10 21:58:09 2005 From: rob at landley.net (Rob Landley) Date: Sat Dec 10 22:44:30 2005 Subject: read-only root fs with Busybox? In-Reply-To: References: Message-ID: <200512102358.09783.rob@landley.net> On Thursday 08 December 2005 21:26, Kevin P. Dankwardt wrote: > In my experience, mount only complains about /etc/fstab if you leave off > either the device file or the mount point. > > Did you try: > > mount /dev/hda1 / -oremount,rw > > or did you just do either: mount / -oremount,rw > or: mount /dev/hda1 -oremount,rw Fixing remount is on my todo list. Right now it wants to parse fstab instead mtab (I.E. /proc/mounts). Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sat Dec 10 22:07:47 2005 From: rob at landley.net (Rob Landley) Date: Sat Dec 10 22:44:47 2005 Subject: Problems with output to console In-Reply-To: <439AB0D0.4040801@imc-berlin.de> References: <439AB0D0.4040801@imc-berlin.de> Message-ID: <200512110007.47880.rob@landley.net> On Saturday 10 December 2005 04:41, Steven Scholz wrote: > Hi all, > > I have two different ARM based boards (different CPUs, both Linux > 2.6.14) running BusyBox v1.00. > > I want a little application (started by a script that is started by > inittab) to output stuff using printf() on my serial console. > > foobar.c is > int main (void) > { > printf("Hello World (printf)!\n"); > return 0; > } > > My /etc/inittab has > > ::sysinit:/opt/imc/start_imc > ::askfirst:-/bin/sh > > On one board I see the output. This one has /dev/ttySMX0 (204,41) as > serial console. On the other board I do _not_ see the output. This has > /dev/ttyS0 (4,64) as serial console. > > When I start foobar directly in inittab it works on both. > > When I create a link "ln -s /dev/ttySMX0 /dev/ttyS0" on the first board, > then I cant see the output there anymore. > > Could someone please explain to me what's going on here. Read init/init.c (which is, alas, a mess o' suckage). static char console[CONSOLE_BUFF_SIZE] = _PATH_CONSOLE; (That's from some header file). static void console_init(void) { ... if ((s = getenv("CONSOLE")) != NULL || (s = getenv("console")) != NULL) { safe_strncpy(console, s, sizeof(console)); And the read on for the full horror of serial console detection and tty and such... It gets ugly quickly... I rewrote all this once. Need to do it again in 2.2... > Cheers, > > Steven Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sat Dec 10 22:00:46 2005 From: rob at landley.net (Rob Landley) Date: Sat Dec 10 22:44:50 2005 Subject: ifconfig with non-standard netmask doesn't get applied In-Reply-To: <4399EF81.2070203@sedsystems.ca> References: <4399BD19.4000205@sedsystems.ca> <78a54e1b0512091130u7a9e435ehf1afd153924581dd@mail.gmail.com> <4399EF81.2070203@sedsystems.ca> Message-ID: <200512110000.46296.rob@landley.net> On Friday 09 December 2005 14:56, Robert Gordon wrote: > Good point. > It works when I do it from the command line. And trying other settings > (IP and mask) from the command line continue to work too. > > I tried repeating the ifconfig command in rc.sysinit so it runs twice, > in case it was an initialization issue, but that didn't help. > > The problem occurs with both class C and class B addresses using smaller > subnet masks. > > Looks like I need to look elsewhere. > > Rob Looks like you need to mount /proc for commands that are dependent on it. We should mark all these commands somehow, by the way. Probably have a CONFIG switch "DEPENDS_ON_PROC"... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sat Dec 10 22:16:46 2005 From: rob at landley.net (Rob Landley) Date: Sat Dec 10 22:44:52 2005 Subject: rcS shell? In-Reply-To: <58595.24.6.213.161.1134241939.squirrel@webmail.packetdesign.com> References: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> <20051210150410.GC9505@toucan.gentoo.org> <58595.24.6.213.161.1134241939.squirrel@webmail.packetdesign.com> Message-ID: <200512110016.46375.rob@landley.net> On Saturday 10 December 2005 13:12, Siddharth Taneja wrote: > > On Fri, Dec 09, 2005 at 10:52:00PM -0800, Siddharth Taneja wrote: > >> PLATFORM =`customscript -p` > > > > the space after the var name is illegal > > PLATFORM=`customscript -p` > > > >> if [ $PLATFORM = "myplat"] ; then > > > > everyone else already pointed out the space you're missing here > > > > however, you should also quote $PLATFORM because if it contains spaces, > > it will trigger errors too > > if [ "$PLATFORM" = "myplat" ] ; then > > -mike > > _______________________________________________ > > busybox mailing list > > busybox@busybox.net > > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > Hi All, > > Thanks for the reply. > > The code that I wrote here was just an example code and I am sure that the > original code is syntactically correct. > > But the problem is that the *same* code which was running fine for years > through rcS with BB_INIT and BB_LINUXRC options (BB default shell msh) > does not work when it is put in linuxrc ( BB is not configured with > BB_INIT and BB_LINUXRC optins and the defalt shell is still msh). Again, wading through the deep and abiding suckage of init/init.c: /* See if any special /bin/sh requiring characters are present */ if (strpbrk(a->command, "~`!$^&*()=|\\{}[];\"'<>?") != NULL) { cmd[0] = (char *)DEFAULT_SHELL; cmd[1] = "-c"; cmd[2] = strcat(strcpy(buf, "exec "), a->command); cmd[3] = NULL; And drilling through a few layers of misdirection, we get: ./include/libbb.h:#define LIBBB_DEFAULT_LOGIN_SHELL "-/bin/sh" Except we skip the initial "-"... If your linuxrc hasn't got a /bin/sh... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sat Dec 10 22:30:11 2005 From: rob at landley.net (Rob Landley) Date: Sat Dec 10 22:47:05 2005 Subject: mark obsolete usage of fold In-Reply-To: <20051211095328.7b6fb7a0.bug1@iinet.net.au> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> Message-ID: <200512110030.11914.rob@landley.net> On Saturday 10 December 2005 16:53, Glenn L. McGrath wrote: > Attached is a patch sets a feature to allow 'fold -40' type arguments > to fail, this behaviour is obsolete even in susv2. > > Im sure some scripts (e.g. configure) are still using it, so its > usefull to support it. > > The patch doesnt change default behaviour. Its really just to start to > organise things so we can one day have a global setting to choose what > posix standard to compile to. 1) If you're going to do this kind of thing, could you please have a global argument to disable nonstandard extensions? (I'm trying to keep the amount of configuration people have to do down to a dull roar. Getting buried in options doesn't help. I'm thinking of adding things like CONFIG_NEEDS_PROC and CONFIG_LONG_OPTIONS to 1.2, for example.) 2) I'm trying to get 1.1 out by new year's. Could this kind of change please wait until January? (See big long bug list posted a couple days ago.) 3) I really think we should pick one standard we care about, and try to implement all of. (Right now it's that Open Group thing that's on the web, which is roughly susv3.) Trying to distinguish between susv2 and susv3 is just going to drive us _crazy_. 4) We now have if(ENABLE_BLAH) rather than #ifdef CONFIG_BLAH. In 1.2 I'm hoping to do a big switchover and cleanup (after documenting it and figuring out what compiler versions competently handle dead code elimination). 5) My worries about standards compliance currently are about filling out the test suite and making sure we implement everything we need to. What's the advantage of #ifdefing _out_ extensions that are still used? (It's not complexity savings if the code is still there. What are the space savings? When we have tiny little changes that save tiny little amounts of space, I like to group them together under bigger config options. I'm not _against_ saving 5 bytes here and 5 bytes there, but someday I'd like to have somehting like a CONFIG_NITPICK to hide all config options that save less than 100 bytes each. :) 6) I can see the advantage of disabling things like gnu extensions when people want to use our code to test standards compliance, but right now we don't implement anything close to the whole standard yet so do we want to start worrying about that now? > Its been a long time since i committed anything, i expect to be more > active in the future... Welcome back. :) > Glenn Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From bug1 at iinet.net.au Sun Dec 11 00:29:04 2005 From: bug1 at iinet.net.au (Glenn L. McGrath) Date: Sun Dec 11 00:30:06 2005 Subject: mark obsolete usage of fold In-Reply-To: <200512110030.11914.rob@landley.net> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512110030.11914.rob@landley.net> Message-ID: <20051211192904.70c5bb23.bug1@iinet.net.au> On Sun, 11 Dec 2005 00:30:11 -0600 Rob Landley wrote: > On Saturday 10 December 2005 16:53, Glenn L. McGrath wrote: > > Attached is a patch sets a feature to allow 'fold -40' type arguments > > to fail, this behaviour is obsolete even in susv2. > > > > Im sure some scripts (e.g. configure) are still using it, so its > > usefull to support it. > > > > The patch doesnt change default behaviour. Its really just to start to > > organise things so we can one day have a global setting to choose what > > posix standard to compile to. > > 1) If you're going to do this kind of thing, could you please have a global > argument to disable nonstandard extensions? (I'm trying to keep the amount > of configuration people have to do down to a dull roar. Getting buried in > options doesn't help. I'm thinking of adding things like CONFIG_NEEDS_PROC > and CONFIG_LONG_OPTIONS to 1.2, for example.) Ive commit some changes, i added 2 config options to Build Options, One for SuSv2, the other for pre SuSv2. > 2) I'm trying to get 1.1 out by new year's. Could this kind of change please > wait until January? (See big long bug list posted a couple days ago.) umm, woops, too late. > 3) I really think we should pick one standard we care about, and try to > implement all of. (Right now it's that Open Group thing that's on the web, > which is roughly susv3.) Trying to distinguish between susv2 and susv3 is > just going to drive us _crazy_. The files i just patched are some obvious ones, but we can also get information about changes between SuSv2 and SuSv3 from coreutils or maybe the Heirloom Project. I think we need a compatability layer for when things break, e.g. configure scripts still use the numeric arguments in head/tail i think. We can try for the latests standard, but still have the old behaviour to fall back on. > 4) We now have if(ENABLE_BLAH) rather than #ifdef CONFIG_BLAH. In 1.2 I'm > hoping to do a big switchover and cleanup (after documenting it and figuring > out what compiler versions competently handle dead code elimination). > > 5) My worries about standards compliance currently are about filling out the > test suite and making sure we implement everything we need to. What's the > advantage of #ifdefing _out_ extensions that are still used? (It's not > complexity savings if the code is still there. What are the space savings? > When we have tiny little changes that save tiny little amounts of space, I > like to group them together under bigger config options. I'm not _against_ > saving 5 bytes here and 5 bytes there, but someday I'd like to have somehting > like a CONFIG_NITPICK to hide all config options that save less than 100 > bytes each. :) The advantage i see of being pedantic about the latest standard is that it helps developers fix their scripts, standards are meaningless if people dont/wont use them. The easier it is for people to move on to the latest standard the quicker we can remove all the compatability code. But that is a long term issue, not a short term one. > 6) I can see the advantage of disabling things like gnu extensions when people > want to use our code to test standards compliance, but right now we don't > implement anything close to the whole standard yet so do we want to start > worrying about that now? I guess those few cases are some obvious ones that had bugged me for a while, they have obsolete in the standard for like four years... I really think people who are using numeric arguments need to fix their scripts so we can all move on. The changes looked pretty safe to me, i.e. not likely to break anything, and its something that has been talked about for a long time i think, so figured why not do it now. > > Its been a long time since i committed anything, i expect to be more > > active in the future... > > Welcome back. :) Thanks Glenn From rep.nop at aon.at Sun Dec 11 02:04:15 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Dec 11 02:03:52 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051209013206.GA14483@toucan.gentoo.org> References: <200512011532.14120.rob@landley.net> <200512022139.05018.rob@landley.net> <20051203041726.GD2240@toucan.gentoo.org> <200512041207.28112.rob@landley.net> <20051209004252.GE3237@aon.at> <20051209013206.GA14483@toucan.gentoo.org> Message-ID: <20051211100415.GL3237@aon.at> On Fri, Dec 09, 2005 at 01:32:06AM +0000, Mike Frysinger wrote: >On Fri, Dec 09, 2005 at 01:42:52AM +0100, Bernhard Fischer wrote: >> I will ci the attached patch tomorrow unless somebody objects. > >why dont you use the simpler form i suggested > >Rules.mak: >LIBRARIES := >need-libm-y := > Then */Makefile would include */Makefile.in and Rules.mak, Rules.mak itself would again include the Makefile.in's, which is ugly. I think that Rules.mak should not include anything except maybe .config. After 1.1 is branched, i was thinking about changing */Makefile to have their includes in a more appealing order. What do you think about this and what should we do now for SORT_BIG? >LIBRARIES += $(need-libm-y) > >coreutils/Makefile.in / miscutils/Makefile.in / etc... >need-libm-$(APPLET) := -lm >-mike From rob at landley.net Sun Dec 11 02:05:37 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 02:08:20 2005 Subject: mark obsolete usage of fold In-Reply-To: <20051211192904.70c5bb23.bug1@iinet.net.au> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512110030.11914.rob@landley.net> <20051211192904.70c5bb23.bug1@iinet.net.au> Message-ID: <200512110405.37813.rob@landley.net> Warning: philosophical differences ahead. You have been warned. On Sunday 11 December 2005 02:29, Glenn L. McGrath wrote: > On Sun, 11 Dec 2005 00:30:11 -0600 > > Rob Landley wrote: > > On Saturday 10 December 2005 16:53, Glenn L. McGrath wrote: > > > Attached is a patch sets a feature to allow 'fold -40' type arguments > > > to fail, this behaviour is obsolete even in susv2. > > > > > > Im sure some scripts (e.g. configure) are still using it, so its > > > usefull to support it. > > > > > > The patch doesnt change default behaviour. Its really just to start to > > > organise things so we can one day have a global setting to choose what > > > posix standard to compile to. > > > > 1) If you're going to do this kind of thing, could you please have a > > global argument to disable nonstandard extensions? (I'm trying to keep > > the amount of configuration people have to do down to a dull roar. > > Getting buried in options doesn't help. I'm thinking of adding things > > like CONFIG_NEEDS_PROC and CONFIG_LONG_OPTIONS to 1.2, for example.) > > Ive commit some changes, i added 2 config options to Build Options, One > for SuSv2, the other for pre SuSv2. Both are "not Susv3". I don't care whether it's a gnu extension, solaris compatibility, or something left over from system 5. We're not currently fully implementing _any_ standard, and I believe the one we're trying to move towards (and that I'd like to audit stuff against) is susv3. And yes, there are cases where we'll still violate that standard. We're not doing the full internationalization thing with locale environment variables, _ever_ if I can help it, because it's just too much bloat for our mandate to absorb. (UTF-8 seems like the low hanging fruit here. You followed those threads?) > > 2) I'm trying to get 1.1 out by new year's. Could this kind of change > > please wait until January? (See big long bug list posted a couple days > > ago.) > > umm, woops, too late. I saw before I posted this, and didn't complain. No biggie. :) > > 3) I really think we should pick one standard we care about, and try to > > implement all of. (Right now it's that Open Group thing that's on the > > web, which is roughly susv3.) Trying to distinguish between susv2 and > > susv3 is just going to drive us _crazy_. > > The files i just patched are some obvious ones, but we can also get > information about changes between SuSv2 and SuSv3 from coreutils or > maybe the Heirloom Project. Something we need to do, totally separate from this, is audit all the apps to see which ones are susv3 compliant and which aren't. In my head, this is tied up with extending the test suites to _test_ all of susv3 (using the new "all tests in one script" format so that the subversion history is actually intelligible). So I don't personally care what susv2 said, unless the spec we're getting off the open group's website is susv2. (The one that all our URLs point to, like the one in the comment towards the start of sed.c.) > I think we need a compatability layer for when things break, e.g. > configure scripts still use the numeric arguments in head/tail i think. Yes, they due. If real world scripts would break due to the lack of numeric arguments, we should be able to handle the numeric arguments. I really don't care what the standard says if a 100% standards compliant implementation is useless in the real world. To me, the standard is an important point of reference, but not the whole picture. For example, uClibc 0.9.28 won't install unless tar has the --exclude option. (I had to fix this to get uClibc 0.9.28 to install with busybox tar.) You still can't install uClibc 0.9.28 with busybox 1.01, and those are the most recent official releases of each... That's not the only gnu extension we need to be useful. Far from it. The ./configure stage of all sorts of gnu extensions in sed and sort in order to complete. (This gets silly at times: look in editors/sed.c for the comment "Lie to autoconf". Yes, this is needed to make things like binutils build correctly. It shouldn't be, but it is.) What standard is bzip part of? Does this mean people should stop using it? > We can try for the latests standard, but still have the old behaviour > to fall back on. This is a case where I consider the additional feature to be an extension. We provide gnu extensions left and right, so where's the downside of providing obsolete behavior as an extension? There are several reasons for removing old behavior. Bloat is high on the list for us, but there's also potential security issues, causing interference with other functionality, and so on. Removing it just _because_ it's old, however... why? We configure out the old tar format because A) it saves space, B) almost nobody ever uses it so it's not a feature there's much demand for. (And we do that because _both_ of those are true.) If the argument starts with "saves x bytes", I'm all for it. If the argument is "because people should convert their scripts"... Busybox provides features that aren't in _any_ standard, and it does so because people want and use those features. (I realise this conflicts with my position that devfsd is evil and should die. The truth is, devfsd is intrusive (breaking stuff like losetup when people do allyesconfig and accidentally enable it), never worked properly, and something I actively don't want to maintain. If Tito steps up to defend it, and is passionate about it and wants to maintain it I'll probably back down on that one. But allyesconfig still shouldn't select it, because it breaks stuff.) If you're going to try to wean people off of obsolete things that some standard depreicates (yet which people choose to widely ignore anyway), then why aren't you trying to wean people off of gnu extensions that were never standardized in the first place? > The advantage i see of being pedantic about the latest standard is that > it helps developers fix their scripts, standards are meaningless if > people dont/wont use them. We're talking about the embedded space. Developers here violate standards left and right. Most of them are going to use the small version of sort. I am a ruthless pragmatist. (You may have noticed. :) My computing history dates back to the Atari 800 and Commodore 64, and wandered to Linux by way of Dos with Desqview and OS/2. All of that was based on "what people got to work", usually by reverse engineering. Saying we implement a standard and can prove it, I'm all for. People who write to the standard can then be pretty sure they can run our code, and that's good to know. But intentionally choking on anything that isn't in the standard, yet is widely understood elsewhere, is counterproductive. "Standards are great, there's so many to choose from, and if you didn't pick the same one we did expect busybox to break"... That's not so good. Offering a debugging tool that lets people who _want_ to be pedantic, I can see. But wouldn't a better way be some kind of debug warning that emits when you use an obsolete feature? (So your script generates messages rather than breaking?) Of course this gets you back to the problem that running your script under busybox, things are likely to break 8 ways from sunday right now. This means that right now, the option you added is merely useless, because "it doesn't run under busybox" is not a useful datapoint anyway. 1.1 will be a _lot_ better about that, but real world use will find stuff we don't handle properly, all over the place. (For example, linking busybox against uClibc right now, "tar xvjfC file.tgz directory ." doesn't work because the argument that "f" gets isn't "file.tgz", it's "C". This is a uClibc bug, but it hits us.) My goal right now is to get everything out there to work with a "make allyesconfig" busybox (which means lots of gnu extensions, but not all of them because many nobody we care about actually uses), and someday being able to say that we implement all of susv3 except for the internationalization bits. If we intentionally break people's scripts in the name of "standards compliance" before we ever get everything working long enough and widely enough that people start to _trust_ that everything works, then all that happens is nobody will ever think of BusyBox as a real environment. In a real world tool, "Standards compliance" doesn't mean you _stop_ at the standard unless you compile the thing with -pedantic and set POSIX_ME_HARDER, and there's a _reason_ both of those options have derogatory names. Right now, our shells (all four of them) are useless for any scripts that people didn't write expicitly for busybox, because in the real world people use bash syntax and we can't handle it. We have four different shells that don't work in different ways, and I want to clean that up and have one scalable shell that runs real scripts. And it's going to implement bash syntax first, and be checked against susv3 later once it works on real scripts. (That's how Linus wrote the Linux kernel originally: he implemented a lot of stuff from the the sun man pages and then got tired of that and started implementing all the system calls bash was trying to make on its' way up.) If I focused on implementing an susv3 shell, I'd just have another shell that nobody can use. Instead, I intend to focus on real scripts people might want to run, and then once those work listen to bug reports from people trying to run other real scripts and finding stuff we can't handle. That's all that _matters_. Compliance with the spec is bragging rights, really, and if it was _important_ there'd already bee a test suite that tells you whether or not your command line is compliant with it. (Writing such a free compliance test suite might is a todo item of mine. Because NOBODY ELSE HAS. Even after all these years...) Don't worship the spec. Please... > The easier it is for people to move on to > the latest standard the quicker we can remove all the compatability > code. But that is a long term issue, not a short term one. If busybox becomes a hare shirt for developers, they'll stop using it. Having debugging modes, yay. But let's debug busybox itself first before we start expecting people to use our tools to find stuff wrong with their scripts. Right now it's hard enough to get them to find stuff wrong with busybox, which _I_ can do at the drop of a hat... > > 6) I can see the advantage of disabling things like gnu extensions when > > people want to use our code to test standards compliance, but right now > > we don't implement anything close to the whole standard yet so do we want > > to start worrying about that now? > > I guess those few cases are some obvious ones that had bugged me for a > while, they have obsolete in the standard for like four years... And nobody cares. They continue to use them as long as they work. And no matter what the standard says, I see nothing wrong with that. > I really think people who are using numeric arguments need to fix their > scripts so we can all move on. Why? What's the downside of saying -40? (Is it ambiguous?) > The changes looked pretty safe to me, i.e. not likely to break > anything, and its something that has been talked about for a long time > i think, so figured why not do it now. Talked about by who? I missed this. In any case, this is very much a 1.2 issue. Could we comply with susv3 before we worry about enforcing it? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rep.nop at aon.at Sun Dec 11 02:06:53 2005 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun Dec 11 02:08:24 2005 Subject: Makefile tweak for -lm? In-Reply-To: <200512102241.08203.rob@landley.net> References: <200512011532.14120.rob@landley.net> <200512041207.28112.rob@landley.net> <20051209004252.GE3237@aon.at> <200512102241.08203.rob@landley.net> Message-ID: <20051211100653.GM3237@aon.at> On Sat, Dec 10, 2005 at 10:41:08PM -0600, Rob Landley wrote: >On Thursday 08 December 2005 18:42, Bernhard Fischer wrote: >> Didn't look at the warning from uClibs about __fpending yet, but i'm >> under the impression that for static linking the msg in link_warning() >> is empty and shouldn't (?) be emitted in this case. > >The empty warning is (confusingly) emitted by gcc 4.0.2, and in certain >circumstances gcc will hang instead of emitting the warning. (Actually, I >think ld or collect2 is what's doing the hanging, but...) You mentioned that you have a testcase where this hangs. How can i reproduce this? From rob at landley.net Sun Dec 11 02:26:46 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 02:28:46 2005 Subject: Makefile tweak for -lm? In-Reply-To: <20051211100653.GM3237@aon.at> References: <200512011532.14120.rob@landley.net> <200512102241.08203.rob@landley.net> <20051211100653.GM3237@aon.at> Message-ID: <200512110426.46470.rob@landley.net> On Sunday 11 December 2005 04:06, Bernhard Fischer wrote: > On Sat, Dec 10, 2005 at 10:41:08PM -0600, Rob Landley wrote: > >On Thursday 08 December 2005 18:42, Bernhard Fischer wrote: > >> Didn't look at the warning from uClibs about __fpending yet, but i'm > >> under the impression that for static linking the msg in link_warning() > >> is empty and shouldn't (?) be emitted in this case. > > > >The empty warning is (confusingly) emitted by gcc 4.0.2, and in certain > >circumstances gcc will hang instead of emitting the warning. (Actually, I > >think ld or collect2 is what's doing the hanging, but...) > > You mentioned that you have a testcase where this hangs. How can i > reproduce this? I had a test case where it hung repeatably, a half dozen builds back. I'll see if I can reproduce it... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From dzo at simtreas.ru Sun Dec 11 02:58:12 2005 From: dzo at simtreas.ru (Vladimir N. Oleynik) Date: Sun Dec 11 02:59:21 2005 Subject: rcS shell? In-Reply-To: <20051210150410.GC9505@toucan.gentoo.org> References: <1320.24.6.213.161.1134197520.squirrel@webmail.packetdesign.com> <20051210150410.GC9505@toucan.gentoo.org> Message-ID: <439C0644.8070004@simtreas.ru> Mike, >>PLATFORM =`customscript -p` > the space after the var name is illegal > PLATFORM=`customscript -p` >>if [ $PLATFORM = "myplat"] ; then > everyone else already pointed out the space you're missing here > however, you should also quote $PLATFORM because if it contains spaces, > it will trigger errors too > if [ "$PLATFORM" = "myplat" ] ; then Full paranoid: if [ "x$PLATFORM" = "xmyplat" ] ; then for protect empty variable or bigining with minus. --w vodz From ps.m at gmx.net Sun Dec 11 03:22:41 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Sun Dec 11 03:25:12 2005 Subject: mark obsolete usage of fold In-Reply-To: <200512110405.37813.rob@landley.net> Message-ID: On Sun, 11 Dec 2005, Rob Landley wrote: [...] > (For example, linking busybox against uClibc > right now, "tar xvjfC file.tgz directory ." doesn't work because the argument > that "f" gets isn't "file.tgz", it's "C". This is a uClibc bug, but it hits > us.) [...] Which bug is that? Can you tell something more concrete? I have a similar case w/ interpretion of rpm's options where the order is relevant. Thanks, Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From farmatito at tiscali.it Sun Dec 11 05:04:04 2005 From: farmatito at tiscali.it (Tito) Date: Sun Dec 11 05:06:04 2005 Subject: was: mark obsolete usage of fold - now: kill devfsd In-Reply-To: <200512110405.37813.rob@landley.net> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <20051211192904.70c5bb23.bug1@iinet.net.au> <200512110405.37813.rob@landley.net> Message-ID: <200512111404.04711.farmatito@tiscali.it> On Sunday 11 December 2005 11:05, Rob Landley wrote: > (I realise this conflicts with my position that devfsd is evil and should die. > The truth is, devfsd is intrusive (breaking stuff like losetup when people do > allyesconfig and accidentally enable it), never worked properly, and > something I actively don't want to maintain. If Tito steps up to defend it, > and is passionate about it and wants to maintain it I'll probably back down > on that one. But allyesconfig still shouldn't select it, because it breaks > stuff.) Hi, I don't think to defend it nor to maintain it as my ubuntu box doesn't use it and I have no way to test it. The last fixes were done blindly and i can't say if I broke something, but as nobody complained about them .....probably nobody use it. BTW: it will be ripped out from the kernel soon, so maybe we should do the same: 1) Remove it from the make *config system at first so that I could be used only by editing .config and bb_config.h manually. 2) Wait if somebody cries..... 3) Remove it (maybe in 1.2) Ciao, Tito > If you're going to try to wean people off of obsolete things that some > standard depreicates (yet which people choose to widely ignore anyway), then > why aren't you trying to wean people off of gnu extensions that were never > standardized in the first place? > From bug1 at iinet.net.au Sun Dec 11 05:10:05 2005 From: bug1 at iinet.net.au (Glenn McGrath) Date: Sun Dec 11 05:15:16 2005 Subject: Busybox and standards/direction In-Reply-To: <200512110405.37813.rob@landley.net> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512110030.11914.rob@landley.net> <20051211192904.70c5bb23.bug1@iinet.net.au> <200512110405.37813.rob@landley.net> Message-ID: <20051212001005.055ef1c2.bug1@iinet.net.au> Trying to state the issues as i see it... Standard always exists, its just "standard" behaviour, peoples behaviour changes over time, so for any definition of a standard to have meaning it needs to change also. When trying to _define_ a standard there will always be people who think this should be in the standard or that shouldnt be in it. So multiple standards can be defined at the same time targeting different demographics. Busybox's demographics has been those wanting a minimal runtime environment, and to a much smaller extent a minimal build environment. AFAIK GNU is backward compatable with SuS, so SuS is definetly a good standard to aim for, it caters to our demographics. As much as we aim for SuS we do need to be able change the behaviour of specific applets so users can have a system suited to them, wether its GNUism, old SuS behaviours or whatever. I guess im not a pragmatist, because i dont see the relavence of how cheaply we can implement default functionality that shouldnt be default. But the the real question isnt what you or i think should or shouldnt be in there, but how do we give users the ability to customise functionality without creating an overly complex configuration system ? We cant give users more choices of behaviour without asking more questions... so i think we have to accept busybox is always going to be complex to configure. Perhaps one thing we could do is group all the SuS utilities together into their own menu, that way any generic configure options related to obsolete SuS behaviour (e.g numeric arguments) would be isolated... not sure if that would make any difference. It would be great to have a testsuite that would check standards conformance, but i suspect there owuld be years of work in developing it. Ideally such an effort would be supported by other utilties projects as well. Glenn From yann.morin.1998 at anciens.enib.fr Sun Dec 11 08:50:20 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun Dec 11 08:50:31 2005 Subject: Bug triage. In-Reply-To: <200512102235.11429.rob@landley.net> References: <200512080033.37822.rob@landley.net> <200512081954.04344.yann.morin.1998@anciens.enib.fr> <200512102235.11429.rob@landley.net> Message-ID: <200512111750.20946.yann.morin.1998@anciens.enib.fr> On Sunday 11 December 2005 053, Rob Landley wrote: > > On Thursday 08 December 2005 171, Rob Landley wrote: > > > The ones you don't get to I'll take a whack at this weekend. Mention > > > which ones of these you fix on your SVN checkin comment and I'll knock > > > them off the list. > > Do I have svn write access? If so, I didn't ask for, did I? > You have to ask Erik Andersen for it. He's the official maintainer, and I > don't have root access to the busybox.net server (and have never administered > an svn repository anyway). Right, but I was answering your saying to comment _my_ SVN checkin, which seemed to imply I had svn access, which I obviously don't have and don't want. > > Had a nice fly? > There's an old saying, "a journey of 1000 miles has a stopover in Atlanta", at > least if you're flying Delta. All four planes I was on were delayed in one > way or another. Sigh... > But I had a nice time, yes... Good. Moving my friend was also kind of a story: I went to Paris, and the truck was already loaded when I arrived. Then back to the subway to her new flat, and when I was there, the truck was already unloaded. Bah, anyway, I had a nice evening with good fellows! :-) 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 Sun Dec 11 10:22:43 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 10:23:16 2005 Subject: mark obsolete usage of fold In-Reply-To: References: Message-ID: <200512111222.44030.rob@landley.net> On Sunday 11 December 2005 05:22, Peter S. Mazinger wrote: > On Sun, 11 Dec 2005, Rob Landley wrote: > > [...] > > > (For example, linking busybox against uClibc > > right now, "tar xvjfC file.tgz directory ." doesn't work because the > > argument that "f" gets isn't "file.tgz", it's "C". This is a uClibc bug, > > but it hits us.) > > [...] > > Which bug is that? Can you tell something more concrete? I have a similar > case w/ interpretion of rpm's options where the order is relevant. > > Thanks, Peter It's another one that I can reproduce if I set up the appropraite environment, and I intend to debug after 1.1 ships. I reported it to the uClibc mailing list to see if it was something they could fix easily, and they refused to discuss it until I wrote a reproduction test case for their test suite. I'll get back to them when I have time to track it down myself and come up with a patch. (For the bug, not their test suite. It hasn't been this week...) There are several bugs I only see linked against uClibc 0.9.28. The mount error message being wrong is another one (which I think is actually a busybox problem using memory after free, but the symptom only reproduces under uClibc...) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 11 10:35:42 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 10:36:15 2005 Subject: was: mark obsolete usage of fold - now: kill devfsd In-Reply-To: <200512111404.04711.farmatito@tiscali.it> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512110405.37813.rob@landley.net> <200512111404.04711.farmatito@tiscali.it> Message-ID: <200512111235.43012.rob@landley.net> On Sunday 11 December 2005 07:04, Tito wrote: > On Sunday 11 December 2005 11:05, Rob Landley wrote: > > (I realise this conflicts with my position that devfsd is evil and should > > die. The truth is, devfsd is intrusive (breaking stuff like losetup when > > people do allyesconfig and accidentally enable it), never worked > > properly, and something I actively don't want to maintain. If Tito steps > > up to defend it, and is passionate about it and wants to maintain it I'll > > probably back down on that one. But allyesconfig still shouldn't select > > it, because it breaks stuff.) > > Hi, > I don't think to defend it nor to maintain it as my ubuntu box > doesn't use it and I have no way to test it. > The last fixes were done blindly and i can't say if > I broke something, but as nobody complained about them > .....probably nobody use it. I mentioned you because I searched through the AUTHORS file for the maintainer, and didn't want to say "if $MAINTAINER stands up for it" without checking if we actually had one I'd ever heard of... > BTW: it will be ripped out from the kernel soon, More or less already was. > so maybe we should do the same: > > 1) Remove it from the make *config system at first > so that I could be used only by editing .config and bb_config.h > manually. > 2) Wait if somebody cries..... > 3) Remove it (maybe in 1.2) If we're going to yank it, just yank it. (It isn't threaded through our code at _nearly_ the level it is in the kernel, so putting it back if a maintainer stood up and made a truly compelling case for keeping it isn't brain surgery.) Yeah, 1.2 sounds about right. > Ciao, > Tito Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From ps.m at gmx.net Sun Dec 11 10:55:32 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Sun Dec 11 10:57:51 2005 Subject: mark obsolete usage of fold In-Reply-To: <200512111222.44030.rob@landley.net> Message-ID: On Sun, 11 Dec 2005, Rob Landley wrote: > On Sunday 11 December 2005 05:22, Peter S. Mazinger wrote: > > On Sun, 11 Dec 2005, Rob Landley wrote: > > > > [...] > > > > > (For example, linking busybox against uClibc > > > right now, "tar xvjfC file.tgz directory ." doesn't work because the > > > argument that "f" gets isn't "file.tgz", it's "C". This is a uClibc bug, > > > but it hits us.) > > > > [...] > > > > Which bug is that? Can you tell something more concrete? I have a similar > > case w/ interpretion of rpm's options where the order is relevant. > > > > Thanks, Peter > > It's another one that I can reproduce if I set up the appropraite environment, > and I intend to debug after 1.1 ships. > > I reported it to the uClibc mailing list to see if it was something they could > fix easily, and they refused to discuss it until I wrote a reproduction test > case for their test suite. I'll get back to them when I have time to track > it down myself and come up with a patch. (For the bug, not their test suite. > It hasn't been this week...) > > There are several bugs I only see linked against uClibc 0.9.28. The mount > error message being wrong is another one (which I think is actually a busybox > problem using memory after free, but the symptom only reproduces under > uClibc...) > > Rob do you refer maybe to not supporting *-progname (something w/ short, can't recall now), so that gnu testsuites fail due to different errors? Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From rob at landley.net Sun Dec 11 11:40:51 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 11:41:29 2005 Subject: Busybox and standards/direction In-Reply-To: <20051212001005.055ef1c2.bug1@iinet.net.au> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512110405.37813.rob@landley.net> <20051212001005.055ef1c2.bug1@iinet.net.au> Message-ID: <200512111340.51891.rob@landley.net> On Sunday 11 December 2005 07:10, Glenn McGrath wrote: > Trying to state the issues as i see it... > > Standard always exists, its just "standard" behaviour, peoples > behaviour changes over time, so for any definition of a standard to > have meaning it needs to change also. Formal standards and de facto standards. > When trying to _define_ a standard there will always be people who > think this should be in the standard or that shouldnt be in it. So > multiple standards can be defined at the same time targeting different > demographics. Standards should document, not legislate. "This is the existing best practice" is a good thing. "We think you should do it this way" is seldom a good thing to come out of a committee. > Busybox's demographics has been those wanting a minimal runtime > environment, and to a much smaller extent a minimal build environment. I see three definitions of "minimal". 1) Smallest possible binary. 2) Smallest run-time memory usage. 3) Least complexity. They're weighted in approximately that order, but that doesn't mean that lower numbers always win over higher numbers. Doubling the complexity to save five bytes out of a 12k applet probably isn't a good trade off. So the question is how to balance them. My objection here isn't to your recent checkin itself, it's that I'm trying to figure out where the trend goes from here. Extra config knobs have a complexity cost for people trying to build busybox. What's the best way to balance that cost off against the gain? (Which means, step 1, define the gain so we know what the goal is here.) > AFAIK GNU is backward compatable with SuS, so SuS is definetly a good > standard to aim for, it caters to our demographics. Agreed. What is _in_ SuS, we can assume is likely to be used. > As much as we aim for SuS we do need to be able change the behaviour of > specific applets so users can have a system suited to them, wether its > GNUism, old SuS behaviours or whatever. Yup. "In theory, there is no difference between theory and practice. But, in practice, there is." > I guess im not a pragmatist, because i dont see the relavence of how > cheaply we can implement default functionality that shouldnt be default. My objection isn't to what is and isn't default. (The defaults that interest me are generally "make allyesconfig" and "make allnoconfig". Those are the two ends people are likely to start from.) My objection is really the granularity of configuration. I'm not saying it's a _bad_ idea to make a #config option that removes this stuff. I'm saying it's a bad idea to confront anybody trying to configure busybox for the first time with a half-dozen separate #config options for every single applet. Is there a larger strategy this fits in, and if so should that strategy have a master switch? (I'm not even against having a half-dozen config options per applet someday, as long as it's hidden behind a master CONFIG_NITPICK switch so most people don't have to deal with it.) If you're interested in going down the road of disabling extensions (more power to you), there should probably be a CONFIG_EXTENSIONS switch to group them together somehow. And that requires some thought and design work before we can figure out how to do that (the real _meat_ of the size savings is likely to be in disabling gnu extensions, since there are more of those than obsolete features), and that very much makes it a 1.2 issue. :) And this is _adding_ complexity to potentially reduce size, so we need to think about the tradeoffs a bit in order to make intelligent decisions here. > But the the real question isnt what you or i think should or shouldnt be > in there, but how do we give users the ability to customise > functionality without creating an overly complex configuration system ? We're on the same page. :) > We cant give users more choices of behaviour without asking more > questions... so i think we have to accept busybox is always going to be > complex to configure. Yes and no. If we group options intelligently, it doesn't have to be. Look at it this way: Some users want to use busybox to replace entire packages, so they're thinking in terms of coreutils, util-linux, vi, and so on. What _they_ want is to look at just the top-level menus and "select all" so they can slap something together really quickly. (The ability to then switch off a few obviously unnecessary things in those menus is a bonus. Right now we have make allyesconfig, but not "select all in menu".) Some users want to select a group of specific applets (audit some script to see everything it calls and enable that list of functions). And they just want those applets to work, so they probably want all the functions in that applet. Some are trying to be as small as possible, and will use every config option we give them. And some are hand-tailoring a system that is on such a tight budget that they're willing to spend all day figuring out how to save another 153 bytes to squeeze it down into the next size rom, and will go into our source code to chop out stuff that we never made configurable. Group #1 currently either goes through menus and selects everything (which gets a bit tedious) or does a "make allyesconfig"and goes through the menus they don't want switching stuff off (which is faster: they don't have to deal with sub-features that way, but this is entirely an indiosyncrasy of our menu system) Group #2 is probably the majority. They start from "allnoconfig" and work their way up, and are decently served right now unless they want to configure something like "tar", which has a distracting number of config options. If everything was like tar, our config menus would be quicksand for these people since the "allyesconfig and trim" thing that lets them easily ignore subfeatures doesn't help them. Groups #3 and #4 aren't that far apart to me. Beyond a certain point, us giving them more config features is probably _less_ convenient for them than just pointing them at clean source they can chop irrelevant bits out of. We'll never be able to guess what strange uses our code will be put to, and trying just makes it a mess for the 99% of people who aren't going to do that. I don't know where the tradeoffs are. My mental rule of thumb has been that if a config option saves less than 100 bytes and only a single-digit percentage of our users would ever want to disable it, it's probably not worth the effort of offering a config option for that. We're often _better_ off making our C code as clean as possible so people can tailor it to their needs more easily. That said, one nice thing about the move from CONFIG_BLAH to ENABLE_FEATURE is that the C code is much cleaner, and can handle a higher level of feature removals. (The config menus may not be able to, but the C code can.) On a C code level, the ENABLE_ tags can even be good documentation of what's easy to rip out, where a corresponding amount of #ifdefs would make the code completely unreadable. The issue is then scaling the config menus to handle a higher number of sub-features, without overwhelming people who just want to slap together "mount, sh, sed, find, ls, tar, and cat" for an initramfs. And thus having "CONFIG_SUBFEATURES" in the general options menu that hides all the applet sub-features when it's enabled (and stuff like CONFIG_EXTENSIONS and CONFIG_NITPICK under CONFIG_SUBFEATURES to control how _much_ granularity you want, or perhaps automatically select or deselect certain categories of features (CONFIG_SUSV3_ONLY)) makes sense to me. But again, a 1.2 issue. > Perhaps one thing we could do is group all the SuS utilities together > into their own menu, that way any generic configure options related to > obsolete SuS behaviour (e.g numeric arguments) would be isolated... not > sure if that would make any difference. Mirroring the packages people get these things from elsewhere has a certain appeal, but then again that could just be one configuration option. One approach that has a certain attraction to me is to put every single applet together in one big menu, alphabetically, and then have another menu with selection items for categories, which we could set to Y, N, or M. (Which to _us_ would mean Yes, No, Maybe.) Y means select everything in that category, N means hide everything in that category, and M means make everything in that category show up for individual selection in the big list... We have several different options... > It would be great to have a testsuite that would check standards > conformance, but i suspect there owuld be years of work in developing > it. Ideally such an effort would be supported by other utilties > projects as well. I'm working on it in the 1.2 timeframe. I think that "uniq.tests" is there, sort is more than halfway, I have about the first 1/3 of such a test for sed... I was more worried about getting the testing infrastructure right, and now I'm focusing on shipping 1.1, but this _is_ a priority. The hard ones are the ones requiring root access (mount, losetup, the attribute preserving portions of tar), but the new test infrastructure is basically just a big shell script so I can put "[ `id -u` -ne 0 ] && echo "Skipping root-only tests" && exit 0" before anything requiring root access (or a similar if statement around it). I'm also making it so the busybox tests aren't dependent on busybox. We can run them against the gnu stuff as well to see how we match up. (That's an important part of the new testing infrastructure.) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From jakelly at shtc.net Sun Dec 11 11:48:27 2005 From: jakelly at shtc.net (John Kelly) Date: Sun Dec 11 11:48:40 2005 Subject: mark obsolete usage of fold In-Reply-To: References: <200512111222.44030.rob@landley.net> Message-ID: On Sun, 11 Dec 2005 19:55:32 +0100 (CET), Peter S Mazinger wrote: >On Sun, 11 Dec 2005, Rob Landley wrote: >> There are several bugs I only see linked against uClibc 0.9.28. >do you refer maybe to not supporting *-progname (something w/ short, >can't recall now), so that gnu testsuites fail due to different errors? I don't know what Rob means, but like I said on the uclibc list, __progname is already defined in the uclibc init code, although the GNU aliases for it are not. Since an extern __progname is already available, changing error.c to output the basename of __progname gets the coreutils tests working right. Otherwise, many of them fail due to the simple fact that the tests expect to see the program name in the output. When I posted about this on the uclibc list, some of the response was downright inhospitable. I wonder if they like to hoard secrets, or if they're just ashamed of what little they do know. From rob at landley.net Sun Dec 11 12:22:35 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 12:22:55 2005 Subject: Bug triage. In-Reply-To: <200512100050.24274.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512100050.24274.yann.morin.1998@anciens.enib.fr> Message-ID: <200512111422.36039.rob@landley.net> On Friday 09 December 2005 17:50, Yann E. MORIN wrote: > Hello All! > Rob, > > On Thursday 08 December 2005 073, Rob Landley wrote: > > 304 sometimes rmmod is unable to remove modules > > It's the - vs _ problem again. > > --> Fixed by revision 12546. Got it. > > 468 rmmod does not report failure > > --> Patch attached. > Easy. > > This is the patch from the bug system rediffed against rev 12789. > => busybox-0000468-rmmod-syscall.patch.bz2 Applied. > > 467 rmmod does not handle -w and -f flags > > --> Fixed in revision 12551. Got it. > > 362 insmod chatter > > --> Patch attached. > Trivial. > > There was (IMHO) no need to update usage.h, as it already specifies both > quiet and verbose options. > This is the patch from the bug system rediffed against rev 12789. > => busybox-0000362-insmod-chatter.patch.bz2 Applied. > > 276 Linux 2.6 module autoloading breaks when support for 2.4 modules is > > disabled > > 272 modprobe does not process parameters > > --> Patch attached. > Heavy. > The attached patch about modprobe rework solves these two issues. Note that > it still relies on my MODPROBE_MULTIPLE_OPTIONS. Rediffed against rev > 12789. => busybox-modprobe.patch.bz2 This has unnecessary DEBUG() stuff in it. I'll come back and give it a closer look this evening. > --> Patch attached. > Easy. > Another patch is attached that reworks the config options order and > dependencies. Note that some options were used by either rmmod, insmod, > lsmod or modprobe, but were available only when insmod was selected. > Against rev 12789. => busybox-modutils-config-reworked.patch.bz2 Applied. This fixes bug 272 by itself? > Note that all these patches are not dependent one on the other, and so can > be applied independently. I applied all but one of them. :) Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 11 12:41:21 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 12:42:21 2005 Subject: mark obsolete usage of fold In-Reply-To: References: Message-ID: <200512111441.21507.rob@landley.net> On Sunday 11 December 2005 12:55, Peter S. Mazinger wrote: > > There are several bugs I only see linked against uClibc 0.9.28. The > > mount error message being wrong is another one (which I think is actually > > a busybox problem using memory after free, but the symptom only > > reproduces under uClibc...) > > > > Rob > > do you refer maybe to not supporting *-progname (something w/ short, > can't recall now), so that gnu testsuites fail due to different errors? > > Peter Doesn't ring a bell. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 11 12:43:16 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 12:44:52 2005 Subject: mark obsolete usage of fold In-Reply-To: References: <200512111222.44030.rob@landley.net> Message-ID: <200512111443.16696.rob@landley.net> On Sunday 11 December 2005 13:48, John Kelly wrote: > Since an extern __progname is already available, changing error.c to > output the basename of __progname gets the coreutils tests working > right. Otherwise, many of them fail due to the simple fact that the > tests expect to see the program name in the output. What's wrong with argv[0]? That's what I've always used... Rob > When I posted about this on the uclibc list, some of the response was > downright inhospitable. I wonder if they like to hoard secrets, or if > they're just ashamed of what little they do know. With an attitude like that, I wouldn't talk to you either. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From yann.morin.1998 at anciens.enib.fr Sun Dec 11 13:17:47 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun Dec 11 13:18:28 2005 Subject: Bug triage. In-Reply-To: <200512111422.36039.rob@landley.net> References: <200512080033.37822.rob@landley.net> <200512100050.24274.yann.morin.1998@anciens.enib.fr> <200512111422.36039.rob@landley.net> Message-ID: <200512112217.48114.yann.morin.1998@anciens.enib.fr> On Sunday 11 December 2005 212, Rob Landley wrote: > > --> Patch attached. > > Heavy. > > The attached patch about modprobe rework solves these two issues. Note that > > it still relies on my MODPROBE_MULTIPLE_OPTIONS. Rediffed against rev > > 12789. => busybox-modprobe.patch.bz2 > > This has unnecessary DEBUG() stuff in it. I'll come back and give it a closer > look this evening. I left them on purpose. As I said in the config help, this is WIP, while waiting for the common parsing for all applets. So I thought I'd leave my DEBUGs for when this parsing thingy would be ready, at which point we could remove them. Plus I think that having some DEBUGs in code is never a bad thing. Now, if you want, I can re-submit a cleaned-up patch. > > --> Patch attached. > > Easy. > > Another patch is attached that reworks the config options order and > > dependencies. Note that some options were used by either rmmod, insmod, > > lsmod or modprobe, but were available only when insmod was selected. > > Against rev 12789. => busybox-modutils-config-reworked.patch.bz2 > Applied. This fixes bug 272 by itself? No, sorry I did not make me clear. I did not try to see if any bug (from your list, Rob) would be fixed by this config re-ordering. It seemed the good thing to do from what I saw in the code. Now, sure there are bugs-to-be that are now avoided with this (I can see, at least, not looking at /etc/modprobe.conf for 2.6) 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 ps.m at gmx.net Sun Dec 11 13:26:10 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Sun Dec 11 13:26:53 2005 Subject: mark obsolete usage of fold In-Reply-To: Message-ID: On Sun, 11 Dec 2005, John Kelly wrote: > On Sun, 11 Dec 2005 19:55:32 +0100 (CET), Peter S Mazinger > wrote: > > >On Sun, 11 Dec 2005, Rob Landley wrote: > > >> There are several bugs I only see linked against uClibc 0.9.28. > > >do you refer maybe to not supporting *-progname (something w/ short, > >can't recall now), so that gnu testsuites fail due to different errors? > > I don't know what Rob means, but like I said on the uclibc list, > __progname is already defined in the uclibc init code, although the > GNU aliases for it are not. > > Since an extern __progname is already available, changing error.c to > output the basename of __progname gets the coreutils tests working > right. Otherwise, many of them fail due to the simple fact that the > tests expect to see the program name in the output. > > When I posted about this on the uclibc list, some of the response was > downright inhospitable. I wonder if they like to hoard secrets, or if > they're just ashamed of what little they do know. You understood/reacted wrong imho. uClibc does not want to be GNU compliant. it tries only to be SuSv3 compliant. There are no GNU extensions expected to be added (ask Erik, he may decide otherwise), those being already there are probably because w/o them you can't really use uClibc in real world. If you come up w/ a SuSv3 addon, that is for sure be added. I know about the test failures for GNU apps since a year, but I have no interest to solve it myself. Come up w/ a patch that is option guarded (CONFIG_GNU_COMPAT?), I can imagine it either be added, or begin putting proposed stuff somewhere into the repository. Thanks, Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From jakelly at shtc.net Sun Dec 11 13:45:09 2005 From: jakelly at shtc.net (John Kelly) Date: Sun Dec 11 13:45:59 2005 Subject: mark obsolete usage of fold In-Reply-To: <200512111443.16696.rob@landley.net> References: <200512111222.44030.rob@landley.net> <200512111443.16696.rob@landley.net> Message-ID: On Sun, 11 Dec 2005 14:43:16 -0600, Rob Landley wrote: >On Sunday 11 December 2005 13:48, John Kelly wrote: > >> Since an extern __progname is already available, changing error.c to >> output the basename of __progname gets the coreutils tests working >> right. Otherwise, many of them fail due to the simple fact that the >> tests expect to see the program name in the output. > >What's wrong with argv[0]? That's what I've always used... > >Rob > >> When I posted about this on the uclibc list, some of the response was >> downright inhospitable. I wonder if they like to hoard secrets, or if >> they're just ashamed of what little they do know. > >With an attitude like that, I wouldn't talk to you either. Then there's no reason for me to respond to the question above, is there. From yann.morin.1998 at anciens.enib.fr Sun Dec 11 13:55:10 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Sun Dec 11 13:55:22 2005 Subject: Bug triage. In-Reply-To: <200512100050.24274.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512100050.24274.yann.morin.1998@anciens.enib.fr> Message-ID: <200512112255.11467.yann.morin.1998@anciens.enib.fr> On Saturday 10 December 2005 005, Yann E. MORIN wrote: > Note that all these patches are not dependent one on the other, and so can be > applied independently. Woopss... I lied. In fact, a quirk from one of my other trees has gone into the Config re-oder patch. :-( The damned "modprobe multiple options parsing" config has been renamed from CONFIG_MODPROBE_MULTIPLE_OPTIONS to CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS which is not yet in bb.net repository. This is a reason I don't want svn access: I'm always a bit too quick at things, and thus might commit bad stuff from time to time. Sorry all, and specially you, Rob, who trusted my work. I'll be more careful next time. :-/ 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 jakelly at shtc.net Sun Dec 11 14:04:25 2005 From: jakelly at shtc.net (John Kelly) Date: Sun Dec 11 14:05:12 2005 Subject: mark obsolete usage of fold In-Reply-To: References: Message-ID: <7i7pp1tpjq9dihikf8sofo1b74f3jc724r@4ax.com> On Sun, 11 Dec 2005 22:26:10 +0100 (CET), Peter S Mazinger wrote: >> Since an extern __progname is already available, changing error.c to >> output the basename of __progname gets the coreutils tests working >> right. Otherwise, many of them fail due to the simple fact that the >> tests expect to see the program name in the output. >You understood/reacted wrong imho. uClibc does not want to be GNU >compliant. it tries only to be SuSv3 compliant. There are no GNU >extensions expected to be added (ask Erik, he may decide otherwise), those >being already there are probably because w/o them you can't really use >uClibc in real world. If your "real world" includes GNU coreutils tests, uclibc is not usable. >Come up w/ a patch that is option guarded (CONFIG_GNU_COMPAT?) Printing the program name in the error.c message is a trivial change, hardly an "extension." But it makes a big difference if you want to run coreutils tests. >I can imagine it either be added, or begin putting proposed stuff >somewhere into the repository. I've solved the problem for myself, so I'll just maintain my own patches, and the uclibc devs can stay in their comfort zone. From rob at landley.net Sun Dec 11 19:49:08 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 19:50:02 2005 Subject: Bug triage. In-Reply-To: <200512112217.48114.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512111422.36039.rob@landley.net> <200512112217.48114.yann.morin.1998@anciens.enib.fr> Message-ID: <200512112149.08961.rob@landley.net> On Sunday 11 December 2005 15:17, Yann E. MORIN wrote: > On Sunday 11 December 2005 212, Rob Landley wrote: > > > --> Patch attached. > > > Heavy. > > > The attached patch about modprobe rework solves these two issues. Note > > > that it still relies on my MODPROBE_MULTIPLE_OPTIONS. Rediffed against > > > rev 12789. => busybox-modprobe.patch.bz2 > > > > This has unnecessary DEBUG() stuff in it. I'll come back and give it a > > closer look this evening. > > I left them on purpose. As I said in the config help, this is WIP, while > waiting for the common parsing for all applets. So I thought I'd leave my > DEBUGs for when this parsing thingy would be ready, at which point we could > remove them. Work in progress says to me "don't check this in yet". > Plus I think that having some DEBUGs in code is never a bad thing. In my experience, the set of printfs a given developer decides to stick in is generally only of use to that developer, and other developers stick in different printfs to analyze the code. I know that even when there are existing debug statements, switching on the master debug switch dumps so much information that what you want is lost in the flood even if you know what you're looking for. And it's also been known to change behavior. (In fact the last one of these I tried was lilo, where switching on DEBUG broke the build because the last time the maintainer was debugging anythign it was under DOS, and it was trying to print out the contents of some variables that don't exist on Linux.) > Now, if you want, I can re-submit a cleaned-up patch. Yes please. Personal preference. I like keeping the code clean. > > > --> Patch attached. > > > Easy. > > > Another patch is attached that reworks the config options order and > > > dependencies. Note that some options were used by either rmmod, insmod, > > > lsmod or modprobe, but were available only when insmod was selected. > > > Against rev 12789. => busybox-modutils-config-reworked.patch.bz2 > > > > Applied. This fixes bug 272 by itself? > > No, sorry I did not make me clear. I did not try to see if any bug (from > your list, Rob) would be fixed by this config re-ordering. It seemed the > good thing to do from what I saw in the code. I'll unmark 272 on my list then. :) > Now, sure there are bugs-to-be that are now avoided with this (I can see, > at least, not looking at /etc/modprobe.conf for 2.6) I'm not saying that we can't check in anything that's not a bugfix. (Although after -rc2 goes out, I'm probably going to ask for bugfixes only until New Year's.) But no new features right now, please. :) > Regards, > Yann E. MORIN. -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 11 20:29:14 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 20:30:46 2005 Subject: Bug triage. In-Reply-To: <200512112255.11467.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512100050.24274.yann.morin.1998@anciens.enib.fr> <200512112255.11467.yann.morin.1998@anciens.enib.fr> Message-ID: <200512112229.14368.rob@landley.net> On Sunday 11 December 2005 15:55, Yann E. MORIN wrote: > On Saturday 10 December 2005 005, Yann E. MORIN wrote: > > Note that all these patches are not dependent one on the other, and so > > can be applied independently. > > Woopss... I lied. In fact, a quirk from one of my other trees has gone into > the Config re-oder patch. :-( > > The damned "modprobe multiple options parsing" config has been renamed from > CONFIG_MODPROBE_MULTIPLE_OPTIONS to > CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS which is not yet in bb.net > repository. Yeah, but that's a good idea anyway. (Allbareconfig and such.) I just moved the users to CONFIG_FEATURE to match the kconfig, and checked that in. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 11 20:30:24 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 20:31:14 2005 Subject: mark obsolete usage of fold In-Reply-To: <7i7pp1tpjq9dihikf8sofo1b74f3jc724r@4ax.com> References: <7i7pp1tpjq9dihikf8sofo1b74f3jc724r@4ax.com> Message-ID: <200512112230.24934.rob@landley.net> On Sunday 11 December 2005 16:04, John Kelly wrote: > On Sun, 11 Dec 2005 22:26:10 +0100 (CET), Peter S Mazinger > >You understood/reacted wrong imho. uClibc does not want to be GNU > >compliant. it tries only to be SuSv3 compliant. There are no GNU > >extensions expected to be added (ask Erik, he may decide otherwise), those > >being already there are probably because w/o them you can't really use > >uClibc in real world. > > If your "real world" includes GNU coreutils tests, uclibc is not > usable. If the gnu tests are testing gnu extensions, who cares about that? Show me a real world application that breaks. > >Come up w/ a patch that is option guarded (CONFIG_GNU_COMPAT?) > > Printing the program name in the error.c message is a trivial change, > hardly an "extension." But it makes a big difference if you want to > run coreutils tests. I, personally, don't. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 11 21:14:20 2005 From: rob at landley.net (Rob Landley) Date: Sun Dec 11 21:15:23 2005 Subject: Darn bug collector. Message-ID: <200512112314.20802.rob@landley.net> It seems that "bugs.busybox.net" is indeed a rich source of bugs, although in itself rather than in busybox. Earlier today it was timing out on me. Then it did some strange javascript thing (or something) that caused konqueror to eat CPU until I killed it. I tried again and it just _hung_. (I have no idea why, and I've stopped asking.) If somebody with access to the bug generator (which, currently, I can't honestly say I have, despite having an account) would like to close these out, that would be nice: 550 MAP_SHARED in insmod causes problems in uClinux svn 12711 529 Syntax (macro definition) error stops build svn 12715 498 mount loop device support broken This one's wasn't our bug in the first place. He had devfs support enabled on a non-devfs system, which breaks stuff. 494 ash prompt corruption svn 11650 (vodz, 2005-09-26) 568 vi displays inserted text incorrectly. svn 11477 (pgf, 2005-09-16) 406 1.01 won't build with shadow passwords disabled Not a problem in 1.1 304 sometimes rmmod is unable to remove modules svn 12546 468 rmmod does not report failure svn 12836 467 rmmod does not handle -w and -f flags svn 12551 362 insmod chatter svn 12838 Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From frank at tuxrocks.com Sun Dec 11 21:23:10 2005 From: frank at tuxrocks.com (Frank Sorenson) Date: Sun Dec 11 21:57:47 2005 Subject: Updated mdev Message-ID: <439D093E.8070301@tuxrocks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attached is an updated mdev. Changes from the previous version: - - bugfixes mentioned on this list - - mdev now dynamically adds and removes device nodes - - command line arguments to process /sys once, monitor for changes, or both mdev compiles to < 7K Comments are welcome. Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University frank@tuxrocks.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDnQk9aI0dwg4A47wRAkC7AKCMkU2ewkS7/q6BWnlXKUoNJEwJDACfQ6Do glsOGXOdSK5hZwLJAntz0G8= =LGEu -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: mdev.c Type: text/x-csrc Size: 6449 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051211/5ad1a856/mdev.c From stephane.billiart at gmail.com Sun Dec 11 22:38:37 2005 From: stephane.billiart at gmail.com (Stephane Billiart) Date: Sun Dec 11 22:52:47 2005 Subject: read-only root fs with Busybox? In-Reply-To: <1125D9E6416F00489EA977418E764B4FE4FAB0@CGYSVW100.gdcan.com> References: <1125D9E6416F00489EA977418E764B4FE4FAB0@CGYSVW100.gdcan.com> Message-ID: <20051212063837.GA19812@localhost.localdomain> On 08/12/05 ? ? 18:07, Jessee, Mark wrote: > > Hi, > > I'm attempting to setup a read-only root filesystem on a Compact Flash card. [...] That's also what I have been doing for quite some time now. > Do I need to add an entry in /etc/fstab for '/' to allow the mount command to > work properly? Does this work alongside the GRUB parameters? Or does adding an > entry for '/' in /etc/fstab with the 'ro' option mean I no longer need to pass > 'ro' in GRUB? > > Why does 'cat /proc/mounts' give 2 entries for '/' with 'rootfs' being 'rw'? Personnally, I use LILO and my /etc/fstab has no entry for '/'. Like you, I have a rootfs partition which is mounted rw, I don't have an explanation for this but I don't think it is an issue. sokdist# cat /etc/fstab proc /proc proc defaults 0 0 devpts /dev/pts devpts defaults 0 0 sokdist# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext2 ro,nogrpid 0 0 none /proc proc rw,nodiratime 0 0 none /sys sysfs rw 0 0 none /var tmpfs rw,noexec 0 0 none /dev/pts devpts rw 0 0 usbfs /proc/bus/usb usbfs rw 0 0 > > Any tips on the correct configuration for a read-only root fs with support for > remounting read-write? Here is what I use to remount rw/ro at will mount -o remount,rw,noatime -n /dev/root / mount -o remount,ro -n /dev/root / -- St?phane Billiart http://perso.wanadoo.fr/billiart/ From ps.m at gmx.net Sun Dec 11 23:26:01 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Sun Dec 11 23:27:14 2005 Subject: mark obsolete usage of fold In-Reply-To: Message-ID: On Sun, 11 Dec 2005, John Kelly wrote: > On Sun, 11 Dec 2005 14:43:16 -0600, Rob Landley > wrote: > > >On Sunday 11 December 2005 13:48, John Kelly wrote: > > > >> Since an extern __progname is already available, changing error.c to > >> output the basename of __progname gets the coreutils tests working > >> right. Otherwise, many of them fail due to the simple fact that the > >> tests expect to see the program name in the output. > > > >What's wrong with argv[0]? That's what I've always used... > > > >Rob > > > >> When I posted about this on the uclibc list, some of the response was > >> downright inhospitable. I wonder if they like to hoard secrets, or if > >> they're just ashamed of what little they do know. > > > >With an attitude like that, I wouldn't talk to you either. > > Then there's no reason for me to respond to the question above, is > there. Wrong conclusion/reaction again ;) Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From ps.m at gmx.net Sun Dec 11 23:30:23 2005 From: ps.m at gmx.net (Peter S. Mazinger) Date: Sun Dec 11 23:31:24 2005 Subject: mark obsolete usage of fold In-Reply-To: <7i7pp1tpjq9dihikf8sofo1b74f3jc724r@4ax.com> Message-ID: On Sun, 11 Dec 2005, John Kelly wrote: > On Sun, 11 Dec 2005 22:26:10 +0100 (CET), Peter S Mazinger > wrote: > > >> Since an extern __progname is already available, changing error.c to > >> output the basename of __progname gets the coreutils tests working > >> right. Otherwise, many of them fail due to the simple fact that the > >> tests expect to see the program name in the output. > > >You understood/reacted wrong imho. uClibc does not want to be GNU > >compliant. it tries only to be SuSv3 compliant. There are no GNU > >extensions expected to be added (ask Erik, he may decide otherwise), those > >being already there are probably because w/o them you can't really use > >uClibc in real world. > > If your "real world" includes GNU coreutils tests, uclibc is not > usable. > > > >Come up w/ a patch that is option guarded (CONFIG_GNU_COMPAT?) > > Printing the program name in the error.c message is a trivial change, > hardly an "extension." But it makes a big difference if you want to > run coreutils tests. > > > >I can imagine it either be added, or begin putting proposed stuff > >somewhere into the repository. > > I've solved the problem for myself, so I'll just maintain my own > patches, and the uclibc devs can stay in their comfort zone. Keep it secret then Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 From steven.scholz at imc-berlin.de Mon Dec 12 00:27:29 2005 From: steven.scholz at imc-berlin.de (Steven Scholz) Date: Mon Dec 12 00:28:42 2005 Subject: Problems with output to console In-Reply-To: <200512110007.47880.rob@landley.net> References: <439AB0D0.4040801@imc-berlin.de> <200512110007.47880.rob@landley.net> Message-ID: <439D3471.20700@imc-berlin.de> Rob, >>On one board I see the output. This one has /dev/ttySMX0 (204,41) as >>serial console. On the other board I do _not_ see the output. This has >>/dev/ttyS0 (4,64) as serial console. >> >>When I start foobar directly in inittab it works on both. >> >>When I create a link "ln -s /dev/ttySMX0 /dev/ttyS0" on the first board, >>then I cant see the output there anymore. >> >>Could someone please explain to me what's going on here. > > > Read init/init.c (which is, alas, a mess o' suckage). > > static char console[CONSOLE_BUFF_SIZE] = _PATH_CONSOLE; > > (That's from some header file). > > static void console_init(void) > { > ... > if ((s = getenv("CONSOLE")) != NULL || (s = getenv("console")) != NULL) { > safe_strncpy(console, s, sizeof(console)); > > And the read on for the full horror of serial console detection and tty and > such... It gets ugly quickly... > > I rewrote all this once. Need to do it again in 2.2... Could you give me a little hint why I dont get any output when creating the link /dev/ttyS0 -> /dev/ttySMX0? How could I hack init/init.c so it works on the board where the serial console is actually ttyS0? Thanks a million! -- Steven From yann.morin.1998 at anciens.enib.fr Mon Dec 12 02:47:50 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Mon Dec 12 02:48:04 2005 Subject: Bug triage. In-Reply-To: <200512112149.08961.rob@landley.net> References: <200512080033.37822.rob@landley.net> <200512112217.48114.yann.morin.1998@anciens.enib.fr> <200512112149.08961.rob@landley.net> Message-ID: <200512121147.51216.yann.morin.1998@anciens.enib.fr> On Monday 12 December 2005 044, Rob Landley wrote: > Work in progress says to me "don't check this in yet". I do agree. On the other hand, WIP is a big name here. What I meant is that a temporary fix is included, until the correct and right one is in place (because it takes time, and I think we can't afford waiting). > > Now, if you want, I can re-submit a cleaned-up patch. > Yes please. Personal preference. I like keeping the code clean. OK, folowing in a next mail. > I'll unmark 272 on my list then. :) But still, 272 will be fixed by the modprobe patch. > > Now, sure there are bugs-to-be that are now avoided with this (I can see, > > at least, not looking at /etc/modprobe.conf for 2.6) > I'm not saying that we can't check in anything that's not a bugfix. (Although > after -rc2 goes out, I'm probably going to ask for bugfixes only until New > Year's.) > But no new features right now, please. :) No new feature, only bugs-to-be killed in the egg. 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 Dec 12 00:06:45 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 03:02:38 2005 Subject: read-only root fs with Busybox? In-Reply-To: <20051212063837.GA19812@localhost.localdomain> References: <1125D9E6416F00489EA977418E764B4FE4FAB0@CGYSVW100.gdcan.com> <20051212063837.GA19812@localhost.localdomain> Message-ID: <200512120206.45126.rob@landley.net> On Monday 12 December 2005 00:38, Stephane Billiart wrote: > On 08/12/05 ? ? 18:07, Jessee, Mark wrote: > > Hi, > > > > I'm attempting to setup a read-only root filesystem on a Compact Flash > > card. > > [...] > > That's also what I have been doing for quite some time now. My firmware linux thing has a read-only root filesystem that's on squashfs, although flash isn't currently involved (but could be). > > Do I need to add an entry in /etc/fstab for '/' to allow the mount > > command to work properly? Does this work alongside the GRUB parameters? > > Or does adding an entry for '/' in /etc/fstab with the 'ro' option mean I > > no longer need to pass 'ro' in GRUB? > > > > Why does 'cat /proc/mounts' give 2 entries for '/' with 'rootfs' being > > 'rw'? In the 2.6.15 kernel, read "Documentation/filesystems/ramfs-rootfs-initramfs.txt". rootfs is always mounted at /, but it's generally an empty ramfs that gets the real root mounted over it, and is thus inaccessable. (You can probably do a mount -o remount,ro on it.) > Personnally, I use LILO and my /etc/fstab has no entry for '/'. Considering / has to be mounted before fstab can be found (modulo being on initramfs), it's a bit redundant to list root in there. Maybe as documentation, but it can never be _useful_. By the time you've got it, it's too late. > Like you, I have a rootfs partition which is mounted rw, I don't have > an explanation for this but I don't think it is an issue. rootfs is always present in 2.6 kernels. (Among other things, it's the starting and ending point for searches of the circular doubly linked list of kernel mount points.) It's sort of the "idle task" of filesystems, as it were. > sokdist# cat /etc/fstab > proc /proc proc defaults 0 0 > devpts /dev/pts devpts defaults 0 0 > sokdist# cat /proc/mounts > rootfs / rootfs rw 0 0 > /dev/root / ext2 ro,nogrpid 0 0 > none /proc proc rw,nodiratime 0 0 > none /sys sysfs rw 0 0 > none /var tmpfs rw,noexec 0 0 > none /dev/pts devpts rw 0 0 > usbfs /proc/bus/usb usbfs rw 0 0 No /dev/shm? > > Any tips on the correct configuration for a read-only root fs with > > support for remounting read-write? > > Here is what I use to remount rw/ro at will > > mount -o remount,rw,noatime -n /dev/root / > mount -o remount,ro -n /dev/root / I'm fixing mount so that "mount -o remount,ro /" will actually work without having to specify /dev/root again, by the way... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Sun Dec 11 23:57:58 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 03:02:49 2005 Subject: Updated mdev In-Reply-To: <439D093E.8070301@tuxrocks.com> References: <439D093E.8070301@tuxrocks.com> Message-ID: <200512120157.58902.rob@landley.net> On Sunday 11 December 2005 23:23, Frank Sorenson wrote: > Attached is an updated mdev. Changes from the previous version: > > - bugfixes mentioned on this list > - mdev now dynamically adds and removes device nodes > - command line arguments to process /sys once, monitor for changes, or > both > > mdev compiles to < 7K > > Comments are welcome. Highly cool. Let's take a look... First thing I noticed paging through: A) file_exists() is only used in one place, so making a function for it is kinda pointless. B) the switch statement is unnecessary complication; if stat() returns -1 for root (which this has to be running as), you can assume we can't access this file. C) "man 2 access". The easy way to ask "does it exist" is access(file,0); Looking more closely, you also seem to have reimplemented strcat (string_cat()), strncmp (string_cmpn()), memset (clear_mem())... Why did you do this? Looking at get_device_info (which is another function that's called from only one place): BUFFER_LENGTH was chosen how? (I'd be more comfortable with bb_asprintf() here.) The check if (ret ==0 ) leaks the filehandle, and doesn't catch the actual error return value (-1) which would leading to the buf[ret-1]=0 assignment writing outside the buffer... All this stuff with netlink needs a CONFIG_ and #ifdefs. Is there _really_ no better header to include than linux/netlink.h and linux/types.h? process_netlink_message: Apparently, it can never get a block device hotplugged over netlink, just char devices. Why bother to check if the file exists before calling unlink? Why do you care about unknown messages from netlink enough to print a message (and filter out a known message about modules which you don't intend to do anything about, just to avoid printing this message)? Why does this function bother returning anything if it's always going to be 0? Why is usage() a function? Or run_daemon()? (Again, called from only one place...) So when this program is run with no arguments, it does nothing? (Not even a help message?) Did you see any of the discussion on the busybox list about a minimal config file format to specify ownership and permissions for devices? What's the deal with local_errno? (You're not using threads, so why cache the value in a local variable?) Errors should go to stderr (dprintf(2,blah) or fprintf(stderr,blah)). (By the way, in busybox we have our own library shared between applets, and that has error printing functions anyway. But I don't expect you to know that...) If nobody ever pays attention to the return value of make_device(), why does it bother to return different values? Similarly, the one and only caller of get_device_info() wouldn't have to deal with marshalling arguments back through integer pointers if the code was just inline. On the whole it's cool, but not something I'd merge right now. I have plans to tackle mdev for busybox at the start of 1.2. (Including the config file functionality and adding it to applets.h and usage.h and kconfig all that.) I see several chunks of code I can use in here, but I'd clean it up noticeably. (Heck, I might take a stab at it tomorrow if I get sick of bug-whacking. Currently going through my triage.txt file and closing out bugs from bugs.busybox.net.) > Thanks, > > Frank Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 12 03:10:23 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 03:10:51 2005 Subject: Problems with output to console In-Reply-To: <439D3471.20700@imc-berlin.de> References: <439AB0D0.4040801@imc-berlin.de> <200512110007.47880.rob@landley.net> <439D3471.20700@imc-berlin.de> Message-ID: <200512120510.23903.rob@landley.net> On Monday 12 December 2005 02:27, Steven Scholz wrote: > Could you give me a little hint why I dont get any output when creating > the link /dev/ttyS0 -> /dev/ttySMX0? > > How could I hack init/init.c so it works on the board where the serial > console is actually ttyS0? > > Thanks a million! Unfortunately, I'm falling asleep right now and can't quite think straight, but if you want to stick printfs into init what you can do is open /dev/console (or whatever output device you know works for you) and put fprintf() or dprintf() statements writing to that file with your debug info. Then you can see what it's actually doing. Also, I find qemu highly cool for debugging this sort of thing, but User Mode Linux might also work for you... > -- > Steven Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From yann.morin.1998 at anciens.enib.fr Mon Dec 12 03:20:44 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Mon Dec 12 03:22:22 2005 Subject: Bug triage. In-Reply-To: <200512100050.24274.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512100050.24274.yann.morin.1998@anciens.enib.fr> Message-ID: <200512121220.44530.yann.morin.1998@anciens.enib.fr> Hello All! Rob, On Saturday 10 December 2005 005, Yann E. MORIN wrote: > > 276 Linux 2.6 module autoloading breaks when support for 2.4 modules is > > disabled > > 272 modprobe does not process parameters > > --> Patch attached. > Heavy. > The attached patch about modprobe rework solves these two issues. Note that > it still relies on my MODPROBE_MULTIPLE_OPTIONS. Rediffed against rev 12789. > => busybox-modprobe.patch.bz2 Attached a cleaned-up patch for modprobe. 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: busybox-modprobe.patch.bz2 Type: application/x-bzip2 Size: 6605 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20051212/9edac6e8/busybox-modprobe.patch.bin From frank at tuxrocks.com Mon Dec 12 08:18:37 2005 From: frank at tuxrocks.com (Frank Sorenson) Date: Mon Dec 12 08:19:38 2005 Subject: Updated mdev In-Reply-To: <200512120157.58902.rob@landley.net> References: <439D093E.8070301@tuxrocks.com> <200512120157.58902.rob@landley.net> Message-ID: <439DA2DD.3060103@tuxrocks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Landley wrote: > Highly cool. Let's take a look... > > First thing I noticed paging through: > > A) file_exists() is only used in one place, so making a function for it is > kinda pointless. Good point, and you're right that I've got several of these. > B) the switch statement is unnecessary complication; if stat() returns -1 for > root (which this has to be running as), you can assume we can't access this > file. > > C) "man 2 access". The easy way to ask "does it exist" is access(file,0); > > Looking more closely, you also seem to have reimplemented strcat > (string_cat()), strncmp (string_cmpn()), memset (clear_mem())... Why did you > do this? Mostly because I seemed to be able to reimplement them smaller than if I just used the functions. "I'm an idiot" factors highly into this, I'm sure ;) > Looking at get_device_info (which is another function that's called from only > one place): BUFFER_LENGTH was chosen how? (I'd be more comfortable with > bb_asprintf() here.) The check if (ret ==0 ) leaks the filehandle, and > doesn't catch the actual error return value (-1) which would leading to the > buf[ret-1]=0 assignment writing outside the buffer... > > All this stuff with netlink needs a CONFIG_ and #ifdefs. Is there _really_ no > better header to include than linux/netlink.h and linux/types.h? Not sure. The udev code itself went this way, and I wasn't aware of replacements. > process_netlink_message: Apparently, it can never get a block device > hotplugged over netlink, just char devices. Both char and block devices should be handled. Why bother to check if the file > exists before calling unlink? Why do you care about unknown messages from > netlink enough to print a message (and filter out a known message about > modules which you don't intend to do anything about, just to avoid printing > this message)? Why does this function bother returning anything if it's > always going to be 0? > > Why is usage() a function? Or run_daemon()? (Again, called from only one > place...) > > So when this program is run with no arguments, it does nothing? (Not even a > help message?) I'm still an idiot :) > Did you see any of the discussion on the busybox list about a minimal config > file format to specify ownership and permissions for devices? Yes. It shouldn't be too difficult to add the code to read the config and set permissions and ownership. > What's the deal with local_errno? (You're not using threads, so why cache the > value in a local variable?) Errors should go to stderr (dprintf(2,blah) or > fprintf(stderr,blah)). I'm an idiot again? (By the way, in busybox we have our own library > shared between applets, and that has error printing functions anyway. But I > don't expect you to know that...) Nice. I figured it could be fixed for busybox by someone who knew what they were doing. > If nobody ever pays attention to the return value of make_device(), why does > it bother to return different values? Similarly, the one and only caller of > get_device_info() wouldn't have to deal with marshalling arguments back > through integer pointers if the code was just inline. > > On the whole it's cool, but not something I'd merge right now. Understood. This was more a proof-of-concept and a first crack at implementing it small. It's functional code, but definitely not clean and complete. > I have plans to tackle mdev for busybox at the start of 1.2. (Including the > config file functionality and adding it to applets.h and usage.h and kconfig > all that.) I see several chunks of code I can use in here, but I'd clean it > up noticeably. Please do. It's working code, but obviously needs help. Feel free to take whatever you find helpful in your rewrite. (Heck, I might take a stab at it tomorrow if I get sick of > bug-whacking. Currently going through my triage.txt file and closing out > bugs from bugs.busybox.net.) Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University frank@tuxrocks.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDnaLdaI0dwg4A47wRAka5AJ9a8uVa7NZwqn3Z4aoNQ0UtduVVsACgs7Y2 Wq/ZZvIK5XUg0B0lOny6jso= =mX1F -----END PGP SIGNATURE----- From rob at landley.net Mon Dec 12 11:39:11 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 11:39:47 2005 Subject: Bug triage. In-Reply-To: <200512121220.44530.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512100050.24274.yann.morin.1998@anciens.enib.fr> <200512121220.44530.yann.morin.1998@anciens.enib.fr> Message-ID: <200512121339.11536.rob@landley.net> On Monday 12 December 2005 05:20, Yann E. MORIN wrote: > Hello All! > Rob, > > On Saturday 10 December 2005 005, Yann E. MORIN wrote: > > > 276 Linux 2.6 module autoloading breaks when support for 2.4 modules > > > is disabled > > > 272 modprobe does not process parameters > > > > --> Patch attached. > > Heavy. > > The attached patch about modprobe rework solves these two issues. Note > > that it still relies on my MODPROBE_MULTIPLE_OPTIONS. Rediffed against > > rev 12789. => busybox-modprobe.patch.bz2 > > Attached a cleaned-up patch for modprobe. Coolness. p = strchr (buffer, ' '); if (p) { *p = 0; + for( p = buffer; ENABLE_FEATURE_2_6_MODULES && *p; p++ ) { + *p = ((*p)=='-')?'_':*p; + } I'm not 100% certain that can cleanly be optimized away, since p lives outside your current scope and the for(;;) will assign to p before terminating (and hopefully optimizing out the body of) the loop. One reason I've been holding on the CONFIG_->ENABLE_ conversion is to get more familiar with the optimization capabilities of gcc. (What kind of guards can we get away with doing without accidentally bloating the code? if(ENABLE) seems pretty safe. I'd want to check this vs putting an explicit if(ENABLE) around it. Might be clearer from a code reading point anyway...) -#ifdef CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS -#ifdef CONFIG_FEATURE_CLEAN_UP - argc_malloc = argc; -#endif + if( ENABLE_FEATURE_CLEAN_UP ) + argc_malloc = argc; You dropped a MODPROBE_MULTIPLE_OPTIONS guard here. I'm assuming it's intentional, could you walk me through the logic? (What lets this optimize out, or why shouldn't it?) -#if defined(CONFIG_FEATURE_2_6_MODULES) - if ( argc ) { + if( argc ) { Why was that guard unnecessary? I just checked it in. Does it fix bugs 276 and 272? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 12 11:59:55 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 12:00:16 2005 Subject: Updated mdev In-Reply-To: <439DA2DD.3060103@tuxrocks.com> References: <439D093E.8070301@tuxrocks.com> <200512120157.58902.rob@landley.net> <439DA2DD.3060103@tuxrocks.com> Message-ID: <200512121359.55714.rob@landley.net> On Monday 12 December 2005 10:18, Frank Sorenson wrote: > > Looking more closely, you also seem to have reimplemented strcat > > (string_cat()), strncmp (string_cmpn()), memset (clear_mem())... Why did > > you do this? > > Mostly because I seemed to be able to reimplement them smaller than if I > just used the functions. > > "I'm an idiot" factors highly into this, I'm sure ;) Well, gcc can definitely lead to that sort of thinking. Linking against uClibc and klibc, however, tends to give much more sane results. > > Looking at get_device_info (which is another function that's called from > > only one place): BUFFER_LENGTH was chosen how? (I'd be more comfortable > > with bb_asprintf() here.) The check if (ret ==0 ) leaks the filehandle, > > and doesn't catch the actual error return value (-1) which would leading > > to the buf[ret-1]=0 assignment writing outside the buffer... > > > > All this stuff with netlink needs a CONFIG_ and #ifdefs. Is there > > _really_ no better header to include than linux/netlink.h and > > linux/types.h? > > Not sure. The udev code itself went this way, and I wasn't aware of > replacements. I haven't looked at any remotely recent udev code, but I'll take a look and see what else I can come up with. > > process_netlink_message: Apparently, it can never get a block device > > hotplugged over netlink, just char devices. > > Both char and block devices should be handled. How? In make_device: if (string_cmpn(path, "/sys/block", 10)) type = S_IFBLK; else if (string_cmpn(path, "/sys/class", 10)) type = S_IFCHR; In process_netlink_message: if (string_cmpn(message, "add@/class/", 11) || string_cmpn(message, "add@/block/", 11)) { message[0] = '/'; message[1] = 's'; message[2] = 'y'; message[3] = 's'; make_device(message); And that's always going to start with /sys/class, so char device. Where do block device messages come in via netlink? ... > > So when this program is run with no arguments, it does nothing? (Not > > even a help message?) > > I'm still an idiot :) Code review. People catch stuff in my code all the time... :) > > Did you see any of the discussion on the busybox list about a minimal > > config file format to specify ownership and permissions for devices? > > Yes. It shouldn't be too difficult to add the code to read the config > and set permissions and ownership. Cool. I can code this up if you like. I _think_ all we need is the device permissions and ownership syntax (with regex support), and the shellout syntax. All the stuff about creating symlinks and directories we really don't need to do. If we don't mount /dev or /sys then the script that does that (and then calls us) can do any other setup required. > Nice. I figured it could be fixed for busybox by someone who knew what > they were doing. That would be me. :) Hmmm... I really _shouldn't_ take a stab at this today, but considering I'm the one setting the schedule for all this in the first place... :) > > On the whole it's cool, but not something I'd merge right now. > > Understood. This was more a proof-of-concept and a first crack at > implementing it small. It's functional code, but definitely not clean > and complete. It's not that far from being turned into something clean and complete, though. I'll probably take a whack at it out of sheer momentum at this point. (I always find _reading_ code to be the hard part. Writing it is easy...) > > I have plans to tackle mdev for busybox at the start of 1.2. (Including > > the config file functionality and adding it to applets.h and usage.h and > > kconfig all that.) I see several chunks of code I can use in here, but > > I'd clean it up noticeably. > > Please do. It's working code, but obviously needs help. Feel free to > take whatever you find helpful in your rewrite. Ooh, temptation... Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 12 13:02:38 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 13:05:08 2005 Subject: Updated mdev In-Reply-To: <200512121359.55714.rob@landley.net> References: <439D093E.8070301@tuxrocks.com> <439DA2DD.3060103@tuxrocks.com> <200512121359.55714.rob@landley.net> Message-ID: <200512121502.39332.rob@landley.net> On Monday 12 December 2005 13:59, Rob Landley wrote: > > Mostly because I seemed to be able to reimplement them smaller than if I > > just used the functions. > > > > "I'm an idiot" factors highly into this, I'm sure ;) > > Well, gcc can definitely lead to that sort of thinking. Ahem. glibc, I mean. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From yann.morin.1998 at anciens.enib.fr Mon Dec 12 14:31:53 2005 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Mon Dec 12 14:32:44 2005 Subject: modprobe update [Was: Re: Bug triage.] In-Reply-To: <200512121339.11536.rob@landley.net> References: <200512080033.37822.rob@landley.net> <200512121220.44530.yann.morin.1998@anciens.enib.fr> <200512121339.11536.rob@landley.net> Message-ID: <200512122331.54319.yann.morin.1998@anciens.enib.fr> Hello all! Rob, On Monday 12 December 2005 203, Rob Landley wrote: > p = strchr (buffer, ' '); > if (p) { > *p = 0; > + for( p = buffer; ENABLE_FEATURE_2_6_MODULES && *p; > p++ ) > { > + *p = ((*p)=='-')?'_':*p; > + } > I'm not 100% certain that can cleanly be optimized away, since p lives outside > your current scope and the for(;;) will assign to p before terminating (and > hopefully optimizing out the body of) the loop. > One reason I've been holding on the CONFIG_->ENABLE_ conversion is to get more > familiar with the optimization capabilities of gcc. (What kind of guards can > we get away with doing without accidentally bloating the code? if(ENABLE) > seems pretty safe. I'd want to check this vs putting an explicit if(ENABLE) > around it. Might be clearer from a code reading point anyway...) You are right. I'm not familiar to C compiler optimisation either, but your reasoning sounds perfectly, well, sound, here. I was thinking, the loop condition is always false, so gcc (and others) will clean that up for us. On the other hand, we will always stumble on dumb (or 'broken') compilers that will not optimises those things out. If we want to be 100% sure no unused code sneaks into the binary, then #ifdef's are the only option, at the expense of readability. Do you want a patch with if(ENABLE) ? > -#ifdef CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS > -#ifdef CONFIG_FEATURE_CLEAN_UP > - argc_malloc = argc; > -#endif > + if( ENABLE_FEATURE_CLEAN_UP ) > + argc_malloc = argc; > You dropped a MODPROBE_MULTIPLE_OPTIONS guard here. I'm assuming it's > intentional, could you walk me through the logic? (What lets this optimize > out, or why shouldn't it?) It is intentional, yes: in this place, options are already parsed (wether it be from config file, or from command line. This allows to free up the memory used by the array to exec(insmod). We want to free up that array, wether we do options parsing, or not. argc_malloc is always declared. If CONFIG_FEATURE_CLEAN_UP is declared, then argc_malloc gets used (written, then read). If CONFIG_FEATURE_CLEAN_UP is not declared, then argc_malloc is only declared, and gcc optimises it out, at the expense of one compiler warning. Am I wrong? Note that the array is filled by the parent before the fork, copied to the child when forking, and freed by the parent. The child automatically frees the copy array with the exec() call. > -#if defined(CONFIG_FEATURE_2_6_MODULES) > - if ( argc ) { > + if( argc ) { > Why was that guard unnecessary? Because we want to use the options from the command line, for both 2.6 and 2.4. That solves bug #272. > I just checked it in. Does it fix bugs 276 and 272? Good. And yes, both bugs are fixed with this patch. 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 bug1 at iinet.net.au Mon Dec 12 16:02:23 2005 From: bug1 at iinet.net.au (Glenn L. McGrath) Date: Mon Dec 12 16:04:45 2005 Subject: Busybox and standards/direction, old tar options In-Reply-To: <200512111340.51891.rob@landley.net> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512110405.37813.rob@landley.net> <20051212001005.055ef1c2.bug1@iinet.net.au> <200512111340.51891.rob@landley.net> Message-ID: <20051213110223.2eb3dfba.bug1@iinet.net.au> On Sun, 11 Dec 2005 13:40:51 -0600 Rob Landley wrote: > On Sunday 11 December 2005 07:10, Glenn McGrath wrote: > > When trying to _define_ a standard there will always be people who > > think this should be in the standard or that shouldnt be in it. So > > multiple standards can be defined at the same time targeting different > > demographics. > > Standards should document, not legislate. "This is the existing best > practice" is a good thing. "We think you should do it this way" is seldom a > good thing to come out of a committee. I hate the concept of pax, its a utilitiy created by a standards body becasue on paper they wanted one standard archiving format and both tar and cpio were used in practice. The standards bodies solution was to create utuility that supports both formats and define it as the standard. I think its good to support people who understand but disagree with a standard, but i have no sympathy for people for follow old standards becasue they are lazy. Laziness is how i see the situation with numeric argument. - arguments were removed because its inconsistent with standard option parsing, imagine if people started wanting to doing - without typing the opion name. It could get very confusing, and hard to parse. Which reminds me, i disagree in principle with supporting old tar options (short options with out the leading '-') GNU considers them obsolete and we arent doing it properly anyway. e.g. $ tar cCf . foo.tar AUTHORS $ ./busybox tar cCf . foo.tar AUTHORS tar: Couldnt chdir to f: No such file or directory $ tar xfC . foo.tar $ ./busybox tar xCf . foo.tar tar: Couldnt chdir to f: No such file or directory There is section in the tar info pages on old options, its more complex than just putting a '-' infront of things, it can also require re-ordering parameters. With old options the order of the option indicates the order of the arguments e.g. These both work $ tar xfC . foo.tar $ tar xCf foo.tar . These both fail $ tar xfC foo.tar . $ tar xCf . foo.tar I thinks old tar options are something left buried, better to encourge people to update the behaviour to use short options. e.g. all of these work and its easy to see which paramater belongs to which option. $ tar -xC . -f foo.tar $ tar -xf foo.tar -C . $ tar -x -f foo.tar -C . $ tar -x -C . -f foo.tar And if people do think that the old tar option behaviour is a good thing then i would expect them to want to apply the same concept to all applets, not just tar. I dont like it in ar etiher, but at least in ar its not considered obsolete by any upstream (possibly because ar is somewhat neglected), and there has never been an ar standard. > One approach that has a certain attraction to me is to put every single applet > together in one big menu, alphabetically, and then have another menu with > selection items for categories, which we could set to Y, N, or M. (Which to > _us_ would mean Yes, No, Maybe.) Y means select everything in that category, > N means hide everything in that category, and M means make everything in that > category show up for individual selection in the big list... > > We have several different options... Hmm, so we have a low level configuration menu where experienced users can tweak to their hearts content, and a high level menu that just beascially uses presets on the lower level configuration options... Sounds reasonable to me. Glenn From bug1 at iinet.net.au Mon Dec 12 16:58:31 2005 From: bug1 at iinet.net.au (Glenn L. McGrath) Date: Mon Dec 12 16:59:18 2005 Subject: Busybox and standards/direction, old tar options In-Reply-To: <20051213110223.2eb3dfba.bug1@iinet.net.au> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512110405.37813.rob@landley.net> <20051212001005.055ef1c2.bug1@iinet.net.au> <200512111340.51891.rob@landley.net> <20051213110223.2eb3dfba.bug1@iinet.net.au> Message-ID: <20051213115831.0ac044dc.bug1@iinet.net.au> On Tue, 13 Dec 2005 11:02:23 +1100 "Glenn L. McGrath" wrote: > With old options the order of the option indicates the order of the > arguments e.g. > These both work > $ tar xfC . foo.tar > $ tar xCf foo.tar . > These both fail > $ tar xfC foo.tar . > $ tar xCf . foo.tar Duoh, I have that backwards bad $ tar xfC . foo.tar $ tar xCf foo.tar . good $ tar xfC foo.tar . $ tar xCf . foo.tar Glenn From rob at landley.net Mon Dec 12 18:30:29 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 18:31:21 2005 Subject: modprobe update [Was: Re: Bug triage.] In-Reply-To: <200512122331.54319.yann.morin.1998@anciens.enib.fr> References: <200512080033.37822.rob@landley.net> <200512121339.11536.rob@landley.net> <200512122331.54319.yann.morin.1998@anciens.enib.fr> Message-ID: <200512122030.30142.rob@landley.net> On Monday 12 December 2005 16:31, Yann E. MORIN wrote: > Hello all! > Rob, > > On Monday 12 December 2005 203, Rob Landley wrote: > > p = strchr (buffer, ' '); > > if (p) { > > *p = 0; > > + for( p = buffer; ENABLE_FEATURE_2_6_MODULES && > > *p; p++ ) > > { > > + *p = ((*p)=='-')?'_':*p; > > + } > > I'm not 100% certain that can cleanly be optimized away, since p lives > > outside your current scope and the for(;;) will assign to p before > > terminating (and hopefully optimizing out the body of) the loop. > > One reason I've been holding on the CONFIG_->ENABLE_ conversion is to get > > more familiar with the optimization capabilities of gcc. (What kind of > > guards can we get away with doing without accidentally bloating the code? > > if(ENABLE) seems pretty safe. I'd want to check this vs putting an > > explicit if(ENABLE) around it. Might be clearer from a code reading > > point anyway...) > > You are right. I'm not familiar to C compiler optimisation either, but your > reasoning sounds perfectly, well, sound, here. I was thinking, the loop > condition is always false, so gcc (and others) will clean that up for us. It's possible (in fact, likely) that assigning to a variable that is never read from again will be discarded. But if this variable is re-used several times, I'm not sure. (This falls under constant propogation and lifespan analysis. I haven't looked at the surrounding code. The nice thing about putting an if() around it is you don't _need_ to look at the surrounding code, which from a simplicity standpoint is a good thing.) > On the other hand, we will always stumble on dumb (or 'broken') compilers > that will not optimises those things out. If we want to be 100% sure no > unused code sneaks into the binary, then #ifdef's are the only option, at > the expense of readability. I'm not worried about compilers that can't optimize out "if(0) { }" because turbo pascal could handle that back under dos and TCC can do it today. Any compiler that can't do at least that much is going to bloat the busybox binary so much that this would just add insult to injury. In fact, what I'm mostly worried about right now is how gcc handles it, since that's the compiler almost everyone is building this thing with right now. I'm not necessarily against doing it the way you did if we know it works. But it's a doubletake moment, where you have to stop and think about the code to understand what it's doing, and that says to me either "put comment here" or figure out how to simplify it so it's more obvious. > Do you want a patch with if(ENABLE) ? In 1.2 I'd like to convert everything over to ENABLE. We need to re-measure the sizes of everything to make sure we don't accidentally bloat anything when we do this, though. > argc_malloc is always declared. > If CONFIG_FEATURE_CLEAN_UP is declared, then argc_malloc gets used > (written, then read). > If CONFIG_FEATURE_CLEAN_UP is not declared, then argc_malloc is only > declared, and gcc optimises it out, at the expense of one compiler warning. > Am I wrong? I'd have to read the context. (You're more familiar with this code than I am, I mostly wanted to confirm that it was intentional and that _you_ had thought this through.) What compiler warning? > > -#if defined(CONFIG_FEATURE_2_6_MODULES) > > - if ( argc ) { > > + if( argc ) { > > Why was that guard unnecessary? > > Because we want to use the options from the command line, for both 2.6 and > 2.4. That solves bug #272. Ok. > > I just checked it in. Does it fix bugs 276 and 272? > > Good. And yes, both bugs are fixed with this patch. Life is good. > Regards, > Yann E. MORIN. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 12 19:42:09 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 19:44:32 2005 Subject: Houston, we have warnings. Message-ID: <200512122142.10055.rob@landley.net> It would be nice if we remove all warnings under gcc 3.3 before the 1.1 release. 4.0 produces whole new categories that would be a lot of work to address, but 3.3 has three left in allyesconfig: /home/landley/busybox/busybox/coreutils/uudecode.c: In function `read_base64': /home/landley/busybox/busybox/coreutils/uudecode.c:101: warning: comparison is always false due to limited range of data type /home/landley/busybox/busybox/networking/traceroute.c:296: warning: `align' attribute directive ignored /home/landley/busybox/busybox/networking/zcip.c:76: warning: useless keyword or type name in empty declaration And allbareconfig has several more... And a build break in modprobe.c. Sigh. Yann? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 12 19:54:43 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 19:55:54 2005 Subject: Busybox and standards/direction, old tar options In-Reply-To: <20051213110223.2eb3dfba.bug1@iinet.net.au> References: <20051211095328.7b6fb7a0.bug1@iinet.net.au> <200512111340.51891.rob@landley.net> <20051213110223.2eb3dfba.bug1@iinet.net.au> Message-ID: <200512122154.43500.rob@landley.net> On Monday 12 December 2005 18:02, Glenn L. McGrath wrote: > On Sun, 11 Dec 2005 13:40:51 -0600 > > Rob Landley wrote: > > On Sunday 11 December 2005 07:10, Glenn McGrath wrote: > > > When trying to _define_ a standard there will always be people who > > > think this should be in the standard or that shouldnt be in it. So > > > multiple standards can be defined at the same time targeting different > > > demographics. > > > > Standards should document, not legislate. "This is the existing best > > practice" is a good thing. "We think you should do it this way" is > > seldom a good thing to come out of a committee. > > I hate the concept of pax, its a utilitiy created by a standards body > becasue on paper they wanted one standard archiving format and both tar > and cpio were used in practice. The standards bodies solution was to > create utuility that supports both formats and define it as the > standard. Somebody suggested we add pax support while you were away, and I believe Erik handed them their head. :) > I think its good to support people who understand but disagree with a > standard, but i have no sympathy for people for follow old standards > becasue they are lazy. I can see deprecating stuff, and yanking it (ipchains and devfs come to mind). If you'd posted a patch to yank the numeric options entirely, I probably would have been less uncomfortable with it. (I'd have objected to it going into 1.1 this late in the cycle, but might have queued it first thing for 1.2.) I.E. I don't see a reason to yank it, but I'm also not strongly motivated to defend it, either. I could be talked into it. It's the propogation of config options that really gets my attention. If we can justify yanking something, yank it. If we can't, leave it. Forking our user interface is disquieting. (And this month ain't the time for making these decisions. :) > Laziness is how i see the situation with numeric argument. - > arguments were removed because its inconsistent with standard option > parsing, imagine if people started wanting to doing - without > typing the opion name. It could get very confusing, and hard to parse. > > Which reminds me, i disagree in principle with supporting old tar > options (short options with out the leading '-') GNU considers them > obsolete and we arent doing it properly anyway. This hits closer to home with me, because I've gone "tar xvjf" for long enough that it's hardwired into my fingers. This is a user interface issue, there are people out there who use command lines who want "ps ax" and "tar xvjf" and right now we don't handle these properly. Saying "we refuse to support the user interface you're used to, you must use _this_ user interface to use our version of your tool" just means that we drive people away. And yes, I would personally refuse to use busybox tar over this. I would maintain my own patch to put it back, come up with some kind of wrapper shell script. On purely user interface grounds. > e.g. > > $ tar cCf . foo.tar AUTHORS > $ ./busybox tar cCf . foo.tar AUTHORS > tar: Couldnt chdir to f: No such file or directory > > $ tar xfC . foo.tar > $ ./busybox tar xCf . foo.tar > tar: Couldnt chdir to f: No such file or directory Notice: this is a uClibc bug. As far as I can tell, it works with glibc, but doesn't with uClibc. > There is section in the tar info pages on old options, its more complex > than just putting a '-' infront of things, it can also require re-ordering > parameters. And I don't care about the standard, I care about what people use. There are 8 gazillion examples of "tar xvjf" out in the wild. > With old options the order of the option indicates the order of the > arguments e.g. You're saying that with dashes it doesn't? (Checks...) Huh, apparently not. Never noticed before. > These both work > $ tar xfC . foo.tar > $ tar xCf foo.tar . > These both fail > $ tar xfC foo.tar . > $ tar xCf . foo.tar Or vice versa, anyway. > I thinks old tar options are something left buried, better to encourge > people to update the behaviour to use short options. I don't think encouraging people to update their behavior for the priviledge of using our tool is an effective strategy. Really, I don't. Making the old interface a CONFIG option, sure. I can get behind that 100% (although what I'd get behind is one global switch to enable old interfaces in all the places we care to mark, and having a CONFIG_NITPICK if we want to break these into individual switches). > e.g. all of these work and its easy to see which paramater belongs to > which option. > $ tar -xC . -f foo.tar > $ tar -xf foo.tar -C . > $ tar -x -f foo.tar -C . > $ tar -x -C . -f foo.tar It's actually kind of strange to me that you can group -xC but not -Cf. But if that's what the gnu version does and what the spec says, then obviously that's right... > And if people do think that the old tar option behaviour is a good > thing then i would expect them to want to apply the same concept to all > applets, not just tar. You mean like "ps ax" which I keep doing under busybox and which annoys me every time? Different commands have different syntax. They always have. X apps have a different syntax from gnu apps which have a different syntax from our legacy v7/BSD apps. Railing against widespread common usage isn't really part of our mandate, is it? We're trying to do minimal implementations of what people actually use. > I dont like it in ar etiher, but at least in ar its not considered > obsolete by any upstream (possibly because ar is somewhat neglected), > and there has never been an ar standard. There's never been an init standard (I've looked, if you can find one please tell me). Strangely, this lack of documentation is somewhat inconvenient but doesn't bother me on a deep existential level. And yes, I consider a standard to be documentation. Where documentation doesn't match common usage, then the documentation is either wrong or useless (and which one is a matter of opinion). > > One approach that has a certain attraction to me is to put every single > > applet together in one big menu, alphabetically, and then have another > > menu with selection items for categories, which we could set to Y, N, or > > M. (Which to _us_ would mean Yes, No, Maybe.) Y means select everything > > in that category, N means hide everything in that category, and M means > > make everything in that category show up for individual selection in the > > big list... > > > > We have several different options... > > Hmm, so we have a low level configuration menu where experienced users > can tweak to their hearts content, and a high level menu that just > beascially uses presets on the lower level configuration options... > > Sounds reasonable to me. Something like that. I'd put master switches like (CONFIG_NITPICK) in the first menu (possibly the general options and build menu should be merged somehow), and then have the options for an applet attached to the applet, but not actually visible unless you select the appropriate granularity. (We should probably have some simple rule, like any invisible feature switch can be considered selected. Something easy to think about.) We're already trying to consistently mark all features with CONFIG_FEATURE, which lets "make allbareconfig" work. (Which is a _marvelous_ testing thing, and something we just broke again in the last 24 hours...) > Glenn Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. From rob at landley.net Mon Dec 12 20:08:07 2005 From: rob at landley.net (Rob Landley) Date: Mon Dec 12 20:08:55 2005 Subject: Houston, we have warnings. In-Reply-To: <200512122142.10055.rob@landley.net> References: <200512122142.10055.rob@landley.net> Message-ID: <200512122208.07304.rob@landley.net> On Monday 12 December 2005 21:42, Rob Landley wrote: > And allbareconfig has several more... And a build break in modprobe.c. > Sigh. Yann? Ok, fixed. Here's the warnings with allbareconfig: /home/landley/busybox/busybox/coreutils/head.c: In function `head_main': /home/landley/busybox/busybox/coreutils/head.c:88: warning: label `GET_COUNT' defined but not used /home/landley/busybox/busybox/coreutils/stat.c: In function `do_stat': /home/landley/busybox/busybox/coreutils/stat.c:486: warning: long unsigned int format, different type arg (arg 3) /home/landley/busybox/busybox/coreutils/stat.c:486: warning: long unsigned int format, different type arg (arg 4) /home/landley/busybox/busybox/coreutils/stat.c:486: warning: long unsigned int format, different type arg (arg 8) /home/landley/busybox/busybox/coreutils/stat.c:486: warning: long unsigned int format, different type arg (arg 9) /home/landley/busybox/busybox/coreutils/stat.c:513: warning: long unsigned int format, different type arg (arg 2) /home/landley/busybox/busybox/coreutils/stat.c:513: warning: long unsigned int format, different type arg (arg 3) /home/landley/busybox/busybox/coreutils/stat.c:513: warning: long unsigned int format, different type arg (arg 6) /home/landley/busybox/busybox/coreutils/stat.c:513: warning: long unsigned int format, different type arg (arg 7) /home/landley/busybox/busybox/coreutils/stat.c:513: warning: long unsigned int format, different type arg (arg 8) /home/landley/busybox/busybox/coreutils/tail.c: In function `tail_main': /home/landley/busybox/busybox/coreutils/tail.c:145: warning: label `GET_COUNT' defined but not used /home/landley/busybox/busybox/coreutils/uudecode.c: In function `read_base64': /home/landley/busybox/busybox/coreutils/uudecode.c:101: warning: comparison is always false due to limited range of data type /home/landley/busybox/busybox/modutils/insmod.c:678: warning: `obj_gpl_license' declared `static' but never defined /home/landley/busybox/busybox/modutils/modprobe.c: In function `build_dep': /home/landley/bu