From g.esp at free.fr Sun Jun 1 00:59:30 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Sun, 1 Jun 2008 09:59:30 +0200 Subject: stty: invalid number 'iutf8' Message-ID: <265201c8c3bd$6c7fa8c0$f9b5a8c0@pii350> 'stty iutf8' call come from unicode_start (kbd-1.13 and 1.14) stty support iutf8 argument since coreutils-5.3.0. busybox stty does not support that (tested in 1.10.1 and 1.10.2) This result in stty: invlaid number 'iutf8' error message on each console opened. I look at original coreutils changeset and find corresponding change (see attached diff) from git tree. But appart to trivially accept iutf8 option, I didn't understand what is done. Any clue? Gilles -------------- next part -------------- A non-text attachment was scrubbed... Name: stty-utf8.diff Type: application/octet-stream Size: 1456 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080601/c9fa30db/attachment.obj From cristian.ionescu-idbohrn at axis.com Sun Jun 1 02:17:01 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 1 Jun 2008 11:17:01 +0200 (CEST) Subject: ut_name vs. ut_user cleanup in miscutils/last(_fancy).c Message-ID: <0806011102580.10516@somehost> Using only one of those would be cleaner, IMO. /usr/include/bits/utmp.h: /* Backwards compatibility hacks. */ #define ut_name ut_user idicates that using ut_user should be preferred. Cheers, -- Cristian From dronnikov at gmail.com Sun Jun 1 05:52:15 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Sun, 01 Jun 2008 05:52:15 -0700 (PDT) Subject: =?utf-8?B?REVQTU9EIGFnYWlu?= Message-ID: <48429b7f.2234440a.3842.ffffa06d@mx.google.com> Hello! Now depmod is really useful. Bernhard, Denys, please, consider applying. -- Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: depmod.patch Type: application/octet-stream Size: 9251 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080601/0dc6d14b/attachment-0001.obj From rep.dot.nop at gmail.com Sun Jun 1 06:03:39 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 1 Jun 2008 15:03:39 +0200 Subject: DEPMOD again In-Reply-To: <48429b7f.2234440a.3842.ffffa06d@mx.google.com> References: <48429b7f.2234440a.3842.ffffa06d@mx.google.com> Message-ID: <20080601130339.GZ27768@mx.loc> On Sun, Jun 01, 2008 at 05:52:15AM -0700, dronnikov at gmail.com wrote: >Hello! > >Now depmod is really useful. >Bernhard, Denys, please, consider applying. I'll fix depmod next week. Thanks for your patience. From vda.linux at googlemail.com Sun Jun 1 07:33:40 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 1 Jun 2008 16:33:40 +0200 Subject: [patch] coreutils/printf.c In-Reply-To: <0805312143000.10516@somehost> References: <0805292042550.14168@somehost> <200805312028.44581.vda.linux@googlemail.com> <0805312143000.10516@somehost> Message-ID: <200806011633.40051.vda.linux@googlemail.com> On Saturday 31 May 2008 22:01, Cristian Ionescu-Idbohrn wrote: > On Sat, 31 May 2008, Denys Vlasenko wrote: > > > On Saturday 31 May 2008 19:10, Cristian Ionescu-Idbohrn wrote: > > > > > > Hmm... I must be blind :( Can't see it :( What's wrong? Compare to this > > > (some lines above in include/applets.h): > > > > > > USE_DIRNAME(APPLET_NOFORK(dirname, dirname, _BB_DIR_USR_BIN, _BB_SUID_NEVER, dirname)) > > > > I meant that if you made it NOFORK (chunk #1) then you must not exit > > (chunk #2). > > Chunk #1 is ok if you fixed chunk #2. > > Got it now. Let's see. Is this a better patch? # ./busybox ash /.1/usr/srcdevel/bbox/fix/busybox.t8 # printf '\c' foo Segmentation fault Other than that: use spaces here, otherwise indentation of "printf" breaks for anybody with non-4-char-wide tabs: { BUILTIN_REGULAR "printf", printfcmd }, Do not replace "return EXIT_SUCCESS;" with "return 0;" - some people insist on having symbolic constant there (don't know why it's so important, but why not?) -- vda From wharms at bfs.de Sun Jun 1 09:06:19 2008 From: wharms at bfs.de (walter harms) Date: Sun, 01 Jun 2008 18:06:19 +0200 Subject: improved last In-Reply-To: <0805220942180.10380@somehost> References: <0805210054500.8956@somehost> <200805220204.09407.vda.linux@googlemail.com> <0805220942180.10380@somehost> Message-ID: <4842C8FB.9070508@bfs.de> Cristian Ionescu-Idbohrn wrote: > On Thu, 22 May 2008, Denys Vlasenko wrote: > >> static void show_entry(struct utmp *ut, int state, long lout) >> { >> long dur_secs; >> long ms, hs, ds; >> char duration[32]; >> char login_time[32]; >> char logout_time[32]; >> >> strcpy(login_time, ctime(&(ut->ut_time))); >> login_time[16] = '\0';; >> >> sprintf(logout_time, "- %s", ctime(&lout) + 11); >> >> Bug. ctime takes time_t*, not long* parameter. > > Yes. It is. Fixed. > Thanks for all input. > We're working on it. > I'll be back soon with a shrinked version. i am a big fan of strftime(). Even it make some overhead here you may like to try it, strftime(login_time,sizeof(login_time),"%Y-%m_%d %H:%M:%S",gmtime(&(ut->ut_time))); same goes for logout time. re, wh From cristian.ionescu-idbohrn at axis.com Sun Jun 1 12:18:20 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 1 Jun 2008 21:18:20 +0200 (CEST) Subject: [patch] coreutils/printf.c In-Reply-To: <200806011633.40051.vda.linux@googlemail.com> References: <0805292042550.14168@somehost> <200805312028.44581.vda.linux@googlemail.com> <0805312143000.10516@somehost> <200806011633.40051.vda.linux@googlemail.com> Message-ID: <0806012112480.19970@somehost> On Sun, 1 Jun 2008, Denys Vlasenko wrote: > # ./busybox ash > /.1/usr/srcdevel/bbox/fix/busybox.t8 # printf '\c' foo > Segmentation fault Bummer. Wouls this hunk sort that out? @@ -264,8 +264,11 @@ precision, ""); break; case '\\': - if (*++f == 'c') - exit(EXIT_SUCCESS); + if (*++f == 'c') { + while (*argv) + argv++; + goto nomore; + } bb_putchar(bb_process_escape_sequence((const char **)&f)); f--; break; (included in attached patch) > Other than that: use spaces here, otherwise indentation of "printf" > breaks for anybody with non-4-char-wide tabs: > > { BUILTIN_REGULAR "printf", printfcmd }, Ok. Fixed that and a couple more similar places. > Do not replace "return EXIT_SUCCESS;" with "return 0;" - some people > insist on having symbolic constant there (don't know why it's so > important, but why not?) Alright. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: ash_builtin_printf.2.patch Type: text/x-diff Size: 4873 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080601/1eb923d9/attachment.patch From g.esp at free.fr Sun Jun 1 12:31:18 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Sun, 1 Jun 2008 21:31:18 +0200 Subject: [patch] coreutils/printf.c References: <0805292042550.14168@somehost><200805312028.44581.vda.linux@googlemail.com><0805312143000.10516@somehost> <200806011633.40051.vda.linux@googlemail.com> Message-ID: <28a501c8c41e$10cf6770$f9b5a8c0@pii350> ----- Original Message ----- From: "Denys Vlasenko" To: Sent: Sunday, June 01, 2008 4:33 PM Subject: Re: [patch] coreutils/printf.c > > Do not replace "return EXIT_SUCCESS;" with "return 0;" - some people > insist on having symbolic constant there (don't know why it's > so important, but why not?) > Sorry if I am saying something evident, I am a bit new there. 0 mean what you think it mean in a certain context, sometime success, sometime failure. Having a source tree with both, this is awfull. EXIT_SUCCESS has no doubt Gilles From vda.linux at googlemail.com Sun Jun 1 15:05:12 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 00:05:12 +0200 Subject: [patch] coreutils/printf.c In-Reply-To: <28a501c8c41e$10cf6770$f9b5a8c0@pii350> References: <0805292042550.14168@somehost> <200806011633.40051.vda.linux@googlemail.com> <28a501c8c41e$10cf6770$f9b5a8c0@pii350> Message-ID: <200806020005.12080.vda.linux@googlemail.com> On Sunday 01 June 2008 21:31, Gilles Espinasse wrote: > > ----- Original Message ----- > From: "Denys Vlasenko" > To: > Sent: Sunday, June 01, 2008 4:33 PM > Subject: Re: [patch] coreutils/printf.c > > > > > > Do not replace "return EXIT_SUCCESS;" with "return 0;" - some people > > insist on having symbolic constant there (don't know why it's > > so important, but why not?) > > > Sorry if I am saying something evident, I am a bit new there. > > 0 mean what you think it mean in a certain context, sometime success, > sometime failure. > Having a source tree with both, this is awfull. > > EXIT_SUCCESS has no doubt I guess if someone does not know what 0 means as a return value of main(), he'd better stay away from Unix coding just yet. That's what makes me think that insisting on having EXIT_SUCCESSes sprinkled through code is not very useful. But there are people who disagree. It's not a big deal anyway. -- vda From vda.linux at googlemail.com Sun Jun 1 15:35:59 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 00:35:59 +0200 Subject: [patch] coreutils/printf.c In-Reply-To: <0806012112480.19970@somehost> References: <0805292042550.14168@somehost> <200806011633.40051.vda.linux@googlemail.com> <0806012112480.19970@somehost> Message-ID: <200806020035.59503.vda.linux@googlemail.com> On Sunday 01 June 2008 21:18, Cristian Ionescu-Idbohrn wrote: int printf_main(int argc ATTRIBUTE_UNUSED, char **argv) { char *format; char **argv2; + /* We must check that stdout is not closed. + * The reason for this is highly non-obvious. + * echo_main is used from shell. Shell must correctly handle "echo foo" + * if stdout is closed. With stdio, output gets shoveled into + * stdout buffer, and even fflush cannot clear it out. It seems that + * even if libc receives EBADF on write attempts, it feels determined + * to output data no matter what. So it will try later, + * and possibly will clobber future output. Not good. */ + if (dup2(1, 1) != 1) + return -1; copy-paste error in comments. Also with attached .config: shell/lib.a(ash.o):(.rodata.builtintab+0xc4): undefined reference to `printf_main' collect2: ld returned 1 exit status make: *** [busybox_unstripped] Error 1 I fixed it up and applied to svn. Thanks. P.S. If it's not too difficult, please send patches which are applyable with patch -p1 (i.e. kernel-style patches). Currently you are sending -p0 patches. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: .config.bz2 Type: application/x-bzip2 Size: 4633 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080602/3b65ec57/attachment.bin From vda.linux at googlemail.com Sun Jun 1 21:49:38 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 06:49:38 +0200 Subject: where is =?utf-8?q?=E2=80=9CDo_you_want_to_build_BusyBox_with_a_Cross_Compiler=3F?= =?utf-8?q?_=E2=80=9Din?= =?utf-8?q?_1=2E8=2E2=EF=BC=9F?= In-Reply-To: <20080528105649.GB6643@mx.loc> References: <17497919.799681211967030974.JavaMail.coremail@bj126app22.126.com> <20080528105649.GB6643@mx.loc> Message-ID: <200806020649.38129.vda.linux@googlemail.com> On Wednesday 28 May 2008 12:56, Bernhard Fischer wrote: > On Wed, May 28, 2008 at 05:30:30PM +0800, wang9736 wrote: > >hello everyone? > > I cannot find this option in busybox-1.8.2?who can tell me where it is?In busybox-1.8.2 ?I can see it. > > We inherited kbuild from the kernel some time ago. > Nowadays you have to make CROSS_COMPILE=/path/to/my/your-cross-prefix- Well, it was not intended to lose that option, it's a breakage. Fixed now, will be in 1.11.x -- vda From cristian.ionescu-idbohrn at axis.com Mon Jun 2 01:05:26 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 2 Jun 2008 10:05:26 +0200 (CEST) Subject: [patch] coreutils/printf.c In-Reply-To: <200806020035.59503.vda.linux@googlemail.com> References: <0805292042550.14168@somehost> <200806011633.40051.vda.linux@googlemail.com> <0806012112480.19970@somehost> <200806020035.59503.vda.linux@googlemail.com> Message-ID: <0806021003230.6722@somehost> On Mon, 2 Jun 2008, Denys Vlasenko wrote: > On Sunday 01 June 2008 21:18, Cristian Ionescu-Idbohrn wrote: > > > int printf_main(int argc ATTRIBUTE_UNUSED, char **argv) > { > char *format; > char **argv2; > > + /* We must check that stdout is not closed. > + * The reason for this is highly non-obvious. > + * echo_main is used from shell. Shell must correctly handle "echo foo" > + * if stdout is closed. With stdio, output gets shoveled into > + * stdout buffer, and even fflush cannot clear it out. It seems that > + * even if libc receives EBADF on write attempts, it feels determined > + * to output data no matter what. So it will try later, > + * and possibly will clobber future output. Not good. */ > + if (dup2(1, 1) != 1) > + return -1; > > copy-paste error in comments. Yes. Sorry about that. > Also with attached .config: > > shell/lib.a(ash.o):(.rodata.builtintab+0xc4): undefined reference to `printf_main' > collect2: ld returned 1 exit status > make: *** [busybox_unstripped] Error 1 > > I fixed it up and applied to svn. Thanks. Thank you. > P.S. If it's not too difficult, please send patches which are applyable > with patch -p1 (i.e. kernel-style patches). > Currently you are sending -p0 patches. Not difficult at all :) I'll try to remember that. Cheers, -- Cristian From neeraj.vaidya at yahoo.co.in Mon Jun 2 01:17:53 2008 From: neeraj.vaidya at yahoo.co.in (Neeraj Vaidya) Date: Mon, 2 Jun 2008 13:47:53 +0530 (IST) Subject: mke2fs errir : no such file Message-ID: <806611.83410.qm@web7911.mail.in.yahoo.com> I am using one of the latest versions of busybox (probably v1.10.0) with relevant patches applied. I boot from an initrd and get to the busybox ash prompt. When I issue the mke2fs command to create an ext3 filesystem on one of the IDE partitions , it outputs a lot of text like "creating superblock " etc etc , but at the end it says "No such file or directory". "mke2fs -j /dev/hda3" When I try to mount this partition using "mount -t ext3 /dev/hda3 /mnt/new_install" , it is not able to mount it. I do not remember the exact error , but it was something like "could not mount partition" Is this a busybox mke2fs problem ? Thanks, Neeraj Bring your gang together. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo.com/groups/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080602/0fa1eaeb/attachment.htm From wharms at bfs.de Mon Jun 2 01:20:21 2008 From: wharms at bfs.de (walter harms) Date: Mon, 02 Jun 2008 10:20:21 +0200 Subject: [patch] coreutils/printf.c In-Reply-To: <200806020005.12080.vda.linux@googlemail.com> References: <0805292042550.14168@somehost> <200806011633.40051.vda.linux@googlemail.com> <28a501c8c41e$10cf6770$f9b5a8c0@pii350> <200806020005.12080.vda.linux@googlemail.com> Message-ID: <4843AD45.3020501@bfs.de> Denys Vlasenko wrote: > On Sunday 01 June 2008 21:31, Gilles Espinasse wrote: >> ----- Original Message ----- >> From: "Denys Vlasenko" >> To: >> Sent: Sunday, June 01, 2008 4:33 PM >> Subject: Re: [patch] coreutils/printf.c >> >> >>> Do not replace "return EXIT_SUCCESS;" with "return 0;" - some people >>> insist on having symbolic constant there (don't know why it's >>> so important, but why not?) >>> >> Sorry if I am saying something evident, I am a bit new there. >> >> 0 mean what you think it mean in a certain context, sometime success, >> sometime failure. >> Having a source tree with both, this is awfull. >> >> EXIT_SUCCESS has no doubt > > I guess if someone does not know what 0 means as a return value of main(), > he'd better stay away from Unix coding just yet. > > That's what makes me think that insisting on having EXIT_SUCCESSes > sprinkled through code is not very useful. But there are people > who disagree. It's not a big deal anyway. mmmh, i remember a very famous computer supplier that reverst the meaning of EXIT_SUCCESS and EXIT_FAILURE in its includes :) NTL using clear names is not a problem and makes it more readable (for some people) just my 2 cents, wh From paulius.zaleckas at teltonika.lt Mon Jun 2 01:21:12 2008 From: paulius.zaleckas at teltonika.lt (Paulius Zaleckas) Date: Mon, 02 Jun 2008 11:21:12 +0300 Subject: [patch] rtcwake: fix default suspend value Message-ID: <4843AD78.9050408@teltonika.lt> Writing "suspend" to /sys/power/state does nothing. Even --help says that default should be "standby" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: rtcwake_standby.patch Type: text/x-patch Size: 403 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080602/3637c3ed/attachment.bin From g.esp at free.fr Mon Jun 2 01:42:17 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Mon, 02 Jun 2008 10:42:17 +0200 Subject: mke2fs errir : no such file In-Reply-To: <806611.83410.qm@web7911.mail.in.yahoo.com> References: <806611.83410.qm@web7911.mail.in.yahoo.com> Message-ID: <1212396137.4843b269bd811@imp.free.fr> Selon Neeraj Vaidya : > I am using one of the latest versions of busybox (probably v1.10.0) with > relevant patches applied. > > I boot from an initrd and get to the busybox ash prompt. > > When I issue the mke2fs command to create an ext3 filesystem on one of the > IDE partitions , it outputs a lot of text like "creating superblock " etc etc > , but at the end it says "No such file or directory". > "mke2fs -j /dev/hda3" > I don't know for mke2fs busybox version but the version from e2fsprogs need to be able to read /etc/mtab to create the journal Without -j, it work without /etc/mtab. I fixed that creating a symlink from /proc/mount to /etc/mtab Gilles From neeraj.vaidya at yahoo.co.in Mon Jun 2 01:43:22 2008 From: neeraj.vaidya at yahoo.co.in (Neeraj Vaidya) Date: Mon, 2 Jun 2008 14:13:22 +0530 (IST) Subject: mke2fs error : no such file Message-ID: <61361.99940.qm@web7911.mail.in.yahoo.com> [NOTE : this is the same as the previous mail but with a typo correction in the subject line] I am using one of the latest versions of busybox (probably v1.10.0) with relevant patches applied. I boot from an initrd and get to the busybox ash prompt. When I issue the mke2fs command to create an ext3 filesystem on one of the IDE partitions , it outputs a lot of text like "creating superblock " etc etc , but at the end it says "No such file or directory". "mke2fs -j /dev/hda3" When I try to mount this partition using "mount -t ext3 /dev/hda3 /mnt/new_install" , it is not able to mount it. I do not remember the exact error , but it was something like "could not mount partition" Is this a busybox mke2fs problem ? Thanks, Neeraj ________________________________ Has your work life balance shifted? Find out. Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.messenger.yahoo.com/webmessengerpromo.php/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080602/495d78a2/attachment.htm From rep.dot.nop at gmail.com Mon Jun 2 04:02:00 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 2 Jun 2008 13:02:00 +0200 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: <4843AD78.9050408@teltonika.lt> References: <4843AD78.9050408@teltonika.lt> Message-ID: <20080602110159.GA6423@mx.loc> On Mon, Jun 02, 2008 at 11:21:12AM +0300, Paulius Zaleckas wrote: > Writing "suspend" to /sys/power/state does nothing. > Even --help says that default should be "standby" :) Applied as 22178. Thanks! From g.esp at free.fr Mon Jun 2 05:40:41 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Mon, 02 Jun 2008 14:40:41 +0200 Subject: mke2fs errir : no such file In-Reply-To: <766755.72776.qm@web7909.mail.in.yahoo.com> References: <766755.72776.qm@web7909.mail.in.yahoo.com> Message-ID: <1212410441.4843ea49c254c@imp.free.fr> Selon Neeraj Vaidya : > So , are you saying that I should rather use the mke2fs from e2fsprogs ? > or are you saying that I should try without using the -j flag ? > but I will need the -j flag as I want to create an ext3 filesystem. > I don't say you should use mke2fs from e2fsprogs. You should first check if proc is mounted, if /etc/mtab exist,... if busybox implementation require that. One grep mtab in busybox sources could be a clue. You could try without -j to see if it make a difference. I just say you that mke2fs from e2fsprogs has a different prerequisite to work with -j You may use strace to see what happen when mk2ef run and see wich file mke2fs fail to open. That's what allow me to solve my issue with /etc/mtab Gilles From vda.linux at googlemail.com Mon Jun 2 09:25:30 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 18:25:30 +0200 Subject: mke2fs errir : no such file In-Reply-To: <1212410441.4843ea49c254c@imp.free.fr> References: <766755.72776.qm@web7909.mail.in.yahoo.com> <1212410441.4843ea49c254c@imp.free.fr> Message-ID: <200806021825.30933.vda.linux@googlemail.com> On Monday 02 June 2008 14:40, Gilles Espinasse wrote: > Selon Neeraj Vaidya : > > > So , are you saying that I should rather use the mke2fs from e2fsprogs ? > > or are you saying that I should try without using the -j flag ? > > but I will need the -j flag as I want to create an ext3 filesystem. > > > I don't say you should use mke2fs from e2fsprogs. > You should first check if proc is mounted, if /etc/mtab exist,... if busybox > implementation require that. One grep mtab in busybox sources could be a clue. busybox 1.10.x does not have mke2fs. To be more precise, it is not possible to select in config and build one without some patching. -- vda From kelberts at gmail.com Mon Jun 2 12:37:13 2008 From: kelberts at gmail.com (Dennis Robert) Date: Mon, 2 Jun 2008 16:37:13 -0300 Subject: About brazilian console Message-ID: Hi friends. If I want that busybox shows me special characters, ('?' or '?' or '?'), like brazilian language, what I need to do? please give me some help to start. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080602/b0bb8c00/attachment.htm From pyrophobicman at gmail.com Mon Jun 2 12:39:15 2008 From: pyrophobicman at gmail.com (Poly-poly man) Date: Mon, 2 Jun 2008 15:39:15 -0400 Subject: About brazilian console In-Reply-To: References: Message-ID: <200806021539.15870.pyrophobicman@gmail.com> On Monday 02 June 2008 03:37:13 pm Dennis Robert wrote: > Hi friends. > > If I want that busybox shows me special characters, ('?' or '?' or '?'), > like brazilian language, what I need to do? > please give me some help to start. > > thanks look at locale support (in uclibc/glibc/etc., as well as busybox), and unicode support (same deal) poly-p man From vapier at gentoo.org Mon Jun 2 13:35:43 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 2 Jun 2008 16:35:43 -0400 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: <4843AD78.9050408@teltonika.lt> References: <4843AD78.9050408@teltonika.lt> Message-ID: <200806021635.43885.vapier@gentoo.org> On Monday 02 June 2008, Paulius Zaleckas wrote: > Writing "suspend" to /sys/power/state does nothing. it depends solely on your kernel configuration > Even --help says that default should be "standby" :) the help is wrong then ... i'll fix that -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080602/610fe5b8/attachment.pgp From rep.dot.nop at gmail.com Mon Jun 2 13:49:01 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 2 Jun 2008 22:49:01 +0200 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: <200806021635.43885.vapier@gentoo.org> References: <4843AD78.9050408@teltonika.lt> <200806021635.43885.vapier@gentoo.org> Message-ID: <20080602204901.GA27768@mx.loc> On Mon, Jun 02, 2008 at 04:35:43PM -0400, Mike Frysinger wrote: >On Monday 02 June 2008, Paulius Zaleckas wrote: >> Writing "suspend" to /sys/power/state does nothing. > >it depends solely on your kernel configuration If i'm not looking at the wrong spot, then # grep -A3 "\[PM_SUSPEND_MAX\]" kernel/power/main.c static const char * const pm_states[PM_SUSPEND_MAX] = { [PM_SUSPEND_STANDBY] = "standby", [PM_SUSPEND_MEM] = "mem", }; So what about stating this in the config and providing a config CONFIG_RTCWAKE_DEFAULT_STATE string "default suspend state" default "suspend" help Available suspend modi depend on your kernel config. Per default this is set to "suspend", other possible values include "standby". See kernel/power/ for details. and using that instead of quasi hardcoding "suspend" ? From vda.linux at googlemail.com Mon Jun 2 13:47:06 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 2 Jun 2008 22:47:06 +0200 Subject: About brazilian console In-Reply-To: References: Message-ID: <200806022247.06284.vda.linux@googlemail.com> On Monday 02 June 2008 21:37, Dennis Robert wrote: > Hi friends. > > If I want that busybox shows me special characters, ('?' or '?' or '?'), > like brazilian language, what I need to do? Not every applet fully supports this. Currently, it will work for most applets if you use a locale where each glyph is represented as one byte. Unfortunately, UTF-8 situation is worse. > please give me some help to start. It's unclear what you already have. Did you build busybox? In what cases it shows and doesn't show these chars properly? -- vda From vapier at gentoo.org Mon Jun 2 15:03:06 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 2 Jun 2008 18:03:06 -0400 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: <20080602204901.GA27768@mx.loc> References: <4843AD78.9050408@teltonika.lt> <200806021635.43885.vapier@gentoo.org> <20080602204901.GA27768@mx.loc> Message-ID: <200806021803.07054.vapier@gentoo.org> On Monday 02 June 2008, Bernhard Fischer wrote: > On Mon, Jun 02, 2008 at 04:35:43PM -0400, Mike Frysinger wrote: > >On Monday 02 June 2008, Paulius Zaleckas wrote: > >> Writing "suspend" to /sys/power/state does nothing. > > > >it depends solely on your kernel configuration > > So what about stating this in the config and providing a the rtcwake applet is based on the util-linux version. that means the defaults are the same. if the default is not appropriate for your system, there's a runtime flag already. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080602/359114cd/attachment.pgp From paulius.zaleckas at teltonika.lt Tue Jun 3 00:18:07 2008 From: paulius.zaleckas at teltonika.lt (Paulius Zaleckas) Date: Tue, 03 Jun 2008 10:18:07 +0300 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: <200806021803.07054.vapier@gentoo.org> References: <4843AD78.9050408@teltonika.lt> <200806021635.43885.vapier@gentoo.org> <20080602204901.GA27768@mx.loc> <200806021803.07054.vapier@gentoo.org> Message-ID: Mike Frysinger wrote: > On Monday 02 June 2008, Bernhard Fischer wrote: >> On Mon, Jun 02, 2008 at 04:35:43PM -0400, Mike Frysinger wrote: >>> On Monday 02 June 2008, Paulius Zaleckas wrote: >>>> Writing "suspend" to /sys/power/state does nothing. >>> it depends solely on your kernel configuration >> So what about stating this in the config and providing a > > the rtcwake applet is based on the util-linux version. that means the > defaults are the same. if the default is not appropriate for your system, > there's a runtime flag already. > -mike What is the default system? If it is linux then it should be "standby". Maybe it is a bug in util-linux too?! From paulius.zaleckas at teltonika.lt Tue Jun 3 02:05:49 2008 From: paulius.zaleckas at teltonika.lt (Paulius Zaleckas) Date: Tue, 03 Jun 2008 12:05:49 +0300 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: <20080602204901.GA27768@mx.loc> References: <4843AD78.9050408@teltonika.lt> <200806021635.43885.vapier@gentoo.org> <20080602204901.GA27768@mx.loc> Message-ID: <4845096D.7010702@teltonika.lt> Bernhard Fischer wrote: > On Mon, Jun 02, 2008 at 04:35:43PM -0400, Mike Frysinger wrote: >> On Monday 02 June 2008, Paulius Zaleckas wrote: >>> Writing "suspend" to /sys/power/state does nothing. >> it depends solely on your kernel configuration > > If i'm not looking at the wrong spot, then > # grep -A3 "\[PM_SUSPEND_MAX\]" kernel/power/main.c > static const char * const pm_states[PM_SUSPEND_MAX] = { > [PM_SUSPEND_STANDBY] = "standby", > [PM_SUSPEND_MEM] = "mem", > }; > > So what about stating this in the config and providing a > config CONFIG_RTCWAKE_DEFAULT_STATE > string "default suspend state" > default "suspend" > help > Available suspend modi depend on your kernel config. > Per default this is set to "suspend", other possible values > include "standby". See kernel/power/ for details. > > and using that instead of quasi hardcoding "suspend" ? Linux kernel never had power state "suspend"! It was "standby", "mem" and "disk" even in 2.6.12 and older. These values are hardcoded and there is no way to change this in config! I have send similar patch to util-linux-ng mailing list and I hope it will be accepted. From vapier at gentoo.org Tue Jun 3 07:19:34 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 3 Jun 2008 10:19:34 -0400 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: References: <4843AD78.9050408@teltonika.lt> <200806021803.07054.vapier@gentoo.org> Message-ID: <200806031019.34866.vapier@gentoo.org> On Tuesday 03 June 2008, Paulius Zaleckas wrote: > Mike Frysinger wrote: > > On Monday 02 June 2008, Bernhard Fischer wrote: > >> On Mon, Jun 02, 2008 at 04:35:43PM -0400, Mike Frysinger wrote: > >>> On Monday 02 June 2008, Paulius Zaleckas wrote: > >>>> Writing "suspend" to /sys/power/state does nothing. > >>> > >>> it depends solely on your kernel configuration > >> > >> So what about stating this in the config and providing a > > > > the rtcwake applet is based on the util-linux version. that means the > > defaults are the same. if the default is not appropriate for your > > system, there's a runtime flag already. > > What is the default system? If it is linux then it should be "standby". > Maybe it is a bug in util-linux too?! busybox applets match the behavior of the utilities they replace. you can certainly ask the util-linux guys to change the default behavior ... at that time, i'll gladly update busybox to match it. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080603/bc677398/attachment.pgp From bernard at largestprime.net Tue Jun 3 07:44:26 2008 From: bernard at largestprime.net (Bernard Blackham) Date: Tue, 03 Jun 2008 22:44:26 +0800 Subject: mdev race conditions Message-ID: <484558CA.8070308@largestprime.net> Hi, When I switched from udev+udevd to mdev, booting was much faster and it shaved a decent amount from the total image size. However, I've recently noticed device nodes sometimes disappearing on boot. The specific scenario is: 1. /dev/ttyS1 exists as a device node in the filesystem on boot - prior to the actual device existing, and prior to mdev being called. 2. echo /bin/mdev > /proc/sys/kernel/hotplug 3. a module is loaded that provides ttyS1 When this module is loaded, most of the time the existing ttyS1 remains. Sometimes however, it is unlinked from the filesystem and is never seen again (until mdev -s is run, or next boot, maybe). I pointed my hotplug to a script to log what mdev was being called as, and found that when the module is loaded, there is actually a remove event emitted followed by an add event. As there is no locking with mdev, sometimes mdev runs the remove after the add and thus the device node goes missing. udev seems to have gotten around this using a daemon that serialises events based on the sequence number provided by the kernel. Is there a lightweight way that mdev can do this or another way to work around this problem? I'd also prefer not to have a udevd running 24/7 unnecessarily, as I imagine most low-memory systems would. Perhaps something like an on-demand udevd that exists during the flurry of uevents from the kernel, waits for things to settle, and then processes things in order and exits? I can't think of a clean way to do this reliably though. Regards, Bernard. From vapier at gentoo.org Tue Jun 3 08:17:07 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 3 Jun 2008 11:17:07 -0400 Subject: mdev race conditions In-Reply-To: <484558CA.8070308@largestprime.net> References: <484558CA.8070308@largestprime.net> Message-ID: <200806031117.07792.vapier@gentoo.org> On Tuesday 03 June 2008, Bernard Blackham wrote: > When I switched from udev+udevd to mdev, booting was much faster and it > shaved a decent amount from the total image size. However, I've recently > noticed device nodes sometimes disappearing on boot. this is a known corner case and will always be there. it's why the kernel guys have deprecated the hotplug exec mechanism in favor of netlink sockets. the only real solution is a daemon + netlink. neither of which are desirable in mdev. everything else is a workaround. feel free to contribute a mdevd ;). that plus init/other daemons provided by busybox are good examples of how PIE can be a very very good thing. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080603/965987a1/attachment.pgp From vda.linux at googlemail.com Tue Jun 3 08:58:32 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 17:58:32 +0200 Subject: mdev race conditions In-Reply-To: <484558CA.8070308@largestprime.net> References: <484558CA.8070308@largestprime.net> Message-ID: <200806031758.32235.vda.linux@googlemail.com> On Tuesday 03 June 2008 16:44, Bernard Blackham wrote: > Hi, > > When I switched from udev+udevd to mdev, booting was much faster and it > shaved a decent amount from the total image size. However, I've recently > noticed device nodes sometimes disappearing on boot. The specific > scenario is: > > 1. /dev/ttyS1 exists as a device node in the filesystem on boot - prior > to the actual device existing, and prior to mdev being called. > > 2. echo /bin/mdev > /proc/sys/kernel/hotplug > > 3. a module is loaded that provides ttyS1 > > When this module is loaded, most of the time the existing ttyS1 remains. > Sometimes however, it is unlinked from the filesystem and is never seen > again (until mdev -s is run, or next boot, maybe). > > I pointed my hotplug to a script to log what mdev was being called as, > and found that when the module is loaded, there is actually a remove > event emitted followed by an add event. As there is no locking with > mdev, sometimes mdev runs the remove after the add and thus the device > node goes missing. > > udev seems to have gotten around this using a daemon that serialises > events based on the sequence number provided by the kernel. How these event seq numbers are passed? Some env variable? -- vda From vda.linux at googlemail.com Tue Jun 3 09:00:49 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 18:00:49 +0200 Subject: mdev race conditions In-Reply-To: <200806031117.07792.vapier@gentoo.org> References: <484558CA.8070308@largestprime.net> <200806031117.07792.vapier@gentoo.org> Message-ID: <200806031800.49482.vda.linux@googlemail.com> On Tuesday 03 June 2008 17:17, Mike Frysinger wrote: > On Tuesday 03 June 2008, Bernard Blackham wrote: > > When I switched from udev+udevd to mdev, booting was much faster and it > > shaved a decent amount from the total image size. However, I've recently > > noticed device nodes sometimes disappearing on boot. > > this is a known corner case and will always be there. it's why the kernel > guys have deprecated the hotplug exec mechanism in favor of netlink sockets. > the only real solution is a daemon + netlink. neither of which are desirable > in mdev. everything else is a workaround. feel free to contribute a > mdevd ;). that plus init/other daemons provided by busybox are good examples > of how PIE can be a very very good thing. Can you chime me in how to build PIE / how it is different from normal executable? I guess there are some restrictions and things to do (e.g. have to pass -fPIE to gcc)? -- vda From bernard at largestprime.net Tue Jun 3 09:14:26 2008 From: bernard at largestprime.net (Bernard Blackham) Date: Wed, 04 Jun 2008 00:14:26 +0800 Subject: mdev race conditions In-Reply-To: <200806031117.07792.vapier@gentoo.org> References: <484558CA.8070308@largestprime.net> <200806031117.07792.vapier@gentoo.org> Message-ID: <48456DE2.8060706@largestprime.net> Mike Frysinger wrote: > On Tuesday 03 June 2008, Bernard Blackham wrote: >> When I switched from udev+udevd to mdev, booting was much faster and it >> shaved a decent amount from the total image size. However, I've recently >> noticed device nodes sometimes disappearing on boot. > > this is a known corner case and will always be there. it's why the kernel > guys have deprecated the hotplug exec mechanism in favor of netlink sockets. > the only real solution is a daemon + netlink. neither of which are desirable > in mdev. everything else is a workaround. Ah k. Thanks for clearing that up :) > feel free to contribute a mdevd ;). Having glanced through udevd.c, I'm rapidly reaching the conclusion that for busybox, a simple mdevd that did the following would suffice: - listen for an event on netlink - when an event arrives, dispatch it to udev (internally even, without forking) - wait for completion (queue up other incoming messages if waiting for an external program) - lather, rinse, repeat No control interface, no event queuing, no process throttling, etc. There's a lot of extra complexity in udevd - e.g. using a queue mechanism which I gather is to support parallel runs of udev when they can be accomodated. If this, along with the control interface were to be dropped (kill -9 is a control interface to me ;) then I imagine the resulting mdevd would be pretty simple, very small and just as functional. Would this be all it takes? Anyone with more than half an hour's experience of looking at udev's source code willing to comment? :) Regards, Bernard. From vda.linux at googlemail.com Tue Jun 3 09:18:59 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 18:18:59 +0200 Subject: mdev race conditions In-Reply-To: <48456DE2.8060706@largestprime.net> References: <484558CA.8070308@largestprime.net> <200806031117.07792.vapier@gentoo.org> <48456DE2.8060706@largestprime.net> Message-ID: <200806031818.59175.vda.linux@googlemail.com> On Tuesday 03 June 2008 18:14, Bernard Blackham wrote: > Mike Frysinger wrote: > > On Tuesday 03 June 2008, Bernard Blackham wrote: > >> When I switched from udev+udevd to mdev, booting was much faster and it > >> shaved a decent amount from the total image size. However, I've recently > >> noticed device nodes sometimes disappearing on boot. > > > > this is a known corner case and will always be there. it's why the kernel > > guys have deprecated the hotplug exec mechanism in favor of netlink sockets. > > the only real solution is a daemon + netlink. neither of which are desirable > > in mdev. everything else is a workaround. > > Ah k. Thanks for clearing that up :) > > > feel free to contribute a mdevd ;). > > Having glanced through udevd.c, I'm rapidly reaching the conclusion that > for busybox, a simple mdevd that did the following would suffice: > > - listen for an event on netlink > - when an event arrives, dispatch it to udev (internally even, without > forking) > - wait for completion (queue up other incoming messages if waiting for > an external program) > - lather, rinse, repeat > > No control interface, no event queuing, no process throttling, etc. > > There's a lot of extra complexity in udevd - e.g. using a queue > mechanism which I gather is to support parallel runs of udev when they > can be accomodated. If this, along with the control interface were to be > dropped (kill -9 is a control interface to me ;) then I imagine the > resulting mdevd would be pretty simple, very small and just as functional. > > Would this be all it takes? Anyone with more than half an hour's > experience of looking at udev's source code willing to comment? :) Didn't look at udev yet. What about just storing current seq # in a file, and if you see wrong number in that file, just want for correct one to appear (or time out in "reasonable time")? -- vda From vda.linux at googlemail.com Tue Jun 3 09:37:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 18:37:50 +0200 Subject: mdev race conditions In-Reply-To: <200806031758.32235.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <200806031758.32235.vda.linux@googlemail.com> Message-ID: <200806031837.50625.vda.linux@googlemail.com> On Tuesday 03 June 2008 17:58, Denys Vlasenko wrote: > On Tuesday 03 June 2008 16:44, Bernard Blackham wrote: > > Hi, > > > > When I switched from udev+udevd to mdev, booting was much faster and it > > shaved a decent amount from the total image size. However, I've recently > > noticed device nodes sometimes disappearing on boot. The specific > > scenario is: > > > > 1. /dev/ttyS1 exists as a device node in the filesystem on boot - prior > > to the actual device existing, and prior to mdev being called. > > > > 2. echo /bin/mdev > /proc/sys/kernel/hotplug > > > > 3. a module is loaded that provides ttyS1 > > > > When this module is loaded, most of the time the existing ttyS1 remains. > > Sometimes however, it is unlinked from the filesystem and is never seen > > again (until mdev -s is run, or next boot, maybe). > > > > I pointed my hotplug to a script to log what mdev was being called as, > > and found that when the module is loaded, there is actually a remove > > event emitted followed by an add event. As there is no locking with > > mdev, sometimes mdev runs the remove after the add and thus the device > > node goes missing. > > > > udev seems to have gotten around this using a daemon that serialises > > events based on the sequence number provided by the kernel. Latest udev I have seems to use netlink. From older udev-030: subsystem = get_subsystem(argv[1]); if (subsystem == NULL) { dbg("no subsystem"); goto exit; } dbg("subsystem = '%s'", subsystem); devpath = get_devpath(); if (devpath == NULL) { dbg("no devpath"); goto exit; } dbg("DEVPATH = '%s'", devpath); action = get_action(); if (action == NULL) { dbg("no action"); goto exit; } dbg("ACTION = '%s'", action); seqnum = get_seqnum(); if (seqnum == NULL) seq = -1; else seq = atoi(seqnum); dbg("SEQNUM = '%d'", seq); You did some debugging and I suspect you can answer this: is SEQNUM per DEVPATH or is it global? Is there events without SEQNUM at all? -- vda From vapier at gentoo.org Tue Jun 3 09:43:42 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 3 Jun 2008 12:43:42 -0400 Subject: mdev race conditions In-Reply-To: <200806031800.49482.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <200806031117.07792.vapier@gentoo.org> <200806031800.49482.vda.linux@googlemail.com> Message-ID: <200806031243.42905.vapier@gentoo.org> On Tuesday 03 June 2008, Denys Vlasenko wrote: > On Tuesday 03 June 2008 17:17, Mike Frysinger wrote: > > On Tuesday 03 June 2008, Bernard Blackham wrote: > > > When I switched from udev+udevd to mdev, booting was much faster and it > > > shaved a decent amount from the total image size. However, I've > > > recently noticed device nodes sometimes disappearing on boot. > > > > this is a known corner case and will always be there. it's why the > > kernel guys have deprecated the hotplug exec mechanism in favor of > > netlink sockets. the only real solution is a daemon + netlink. neither > > of which are desirable in mdev. everything else is a workaround. feel > > free to contribute a mdevd ;). that plus init/other daemons provided by > > busybox are good examples of how PIE can be a very very good thing. > > Can you chime me in how to build PIE / how it is different from normal > executable? I guess there are some restrictions and things to do (e.g. have > to pass -fPIE to gcc)? -- afaik (solar can correct me), just compile all objects with -fPIE and link with -pie a quick test is (1) it still executes ;) and (2) running `file` on the ELF should declare it as a shared object rather than executable -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080603/6a3b8611/attachment.pgp From vapier at gentoo.org Tue Jun 3 09:47:32 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 3 Jun 2008 12:47:32 -0400 Subject: mdev race conditions In-Reply-To: <200806031818.59175.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <48456DE2.8060706@largestprime.net> <200806031818.59175.vda.linux@googlemail.com> Message-ID: <200806031247.33080.vapier@gentoo.org> On Tuesday 03 June 2008, Denys Vlasenko wrote: > On Tuesday 03 June 2008 18:14, Bernard Blackham wrote: > > Mike Frysinger wrote: > > > On Tuesday 03 June 2008, Bernard Blackham wrote: > > >> When I switched from udev+udevd to mdev, booting was much faster and > > >> it shaved a decent amount from the total image size. However, I've > > >> recently noticed device nodes sometimes disappearing on boot. > > > > > > this is a known corner case and will always be there. it's why the > > > kernel guys have deprecated the hotplug exec mechanism in favor of > > > netlink sockets. the only real solution is a daemon + netlink. neither > > > of which are desirable in mdev. everything else is a workaround. > > > > Ah k. Thanks for clearing that up :) > > > > > feel free to contribute a mdevd ;). > > > > Having glanced through udevd.c, I'm rapidly reaching the conclusion that > > for busybox, a simple mdevd that did the following would suffice: > > > > - listen for an event on netlink > > - when an event arrives, dispatch it to udev (internally even, without > > forking) > > - wait for completion (queue up other incoming messages if waiting for > > an external program) > > - lather, rinse, repeat > > > > No control interface, no event queuing, no process throttling, etc. > > > > There's a lot of extra complexity in udevd - e.g. using a queue > > mechanism which I gather is to support parallel runs of udev when they > > can be accomodated. If this, along with the control interface were to be > > dropped (kill -9 is a control interface to me ;) then I imagine the > > resulting mdevd would be pretty simple, very small and just as > > functional. > > > > Would this be all it takes? Anyone with more than half an hour's > > experience of looking at udev's source code willing to comment? :) > > Didn't look at udev yet. > > What about just storing current seq # in a file, and if you see wrong > number in that file, just want for correct one to appear (or time out > in "reasonable time")? how do you time out without running as a daemon ? have the mdev binary sleep() ? then you may have multiple mdev's sleeping which means you need to do process management, or implement some method for shared communication, or ... just biting the bullet and making mdevd would be less painful. or even better, just use udevd (which i honestly dont think is a big deal, it isnt exactly bloated ... it's 76k on x86_64 and it's built for speed, not size). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080603/75cb172b/attachment-0001.pgp From vda.linux at googlemail.com Tue Jun 3 11:28:32 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 3 Jun 2008 20:28:32 +0200 Subject: mdev race conditions In-Reply-To: <200806031247.33080.vapier@gentoo.org> References: <484558CA.8070308@largestprime.net> <200806031818.59175.vda.linux@googlemail.com> <200806031247.33080.vapier@gentoo.org> Message-ID: <200806032028.32999.vda.linux@googlemail.com> On Tuesday 03 June 2008 18:47, Mike Frysinger wrote: > > > Would this be all it takes? Anyone with more than half an hour's > > > experience of looking at udev's source code willing to comment? :) > > > > Didn't look at udev yet. > > > > What about just storing current seq # in a file, and if you see wrong > > number in that file, just want for correct one to appear (or time out > > in "reasonable time")? > > how do you time out without running as a daemon? have the mdev binary > sleep()? More or less. mdev can have an option where to store seqfile: mdev -l , and then it does: seqnum = atoi(getenv("SEQNUM")); timeout = 300/2 + 1; /* 3 seconds */ while (--timeout && read_num(SEQFILE) + 1 != seqnum) usleep(20*1000); write_num(SEQFILE, seqnum); /* atomically */ In other words, mdev's will be started asyncronously but will wait until they see that mdev with preceding seqnum have finished. > then you may have multiple mdev's sleeping which means you need to > do process management, or implement some method for shared communication, > or ... Above looks like pretty simple shared communication to me. -- vda From cristian.ionescu-idbohrn at axis.com Tue Jun 3 13:06:49 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 3 Jun 2008 22:06:49 +0200 (CEST) Subject: [patch] Makefile.flags: would this make more sense? Message-ID: <0806032202570.16214@somehost> When using gdb, one would expect to have the source compiled with '-g -O0', and not '-g -Os'. Index: Makefile.flags =================================================================== --- busybox-svn-/Makefile.flags (revision 22004) +++ busybox-svn/Makefile.flags (working copy) @@ -35,7 +35,7 @@ # gcc 3.x emits bogus "old style proto" warning on find.c:alloc_action() CFLAGS += $(call cc-ifversion, -ge, 0400, -Wold-style-definition) -CFLAGS += $(call cc-option,-Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections,) +CFLAGS += $(call cc-option,-fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections,) # -fno-guess-branch-probability: prohibit pseudo-random guessing # of branch probabilities (hopefully makes bloatcheck more stable): CFLAGS += $(call cc-option,-fno-guess-branch-probability,) @@ -47,7 +47,9 @@ #CFLAGS+=$(call cc-option,-Wconversion,) ifeq ($(CONFIG_DEBUG),y) -CFLAGS += $(call cc-option,-g) +CFLAGS += $(call cc-option,-g -O0,) +else +CFLAGS += $(call cc-option,-Os,) endif ifeq ($(CONFIG_BUILD_LIBBUSYBOX),y) Cheers, -- Cristian From vapier at gentoo.org Tue Jun 3 13:08:43 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 3 Jun 2008 16:08:43 -0400 Subject: mdev race conditions In-Reply-To: <200806032028.32999.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <200806031247.33080.vapier@gentoo.org> <200806032028.32999.vda.linux@googlemail.com> Message-ID: <200806031608.44376.vapier@gentoo.org> On Tuesday 03 June 2008, Denys Vlasenko wrote: > On Tuesday 03 June 2008 18:47, Mike Frysinger wrote: > > > > Would this be all it takes? Anyone with more than half an hour's > > > > experience of looking at udev's source code willing to comment? :) > > > > > > Didn't look at udev yet. > > > > > > What about just storing current seq # in a file, and if you see wrong > > > number in that file, just want for correct one to appear (or time out > > > in "reasonable time")? > > > > how do you time out without running as a daemon? have the mdev binary > > sleep()? > > More or less. mdev can have an option where to store seqfile: > mdev -l , and then it does: > > seqnum = atoi(getenv("SEQNUM")); > timeout = 300/2 + 1; /* 3 seconds */ > while (--timeout && read_num(SEQFILE) + 1 != seqnum) > usleep(20*1000); > > write_num(SEQFILE, seqnum); /* atomically */ > > In other words, mdev's will be started asyncronously but will wait > until they see that mdev with preceding seqnum have finished. a single hotplug event will trigger many messages (iirc, you can easily get bursts of ~10 or so with a single network interface). which means you'll have many mdev processes all hanging out. hopefully that flurry doesnt cause the delays to stretch out of sequence again. you'll also need to make sure you do this somewhere which has temporary storage ... otherwise you'll wreck embedded flash systems > > then you may have multiple mdev's sleeping which means you need to > > do process management, or implement some method for shared communication, > > or ... > > Above looks like pretty simple shared communication to me. *shrug* anything not daemon/netlink based looks like a hack to me ... which means i still dont understand why people dont go use udevd if they need a real setup. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080603/1d750d5e/attachment.pgp From wharms at bfs.de Tue Jun 3 13:16:01 2008 From: wharms at bfs.de (walter harms) Date: Tue, 03 Jun 2008 22:16:01 +0200 Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <0806032202570.16214@somehost> References: <0806032202570.16214@somehost> Message-ID: <4845A681.4000602@bfs.de> yes it makes no sense i would even drop -O0 (see my patch some weeks ago :) re, wh Cristian Ionescu-Idbohrn wrote: > When using gdb, one would expect to have the source compiled with '-g -O0', > and not '-g -Os'. > > Index: Makefile.flags > =================================================================== > --- busybox-svn-/Makefile.flags (revision 22004) > +++ busybox-svn/Makefile.flags (working copy) > @@ -35,7 +35,7 @@ > # gcc 3.x emits bogus "old style proto" warning on find.c:alloc_action() > CFLAGS += $(call cc-ifversion, -ge, 0400, -Wold-style-definition) > > -CFLAGS += $(call cc-option,-Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections,) > +CFLAGS += $(call cc-option,-fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections,) > # -fno-guess-branch-probability: prohibit pseudo-random guessing > # of branch probabilities (hopefully makes bloatcheck more stable): > CFLAGS += $(call cc-option,-fno-guess-branch-probability,) > @@ -47,7 +47,9 @@ > #CFLAGS+=$(call cc-option,-Wconversion,) > > ifeq ($(CONFIG_DEBUG),y) > -CFLAGS += $(call cc-option,-g) > +CFLAGS += $(call cc-option,-g -O0,) > +else > +CFLAGS += $(call cc-option,-Os,) > endif > > ifeq ($(CONFIG_BUILD_LIBBUSYBOX),y) > > > Cheers, > From cristian.ionescu-idbohrn at axis.com Tue Jun 3 13:39:09 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 3 Jun 2008 22:39:09 +0200 (CEST) Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <4845A681.4000602@bfs.de> References: <0806032202570.16214@somehost> <4845A681.4000602@bfs.de> Message-ID: <0806032237280.16214@somehost> On Tue, 3 Jun 2008, walter harms wrote: > yes it makes no sense > i would even drop -O0 > > (see my patch some weeks ago :) Would it be too much trouble for you to point me to your patch from some weeks ago? Cheers, -- Cristian From cristian.ionescu-idbohrn at axis.com Tue Jun 3 15:28:35 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Wed, 4 Jun 2008 00:28:35 +0200 (CEST) Subject: would you be interested of a sketchy testsuite/printf.tests Message-ID: <0806040026430.16214@somehost> Attached. Cheers, -- Cristian -------------- next part -------------- #!/bin/sh set -e . testing.sh bb="busybox " testing "printf: produce no further output 1" \ "${bb}printf '\c' foo" \ "" \ "" \ "" testing "printf: produce no further output 2" \ "${bb}printf '%s\c' foo \$HOME" \ "foo" \ "" \ "" testing "printf: produce no further output 3" \ "${bb}printf '%s\n' foo \$HOME" \ "foo\n$HOME\n" \ "" \ "" exit 0 From bernard at largestprime.net Tue Jun 3 17:33:39 2008 From: bernard at largestprime.net (Bernard Blackham) Date: Wed, 04 Jun 2008 08:33:39 +0800 Subject: mdev race conditions In-Reply-To: <200806031837.50625.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <200806031758.32235.vda.linux@googlemail.com> <200806031837.50625.vda.linux@googlemail.com> Message-ID: <4845E2E3.5050902@largestprime.net> Denys Vlasenko wrote: You did some debugging and I suspect you can answer this: > is SEQNUM per DEVPATH or is it global? Is there events without SEQNUM at all? Looking at the kernel sources, it's per uevent emitted. Every event is given a unique monotonically increasing sequence number. Bernard. From bernard at largestprime.net Tue Jun 3 17:43:35 2008 From: bernard at largestprime.net (Bernard Blackham) Date: Wed, 04 Jun 2008 08:43:35 +0800 Subject: mdev race conditions In-Reply-To: <200806031608.44376.vapier@gentoo.org> References: <484558CA.8070308@largestprime.net> <200806031247.33080.vapier@gentoo.org> <200806032028.32999.vda.linux@googlemail.com> <200806031608.44376.vapier@gentoo.org> Message-ID: <4845E537.1000705@largestprime.net> Mike Frysinger wrote: > you'll also need to make sure you do this somewhere which has temporary > storage ... otherwise you'll wreck embedded flash systems /dev is on tmpfs anyway. > *shrug* anything not daemon/netlink based looks like a hack to me And I'm inclined to agree. > which means i still dont understand why people dont go use udevd if > they need a real setup. s/real/reliable/ What good is using mdev if it cannot be relied upon? (apart from using mdev -s at boot and an otherwise completely-static /dev). [... snip ...] > better, just use udevd (which i honestly dont think is a big deal, it > isnt exactly bloated ... it's 76k on x86_64 and it's built for speed, > not size). It's 66K stripped on arm and built for size (the Makefile for udev-120 does this by default). 66K is a lot for a critical daemon. It does a *lot* of stuff that nobody needs - it maintains a database in /dev/.udev of all devices and exports lots of information to userspace which probably does not matter to most embedded systems. I'd like someone to answer my original proposal of whether or not a simple daemon running in a loop would suffice. I imagine the resulting binary would be a mere few kilobytes in size, as *all* it needs to do is serialize requests and pass them to mdev. Nothing more. Bernard. From paulius.zaleckas at teltonika.lt Wed Jun 4 00:10:12 2008 From: paulius.zaleckas at teltonika.lt (Paulius Zaleckas) Date: Wed, 04 Jun 2008 10:10:12 +0300 Subject: [patch] rtcwake: fix default suspend value In-Reply-To: <200806031019.34866.vapier@gentoo.org> References: <4843AD78.9050408@teltonika.lt> <200806021803.07054.vapier@gentoo.org> <200806031019.34866.vapier@gentoo.org> Message-ID: <48463FD4.6010209@teltonika.lt> Mike Frysinger wrote: > On Tuesday 03 June 2008, Paulius Zaleckas wrote: >> Mike Frysinger wrote: >>> On Monday 02 June 2008, Bernhard Fischer wrote: >>>> On Mon, Jun 02, 2008 at 04:35:43PM -0400, Mike Frysinger wrote: >>>>> On Monday 02 June 2008, Paulius Zaleckas wrote: >>>>>> Writing "suspend" to /sys/power/state does nothing. >>>>> it depends solely on your kernel configuration >>>> So what about stating this in the config and providing a >>> the rtcwake applet is based on the util-linux version. that means the >>> defaults are the same. if the default is not appropriate for your >>> system, there's a runtime flag already. >> What is the default system? If it is linux then it should be "standby". >> Maybe it is a bug in util-linux too?! > > busybox applets match the behavior of the utilities they replace. you can > certainly ask the util-linux guys to change the default behavior ... at that > time, i'll gladly update busybox to match it. > -mike This bug will be fixed in util-linux-ng release 2.14 I think it is safe to apply my patch. From vapier at gentoo.org Wed Jun 4 01:27:31 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 4 Jun 2008 04:27:31 -0400 Subject: mdev race conditions In-Reply-To: <4845E537.1000705@largestprime.net> References: <484558CA.8070308@largestprime.net> <200806031608.44376.vapier@gentoo.org> <4845E537.1000705@largestprime.net> Message-ID: <200806040427.34112.vapier@gentoo.org> On Tuesday 03 June 2008, Bernard Blackham wrote: > Mike Frysinger wrote: > > you'll also need to make sure you do this somewhere which has temporary > > storage ... otherwise you'll wreck embedded flash systems > > /dev is on tmpfs anyway. not always ... but for the cases which i'm flagging, they'd better be or you're already wrecking things :) > > *shrug* anything not daemon/netlink based looks like a hack to me > > And I'm inclined to agree. > > > which means i still dont understand why people dont go use udevd if > > they need a real setup. > > s/real/reliable/ > > What good is using mdev if it cannot be relied upon? (apart from using > mdev -s at boot and an otherwise completely-static /dev). this is actually a significant base for which mdev is perfect > [... snip ...] > > > better, just use udevd (which i honestly dont think is a big deal, it > > isnt exactly bloated ... it's 76k on x86_64 and it's built for speed, > > not size). > > It's 66K stripped on arm and built for size (the Makefile for udev-120 > does this by default). 66K is a lot for a critical daemon. i'd disagree. ignoring busybox, 66k is pretty damn tight considering everything udev offers. > It does a > *lot* of stuff that nobody needs - it maintains a database in /dev/.udev > of all devices and exports lots of information to userspace which > probably does not matter to most embedded systems. it does a *lot* of stuff that people keep asking to add to mdev. historically i declined anything but the bare min stuff as imo, we're wasting time reinventing a perfectly good wheel. Denys seems to be more open to merging features. > I'd like someone to answer my original proposal of whether or not a > simple daemon running in a loop would suffice. I imagine the resulting > binary would be a mere few kilobytes in size, as *all* it needs to do is > serialize requests and pass them to mdev. Nothing more. writing a standalone binary does not fit the busybox design. i doubt mdevd would be terribly difficult to do with real netlink sockets/daemon. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080604/3c2cbf53/attachment-0001.pgp From vda.linux at googlemail.com Wed Jun 4 01:41:38 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 4 Jun 2008 10:41:38 +0200 Subject: mdev race conditions In-Reply-To: <4845E537.1000705@largestprime.net> References: <484558CA.8070308@largestprime.net> <200806031608.44376.vapier@gentoo.org> <4845E537.1000705@largestprime.net> Message-ID: <200806041041.38663.vda.linux@googlemail.com> On Wednesday 04 June 2008 02:43, Bernard Blackham wrote: > Mike Frysinger wrote: > > you'll also need to make sure you do this somewhere which has temporary > > storage ... otherwise you'll wreck embedded flash systems > > /dev is on tmpfs anyway. > > > *shrug* anything not daemon/netlink based looks like a hack to me > > And I'm inclined to agree. > > > which means i still dont understand why people dont go use udevd if > > they need a real setup. > > s/real/reliable/ > > What good is using mdev if it cannot be relied upon? (apart from using > mdev -s at boot and an otherwise completely-static /dev). Try attached 2.patch. It adds mdev options -f SEQFILE and -t TIMEOUT_MSEC. If -f is not given, the behavious is unchanged. If -f SEQFILE is given, and if SEQNUM env var is set, mdev will check whether SEQFILE contains exactly the same line as $SEQNUM (must match exactly, not even '\n' is allowed to be there). It will proceed immediately if file can't be read. It will time out (default 1000 msec) and proceed even if SEQFILE contains non-matching line. After mdev is done, and if both -f was given and $SEQNUM is set, mdev will write $SEQNUM + 1 to SEQFILE prior to exit. Note that if SEQFILE is not absolute, it will be read/written relative to /dev. Only compile tested... -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.patch Type: text/x-diff Size: 2612 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080604/84f7bd4d/attachment.patch From bernard at largestprime.net Wed Jun 4 02:04:16 2008 From: bernard at largestprime.net (Bernard Blackham) Date: Wed, 4 Jun 2008 17:04:16 +0800 Subject: mdev race conditions In-Reply-To: <200806040427.34112.vapier@gentoo.org> References: <484558CA.8070308@largestprime.net> <200806031608.44376.vapier@gentoo.org> <4845E537.1000705@largestprime.net> <200806040427.34112.vapier@gentoo.org> Message-ID: <20080604090416.GA7964@mersenne.largestprime.net> On Wed, Jun 04, 2008 at 04:27:31AM -0400, Mike Frysinger wrote: > [udev] does a *lot* of stuff that people keep asking to add to mdev. > historically i declined anything but the bare min stuff as imo, > we're wasting time reinventing a perfectly good wheel. I'm not asking for features. I just want reliability. If people use mdev through /proc/sys/kernel/hotplug as it is currently documented, they will hit race conditions 1% of the time which may slip through their testing. (Luckily, we're hitting it about 20% of the time here). > > I'd like someone to answer my original proposal of whether or not a > > simple daemon running in a loop would suffice. I imagine the resulting > > binary would be a mere few kilobytes in size, as *all* it needs to do is > > serialize requests and pass them to mdev. Nothing more. > > writing a standalone binary does not fit the busybox design. Sorry, what I meant to say is that the resulting addition of mdevd to the busybox binary would only add a few kilobytes to its size. > i doubt mdevd would be terribly difficult to do with real netlink > sockets/daemon. And that's exactly what I'm proposing. I think I'll just do it. I'll let you know how I go :) Cheers, Bernard. From bernard at largestprime.net Wed Jun 4 02:08:56 2008 From: bernard at largestprime.net (Bernard Blackham) Date: Wed, 4 Jun 2008 17:08:56 +0800 Subject: mdev race conditions In-Reply-To: <200806041041.38663.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <200806031608.44376.vapier@gentoo.org> <4845E537.1000705@largestprime.net> <200806041041.38663.vda.linux@googlemail.com> Message-ID: <20080604090855.GB7964@mersenne.largestprime.net> On Wed, Jun 04, 2008 at 10:41:38AM +0200, Denys Vlasenko wrote: > Try attached 2.patch. It adds mdev options -f SEQFILE and -t TIMEOUT_MSEC. > If -f is not given, the behavious is unchanged. Thanks, but this is not helpful as you can't get hotplug/uevent_helper to pass arguments to mdev. > After mdev is done, and if both -f was given and $SEQNUM is set, > mdev will write $SEQNUM + 1 to SEQFILE prior to exit. Bear in mind too that seqnum is a u64. As outlined in the email I just sent to Mike, I'll try and do up an mdevd tonight which does it cleanly. Cheers, Bernard. From vapier at gentoo.org Wed Jun 4 03:32:16 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 4 Jun 2008 06:32:16 -0400 Subject: mdev race conditions In-Reply-To: <20080604090416.GA7964@mersenne.largestprime.net> References: <484558CA.8070308@largestprime.net> <200806040427.34112.vapier@gentoo.org> <20080604090416.GA7964@mersenne.largestprime.net> Message-ID: <200806040632.17428.vapier@gentoo.org> On Wednesday 04 June 2008, Bernard Blackham wrote: > On Wed, Jun 04, 2008 at 04:27:31AM -0400, Mike Frysinger wrote: > > [udev] does a *lot* of stuff that people keep asking to add to mdev. > > historically i declined anything but the bare min stuff as imo, > > we're wasting time reinventing a perfectly good wheel. > > I'm not asking for features. I just want reliability. If people use > mdev through /proc/sys/kernel/hotplug as it is currently documented, > they will hit race conditions 1% of the time which may slip through > their testing. (Luckily, we're hitting it about 20% of the time > here). again, it's all about intentions. mdev was intended to seed /dev and then just update it on occasion, not be stress tested. a completely reliable version is a feature imo ;). it also isnt a matter of documentation ... the whole reason for moving to netlink socket communication is because, by design, executing a binary per event is racy. adding delays/checks would mitigate that, not fix it. > > > I'd like someone to answer my original proposal of whether or not a > > > simple daemon running in a loop would suffice. I imagine the resulting > > > binary would be a mere few kilobytes in size, as *all* it needs to do > > > is serialize requests and pass them to mdev. Nothing more. > > > > writing a standalone binary does not fit the busybox design. > > Sorry, what I meant to say is that the resulting addition of mdevd > to the busybox binary would only add a few kilobytes to its size. and as things are today, your "tiny" addition results in much more overhead than udevd. busybox is one big blob and every instance of it (regardless of what applet it's invoking) means a unique instance of that big blog in memory. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080604/574ec8b5/attachment.pgp From vda.linux at googlemail.com Wed Jun 4 04:27:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 4 Jun 2008 13:27:50 +0200 Subject: mdev race conditions In-Reply-To: <200806031243.42905.vapier@gentoo.org> References: <484558CA.8070308@largestprime.net> <200806031800.49482.vda.linux@googlemail.com> <200806031243.42905.vapier@gentoo.org> Message-ID: <200806041327.50192.vda.linux@googlemail.com> On Tuesday 03 June 2008 18:43, Mike Frysinger wrote: > > Can you chime me in how to build PIE / how it is different from normal > > executable? I guess there are some restrictions and things to do (e.g. have > > to pass -fPIE to gcc)? -- > > afaik (solar can correct me), just compile all objects with -fPIE and link > with -pie > > a quick test is (1) it still executes ;) and (2) running `file` on the ELF > should declare it as a shared object rather than executable Thanks. Just committed CONFIG_PIE option. The help text is just a placeholder for now: "TODO: what is it and why/when is it useful?" Can you elaborate when it is useful? And when it is definitely not useful, so that people won't select it needlessly? -- vda From wharms at bfs.de Wed Jun 4 05:20:26 2008 From: wharms at bfs.de (walter harms) Date: Wed, 04 Jun 2008 14:20:26 +0200 Subject: mdev race conditions In-Reply-To: <200806041327.50192.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <200806031800.49482.vda.linux@googlemail.com> <200806031243.42905.vapier@gentoo.org> <200806041327.50192.vda.linux@googlemail.com> Message-ID: <4846888A.60906@bfs.de> maybe this explanation is helpful http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00145.html re, wh Denys Vlasenko wrote: > On Tuesday 03 June 2008 18:43, Mike Frysinger wrote: >>> Can you chime me in how to build PIE / how it is different from normal >>> executable? I guess there are some restrictions and things to do (e.g. have >>> to pass -fPIE to gcc)? -- >> afaik (solar can correct me), just compile all objects with -fPIE and link >> with -pie >> >> a quick test is (1) it still executes ;) and (2) running `file` on the ELF >> should declare it as a shared object rather than executable > > Thanks. > > Just committed CONFIG_PIE option. > The help text is just a placeholder for now: > > "TODO: what is it and why/when is it useful?" > > Can you elaborate when it is useful? > And when it is definitely not useful, so that people won't select it needlessly? > -- > vda > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > From rep.dot.nop at gmail.com Wed Jun 4 05:25:52 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 4 Jun 2008 14:25:52 +0200 Subject: svn commit: trunk/busybox In-Reply-To: <20080604115324.90FE33C617@busybox.net> References: <20080604115324.90FE33C617@busybox.net> Message-ID: <20080604122552.GF20378@mx.loc> On Wed, Jun 04, 2008 at 04:53:24AM -0700, vda at busybox.net wrote: >Author: vda >Date: 2008-06-04 04:53:24 -0700 (Wed, 04 Jun 2008) >New Revision: 22212 > >Log: >remove -fno-jump-tables - after stripping it proved to be worse The only thing that really makes sense and is (imo) benefical is http://www.google.com/search?hl=en&as_q=flatten+switch-stmt i.e. do away with all useless jumping around and branching. From rep.dot.nop at gmail.com Wed Jun 4 09:35:30 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 4 Jun 2008 18:35:30 +0200 Subject: depmod In-Reply-To: <6784529b0805290913xa5434b7l839d67006debab41@mail.gmail.com> References: <6784529b0805260913n4c47f63dye1138e7d9cb23c50@mail.gmail.com> <20080526173054.GB20863@mx.loc> <6784529b0805261109k35a500d0vadfebc51ce649d19@mail.gmail.com> <6784529b0805261125k6edfc19et88a5eb20a13cb81e@mail.gmail.com> <20080528104920.GA6643@mx.loc> <6784529b0805280802od01181dp5db800bb9df78afd@mail.gmail.com> <20080528151925.GB10228@mx.loc> <6784529b0805281206r7ef97e56we6003b25a3a1a217@mail.gmail.com> <20080529160112.GV27768@mx.loc> <6784529b0805290913xa5434b7l839d67006debab41@mail.gmail.com> Message-ID: <20080604163529.GA30430@mx.loc> On Thu, May 29, 2008 at 08:13:41PM +0400, Vladimir Dronnikov wrote: >2008/5/29, Bernhard Fischer : >> >> On Wed, May 28, 2008 at 11:06:09PM +0400, Vladimir Dronnikov wrote: >> >> >5. I've prepared modules.tar.bz2 (of size 2.7Mb). Sorry, have no location >> to >> >upload it. Do you have? Or can I send you that tarball directly? >> >> >> I'd like to see the output of the patched modprobe first. >> > >I've no gdb on my system, Bernhard. >Modprobe complains on module snd.ko has unresolved symbols. >This means the sequence of loading is wrong. snd.ko requires soundcore.ko to >be loaded. And so on. >Would you run depmod.snd to unload _all_ sound modules and load them again >using _newly generated modules.dep_? Why sound >modules? Because it seems they have the most complicated dependencies. >I assure you that depmod in current state generate modules.dep in the wrong >way. If you sort then diff >both production and BB-generated modules.dep you'll see they differ >dramatically. Yes, but this doesn't make any difference for my modprobe, and i tried module-init-tools 3.3-pre4-2 and 3.4-1 as well as our modprobe. All do work just fine for modprobing snd-hda-intel, of course even if i have turned *off* the fancy pruning. I really suspect that your modprobe or toolchain or setup or whatever has a problem, not depmod. > > >-- >Vladimir > >P.S. Sorry, I can not right now access my system to provide you with exact >output of the patched modprobe. I'm still interrested in this output if you find the time. Perhaps you don't have proc mounted? Please show me the output of those debug-lines. friendly, Bernhard From rep.dot.nop at gmail.com Wed Jun 4 09:57:54 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 4 Jun 2008 18:57:54 +0200 Subject: DEPMOD again In-Reply-To: <48441c20.26a75e0a.6d42.5513@mx.google.com> References: <48441c20.26a75e0a.6d42.5513@mx.google.com> Message-ID: <20080604165753.GB30430@mx.loc> On Mon, Jun 02, 2008 at 09:13:20AM -0700, dronnikov at gmail.com wrote: >Hello, Bernhard! [hey there. Replying on the ML, hope you don't mind] > >Please, tell me: do you test your code before you submit it? occasionally, yes ;P In this case i did, see below. > >I put my modules into /usr/lib/modules. I set CONFIG_DEFAULT_MODULES_DIR to that location. That's fine and the reason why we have that CONFIG. >I ran depmod. I got null modules.dep... Sounds odd. What revision are you using? Please use rev22215 or later *without* any patches. >I ran "ln -s . 2.6.25.2" in /usr/lib/modules. That way I simulated /usr/lib/modules/2.6.25.2 being _so_ >necessary in depmod. I reran depmod. And regot null modules.dep! a symlink won't work, make that a hardlink (and no, i won't change it to accept symlinks since then it would potentially walk down the source/ dir. No way). >Ah. recursive_action() can not resolve symlinks... It can but we don't want that. See above. >But I just can not guess what parameters to pass in my situation?!! make a hardlink or patch the c code or use the perl script or use the sh script :) > >Can you reproduce the situation? I imagine that a symlink will not work, yes. >Can you answer all the following questions? > >1. Why two cycles? It was a design-decision that helped collecting all full paths to modules. I then had all info to emit the module right on the spot when matching a dependency. Somehow i thought that i have to protect against modules with identical filenames living in different directories, but fortunately there are no such occurances and this is unlikely to change (so i dropped the gather-only walk a few days ago). >2. Why append 2.6.25.2 or specific kernel version? well, that's what the manpage of depmod says and we want to have a drop-in replacement. >3. Why bloaty code is better? Where did i say that? >4. Why reject and even not mention other people contribution? vda added your shell-script. I didn't look at nor used any code from you for depmod. What do you mean, specifically? > >--- > /* modprobe allegedly wants dependencies without duplicates, i.e. > * mod1: mod2 mod3 > * mod2: mod3 > * mod3: > * implies that mod1 directly depends on mod2 and _not_ mod3 as mod3 is > * already implicitely pulled in via mod2. This leaves us with: > * mod1: mod2 > * mod2: mod3 > * mod3: > */ > >Wrong! >modprobe has no recursive lookup. If it has been told to load mod1 it will lookup for JUST mod1: line in modules.dep. Are you sure? All of my modprobes load the deps in order, but see below. >What you name ENABLE_FEATURE_DEPMOD_PRUNE_FANCY is (the only) way to generate useful modules.dep! nope. The non-pruning one works just fine for me. > >Can you unload ALL sound modules (including snd and soundcore) and then reload snd-pcm-oss one? yes, loading snd-pcm-oss is loaded fine for me with both modprobe from module-init-tools as well as our modprobe. Tried it, works flawlessly. Could it be that you have a stale link to some old or broken modprobe on your box? What version are you using? As mentioned a few minutes ago, please also send me the debugging-output of modprobe and make sure that you really use the insmod and modprobe that you think you are using. TIA, From nicolas.dichtel at dev.6wind.com Wed Jun 4 09:51:48 2008 From: nicolas.dichtel at dev.6wind.com (Nicolas Dichtel) Date: Wed, 04 Jun 2008 18:51:48 +0200 Subject: Console problem Message-ID: <4846C824.4060501@dev.6wind.com> Hi all, I was using busybox-1.01 for a long time and recently I've switched to busybox-1.10.2. On x86, there is no problem, but on MIPS architecture, the console does not work properly: need to type second character to make the first appear. If I apply this patch: --- busybox/init/init.c 2008-04-17 11:13:25.000000000 +0200 +++ busybox-new/init/init.c 2008-05-20 16:47:00.000000000 +0200 @@ -873,6 +873,9 @@ int init_main(int argc ATTRIBUTE_UNUSED, /* Figure out where the default console should be */ console_init(); + close(0); + close(1); + close(2); set_sane_term(); chdir("/"); setsid(); the problem is solved. Of course, some log messages are hidden with this patch. I didn't find a better way to fix that problem. Any ideas ? Regards, Nicolas From natanael.copa at gmail.com Wed Jun 4 11:29:56 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed, 04 Jun 2008 20:29:56 +0200 Subject: [PATCH] Support for the LOWER_UP flag Message-ID: <4846DF24.601@gmail.com> Hi, Attatched is a patch for the LOWER_UP flag in 'ip link/addr' output. Useful to check if network cable is inserted or not. The code does an ugly ifdef to check if IFF_LOWER_UP is declared or not. On my zenwalk desktop it was not. It looks like iproute2 maintain their own copies of the linux headers so I suppose we cannot expect the flag be there. (should mabe be in one of the include files rather than in the .c file?) The patch does increase the size a bit due to a macro. Maybe should have a config option for it? on my hardened uclibc i386 build: function old new delta ipaddr_list_or_flush 2929 2981 +52 .rodata 7677 7683 +6 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 58/0) Total: 58 bytes text data bss dec hex filename 47498 670 4244 52412 ccbc busybox_old 47556 670 4244 52470 ccf6 busybox_unstripped -nc -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-iproute-LOWER_UP.patch Type: text/x-patch Size: 562 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080604/8012a6d1/attachment.bin From rep.dot.nop at gmail.com Wed Jun 4 13:06:37 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 4 Jun 2008 22:06:37 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <4846DF24.601@gmail.com> References: <4846DF24.601@gmail.com> Message-ID: <20080604200637.GF27768@mx.loc> On Wed, Jun 04, 2008 at 08:29:56PM +0200, Natanael Copa wrote: > Hi, > > Attatched is a patch for the LOWER_UP flag in 'ip link/addr' output. > Useful to check if network cable is inserted or not. > > The code does an ugly ifdef to check if IFF_LOWER_UP is declared or not. > On my zenwalk desktop it was not. It looks like iproute2 maintain their > own copies of the linux headers so I suppose we cannot expect the flag > be there. (should mabe be in one of the include files rather than in the > .c file?) > > The patch does increase the size a bit due to a macro. Maybe should have > a config option for it? no config, no. I was about to apply it but looking at the macro i'd be curious if we have more occurances of the if (foo & flag) emit(#flag) pattern so we should provide something like the reversed form of index_in_strings() like string_in_index(int state) that emits the corresponding string? Could you try that and convert some users to that scheme? I'd be surprised if this would not be an overall win. > > on my hardened uclibc i386 build: > > function old new delta > ipaddr_list_or_flush 2929 2981 +52 > .rodata 7677 7683 +6 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 2/0 up/down: 58/0) Total: 58 > bytes > text data bss dec hex filename > 47498 670 4244 52412 ccbc busybox_old > 47556 670 4244 52470 ccf6 busybox_unstripped > > -nc From jsimmons at infradead.org Wed Jun 4 13:40:09 2008 From: jsimmons at infradead.org (James Simmons) Date: Wed, 4 Jun 2008 21:40:09 +0100 (BST) Subject: ash/stty usage Message-ID: Hi! I'm attempting color text but I'm getting "K[37;1mTextK[31;1m". Any idea what is wrong? Also I'm looking to flush the tty. Currently I'm doing eat_extra_keys() { local saved=$(stty -g) stty -icanon min 1 time 1 cat -N > /dev/null // Modified cat to flush the and not block if no stty $saved // data is present. } Do you know of a better way? From vda.linux at googlemail.com Wed Jun 4 17:13:17 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 02:13:17 +0200 Subject: elf2flt questions Message-ID: <200806050213.17578.vda.linux@googlemail.com> Hi Mike. A bit of a background of what I am doing here. I was given a blackfin board (BF537). I want to build and run busybox on it (for starters). I never built or ran blackfin binaries, and more broadly have no experience with flat binaries for any architecture. I want to do it in "Linux from scratch" style. This way, I will get better understanding of the way it is done, and possibly stumble upon rough edges in busybox, uclubc, etc. This will lead to "itch scratching" and bug fixing. I managed to build uclibc as a static lib and busybox as a static elf binary for bfin. Now I need to create a flat binary. For one, the kernel on this board seems to be unable to run elf binaries, it says "BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5)". It means that I am venturing into unexplored (by me) territory of elf2flt. I took toolchain/trunk/elf2flt directory and built elf2flt: # ./elf2flt Usage: ./elf2flt [vrzd] [-p ] [-s stack-size] [-o ] -v : verbose operation -r : force load to RAM -k : enable kernel trace on load (for debug) -z : compress code/data/relocs -d : compress data/relocs -a : use existing symbol references instead of recalculating from relocation info -R reloc-file : read relocations from a separate file -p abs-pic-file : GOT/PIC processing with files -s stacksize : set application stack size -o output-file : output file name Compiled for bfin architecture To be honest, building it was somewhat contrived - I copied the directory into binutils' build dir and gave it all necessary configure parameters, and it still could not find e.g. elf/bfin.h - had to add some include paths by hand. (Do you want a more detailed report about this?) If I did it incorrectly - well, there are no build instructions apart from configure help. Looking into ld-elf2flt makes me doubtful - "LINKER="$0.real" # the original renamed-linker" - really? It will rename my linker and replace it by itself? This script looks rather contrived, will it really work correctly for all possible invocations of ld which don't even want to do any elf2flt-ification? This makes me reluctant to run "make install" blidly, I decided to ask you instead for some directions. In the order of importance: Can you write up a small explanation what elf2flt does, how to produce a flat executable with it? Let's say in my situation - I seem to have correctly built static elf bfin busybox, can I make a flat one out of it? What is this ld-elf2flt wrapper - what is it doing? How elf2flt is added into binutils? Again, my situation - I built bfin toolchain (binutils+gcc), it works, but it produces elf executables. (Actually, I have two toolchains - bfin-linux-uclibc and bfin-uclinux. Both produce elf executables). How to add elf2flt to the toolchain so that it can produce flat executables? After that, how to instruct ld to produce flat executable? Thanks. -- vda From vda.linux at googlemail.com Wed Jun 4 17:38:00 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 02:38:00 +0200 Subject: elf2flt questions In-Reply-To: <200806050213.17578.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> Message-ID: <200806050238.00646.vda.linux@googlemail.com> On Thursday 05 June 2008 02:13, Denys Vlasenko wrote: > Can you write up a small explanation what elf2flt does, how to produce > a flat executable with it? Let's say in my situation - I seem to have > correctly built static elf bfin busybox, can I make a flat one out of it? Straightforward approach suggested by "elf2flt --help" doesn't work: # ./elf2flt busybox_unstripped -a -o busybox_unstripped.flat busybox_unstripped: Input file contains no relocation info Obviously, input file should be something different than static elf binary... heeeeelp :) Sanity check: is it really an elf blackfin? Looks like it: # bfin-linux-uclibc-objdump -xrd busybox_unstripped busybox_unstripped: file format elf32-bfinfdpic busybox_unstripped architecture: bfin, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x000000b0 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x000bd4e4 memsz 0x000bd4e4 flags r-x LOAD off 0x000bd4e4 vaddr 0x000c14e4 paddr 0x000c14e4 align 2**12 filesz 0x0000879c memsz 0x00009f84 flags rw- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**3 filesz 0x00000000 memsz 0x00020000 flags rwx private flags = 2: -mfdpic Sections: Idx Name Size VMA LMA File off Algn 0 .init 0000001a 00000094 00000094 00000094 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .text 00094d40 000000b0 000000b0 000000b0 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE ... ... ... 00001cec g F .text 00000028 .hidden _xopen3 000855d0 g F .text 00000358 _strptime 000782f4 g F .text 000000ba _encrypt Disassembly of section .init: 00000094 <__init>: 94: 4b 01 [--SP] = P3; 96: 00 e8 03 00 LINK 0xc; /* (12) */ 9a: 73 ad P3 = [SP + 0x14]; 9c: 00 e3 dc 00 CALL 0x254 <_frame_dummy>; a0: 73 ad P3 = [SP + 0x14]; a2: 04 e3 95 a6 CALL 0x94dcc <___do_global_ctors_aux>; a6: 01 e8 00 00 UNLINK; aa: 73 90 P3 = [SP++]; ac: 10 00 RTS; Disassembly of section .text: 000000b0 <__start>: b0: 00 e3 02 00 CALL 0xb4 <__start+0x4>; b4: 27 31 R4 = RETS; b6: a6 6f SP += -0xc; /* (-12) */ ... -- vda From vda.linux at googlemail.com Wed Jun 4 17:46:32 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 02:46:32 +0200 Subject: Console problem In-Reply-To: <4846C824.4060501@dev.6wind.com> References: <4846C824.4060501@dev.6wind.com> Message-ID: <200806050246.32550.vda.linux@googlemail.com> On Wednesday 04 June 2008 18:51, Nicolas Dichtel wrote: > Hi all, > > I was using busybox-1.01 for a long time and recently I've switched to > busybox-1.10.2. On x86, there is no problem, but on MIPS architecture, > the console does not work properly: need to type second character to make > the first appear. Please give more details. You need to type every char twice or what? What program is receiving your keypresses? getty? shell? How exactly do you start it (command line, etc)? Can you show ls -l /proc/$PID/fd of this program and also ls -l /proc/1/fd? Do you have any console=XXX or CONSOLE=XXX params on kernel command line? > If I apply this patch: > > --- busybox/init/init.c 2008-04-17 11:13:25.000000000 +0200 > +++ busybox-new/init/init.c 2008-05-20 16:47:00.000000000 +0200 > @@ -873,6 +873,9 @@ int init_main(int argc ATTRIBUTE_UNUSED, > > /* Figure out where the default console should be */ > console_init(); > + close(0); > + close(1); > + close(2); > set_sane_term(); > chdir("/"); > setsid(); > > the problem is solved. Of course, some log messages are hidden with this patch. > I didn't find a better way to fix that problem. Any ideas ? Sorry, but I don't like it. Not only you deprive all future children from knowing what console is, you risk starting them with stdio CLOSED - which is very bad, a lot of programs have bugs where they overwrite random files if they are run with stdio closed. From vda.linux at googlemail.com Wed Jun 4 17:47:35 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 02:47:35 +0200 Subject: DEPMOD again In-Reply-To: <20080604165753.GB30430@mx.loc> References: <48441c20.26a75e0a.6d42.5513@mx.google.com> <20080604165753.GB30430@mx.loc> Message-ID: <200806050247.35163.vda.linux@googlemail.com> On Wednesday 04 June 2008 18:57, Bernhard Fischer wrote: > On Mon, Jun 02, 2008 at 09:13:20AM -0700, dronnikov at gmail.com wrote: > >Hello, Bernhard! > [hey there. Replying on the ML, hope you don't mind] > > > >Please, tell me: do you test your code before you submit it? > > occasionally, yes ;P In this case i did, see below. :) :) :) For the record - I let you guys sort depmod out, don't want to interfere. -- vda From vda.linux at googlemail.com Wed Jun 4 18:02:39 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 03:02:39 +0200 Subject: ash/stty usage In-Reply-To: References: Message-ID: <200806050302.39621.vda.linux@googlemail.com> On Wednesday 04 June 2008 22:40, James Simmons wrote: > > Hi! > > I'm attempting color text but I'm getting "K[37;1mTextK[31;1m". Any > idea what is wrong? What do you do to get it? > Also I'm looking to flush the tty. Currently I'm doing > > eat_extra_keys() { > local saved=$(stty -g) > stty -icanon min 1 time 1 > cat -N > /dev/null // Modified cat to flush the and not block if no > stty $saved // data is present. > } > > Do you know of a better way? Don't know for sure, maybe this? int tcflush(int fd, int queue_selector); tcflush() discards data written to the object referred to by fd but not transmitted, or data received but not read, depending on the value of queue_selector: TCIFLUSH flushes data received but not read. TCOFLUSH flushes data written but not transmitted. TCIOFLUSH flushes both data received but not read, and data written but not transmitted. -- vda From vda.linux at googlemail.com Wed Jun 4 20:43:06 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 05:43:06 +0200 Subject: elf2flt questions In-Reply-To: <484734AC.7050903@t-online.de> References: <200806050213.17578.vda.linux@googlemail.com> <484734AC.7050903@t-online.de> Message-ID: <200806050543.06306.vda.linux@googlemail.com> On Thursday 05 June 2008 02:34, Bernd Schmidt wrote: > > elf binaries, it says "BINFMT_FLAT: bad magic/rev (0x1010100, need 0x5)". > > One thing I just remembered is that we used to have non-standard flat > files. Version 5 doesn't exist in any tools/kernels other than ancient > Blackfin distributions. Our tools were fixed long ago to generate > version 4 flat binaries. With a modern toolchain you can't actually > produce binaries that will run on the 2005 kernel you're using (never > mind that it's totally bug-infested anyway), so please upgrade that > first. There's a u-boot installed on your board, surely? Yes. U-Boot 1.1.6-svn1226 (ADI-2008R2-pre) (May 29 2008 - 15:54:06) CPU: ADSP bf537-0.2 (Detected Rev: 0.2) Board: ADI BF537 stamp board Support: http://blackfin.uclinux.org/ Clock: VCO: 500 MHz, Core: 500 MHz, System: 100 MHz RAM: 64 MB Flash: 4 MB In: serial Out: serial Err: serial Net: Blackfin EMAC MAC: 00:E0:22:FE:47:CC Hit any key to stop autoboot: 0 The board has one image: bfin> imls Image at 20100000: Image Name: uClinux Kernel Image Created: 2005-09-30 3:03:16 UTC Image Type: Blackfin Linux Kernel Image (gzip compressed) Data Size: 1429678 Bytes = 1.4 MB Load Address: 00001000 Entry Point: 00001000 Verifying Checksum ... OK From vda.linux at googlemail.com Wed Jun 4 21:18:24 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 06:18:24 +0200 Subject: "building toolchain" wiki In-Reply-To: <200806050545.02758.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <484734AC.7050903@t-online.de> <200806050545.02758.vda.linux@googlemail.com> Message-ID: <200806050618.24553.vda.linux@googlemail.com> On Thursday 05 June 2008 05:45, Denys Vlasenko wrote: > Let's try building toolchain from blackfin.uclinux.org. > > I got svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain/trunk. > > I made a copy of checked-out tree. > > I run BuildToolChain: > > # buildscript/BuildToolChain 2>&1 | tee err > Checking for development packages (skip checks with the -D option) > BusyBox v1.10.0 (2008-03-22 15:35:10 CET) multi-call binary > > Usage: mktemp [-dt] [-p DIR] TEMPLATE > > Create a temporary file with its name based on TEMPLATE. > TEMPLATE is any name with six 'Xs' (i.e., /tmp/temp.XXXXXX). > > Options: > -d Make a directory instead of a file > -t Generate a path rooted in temporary directory > -p DIR Use DIR as a temporary directory (implies -t) > > For -t or -p, directory is chosen as follows: > $TMPDIR if set, else -p DIR, else /tmp I went to this page: http://docs.blackfin.uclinux.org/doku.php?id=toolchain:buildscript It says the following. My comments are with ===>, they mark the questions I've got while reading the page which I had no answers for. Can it be updated? (I tried editing it, it seems to be locked for editing). There is a build script for the toolchain that builds and installs the toolchain from source.... To build from source, you need the source of the kernel and toolchain. The kernel source is required because we need the userspace kernel headers... If you need to build a svn toolchain, it is recommended to use a svn kernel source. Although, at first glance, it seems like the toolchain, bootloader, libraries, and kernel should be separate - that is not true... Because of these, and other issues, building a svn toolchain, and using a non-svn kernel uClibc is not supported/tested/validated. ===> Great, I want to download source of toolchain and kernel. ===> Where I can do it? URLs? Building takes awhile as it will be compiling binutils/gcc/uClibc multiple times over (once per target). For example to run the script a command similar to this must be issued: ./BuildToolChain -s /home/user/checkouts/gcc/ \ -k /home/user/checkouts/kernel/uClinux-dist/linux-2.6.x \ -u /home/user/checkouts/uboot/u-boot_1.1.3 \ -b /home/user/gcc-build/ -o /home/user/cvsoutput ===> I went to http://blackfin.uclinux.org/gf/project/toolchain/frs/ ===> and downloaded blackfin-toolchain-08r1-8.src.tar.gz ===> It has no ./BuildToolChain, only buildscript.tar.bz2 (among others) ===> with blackfin-toolchain-08r1/* (including BuildToolChain script) inside. ===> Should I unpack buildscript.tar.bz2? Or should I unpack all *.tar.bz2? ===> Should I copy BuildToolChain to the top directory ===> (as implied by ./BuildToolChain above) or I can run it ===> inside blackfin-toolchain-08r1 dir? -- vda From vda.linux at googlemail.com Thu Jun 5 01:10:53 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 10:10:53 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <4846DF24.601@gmail.com> References: <4846DF24.601@gmail.com> Message-ID: <200806051010.53125.vda.linux@googlemail.com> On Wednesday 04 June 2008 20:29, Natanael Copa wrote: > Hi, > > Attatched is a patch for the LOWER_UP flag in 'ip link/addr' output. > Useful to check if network cable is inserted or not. Does it match what "standard" ip shows? -- vda From vda.linux at googlemail.com Thu Jun 5 01:18:16 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 10:18:16 +0200 Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <0806032202570.16214@somehost> References: <0806032202570.16214@somehost> Message-ID: <200806051018.16958.vda.linux@googlemail.com> On Tuesday 03 June 2008 22:06, Cristian Ionescu-Idbohrn wrote: > When using gdb, one would expect to have the source compiled with '-g -O0', > and not '-g -Os'. There were people who disagree (they say "debug what you ship"). I see only one way to leave BOTH camps happy. Create a CONFIG_DEBUG0 option (dependent on CONFIG_DEBUG) which forces -O0 build. Otherwise, -Os would be used. Can you do this? -- vda From vda.linux at googlemail.com Thu Jun 5 01:23:54 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 10:23:54 +0200 Subject: would you be interested of a sketchy testsuite/printf.tests In-Reply-To: <0806040026430.16214@somehost> References: <0806040026430.16214@somehost> Message-ID: <200806051023.54944.vda.linux@googlemail.com> On Wednesday 04 June 2008 00:28, Cristian Ionescu-Idbohrn wrote: > Attached. Applied, thanks. From nicolas.dichtel at dev.6wind.com Thu Jun 5 02:07:37 2008 From: nicolas.dichtel at dev.6wind.com (Nicolas Dichtel) Date: Thu, 05 Jun 2008 11:07:37 +0200 Subject: Console problem In-Reply-To: <200806050246.32550.vda.linux@googlemail.com> References: <4846C824.4060501@dev.6wind.com> <200806050246.32550.vda.linux@googlemail.com> Message-ID: <4847ACD9.9040100@dev.6wind.com> Le 05.06.2008 02:46, Denys Vlasenko a ?crit : > On Wednesday 04 June 2008 18:51, Nicolas Dichtel wrote: >> Hi all, >> >> I was using busybox-1.01 for a long time and recently I've switched to >> busybox-1.10.2. On x86, there is no problem, but on MIPS architecture, >> the console does not work properly: need to type second character to make >> the first appear. > > Please give more details. You need to type every char twice or what? No, when I type a char, the previous one is displayed (and not the current). Here is an example: # I type '1': # I type '2': #1 I type '3': #12 I type return: #123 This problem appears before the login and after the login. > What program is receiving your keypresses? getty? shell? How exactly Before the login, it's getty and after it's bash (version 2.05.0). Started with /etc/inittab (sh is a link to bash): root at minos:~# cat /etc/inittab ::sysinit:/bin/sh /etc/rc ::respawn:/sbin/getty -L 38400 ttyS0 vt100 ::shutdown:/bin/sh /etc/rc.shutdown > do you start it (command line, etc)? Can you show ls -l /proc/$PID/fd > of this program and also ls -l /proc/1/fd? With the old busybox (after login on console): root at minos:~# ls -l /proc/318/fd/ lrwx------ 1 root root 64 Jan 1 00:00 0 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:08 1 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:00 2 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:08 255 -> /dev/ttyS0 root at minos:~# ls -l /proc/1/fd/ root at minos:~# With the new busybox: - getty (before login on console): root 325 0.0 0.0 3584 644 ttyS0 Ss+ 00:00 0:00 /sbin/getty -L 38400 ttyS0 vt100 root at minos:~# ls -l /proc/325/fd/ lrwx------ 1 root root 64 Jan 1 00:02 0 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:02 1 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:01 2 -> /dev/ttyS0 - bash (after login on console): root 325 0.0 0.0 4596 1356 ttyS0 Ss+ 00:00 0:00 -sh root at minos:~# ls -l /proc/325/fd lrwx------ 1 root root 64 Jan 1 00:02 0 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:02 1 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:01 2 -> /dev/ttyS0 lrwx------ 1 root root 64 Jan 1 00:06 255 -> /dev/ttyS0 - init: root at minos:~# ls -l /proc/1/fd/ lrwx------ 1 root root 64 Jan 1 00:07 0 -> /dev/console lrwx------ 1 root root 64 Jan 1 00:07 1 -> /dev/console lrwx------ 1 root root 64 Jan 1 00:07 2 -> /dev/console > > Do you have any console=XXX or CONSOLE=XXX params on kernel command line? Kernel command line: console=ttyS0,38400 rdinit=/sbin/init > >> If I apply this patch: >> >> --- busybox/init/init.c 2008-04-17 11:13:25.000000000 +0200 >> +++ busybox-new/init/init.c 2008-05-20 16:47:00.000000000 +0200 >> @@ -873,6 +873,9 @@ int init_main(int argc ATTRIBUTE_UNUSED, >> >> /* Figure out where the default console should be */ >> console_init(); >> + close(0); >> + close(1); >> + close(2); >> set_sane_term(); >> chdir("/"); >> setsid(); >> >> the problem is solved. Of course, some log messages are hidden with this patch. >> I didn't find a better way to fix that problem. Any ideas ? > > Sorry, but I don't like it. Not only you deprive all future children > from knowing what console is, you risk starting them with > stdio CLOSED - which is very bad, a lot of programs have bugs > where they overwrite random files if they are run with stdio closed. Sure that this patch is only a temporary work around ... Thank you, Nicolas From vapier at gentoo.org Thu Jun 5 02:10:13 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 05:10:13 -0400 Subject: elf2flt questions In-Reply-To: <200806050543.06306.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <484734AC.7050903@t-online.de> <200806050543.06306.vda.linux@googlemail.com> Message-ID: <200806050510.14665.vapier@gentoo.org> On Wednesday 04 June 2008, Denys Vlasenko wrote: > On Thursday 05 June 2008 02:34, Bernd Schmidt wrote: > > > elf binaries, it says "BINFMT_FLAT: bad magic/rev (0x1010100, need > > > 0x5)". > > > > One thing I just remembered is that we used to have non-standard flat > > files. Version 5 doesn't exist in any tools/kernels other than ancient > > Blackfin distributions. Our tools were fixed long ago to generate > > version 4 flat binaries. With a modern toolchain you can't actually > > produce binaries that will run on the 2005 kernel you're using (never > > mind that it's totally bug-infested anyway), so please upgrade that > > first. There's a u-boot installed on your board, surely? > > U-Boot 1.1.6-svn1226 (ADI-2008R2-pre) (May 29 2008 - 15:54:06) livin on the edge :) > bfin> imls > Image at 20100000: > Image Name: uClinux Kernel Image > Created: 2005-09-30 3:03:16 UTC yeah that's old. you can grab newer uImage's from the blackfin.uclinux.org website. those of course are just the default builds. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080605/94b9d386/attachment.pgp From vapier at gentoo.org Thu Jun 5 02:11:51 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 05:11:51 -0400 Subject: elf2flt questions In-Reply-To: <200806050238.00646.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806050238.00646.vda.linux@googlemail.com> Message-ID: <200806050511.52232.vapier@gentoo.org> On Wednesday 04 June 2008, Denys Vlasenko wrote: > On Thursday 05 June 2008 02:13, Denys Vlasenko wrote: > > Can you write up a small explanation what elf2flt does, how to produce > > a flat executable with it? Let's say in my situation - I seem to have > > correctly built static elf bfin busybox, can I make a flat one out of it? > > Straightforward approach suggested by "elf2flt --help" doesn't work: well you really arent supposed to invoke elf2flt directly. just run your toolchain like normal but specify "-elf2flt" when doing the linking step. the wrapper script will take care of the rest. it really isnt worth knowing how to invoke elf2flt directly. honestly, such knowledge is completely useless. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080605/866f7fbb/attachment.pgp From vapier at gentoo.org Thu Jun 5 02:17:54 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 05:17:54 -0400 Subject: "building toolchain" wiki In-Reply-To: <200806050618.24553.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <200806050545.02758.vda.linux@googlemail.com> <200806050618.24553.vda.linux@googlemail.com> Message-ID: <200806050517.55924.vapier@gentoo.org> On Thursday 05 June 2008, Denys Vlasenko wrote: > http://docs.blackfin.uclinux.org/doku.php?id=toolchain:buildscript > > It says the following. My comments are with ===>, they mark > the questions I've got while reading the page which I had no answers for. > Can it be updated? (I tried editing it, it seems to be locked for editing). the wiki at docs.b.u.o only allows writing to people who ask and are granted permission. that keeps the spammers at bay, keeps the less knowledgeable from entering incorrect info, and allows us to make sure copyright/licensing is in our domain. > ===> Great, I want to download source of toolchain and kernel. > ===> Where I can do it? URLs? the wiki operates with the implicit knowledge that all of the source code lives on blackfin.u.o. when you visit that site, the frontpage has links to all the places. but i'll toss in links at the top. > ===> I went to http://blackfin.uclinux.org/gf/project/toolchain/frs/ > ===> and downloaded blackfin-toolchain-08r1-8.src.tar.gz > ===> It has no ./BuildToolChain, only buildscript.tar.bz2 (among others) > ===> with blackfin-toolchain-08r1/* (including BuildToolChain script) > inside. ===> Should I unpack buildscript.tar.bz2? Or should I unpack all > *.tar.bz2? ===> Should I copy BuildToolChain to the top directory > ===> (as implied by ./BuildToolChain above) or I can run it > ===> inside blackfin-toolchain-08r1 dir? the src tarball is a little out of tune with how things are organized in svn. i blame bernd ;). you'll probably have to unpack all the archives and take it from there. generally people dont actually build the src tarball from a release because the binaries already exist. they do however frequently build from svn ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080605/e4be8406/attachment-0001.pgp From wharms at bfs.de Thu Jun 5 02:37:51 2008 From: wharms at bfs.de (walter harms) Date: Thu, 05 Jun 2008 11:37:51 +0200 Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <200806051018.16958.vda.linux@googlemail.com> References: <0806032202570.16214@somehost> <200806051018.16958.vda.linux@googlemail.com> Message-ID: <4847B3EF.90909@bfs.de> Denys Vlasenko wrote: > On Tuesday 03 June 2008 22:06, Cristian Ionescu-Idbohrn wrote: >> When using gdb, one would expect to have the source compiled with '-g -O0', >> and not '-g -Os'. > > There were people who disagree (they say "debug what you ship"). > I see only one way to leave BOTH camps happy. Create a CONFIG_DEBUG0 > option (dependent on CONFIG_DEBUG) which forces -O0 build. > Otherwise, -Os would be used. > > Can you do this? > -- hi vda, hi all, -Os specially, does not make sense with -g since i what to save space what i am adding with debugsymbols again. -O0 disables optimisation this is the default. IMHO debugging optimised code is only useful when using the asm-level since even the function i try to debug may not exist any more (inline). The normal case for me is that i want to debug code using tools like gdb at C-level that is only useful (possible) when i disable optimisation. I guess that is the case for most people. And if your code works only correct when -g is enabled you are in even deeper trouble. (no comment). To make everyone happy is hard, but i would insist that the DEBUG option should enable all debug options and disable all optimisation to make things easy as possible. To make others happy we can add a CUSTOM_CFLAGS where people may add there personal preferred CFLAGS (e.g. -g) for the final binary. This could also take same fancy option that do not went into the mainline. re, wh From cristian.ionescu-idbohrn at axis.com Thu Jun 5 03:09:51 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 5 Jun 2008 12:09:51 +0200 (CEST) Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <200806051018.16958.vda.linux@googlemail.com> References: <0806032202570.16214@somehost> <200806051018.16958.vda.linux@googlemail.com> Message-ID: <0806051209180.6722@somehost> On Thu, 5 Jun 2008, Denys Vlasenko wrote: > On Tuesday 03 June 2008 22:06, Cristian Ionescu-Idbohrn wrote: > > When using gdb, one would expect to have the source compiled with '-g -O0', > > and not '-g -Os'. > > There were people who disagree (they say "debug what you ship"). > I see only one way to leave BOTH camps happy. Create a CONFIG_DEBUG0 > option (dependent on CONFIG_DEBUG) which forces -O0 build. > Otherwise, -Os would be used. > > Can you do this? I'll have a look at it. Cheers, -- Cristian From natanael.copa at gmail.com Thu Jun 5 04:04:54 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 05 Jun 2008 13:04:54 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <200806051010.53125.vda.linux@googlemail.com> References: <4846DF24.601@gmail.com> <200806051010.53125.vda.linux@googlemail.com> Message-ID: <1212663894.6022.17.camel@nc.nor.wtbts.org> On Thu, 2008-06-05 at 10:10 +0200, Denys Vlasenko wrote: > On Wednesday 04 June 2008 20:29, Natanael Copa wrote: > > Hi, > > > > Attatched is a patch for the LOWER_UP flag in 'ip link/addr' output. > > Useful to check if network cable is inserted or not. > > Does it match what "standard" ip shows? yes. perfect match. -nc From natanael.copa at gmail.com Thu Jun 5 04:52:57 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 05 Jun 2008 13:52:57 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <20080604200637.GF27768@mx.loc> References: <4846DF24.601@gmail.com> <20080604200637.GF27768@mx.loc> Message-ID: <1212666777.6022.27.camel@nc.nor.wtbts.org> On Wed, 2008-06-04 at 22:06 +0200, Bernhard Fischer wrote: > On Wed, Jun 04, 2008 at 08:29:56PM +0200, Natanael Copa wrote: > > Hi, > > > > Attatched is a patch for the LOWER_UP flag in 'ip link/addr' output. > > Useful to check if network cable is inserted or not. > > > > The code does an ugly ifdef to check if IFF_LOWER_UP is declared or not. > > On my zenwalk desktop it was not. It looks like iproute2 maintain their > > own copies of the linux headers so I suppose we cannot expect the flag > > be there. (should mabe be in one of the include files rather than in the > > .c file?) > > > > The patch does increase the size a bit due to a macro. Maybe should have > > a config option for it? > > no config, no. > > I was about to apply it but looking at the macro i'd be curious if we > have more occurances of the > if (foo & flag) > emit(#flag) > pattern so we should provide something like the reversed form of > index_in_strings() like string_in_index(int state) that emits the > corresponding string? maybe string_in_mask()/string_in_flags()? > Could you try that and convert some users to that scheme? I'd be > surprised if this would not be an overall win. ?I think that we maybe want something like this: struct mask_string { int mask; const char *string; } void print_flags(struct mask_string* ms, int flags, const char *separator) { int need_separator = 0; while (ms) { if (flags, ms->mask) { printf("%s%s", need_separator ? separator : "", ms->string) need_separator = 1; } ms++; } } I checked and atleast the following files would benefit from something like that: ./miscutils/hdparm.c:1231: if (id->eide_pio_modes & 1) printf("pio3 "); ... ./networking/arp.c:336: if (arp_flags & ATF_PERM) ./networking/arp.c:337: printf("PERM "); ./networking/arp.c:338: if (arp_flags & ATF_PUBL) ./networking/arp.c:339: printf("PUP "); ... ./util-linux/fdisk_osf.c:517: if (lp->d_flags & BSD_D_REMOVABLE) ./util-linux/fdisk_osf.c:518: printf(" removable"); ./util-linux/fdisk_osf.c:519: if (lp->d_flags & BSD_D_ECC) ./util-linux/fdisk_osf.c:520: printf(" ecc"); ... -nc From jacmet at uclibc.org Thu Jun 5 04:53:18 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Thu, 5 Jun 2008 13:53:18 +0200 Subject: [PATCH] dpkg: don't error out on missing conffiles In-Reply-To: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> References: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> Message-ID: <1212666798-13110-2-git-send-email-jacmet@uclibc.org> From: Peter Korsgaard The conffiles control file isn't required in Debian packages, so don't error out if it's missing. --- archival/dpkg.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/archival/dpkg.c b/archival/dpkg.c index 5bc64d5..85b3df2 100644 --- a/archival/dpkg.c +++ b/archival/dpkg.c @@ -1335,8 +1335,8 @@ static void remove_package(const unsigned package_num, int noisy) free_array(remove_files); free_array(exclude_files); - /* rename .conffile to .list */ - xrename(conffile_name, list_name); + /* rename .conffiles to .list */ + rename(conffile_name, list_name); /* Change package status */ set_status(status_num, "config-files", 3); -- 1.5.5.1 From jacmet at uclibc.org Thu Jun 5 04:53:17 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Thu, 5 Jun 2008 13:53:17 +0200 Subject: [PATCH] dpkg: create_list: zero terminate list in loop Message-ID: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> From: Peter Korsgaard Saves a few bytes: function old new delta create_list 124 103 -21 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-21) Total: -21 bytes --- archival/dpkg.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/archival/dpkg.c b/archival/dpkg.c index 1280ca0..5bc64d5 100644 --- a/archival/dpkg.c +++ b/archival/dpkg.c @@ -1164,15 +1164,11 @@ static char **create_list(const char *filename) while ((line = xmalloc_fgetline(list_stream)) != NULL) { file_list = xrealloc(file_list, sizeof(char *) * (count + 2)); - file_list[count] = line; - count++; + file_list[count++] = line; + file_list[count] = NULL; } fclose(list_stream); - if (count == 0) { - return NULL; - } - file_list[count] = NULL; return file_list; } -- 1.5.5.1 From rep.dot.nop at gmail.com Thu Jun 5 05:14:57 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 5 Jun 2008 14:14:57 +0200 Subject: [PATCH] dpkg: create_list: zero terminate list in loop In-Reply-To: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> References: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> Message-ID: <20080605121457.GB5252@mx.loc> On Thu, Jun 05, 2008 at 01:53:17PM +0200, Peter Korsgaard wrote: >From: Peter Korsgaard > >Saves a few bytes: > >function old new delta >create_list 124 103 -21 >------------------------------------------------------------------------------ >(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-21) Total: -21 bytes >--- > archival/dpkg.c | 8 ++------ > 1 files changed, 2 insertions(+), 6 deletions(-) > >diff --git a/archival/dpkg.c b/archival/dpkg.c >index 1280ca0..5bc64d5 100644 >--- a/archival/dpkg.c >+++ b/archival/dpkg.c >@@ -1164,15 +1164,11 @@ static char **create_list(const char *filename) > > while ((line = xmalloc_fgetline(list_stream)) != NULL) { > file_list = xrealloc(file_list, sizeof(char *) * (count + 2)); >- file_list[count] = line; >- count++; >+ file_list[count++] = line; >+ file_list[count] = NULL; > } > fclose(list_stream); Only seeing these lines i wonder if create_list() shouldn't really just be replaced by xmalloc_xopen_read_close() ? > >- if (count == 0) { >- return NULL; >- } >- file_list[count] = NULL; > return file_list; > } From rep.dot.nop at gmail.com Thu Jun 5 05:18:57 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 5 Jun 2008 14:18:57 +0200 Subject: [PATCH] dpkg: don't error out on missing conffiles In-Reply-To: <1212666798-13110-2-git-send-email-jacmet@uclibc.org> References: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> <1212666798-13110-2-git-send-email-jacmet@uclibc.org> Message-ID: <20080605121857.GC5252@mx.loc> On Thu, Jun 05, 2008 at 01:53:18PM +0200, Peter Korsgaard wrote: >From: Peter Korsgaard > >The conffiles control file isn't required in Debian packages, so don't >error out if it's missing. Applied with the comment extended accordingly. Thanks From vda.linux at googlemail.com Thu Jun 5 06:58:04 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 15:58:04 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <4846DF24.601@gmail.com> References: <4846DF24.601@gmail.com> Message-ID: <200806051558.04794.vda.linux@googlemail.com> On Wednesday 04 June 2008 20:29, Natanael Copa wrote: > Hi, > > Attatched is a patch for the LOWER_UP flag in 'ip link/addr' output. > Useful to check if network cable is inserted or not. > > The code does an ugly ifdef to check if IFF_LOWER_UP is declared or not. > On my zenwalk desktop it was not. It looks like iproute2 maintain their > own copies of the linux headers so I suppose we cannot expect the flag > be there. (should mabe be in one of the include files rather than in the > .c file?) > > The patch does increase the size a bit due to a macro. Maybe should have > a config option for it? > > on my hardened uclibc i386 build: > > function old new delta > ipaddr_list_or_flush 2929 2981 +52 > .rodata 7677 7683 +6 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 2/0 up/down: 58/0) Total: 58 > bytes > text data bss dec hex filename > 47498 670 4244 52412 ccbc busybox_old > 47556 670 4244 52470 ccf6 busybox_unstripped Applied, thanks. (It also brought my attention to ~300+ bytes of bloat nearby, which I removed). -- vda From vda.linux at googlemail.com Thu Jun 5 07:30:45 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 16:30:45 +0200 Subject: elf2flt questions In-Reply-To: <4847D968.5070108@t-online.de> References: <200806050213.17578.vda.linux@googlemail.com> <200806050238.00646.vda.linux@googlemail.com> <4847D968.5070108@t-online.de> Message-ID: <200806051630.45413.vda.linux@googlemail.com> On Thursday 05 June 2008 14:17, Bernd Schmidt wrote: > Denys Vlasenko wrote: > > > busybox_unstripped: file format elf32-bfinfdpic > > Noticed this... Trying to use an FDPIC toolchain with elf2flt will > produce interesting results. Will this fare better? bfin-uclinux-objdump -xdr busybox_unstripped busybox_unstripped: file format elf32-bfin busybox_unstripped architecture: bfin, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x00000014 Program Header: LOAD off 0x00001000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x000b2634 memsz 0x000b2634 flags r-x LOAD off 0x000b3634 vaddr 0x000b3634 paddr 0x000b3634 align 2**12 filesz 0x000003c0 memsz 0x00001bac flags rw- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rwx private flags = 0: ... Now I'll look into how to make bbox use correct options to ld in order to produce flat binary... -- vda From vapier at gentoo.org Thu Jun 5 07:39:16 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 5 Jun 2008 10:39:16 -0400 Subject: elf2flt questions In-Reply-To: <200806051630.45413.vda.linux@googlemail.com> References: <200806050213.17578.vda.linux@googlemail.com> <4847D968.5070108@t-online.de> <200806051630.45413.vda.linux@googlemail.com> Message-ID: <200806051039.17743.vapier@gentoo.org> On Thursday 05 June 2008, Denys Vlasenko wrote: > On Thursday 05 June 2008 14:17, Bernd Schmidt wrote: > > Denys Vlasenko wrote: > > > busybox_unstripped: file format elf32-bfinfdpic > > > > Noticed this... Trying to use an FDPIC toolchain with elf2flt will > > produce interesting results. > > Will this fare better? > > bfin-uclinux-objdump -xdr busybox_unstripped > > busybox_unstripped: file format elf32-bfin yes. bfin-uclinux is for FLAT, not any other toolchain. > Now I'll look into how to make bbox use correct options to ld in order > to produce flat binary... it already works today. just put -elf2flt into LDFLAGS. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080605/584a5618/attachment.pgp From natanael.copa at gmail.com Thu Jun 5 07:54:44 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 05 Jun 2008 16:54:44 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <200806051558.04794.vda.linux@googlemail.com> References: <4846DF24.601@gmail.com> <200806051558.04794.vda.linux@googlemail.com> Message-ID: <1212677684.6022.33.camel@nc.nor.wtbts.org> On Thu, 2008-06-05 at 15:58 +0200, Denys Vlasenko wrote: > On Wednesday 04 June 2008 20:29, Natanael Copa wrote: > > Hi, > > > > Attatched is a patch for the LOWER_UP flag in 'ip link/addr' output. > > Useful to check if network cable is inserted or not. > > > > The code does an ugly ifdef to check if IFF_LOWER_UP is declared or not. > > On my zenwalk desktop it was not. It looks like iproute2 maintain their > > own copies of the linux headers so I suppose we cannot expect the flag > > be there. (should mabe be in one of the include files rather than in the > > .c file?) > > > > The patch does increase the size a bit due to a macro. Maybe should have > > a config option for it? > > > > on my hardened uclibc i386 build: > > > > function old new delta > > ipaddr_list_or_flush 2929 2981 +52 > > .rodata 7677 7683 +6 > > ------------------------------------------------------------------------------ > > (add/remove: 0/0 grow/shrink: 2/0 up/down: 58/0) Total: 58 > > bytes > > text data bss dec hex filename > > 47498 670 4244 52412 ccbc busybox_old > > 47556 670 4244 52470 ccf6 busybox_unstripped > > Applied, thanks. (It also brought my attention to ~300+ bytes > of bloat nearby, which I removed). oh.... I guess we were working on the same thing then. I'm attatching what I was looking at. I guess it does not apply anymore. # make bloatcheck function old new delta hdparm_main 1067 4916 +3849 print_flags - 135 +135 static.ultra_modes2 - 88 +88 static.dma_mword_modes - 72 +72 static.dma_1word_modes - 72 +72 static.ms - 64 +64 static.ultra_modes1 - 56 +56 static.pm - 32 +32 static.pio_modes - 32 +32 static.dflags - 32 +32 .rodata 31778 31768 -10 xbsd_print_disklabel 927 892 -35 arp_main 2474 2439 -35 ipaddr_list_or_flush 2687 2455 -232 process_dev 4446 - -4446 ------------------------------------------------------------------------------ (add/remove: 9/1 grow/shrink: 1/4 up/down: 4432/-4758) Total: -326 bytes text data bss dec hex filename 135105 2173 4500 141778 229d2 busybox_old 134715 2709 4500 141924 22a64 busybox_unstripped > -- > vda -nc -------------- next part -------------- A non-text attachment was scrubbed... Name: libbb-print_flags.patch Type: text/x-patch Size: 9103 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080605/5d48bebb/attachment.bin From vda.linux at googlemail.com Thu Jun 5 07:56:28 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 16:56:28 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <1212677684.6022.33.camel@nc.nor.wtbts.org> References: <4846DF24.601@gmail.com> <200806051558.04794.vda.linux@googlemail.com> <1212677684.6022.33.camel@nc.nor.wtbts.org> Message-ID: <200806051656.28378.vda.linux@googlemail.com> On Thursday 05 June 2008 16:54, Natanael Copa wrote: > > Applied, thanks. (It also brought my attention to ~300+ bytes > > of bloat nearby, which I removed). > > oh.... I guess we were working on the same thing then. > > I'm attatching what I was looking at. I guess it does not apply anymore. Not at all, I just removed some useless dances with fprintf(fp, ...) which were invariably printing to stdout. You are working on something different, so please continue :) -- vda From natanael.copa at gmail.com Thu Jun 5 08:07:34 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 05 Jun 2008 17:07:34 +0200 Subject: [PATCH] Support for the LOWER_UP flag In-Reply-To: <200806051656.28378.vda.linux@googlemail.com> References: <4846DF24.601@gmail.com> <200806051558.04794.vda.linux@googlemail.com> <1212677684.6022.33.camel@nc.nor.wtbts.org> <200806051656.28378.vda.linux@googlemail.com> Message-ID: <1212678454.6022.40.camel@nc.nor.wtbts.org> On Thu, 2008-06-05 at 16:56 +0200, Denys Vlasenko wrote: > On Thursday 05 June 2008 16:54, Natanael Copa wrote: > > > Applied, thanks. (It also brought my attention to ~300+ bytes > > > of bloat nearby, which I removed). > > > > oh.... I guess we were working on the same thing then. > > > > I'm attatching what I was looking at. I guess it does not apply anymore. > > Not at all, I just removed some useless dances with fprintf(fp, ...) > which were invariably printing to stdout. You are working on something > different, so please continue :) I'm done with it more or less (and my day is over). I think the patch i posted in previous email need testing though. It touches (too?) many places. basicly it replaces: if (flags & mask) printf("FLAG "); with a "mask_string" struct (better name anyone?) and print_flags() func: flag_struc = { { mask, "FLAG" }, { 0, NULL } }; ... print_flags(flag_struc, flags, " "); ... There seems to be a drawback on places where the mask and flags is a byte rahter than int. But it reduces text as showed in the previous posted 'make bloatcheck'. Please have a look at it. Thanks! > -- > vda From e.robertson.svg at gmail.com Thu Jun 5 08:08:34 2008 From: e.robertson.svg at gmail.com (E Robertson) Date: Thu, 5 Jun 2008 10:08:34 -0500 Subject: tar: short read problem in release 1.10.2 Message-ID: <3972542e0806050808k1b0c4fb0l6b8a7b3aa642681d@mail.gmail.com> Hi All, I did a search on the "tar: short read" error and notice it was reported several times and fixed but it looks like it's broken again. I have a U-boot binary image in an archive file and tried to extract it using the following command: #tar -xz -C /tmp -f /tmp/usbstick/IMG_ARCHIVE.gz ./upgrade/uboot.img tar: short read # echo $? 1 However, the uboot.img has not been extracted. I repeated this several times with the same result. I did the same thing on my kernel image and although this was extracted, the size of the extracted image is less than half the original size. Is this a bug? If not, Is their a solution for this? Thanks. From rpjday at crashcourse.ca Thu Jun 5 04:56:48 2008 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Thu, 5 Jun 2008 07:56:48 -0400 (EDT) Subject: [PATCH] dpkg: create_list: zero terminate list in loop In-Reply-To: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> References: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> Message-ID: On Thu, 5 Jun 2008, Peter Korsgaard wrote: > From: Peter Korsgaard > > Saves a few bytes: > > function old new delta > create_list 124 103 -21 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-21) Total: -21 bytes > --- > archival/dpkg.c | 8 ++------ > 1 files changed, 2 insertions(+), 6 deletions(-) > > diff --git a/archival/dpkg.c b/archival/dpkg.c > index 1280ca0..5bc64d5 100644 > --- a/archival/dpkg.c > +++ b/archival/dpkg.c > @@ -1164,15 +1164,11 @@ static char **create_list(const char *filename) > > while ((line = xmalloc_fgetline(list_stream)) != NULL) { > file_list = xrealloc(file_list, sizeof(char *) * (count + 2)); > - file_list[count] = line; > - count++; > + file_list[count++] = line; > + file_list[count] = NULL; > } > fclose(list_stream); > > - if (count == 0) { > - return NULL; > - } > - file_list[count] = NULL; > return file_list; > } you know, even though that saves a few bytes, i'd be tempted not to do it that way since it's just plain inefficient in terms of machine cycles -- constantly assigning NULL only to overwrite it during the next iteration. IMHO, not worth the saved bytes to torture the logic that way. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== From vda.linux at googlemail.com Thu Jun 5 08:56:13 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 17:56:13 +0200 Subject: tar: short read problem in release 1.10.2 In-Reply-To: <3972542e0806050808k1b0c4fb0l6b8a7b3aa642681d@mail.gmail.com> References: <3972542e0806050808k1b0c4fb0l6b8a7b3aa642681d@mail.gmail.com> Message-ID: <200806051756.13130.vda.linux@googlemail.com> On Thursday 05 June 2008 17:08, E Robertson wrote: > Hi All, > I did a search on the "tar: short read" error and notice it was > reported several times and fixed but it looks like it's broken again. > I have a U-boot binary image in an archive file and tried to extract > it using the following command: > > #tar -xz -C /tmp -f /tmp/usbstick/IMG_ARCHIVE.gz ./upgrade/uboot.img > tar: short read From the name of it it doesn't seem to be a tar file at all. Can you show "gunzip # echo $? > 1 > > However, the uboot.img has not been extracted. I repeated this several > times with the same result. > I did the same thing on my kernel image and although this was > extracted, the size of the extracted image is less than half the > original size. > > Is this a bug? If not, Is their a solution for this? So far there is insufficient data to know what is it. -- vda From e.robertson.svg at gmail.com Thu Jun 5 09:10:27 2008 From: e.robertson.svg at gmail.com (E Robertson) Date: Thu, 5 Jun 2008 11:10:27 -0500 Subject: tar: short read problem in release 1.10.2 In-Reply-To: <200806051756.13130.vda.linux@googlemail.com> References: <3972542e0806050808k1b0c4fb0l6b8a7b3aa642681d@mail.gmail.com> <200806051756.13130.vda.linux@googlemail.com> Message-ID: <3972542e0806050910k4726e37al4de4d5c5b58d130a@mail.gmail.com> On Thu, Jun 5, 2008 at 10:56 AM, Denys Vlasenko wrote: > On Thursday 05 June 2008 17:08, E Robertson wrote: >> Hi All, >> I did a search on the "tar: short read" error and notice it was >> reported several times and fixed but it looks like it's broken again. >> I have a U-boot binary image in an archive file and tried to extract >> it using the following command: >> >> #tar -xz -C /tmp -f /tmp/usbstick/IMG_ARCHIVE.gz ./upgrade/uboot.img >> tar: short read > > From the name of it it doesn't seem to be a tar file at all. > Can you show "gunzip >> # echo $? >> 1 >> >> However, the uboot.img has not been extracted. I repeated this several >> times with the same result. >> I did the same thing on my kernel image and although this was >> extracted, the size of the extracted image is less than half the >> original size. >> >> Is this a bug? If not, Is their a solution for this? > > So far there is insufficient data to know what is it. I went back and tried some different formats. I see then if I use --format=gnu or oldgnu it works fine. I'm not too familiar with the different formats but that did the trick. My current tar on the host is version 1.19. Does that make sense? I'll add the header anyway (no format specified -- still trying to find out which is the default): 00000000 2e 2f 75 70 67 72 61 64 65 2f 00 00 00 00 00 00 |./images/......| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 30 30 30 30 37 35 35 00 30 30 30 30 |....0000755.0000| 00000070 30 30 30 00 30 30 30 30 30 30 30 00 30 30 30 30 |000.0000000.0000| 00000080 30 30 30 30 30 30 30 00 31 30 37 34 30 34 35 34 |0000000.10740454| 00000090 34 30 34 00 30 31 31 33 34 32 00 20 35 00 00 00 |404.011342. 5...| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000100 00 75 73 74 61 72 20 20 00 72 6f 6f 74 00 00 00 |.ustar .root...| 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000120 00 00 00 00 00 00 00 00 00 72 6f 6f 74 00 00 00 |.........root...| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000200 2e 2f 75 70 67 72 61 64 65 2f 64 65 76 2f 00 00 |./images/dev/..| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000260 00 00 00 00 30 30 30 30 37 35 35 00 30 30 30 30 |....0000755.0000| 00000270 30 30 30 00 30 30 30 30 30 30 30 00 30 30 30 30 |000.0000000.0000| 00000280 30 30 30 30 30 30 30 00 31 30 37 34 30 34 35 32 |0000000.10740452| 00000290 35 34 30 00 30 31 32 31 31 37 00 20 35 00 00 00 |540.012117. 5...| 000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000300 00 75 73 74 61 72 20 20 00 72 6f 6f 74 00 00 00 |.ustar .root...| 00000310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000320 00 00 00 00 00 00 00 00 00 72 6f 6f 74 00 00 00 |.........root...| 00000330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000400 2e 2f 75 70 67 72 61 64 65 2f 64 65 76 2f 63 6f |./images/dev/co| 00000410 6e 73 6f 6c 65 00 00 00 00 00 00 00 00 00 00 00 |nsole...........| 00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000460 00 00 00 00 30 30 30 30 36 30 30 00 30 30 30 30 |....0000600.0000| 00000470 30 30 30 00 30 30 30 30 30 30 30 00 30 30 30 30 |000.0000000.0000| 00000480 30 30 30 30 30 30 30 00 31 30 32 30 32 32 30 31 |0000000.10202201| 00000490 37 37 30 00 30 31 34 37 32 31 00 20 33 00 00 00 |770.014721. 3...| 000004a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... From vda.linux at googlemail.com Thu Jun 5 09:18:45 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 5 Jun 2008 18:18:45 +0200 Subject: tar: short read problem in release 1.10.2 In-Reply-To: <3972542e0806050910k4726e37al4de4d5c5b58d130a@mail.gmail.com> References: <3972542e0806050808k1b0c4fb0l6b8a7b3aa642681d@mail.gmail.com> <200806051756.13130.vda.linux@googlemail.com> <3972542e0806050910k4726e37al4de4d5c5b58d130a@mail.gmail.com> Message-ID: <200806051818.45614.vda.linux@googlemail.com> On Thursday 05 June 2008 18:10, E Robertson wrote: > On Thu, Jun 5, 2008 at 10:56 AM, Denys Vlasenko > wrote: > > On Thursday 05 June 2008 17:08, E Robertson wrote: > >> Hi All, > >> I did a search on the "tar: short read" error and notice it was > >> reported several times and fixed but it looks like it's broken again. > >> I have a U-boot binary image in an archive file and tried to extract > >> it using the following command: > >> > >> #tar -xz -C /tmp -f /tmp/usbstick/IMG_ARCHIVE.gz ./upgrade/uboot.img > >> tar: short read > > > > From the name of it it doesn't seem to be a tar file at all. > > Can you show "gunzip > > >> # echo $? > >> 1 > >> > >> However, the uboot.img has not been extracted. I repeated this several > >> times with the same result. > >> I did the same thing on my kernel image and although this was > >> extracted, the size of the extracted image is less than half the > >> original size. > >> > >> Is this a bug? If not, Is their a solution for this? > > > > So far there is insufficient data to know what is it. > > I went back and tried some different formats. I see then if I use > --format=gnu or oldgnu it works fine. > I'm not too familiar with the different formats but that did the > trick. My current tar on the host is version 1.19. > Does that make sense? > > I'll add the header anyway (no format specified -- still trying to > find out which is the default): > > 00000000 2e 2f 75 70 67 72 61 64 65 2f 00 00 00 00 00 00 |./images/......| Hex dump corresponds to "./upgrade/", not "./images/" It's very strange that you hack your own bug report. What's going on? Can you send some small tar file (<30kb compressed) which is not unpacking properly? Or upload it somewhere? -- vda From e.robertson.svg at gmail.com Thu Jun 5 09:27:22 2008 From: e.robertson.svg at gmail.com (E Robertson) Date: Thu, 5 Jun 2008 11:27:22 -0500 Subject: tar: short read problem in release 1.10.2 In-Reply-To: <200806051818.45614.vda.linux@googlemail.com> References: <3972542e0806050808k1b0c4fb0l6b8a7b3aa642681d@mail.gmail.com> <200806051756.13130.vda.linux@googlemail.com> <3972542e0806050910k4726e37al4de4d5c5b58d130a@mail.gmail.com> <200806051818.45614.vda.linux@googlemail.com> Message-ID: <3972542e0806050927j2394a421hcc5b35e5fd82896a@mail.gmail.com> On Thu, Jun 5, 2008 at 11:18 AM, Denys Vlasenko wrote: > On Thursday 05 June 2008 18:10, E Robertson wrote: >> On Thu, Jun 5, 2008 at 10:56 AM, Denys Vlasenko >> wrote: >> > On Thursday 05 June 2008 17:08, E Robertson wrote: >> >> Hi All, >> >> I did a search on the "tar: short read" error and notice it was >> >> reported several times and fixed but it looks like it's broken again. >> >> I have a U-boot binary image in an archive file and tried to extract >> >> it using the following command: >> >> >> >> #tar -xz -C /tmp -f /tmp/usbstick/IMG_ARCHIVE.gz ./upgrade/uboot.img >> >> tar: short read >> > >> > From the name of it it doesn't seem to be a tar file at all. >> > Can you show "gunzip > > >> >> # echo $? >> >> 1 >> >> >> >> However, the uboot.img has not been extracted. I repeated this several >> >> times with the same result. >> >> I did the same thing on my kernel image and although this was >> >> extracted, the size of the extracted image is less than half the >> >> original size. >> >> >> >> Is this a bug? If not, Is their a solution for this? >> > >> > So far there is insufficient data to know what is it. >> >> I went back and tried some different formats. I see then if I use >> --format=gnu or oldgnu it works fine. >> I'm not too familiar with the different formats but that did the >> trick. My current tar on the host is version 1.19. >> Does that make sense? >> >> I'll add the header anyway (no format specified -- still trying to >> find out which is the default): >> >> 00000000 2e 2f 75 70 67 72 61 64 65 2f 00 00 00 00 00 00 |./images/......| > > Hex dump corresponds to "./upgrade/", not "./images/" > > It's very strange that you hack your own bug report. What's going on? Sorry, I cut/paste from the wrong terminal. I was trying one of my tricks which didn't turn out so good. > Can you send some small tar file (<30kb compressed) which is > not unpacking properly? Or upload it somewhere? will do. From e.robertson.svg at gmail.com Thu Jun 5 09:48:33 2008 From: e.robertson.svg at gmail.com (E Robertson) Date: Thu, 5 Jun 2008 11:48:33 -0500 Subject: tar: short read problem in release 1.10.2 In-Reply-To: <3972542e0806050927j2394a421hcc5b35e5fd82896a@mail.gmail.com> References: <3972542e0806050808k1b0c4fb0l6b8a7b3aa642681d@mail.gmail.com> <200806051756.13130.vda.linux@googlemail.com> <3972542e0806050910k4726e37al4de4d5c5b58d130a@mail.gmail.com> <200806051818.45614.vda.linux@googlemail.com> <3972542e0806050927j2394a421hcc5b35e5fd82896a@mail.gmail.com> Message-ID: <3972542e0806050948v6712cad3w606cf4ca609990da@mail.gmail.com> On Thu, Jun 5, 2008 at 11:27 AM, E Robertson wrote: > On Thu, Jun 5, 2008 at 11:18 AM, Denys Vlasenko > wrote: >> On Thursday 05 June 2008 18:10, E Robertson wrote: >>> On Thu, Jun 5, 2008 at 10:56 AM, Denys Vlasenko >>> wrote: >>> > On Thursday 05 June 2008 17:08, E Robertson wrote: >>> >> Hi All, >>> >> I did a search on the "tar: short read" error and notice it was >>> >> reported several times and fixed but it looks like it's broken again. >>> >> I have a U-boot binary image in an archive file and tried to extract >>> >> it using the following command: >>> >> >>> >> #tar -xz -C /tmp -f /tmp/usbstick/IMG_ARCHIVE.gz ./upgrade/uboot.img >>> >> tar: short read >>> > >>> > From the name of it it doesn't seem to be a tar file at all. >>> > Can you show "gunzip >> > >>> >> # echo $? >>> >> 1 >>> >> >>> >> However, the uboot.img has not been extracted. I repeated this several >>> >> times with the same result. >>> >> I did the same thing on my kernel image and although this was >>> >> extracted, the size of the extracted image is less than half the >>> >> original size. >>> >> >>> >> Is this a bug? If not, Is their a solution for this? >>> > >>> > So far there is insufficient data to know what is it. >>> >>> I went back and tried some different formats. I see then if I use >>> --format=gnu or oldgnu it works fine. >>> I'm not too familiar with the different formats but that did the >>> trick. My current tar on the host is version 1.19. >>> Does that make sense? >>> >>> I'll add the header anyway (no format specified -- still trying to >>> find out which is the default): >>> >>> 00000000 2e 2f 75 70 67 72 61 64 65 2f 00 00 00 00 00 00 |./images/......| >> >> Hex dump corresponds to "./upgrade/", not "./images/" >> >> It's very strange that you hack your own bug report. What's going on? > > Sorry, I cut/paste from the wrong terminal. I was trying one of my > tricks which didn't turn out so good. > >> Can you send some small tar file (<30kb compressed) which is >> not unpacking properly? Or upload it somewhere? > will do. Sorry guys but it looks like this was an error on my part (probably obvious). So far I haven't been able to reproduce the problem. I pulled some updated libraries (Debian sid - sorry didn't mention that either) as I notice some thing strange on in some of my package header. This may have been where the problem exist. I've recreated the archive (since my last one had a crude hack) several times but could not reproduce it. All seem to work great. If I should run into it again, I will post it. Thanks. E! From khollan at daktronics.com Thu Jun 5 10:40:15 2008 From: khollan at daktronics.com (Kevin Holland) Date: Thu, 05 Jun 2008 12:40:15 -0500 Subject: lsattr operation not supported Message-ID: <1212687615.6390.6.camel@kevin-laptop> Hi I'm using busybox version 1.5.1 any idea why it says: lsattr zImage.elf lsattr: reading zImage.elf: Operation not supported Thanks Kevin From cristian.ionescu-idbohrn at axis.com Thu Jun 5 11:18:22 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 5 Jun 2008 20:18:22 +0200 (CEST) Subject: [patch] include/usage.h Message-ID: <0806052014280.8921@somehost> Wouldn't this be more in line with the code? Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: usage.h.patch Type: text/x-diff Size: 1292 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080605/0c988a26/attachment-0001.patch From jacmet at uclibc.org Fri Jun 6 01:10:10 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 06 Jun 2008 10:10:10 +0200 Subject: [PATCH] dpkg: create_list: zero terminate list in loop In-Reply-To: <20080605121457.GB5252@mx.loc> (Bernhard Fischer's message of "Thu\, 5 Jun 2008 14\:14\:57 +0200") References: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> <20080605121457.GB5252@mx.loc> Message-ID: <87zlpzhtlp.fsf@macbook.be.48ers.dk> >>>>> "Bernhard" == Bernhard Fischer writes: Hi, >> while ((line = xmalloc_fgetline(list_stream)) != NULL) { >> file_list = xrealloc(file_list, sizeof(char *) * (count + 2)); >> - file_list[count] = line; >> - count++; >> + file_list[count++] = line; >> + file_list[count] = NULL; >> } >> fclose(list_stream); Bernhard> Only seeing these lines i wonder if create_list() shouldn't Bernhard> really just be replaced by xmalloc_xopen_read_close() ? Unfortunately not, dpkg needs an array of line pointers, not the file contents as a single blob. -- Bye, Peter Korsgaard From jacmet at uclibc.org Fri Jun 6 01:12:46 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 06 Jun 2008 10:12:46 +0200 Subject: [PATCH] dpkg: create_list: zero terminate list in loop In-Reply-To: (Robert P. J. Day's message of "Thu\, 5 Jun 2008 07\:56\:48 -0400 \(EDT\)") References: <1212666798-13110-1-git-send-email-jacmet@uclibc.org> Message-ID: <87skvrhthd.fsf@macbook.be.48ers.dk> >>>>> "Robert" == Robert P J Day writes: Hi, Robert> you know, even though that saves a few bytes, i'd be tempted Robert> not to do it that way since it's just plain inefficient in Robert> terms of machine cycles -- constantly assigning NULL only to Robert> overwrite it during the next iteration. That's hardly going to be measurable compared to the file I/O and malloc/realloc stuff - Especially when you see that create_list is only used on conffiles, E.G. files of typically only a few lines, and it's only called twice doing an install/remove. My bet is that most of the time will be spent on file I/O, decompression and running pre/postinst scripts. Robert> IMHO, not worth the saved bytes to torture the logic that way. I disagree. -- Bye, Peter Korsgaard From Ralf.Friedl at online.de Fri Jun 6 01:44:38 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Fri, 06 Jun 2008 10:44:38 +0200 Subject: lsattr operation not supported In-Reply-To: <1212687615.6390.6.camel@kevin-laptop> References: <1212687615.6390.6.camel@kevin-laptop> Message-ID: <4848F8F6.2000704@online.de> Kevin Holland wrote: > I'm using busybox version 1.5.1 any idea why it says: > lsattr zImage.elf > lsattr: reading zImage.elf: Operation not supported > Probably your filesystem and/or kernel is not configured to support it. Regards Ralf Friedl From natanael.copa at gmail.com Fri Jun 6 04:39:15 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Fri, 06 Jun 2008 13:39:15 +0200 Subject: [PATCH] libbb print_flags() -380 bytes Message-ID: <1212752355.4918.10.camel@nc.nor.wtbts.org> Hi, I have looked more at the print_flags() I started with yesterday. Attatched are some patches and they should probably be committed to svn separatly (easier to revert in case they have bugs). I tried to use print_flags() in arp.c and fdisk.c but they seemed to increase the size so I chosed to not included them here. (ping me if someone want to take a look at them anyway) Patches are rebased from svn trunk this morning. Bloatcheck on hardened uclibc gcc-3.4.6: function old new delta hdparm_main 1067 4916 +3849 print_flags - 135 +135 static.ultra_modes2 - 88 +88 static.dma_mword_modes - 72 +72 static.dma_1word_modes - 72 +72 static.ultra_modes1 - 56 +56 static.link_flags - 56 +56 static.pio_modes - 32 +32 static.dflags - 32 +32 .rodata 31784 31770 -14 xbsd_print_disklabel 927 892 -35 ipaddr_list_or_flush 2732 2455 -277 process_dev 4446 - -4446 ------------------------------------------------------------------------------ (add/remove: 8/1 grow/shrink: 1/3 up/down: 4392/-4772) Total: -380 bytes text data bss dec hex filename 135156 2173 4500 141829 22a05 busybox_old 134728 2677 4500 141905 22a51 busybox_unstripped -nc -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags-hdparm.patch Type: text/x-patch Size: 3819 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080606/8b6c8c30/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags-ip.patch Type: text/x-patch Size: 1248 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080606/8b6c8c30/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags-libbb.patch Type: text/x-patch Size: 1662 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080606/8b6c8c30/attachment-0002.bin From rep.dot.nop at gmail.com Fri Jun 6 05:14:42 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 6 Jun 2008 14:14:42 +0200 Subject: [PATCH] libbb print_flags() -380 bytes In-Reply-To: <1212752355.4918.10.camel@nc.nor.wtbts.org> References: <1212752355.4918.10.camel@nc.nor.wtbts.org> Message-ID: <20080606121442.GI27768@mx.loc> On Fri, Jun 06, 2008 at 01:39:15PM +0200, Natanael Copa wrote: >Hi, > >I have looked more at the print_flags() I started with yesterday. > >Attatched are some patches and they should probably be committed to svn >separatly (easier to revert in case they have bugs). > >I tried to use print_flags() in arp.c and fdisk.c but they seemed to >increase the size so I chosed to not included them here. (ping me if >someone want to take a look at them anyway) > >Patches are rebased from svn trunk this morning. > >Bloatcheck on hardened uclibc gcc-3.4.6: > >function old new delta >hdparm_main 1067 4916 +3849 >print_flags - 135 +135 >static.ultra_modes2 - 88 +88 >static.dma_mword_modes - 72 +72 >static.dma_1word_modes - 72 +72 >static.ultra_modes1 - 56 +56 >static.link_flags - 56 +56 >static.pio_modes - 32 +32 >static.dflags - 32 +32 >.rodata 31784 31770 -14 >xbsd_print_disklabel 927 892 -35 >ipaddr_list_or_flush 2732 2455 -277 >process_dev 4446 - -4446 >------------------------------------------------------------------------------ >(add/remove: 8/1 grow/shrink: 1/3 up/down: 4392/-4772) Total: -380 >bytes > text data bss dec hex filename > 135156 2173 4500 141829 22a05 busybox_old > 134728 2677 4500 141905 22a51 busybox_unstripped > >-nc >Index: libbb/print_flags.c >=================================================================== >--- libbb/print_flags.c (revision 0) >+++ libbb/print_flags.c (revision 0) >@@ -0,0 +1,26 @@ >+/* vi: set sw=4 ts=4: */ >+/* Print string that matches bit masked flags >+ * >+ * Copyright (C) 2008 Natanael Copa >+ * >+ * Licensed under GPLv2 or later, see file LICENSE in this tarball for details. >+ */ >+ >+#include >+ >+/* returns a set with the flags not printed */ >+int print_flags(const struct mask_string *ms, int flags, const char *separator) >+{ ->+ int need_separator = 0; and pass NULL instead of "", or rename this func to print_flags_separated(mask_string_t, int, const char *const) and for the NULL cases add a wrapper int print_flags(const mask_string_t *ms, int flags) { return print_flags_separated(ms, flags, NULL); } >+ while (ms->string) { I think it would be better (not sure if it would help that much, admittedly) to have the strings 0 separated like we do with index_in_strings and do something correspondingly with the flags. >Index: include/libbb.h >=================================================================== >--- include/libbb.h (revision 22223) >+++ include/libbb.h (working copy) >@@ -1304,7 +1304,14 @@ > /* "sh" */ > #define DEFAULT_SHELL_SHORT_NAME (bb_default_login_shell+6) > >+struct mask_string { >+ int mask; >+ const char *string; >+}; typedef this, please. > >+extern int print_flags(const struct mask_string *ms, int flags, const char *separator); bunch of const missing. IIRC networking/{,*/}* has several occurances of that pattern, too, just as a sidenote. From manuprivat at gmx.de Fri Jun 6 06:01:52 2008 From: manuprivat at gmx.de (Manu) Date: Fri, 06 Jun 2008 15:01:52 +0200 Subject: udhcpd Message-ID: <48493540.3000705@gmx.de> Hi there, I encountered a problem with udhcpd in combination with a ISP, that drops every ping request! I can only surf with IP not by name - the DNS doesn't work! Tvcabo is a big cable isp in Portugal and ex-portugal colonies. On a fixed I-net-IP tvcabo net, with ping allowed the name resolution works fine. On DSL with ping allowed, the name resolution works fine. On NON-fixed-IP tvcabo net, with ping not allowed, the name resolution doesn't work!!! I can confiure 2 nameservers. In the fix I-net-IP test I set in 'nameserver' = 196.46.0.236 ( tvcabo dns WITH PING DROP ) and in 'Nameserver2' = 80.58.0.33 (telefonica dns WITHOUT PING DROP ) I receive by dhcp, the telefonica dns!! I dont understand it!? Is there a possibility to configure udhcpd to not test the DNS servers! Is there a ping in the background to check if the DNS-Server is available?! Any help would greatly appreciated, Thanks in advance! Regards mando From vda.linux at googlemail.com Fri Jun 6 05:57:59 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 6 Jun 2008 14:57:59 +0200 Subject: [PATCH] libbb print_flags() -380 bytes In-Reply-To: <1212752355.4918.10.camel@nc.nor.wtbts.org> References: <1212752355.4918.10.camel@nc.nor.wtbts.org> Message-ID: <200806061458.00016.vda.linux@googlemail.com> Hi Natanael, On Friday 06 June 2008 13:39, Natanael Copa wrote: > I have looked more at the print_flags() I started with yesterday. > > Attatched are some patches and they should probably be committed to svn > separatly (easier to revert in case they have bugs). > > I tried to use print_flags() in arp.c and fdisk.c but they seemed to > increase the size so I chosed to not included them here. (ping me if > someone want to take a look at them anyway) > > Patches are rebased from svn trunk this morning. Why it's "struct mask_string" in print_flags-libbb.patch but "struct flag_label" in other patches? something is wrong... But anyway. I bet the most of waste is in string pointer member here: +struct mask_string { + int mask; + const char *string; <===== +}; Just count how many of char* pointers are here: + static const struct flag_label dma_1word_modes[] = { + { 0x100, "*" }, + { 1, "sdma0" }, + { 0x200, "*" }, + { 2, "sdma1" }, + { 0x400, "*" }, + { 4, "sdma2" }, + { 0xf800, "*" }, + { 0xf8, "sdma?" }, + { 0, NULL }, + }; Nine! Each ptr is 4 or even 8 bytes. By changing int print_flags(const struct mask_string *ms, int flags, const char *separator) into int print_flags(const int masks[], const char *strings, int flags, const char *separator) and passing a vector of masks (0-terminated) and a single string, in the above example it would be "*\0""sdma0\0""*\0""sdma1\0""*\0""sdma2\0""*\0""sdma?", you will save ~30 bytes in that example alone. Small note: you missed const at least here: + static struct flag_label ultra_modes2[] = { Overall, I welcome any patch which shrinks bbox. This one looks promising. -- vda From natanael.copa at gmail.com Fri Jun 6 06:25:07 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Fri, 06 Jun 2008 15:25:07 +0200 Subject: [PATCH] libbb print_flags() -380 bytes In-Reply-To: <200806061458.00016.vda.linux@googlemail.com> References: <1212752355.4918.10.camel@nc.nor.wtbts.org> <200806061458.00016.vda.linux@googlemail.com> Message-ID: <1212758707.4918.18.camel@nc.nor.wtbts.org> On Fri, 2008-06-06 at 14:57 +0200, Denys Vlasenko wrote: > Hi Natanael, > > On Friday 06 June 2008 13:39, Natanael Copa wrote: > > I have looked more at the print_flags() I started with yesterday. > > > > Attatched are some patches and they should probably be committed to svn > > separatly (easier to revert in case they have bugs). > > > > I tried to use print_flags() in arp.c and fdisk.c but they seemed to > > increase the size so I chosed to not included them here. (ping me if > > someone want to take a look at them anyway) > > > > Patches are rebased from svn trunk this morning. > > Why it's "struct mask_string" in print_flags-libbb.patch > but "struct flag_label" in other patches? something is wrong... ouch... yes. I attatched wrong patch. > But anyway. > I bet the most of waste is in string pointer member here: > > +struct mask_string { > + int mask; > + const char *string; <===== > +}; ... > By changing > > int print_flags(const struct mask_string *ms, int flags, const char *separator) > > into > > int print_flags(const int masks[], const char *strings, int flags, const char *separator) > > and passing a vector of masks (0-terminated) and a single string, > in the above example it would be > "*\0""sdma0\0""*\0""sdma1\0""*\0""sdma2\0""*\0""sdma?", > you will save ~30 bytes in that example alone. thanks! i wanted something like that but could not find out how. > Small note: you missed const at least here: > > + static struct flag_label ultra_modes2[] = { > > Overall, I welcome any patch which shrinks bbox. This one looks promising. Got several good tips from Benhard too. Will have a look at it, hopefully during the weekend. thanks! > -- > vda From vda.linux at googlemail.com Fri Jun 6 06:28:28 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 6 Jun 2008 15:28:28 +0200 Subject: udhcpd In-Reply-To: <48493540.3000705@gmx.de> References: <48493540.3000705@gmx.de> Message-ID: <200806061528.29021.vda.linux@googlemail.com> On Friday 06 June 2008 15:01, Manu wrote: > Hi there, > > I encountered a problem with udhcpd in combination with a ISP, that > drops every ping request! > I can only surf with IP not by name - the DNS doesn't work! > Tvcabo is a big cable isp in Portugal and ex-portugal colonies. > On a fixed I-net-IP tvcabo net, with ping allowed the name resolution > works fine. > On DSL with ping allowed, the name resolution works fine. > On NON-fixed-IP tvcabo net, with ping not allowed, the name resolution > doesn't work!!! > > I can confiure 2 nameservers. > In the fix I-net-IP test I set in 'nameserver' = 196.46.0.236 ( tvcabo > dns WITH PING DROP ) > and in 'Nameserver2' = 80.58.0.33 (telefonica dns WITHOUT PING DROP ) > I receive by dhcp, the telefonica dns!! I dont understand it!? > Is there a possibility to configure udhcpd to not test the DNS servers! Show your udhcpc command line and log; tcpdump trace and the like. As of now, the description you gave lacks details needed to diagnose the problem. > Is there a ping in the background to check if the DNS-Server is available?! No, udhcpc does not do any tests by pinging. -- vda From lich at math.spbu.ru Fri Jun 6 06:35:12 2008 From: lich at math.spbu.ru (Kirill K. Smirnov) Date: Fri, 6 Jun 2008 17:35:12 +0400 Subject: [patch] Let busybox use monotonical clock with old glibc (<2.3.4) Message-ID: <200806061735.12511.lich@math.spbu.ru> Hi! This patch helps busybox built with old glibc use monotonical clock (CLOCK_MONOTONIC). -- Kirill -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.10.3.patch Type: text/x-diff Size: 614 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080606/c31ebe08/attachment.patch From fialamarti at seznam.cz Fri Jun 6 06:57:09 2008 From: fialamarti at seznam.cz (=?us-ascii?Q?Martin=20Fiala?=) Date: Fri, 06 Jun 2008 15:57:09 +0200 (CEST) Subject: =?us-ascii?Q?kernel=20panic=20=2D=20attempted=20to=20kill=20init?= Message-ID: <291.403-22664-654017143-1212760629@seznam.cz> Hello, i'm porting Montavista linux 2.6.24.3 to our board which is based on Amd alchemy mips processor. I'm using U-boot as boot loader and Eldk 4.1 by Denx, which contains also busybox 1.3.0, for development. Linux boots well until it gets to starting of init process. After sys_execve function is completed (with no error), process, called init, invokes fpu emulator eight times with no error. After that is program moving in scheduller code and any assembler code, which is used to clearing memmory bits. Then linux randomly crashes with "not syncing - attemted to kill init" message. This happens no matter if i try to boot from nfs or from ramdisk. I used ramdisk, which is part of eldk package and ramdisk which i created using bussybox in combination with Eldk libraries, but result was almost the same. The difference was only in some libraries, which are loaded by linker, i think. I got the same results with NFS. I can not post you messages, which writes linux during boot, because my console also doesn't work yet. I didn't even try to make console work much, because i can read printk messages from log_buf variable, when i debug linux using kgdb. I also compiled hello world application, i found at bussybox internet page, with Eldk compiler, changed it to elf format with cross compile objcopy and renamed it to init, but kernel gave me no init found message. Right now, i'm quite clueless, because my knowledges ot this problematics are quie poor. Could someone give me any hint, or idea, where the problem could probably be? Are there any differences in constitution of filesystem between ramdisk and filesystem accessed through NFS? Thanks, Martin. From vda.linux at googlemail.com Fri Jun 6 10:01:26 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 6 Jun 2008 19:01:26 +0200 Subject: kernel panic - attempted to kill init In-Reply-To: <291.403-22664-654017143-1212760629@seznam.cz> References: <291.403-22664-654017143-1212760629@seznam.cz> Message-ID: <200806061901.26255.vda.linux@googlemail.com> Hi, On Friday 06 June 2008 15:57, Martin Fiala wrote: > i'm porting Montavista linux 2.6.24.3 to our board which is based on Amd alchemy mips processor. I'm using U-boot as boot loader and Eldk 4.1 by Denx, which contains also busybox 1.3.0, for development. Please do not try to win the monthly prize for the email with longest line lengths. > Linux boots well until it gets to starting of init process. > After sys_execve function is completed (with no error), process, > called init, invokes fpu emulator eight times with no error. > After that is program moving in scheduller code and any assembler > code, which is used to clearing memmory bits. Then linux randomly > crashes with "not syncing - attemted to kill init" message. The usual procedure to debug it is ti try to boot with init which is very simple, say, which prints "Hello world!" and sleeps for one second in a loop. When that works, build busybox with the same exact toolchain libc, options etc which were working for Hello-world class init. > This happens no matter if i try to boot from nfs or from ramdisk. > I used ramdisk, which is part of eldk package and ramdisk which > i created using bussybox in combination with Eldk libraries, > but result was almost the same. The difference was only in some > libraries, which are loaded by linker, i think. I got the same > results with NFS. Generally, try to make it work with statically linked init (and then busybox). Shared libraries are another can of worms, do not try to solve two problems at once. You can attack that later. > I can not post you messages, which writes linux during boot, > because my console also doesn't work yet. I didn't even try > to make console work much, because i can read printk messages > from log_buf variable, when i debug linux using kgdb. You are more advanced than me, I dont know kgdb. > I also compiled hello world application, i found at bussybox > internet page, with Eldk compiler, changed it to elf format > with cross compile objcopy and renamed it to init, > but kernel gave me no init found message. You are on the right track. Find a working combination of toolchain and libc which works for simple statically linked "hello world". > Right now, i'm quite clueless, because my knowledges > ot this problematics are quie poor. Everyone was starting like this. -- vda From sidkapoor2000 at gmail.com Fri Jun 6 10:23:59 2008 From: sidkapoor2000 at gmail.com (Sid Kapoor) Date: Fri, 6 Jun 2008 22:53:59 +0530 Subject: busybox binaries hangs when trying to do "lstat" Message-ID: Hi all, The busybox 'ls' applet uses the kernel(system) calls such as lstat to locate mounted file system information. When a file system has been mounted from an NFS server and that server is temporarily unavailable, the calls 'lstat' uses may block in the kernel, resulting in the whole terminal in a hung-up status. I NFS mounted a folder at the mount point '/root/tmp/'. When the server was unavailable, and 'ls' was executed at /root, it tried to locate mounted file system's information. Eventually the system did not respond to the 'lstat' call and the system hanged. The final lines of the log of the strace command while executing 'ls' is as follows (full log file is attached with this mail) : open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20Z\1\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=1248904, ...}) = 0 mmap2(NULL, 1258876, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e65000 mmap2(0xb7f92000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12c) = 0xb7f92000 mmap2(0xb7f96000, 9596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f96000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e64000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e646b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7f92000, 8192, PROT_READ) = 0 mprotect(0x36aa000, 4096, PROT_READ) = 0 getuid32() = 0 getpid() = 15915 time(NULL) = 1212803764 ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=724, ws_ypixel=508}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 stat64(".", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 brk(0) = 0x80df000 brk(0x8100000) = 0x8100000 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents64(3, /* 32 entries */, 1024) = 1008 lstat64("./abc", {st_mode=S_IFREG|0755, st_size=48, ...}) = 0 lstat64("./img.jpg", {st_mode=S_IFREG|S_ISGID|S_ISVTX|0745, st_size=27291, ...}) = 0 lstat64("./Desktop", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 lstat64("./ControlCenter", {st_mode=S_IFREG|0755, st_size=955503, ...}) = 0 lstat64("./tmp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 --- SIGHUP (Hangup) @ 0 (0) --- +++ killed by SIGHUP +++ Can anyone tell the reason why is this happening? Is it a bug in busybox? Waiting for reply. Thanks in advance, Siddharth From sidkapoor2000 at gmail.com Fri Jun 6 10:25:35 2008 From: sidkapoor2000 at gmail.com (Sid Kapoor) Date: Fri, 6 Jun 2008 22:55:35 +0530 Subject: busybox binaries hangs when trying to do "lstat" In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Sid Kapoor Date: Fri, Jun 6, 2008 at 10:53 PM Subject: busybox binaries hangs when trying to do "lstat" To: busybox at busybox.net Hi all, The busybox 'ls' applet uses the kernel(system) calls such as lstat to locate mounted file system information. When a file system has been mounted from an NFS server and that server is temporarily unavailable, the calls 'lstat' uses may block in the kernel, resulting in the whole terminal in a hung-up status. I NFS mounted a folder at the mount point '/root/tmp/'. When the server was unavailable, and 'ls' was executed at /root, it tried to locate mounted file system's information. Eventually the system did not respond to the 'lstat' call and the system hanged. The final lines of the log of the strace command while executing 'ls' is as follows (full log file is attached with this mail) : open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20Z\1\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=1248904, ...}) = 0 mmap2(NULL, 1258876, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e65000 mmap2(0xb7f92000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12c) = 0xb7f92000 mmap2(0xb7f96000, 9596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f96000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e64000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e646b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7f92000, 8192, PROT_READ) = 0 mprotect(0x36aa000, 4096, PROT_READ) = 0 getuid32() = 0 getpid() = 15915 time(NULL) = 1212803764 ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=724, ws_ypixel=508}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 stat64(".", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 brk(0) = 0x80df000 brk(0x8100000) = 0x8100000 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents64(3, /* 32 entries */, 1024) = 1008 lstat64("./abc", {st_mode=S_IFREG|0755, st_size=48, ...}) = 0 lstat64("./img.jpg", {st_mode=S_IFREG|S_ISGID|S_ISVTX|0745, st_size=27291, ...}) = 0 lstat64("./Desktop", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 lstat64("./ControlCenter", {st_mode=S_IFREG|0755, st_size=955503, ...}) = 0 lstat64("./tmp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 --- SIGHUP (Hangup) @ 0 (0) --- +++ killed by SIGHUP +++ Can anyone tell the reason why is this happening? Is it a bug in busybox? Waiting for reply. Thanks in advance, Siddharth -- Siddharth Kapoor Sr. Software Engg., Monitor Group Samsung India Software Center(SISC), Noida Mobile - 9999169466 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log Url: http://busybox.net/lists/busybox/attachments/20080606/1f6eac5a/attachment-0001.txt From Ralf.Friedl at online.de Fri Jun 6 10:36:19 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Fri, 06 Jun 2008 19:36:19 +0200 Subject: busybox binaries hangs when trying to do "lstat" In-Reply-To: References: Message-ID: <48497593.1010401@online.de> Sid Kapoor wrote: > Hi all, > > The busybox 'ls' applet uses the kernel(system) calls such as lstat to > locate mounted file system information. When a file system has been > mounted from an NFS server and that server is temporarily unavailable, > the calls 'lstat' uses may block in the kernel, resulting in the whole > terminal in a hung-up status. > > I NFS mounted a folder at the mount point '/root/tmp/'. When the > server was unavailable, and 'ls' was executed at /root, it tried to > locate mounted file system's information. Eventually the system did > not respond to the 'lstat' call and the system hanged. The final lines > of the log of the strace command while executing 'ls' is as follows > (full log file is attached with this mail) : > > > lstat64("./tmp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > --- SIGHUP (Hangup) @ 0 (0) --- > +++ killed by SIGHUP +++ > > Can anyone tell the reason why is this happening? Is it a bug in > busybox? Waiting for reply. > The last line from strace shows that lstat succeeds. You may consider the NFS option 'soft' for your mount. The reason why busybox ls uses lstat is that is uses colored display of names by default, even with no options or environment variables set. Regards Ralf Friedl From vda.linux at googlemail.com Fri Jun 6 11:21:52 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 6 Jun 2008 20:21:52 +0200 Subject: busybox binaries hangs when trying to do "lstat" In-Reply-To: <48497593.1010401@online.de> References: <48497593.1010401@online.de> Message-ID: <200806062021.52643.vda.linux@googlemail.com> On Friday 06 June 2008 19:36, Ralf Friedl wrote: > Sid Kapoor wrote: > > The busybox 'ls' applet uses the kernel(system) calls such as lstat to > > locate mounted file system information. When a file system has been > > mounted from an NFS server and that server is temporarily unavailable, > > the calls 'lstat' uses may block in the kernel, resulting in the whole > > terminal in a hung-up status. > > > > I NFS mounted a folder at the mount point '/root/tmp/'. When the > > server was unavailable, and 'ls' was executed at /root, it tried to > > locate mounted file system's information. Eventually the system did > > not respond to the 'lstat' call and the system hanged. The final lines > > of the log of the strace command while executing 'ls' is as follows > > (full log file is attached with this mail) : > > > > > > lstat64("./tmp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > > --- SIGHUP (Hangup) @ 0 (0) --- > > +++ killed by SIGHUP +++ > > > > Can anyone tell the reason why is this happening? Is it a bug in > > busybox? Waiting for reply. > > > The last line from strace shows that lstat succeeds. > You may consider the NFS option 'soft' for your mount. > > The reason why busybox ls uses lstat is that is uses colored display of > names by default, even with no options or environment variables set. Well, I don't understand what the original post implies. What ls should do instead? It has to obtain filename list SOMEHOW, no? It can be done only by asking the kernel to do readdir, [l]stat, etc. And if that call takes very long (as in: 5 years) to finish due to NFS server, it's not ls' fault. This is how NFS operated for as long as I remember. This is actually a design choice - if you use "hard" NFS mounts and NFS server dies, file accesses will hang (as opposed to "fail") in the hope that server will eventually come back online. (And they DO succeed if it comes back online). -- vda From natanael.copa at gmail.com Fri Jun 6 11:58:34 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Fri, 06 Jun 2008 20:58:34 +0200 Subject: [PATCH] libbb print_flags() -380 bytes In-Reply-To: <20080606121442.GI27768@mx.loc> References: <1212752355.4918.10.camel@nc.nor.wtbts.org> <20080606121442.GI27768@mx.loc> Message-ID: <484988DA.6070806@gmail.com> Bernhard Fischer wrote: >> Index: include/libbb.h >> =================================================================== >> --- include/libbb.h (revision 22223) >> +++ include/libbb.h (working copy) >> @@ -1304,7 +1304,14 @@ >> /* "sh" */ >> #define DEFAULT_SHELL_SHORT_NAME (bb_default_login_shell+6) >> >> +struct mask_string { >> + int mask; >> + const char *string; >> +}; >> > > typedef this, please. > I tend to agree with the linux coding style there but ok. http://www.linuxjournal.com/article/5780 (look for "typedef is evil") -nc From Ralf.Friedl at online.de Fri Jun 6 13:13:18 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Fri, 06 Jun 2008 22:13:18 +0200 Subject: busybox binaries hangs when trying to do "lstat" In-Reply-To: <200806062021.52643.vda.linux@googlemail.com> References: <48497593.1010401@online.de> <200806062021.52643.vda.linux@googlemail.com> Message-ID: <48499A5E.8020200@online.de> Denys Vlasenko wrote: > Well, I don't understand what the original post implies. What ls > should do instead? It has to obtain filename list SOMEHOW, no? > It can be done only by asking the kernel to do readdir, [l]stat, > etc. In case of "ls" without options, readdir() without lstat would be enough, if busybox would not do colored output by default. Coreutils "ls" does not lstat when it doesn't create colored output (which is default if stdout is not a tty), because the stat information is not used in that case.. Regards Ralf Friedl From beck0778 at umn.edu Fri Jun 6 13:39:44 2008 From: beck0778 at umn.edu (beck0778 at umn.edu) Date: 06 Jun 2008 15:39:44 -0500 Subject: fgrep alias for grep Message-ID: Hello, I'm trying to extend busybox to include aliases for dnsdomainname and domainname in the hostname applet. It seems fairly straightforward, and I'm not having trouble with it, but I stumbled upon something odd in the source for the grep applet, specifically its treatment of the fgrep alias for grep. In the file busybox-1.10.1/findutils/grep.c, starting at line 457: if (option_mask32 & OPT_f) load_regexes_from_file(fopt); if (ENABLE_FEATURE_GREP_FGREP_ALIAS && applet_name[0] == 'f') option_mask32 |= OPT_F; Since this code is not in a loop, it seems that the fgrep alias detection (the second chunk of code here), which sets the OPT_F flag in option_mask32, comes after the code that detects the presence of that flag. Am I reading this wrong, or should those two parts be switched? Thanks, Matthew From roy at marples.name Fri Jun 6 17:25:22 2008 From: roy at marples.name (Roy Marples) Date: Sat, 7 Jun 2008 01:25:22 +0100 Subject: [PATCH] libbb print_flags() -380 bytes In-Reply-To: <484988DA.6070806@gmail.com> References: <1212752355.4918.10.camel@nc.nor.wtbts.org> <20080606121442.GI27768@mx.loc> <484988DA.6070806@gmail.com> Message-ID: <200806070125.22579.roy@marples.name> On Friday 06 June 2008 19:58:34 Natanael Copa wrote: > Bernhard Fischer wrote: > >> Index: include/libbb.h > >> =================================================================== > >> --- include/libbb.h (revision 22223) > >> +++ include/libbb.h (working copy) > >> @@ -1304,7 +1304,14 @@ > >> /* "sh" */ > >> #define DEFAULT_SHELL_SHORT_NAME (bb_default_login_shell+6) > >> > >> +struct mask_string { > >> + int mask; > >> + const char *string; > >> +}; > > > > typedef this, please. > > I tend to agree with the linux coding style there but ok. > http://www.linuxjournal.com/article/5780 (look for "typedef is evil") And if you must typedef, the BSD style works well here. Basically the typedef is the name of the structure but in upper case. (BSD also discourages typedefs) struct mask_string { int mask; const char *string; } MASK_STRING; So struct mask_string ms; and MASK_STRING ms; are equivalent. Thanks Roy From vda.linux at googlemail.com Fri Jun 6 22:17:41 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 07:17:41 +0200 Subject: fgrep alias for grep In-Reply-To: References: Message-ID: <200806070717.41936.vda.linux@googlemail.com> On Friday 06 June 2008 22:39, beck0778 at umn.edu wrote: > I'm trying to extend busybox to include aliases for dnsdomainname and > domainname in the hostname applet. It seems fairly straightforward, and I'm > not having trouble with it, but I stumbled upon something odd in the source > for the grep applet, specifically its treatment of the fgrep alias for > grep. > > In the file busybox-1.10.1/findutils/grep.c, starting at line 457: > > if (option_mask32 & OPT_f) > load_regexes_from_file(fopt); > > if (ENABLE_FEATURE_GREP_FGREP_ALIAS && applet_name[0] == 'f') > option_mask32 |= OPT_F; > > Since this code is not in a loop, it seems that the fgrep alias detection > (the second chunk of code here), which sets the OPT_F flag in > option_mask32, comes after the code that detects the presence of that flag. You confused OPT_f and OPT_F. But there indeed was a small bug nearby: -f - ("read regexps from stdin") wasn't working. -- vda From vda.linux at googlemail.com Fri Jun 6 22:24:43 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 07:24:43 +0200 Subject: busybox binaries hangs when trying to do "lstat" In-Reply-To: <48499A5E.8020200@online.de> References: <200806062021.52643.vda.linux@googlemail.com> <48499A5E.8020200@online.de> Message-ID: <200806070724.43505.vda.linux@googlemail.com> On Friday 06 June 2008 22:13, Ralf Friedl wrote: > Denys Vlasenko wrote: > > Well, I don't understand what the original post implies. What ls > > should do instead? It has to obtain filename list SOMEHOW, no? > > It can be done only by asking the kernel to do readdir, [l]stat, > > etc. > In case of "ls" without options, readdir() without lstat would be > enough, if busybox would not do colored output by default. Well, this is true only if you want a bare list of files. No coloring, no file type suffixes ("dir/"), no recursion (-R), no file info (-l). In other words, this is an optimization which is "nice to have" but in real world usage it won't happen to be used as often as one might want. Back to "NFS stall" question: readdir will stall as readily as lstat if the NFS server is down. > Coreutils "ls" does not lstat when it doesn't create colored output > (which is default if stdout is not a tty), because the stat information > is not used in that case.. Yes. -- vda From vda.linux at googlemail.com Fri Jun 6 22:42:14 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 07:42:14 +0200 Subject: [patch] include/usage.h In-Reply-To: <0806052014280.8921@somehost> References: <0806052014280.8921@somehost> Message-ID: <200806070742.14570.vda.linux@googlemail.com> On Thursday 05 June 2008 20:18, Cristian Ionescu-Idbohrn wrote: > Wouldn't this be more in line with the code? Not really. Only last six X's are required and subsequently replaced by random chars. -- vda From vda.linux at googlemail.com Fri Jun 6 22:55:41 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 07:55:41 +0200 Subject: mdev race conditions In-Reply-To: <4846888A.60906@bfs.de> References: <484558CA.8070308@largestprime.net> <200806041327.50192.vda.linux@googlemail.com> <4846888A.60906@bfs.de> Message-ID: <200806070755.41507.vda.linux@googlemail.com> On Wednesday 04 June 2008 14:20, walter harms wrote: > > maybe this explanation is helpful > > http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00145.html Well, it explains what PIE is, but does not explain in which situations PIE bring some substantial benefits. We need a snippet of text which lets a user who didn't hear about PIE *at all* decide whether he needs it or not. -- vda From vda.linux at googlemail.com Fri Jun 6 22:59:01 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 07:59:01 +0200 Subject: mdev race conditions In-Reply-To: <200806040632.17428.vapier@gentoo.org> References: <484558CA.8070308@largestprime.net> <20080604090416.GA7964@mersenne.largestprime.net> <200806040632.17428.vapier@gentoo.org> Message-ID: <200806070759.01423.vda.linux@googlemail.com> On Wednesday 04 June 2008 12:32, Mike Frysinger wrote: > > Sorry, what I meant to say is that the resulting addition of mdevd > > to the busybox binary would only add a few kilobytes to its size. > > and as things are today, your "tiny" addition results in much more overhead > than udevd. busybox is one big blob and every instance of it (regardless of > what applet it's invoking) means a unique instance of that big blog in > memory. Not related to mdev: I am trying to fix it by (1) seriously reducing the size of data+bss and (2) making libbusybox build option work ewll for those poor souls who sits on arch which is incapable of reusing text+rodata segment of loaded executables. I need some feedback if these efforts don't work well. -- vda From vda.linux at googlemail.com Fri Jun 6 23:00:53 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 08:00:53 +0200 Subject: mdev race conditions In-Reply-To: <20080604090855.GB7964@mersenne.largestprime.net> References: <484558CA.8070308@largestprime.net> <200806041041.38663.vda.linux@googlemail.com> <20080604090855.GB7964@mersenne.largestprime.net> Message-ID: <200806070800.53378.vda.linux@googlemail.com> On Wednesday 04 June 2008 11:08, Bernard Blackham wrote: > On Wed, Jun 04, 2008 at 10:41:38AM +0200, Denys Vlasenko wrote: > > Try attached 2.patch. It adds mdev options -f SEQFILE and -t TIMEOUT_MSEC. > > If -f is not given, the behavious is unchanged. > > Thanks, but this is not helpful as you can't get > hotplug/uevent_helper to pass arguments to mdev. This can be hardcoded then (so that mdev without options does this). I wanted to get a feedback whether it works as intended *at all*, and how many running mdevs pile up in the memory waiting for this crude "semaphore". -- vda From Ralf.Friedl at online.de Sat Jun 7 02:10:56 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Sat, 07 Jun 2008 11:10:56 +0200 Subject: busybox binaries hangs when trying to do "lstat" In-Reply-To: <200806070724.43505.vda.linux@googlemail.com> References: <200806062021.52643.vda.linux@googlemail.com> <48499A5E.8020200@online.de> <200806070724.43505.vda.linux@googlemail.com> Message-ID: <484A50A0.8000809@online.de> Denys Vlasenko wrote: > On Friday 06 June 2008 22:13, Ralf Friedl wrote: > >> In case of "ls" without options, readdir() without lstat would be >> enough, if busybox would not do colored output by default. >> > > Well, this is true only if you want a bare list of files. > No coloring, no file type suffixes ("dir/"), no recursion (-R), > no file info (-l). > > In other words, this is an optimization which is "nice to have" > but in real world usage it won't happen to be used as often > as one might want. > I know, and I didn't want to imply that busybox should be changed. It was just a possible explanation why this might have been considered a busybox problem in the original message. > Back to "NFS stall" question: readdir will stall as readily as lstat > if the NFS server is down. > I agree that the NFS server is the main problem and it's not a problem of busybox can solve. Regards Ralf Friedl From vda.linux at googlemail.com Sat Jun 7 02:43:14 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 11:43:14 +0200 Subject: busybox binaries hangs when trying to do "lstat" In-Reply-To: <484A50A0.8000809@online.de> References: <200806070724.43505.vda.linux@googlemail.com> <484A50A0.8000809@online.de> Message-ID: <200806071143.14822.vda.linux@googlemail.com> On Saturday 07 June 2008 11:10, Ralf Friedl wrote: > > Well, this is true only if you want a bare list of files. > > No coloring, no file type suffixes ("dir/"), no recursion (-R), > > no file info (-l). > > > > In other words, this is an optimization which is "nice to have" > > but in real world usage it won't happen to be used as often > > as one might want. > > > I know, and I didn't want to imply that busybox should be changed. It > was just a possible explanation why this might have been considered a > busybox problem in the original message. Yes, this is not a "problem", but would be a useful improvement indeed. I was thinking how to avoid stat calls. This becomes more interesting if there is any way to do "ls -R" without stat calls too - it's much more common thing to do than bare "ls" (and it usually lists much more files, so the win is bigger), but nothing comes to mind. -- vda From cristian.ionescu-idbohrn at axis.com Sat Jun 7 03:37:29 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sat, 7 Jun 2008 12:37:29 +0200 (CEST) Subject: [PATCH] libbb print_flags() -380 bytes In-Reply-To: <484988DA.6070806@gmail.com> References: <1212752355.4918.10.camel@nc.nor.wtbts.org> <20080606121442.GI27768@mx.loc> <484988DA.6070806@gmail.com> Message-ID: <0806071235410.8921@somehost> On Fri, 6 Jun 2008, Natanael Copa wrote: > I tend to agree with the linux coding style there but ok. > http://www.linuxjournal.com/article/5780 (look for "typedef is evil") The "No ifdefs in .c Code" part in the same article is interesting too. Cheers, -- Cristian From natanael.copa at gmail.com Sat Jun 7 05:47:55 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Sat, 07 Jun 2008 14:47:55 +0200 Subject: [PATCH] print_flags() take 2: -644 bytes Message-ID: <484A837B.1000209@gmail.com> Hi, So I collected the ideas/suggestions and prepared another set of patches. I grouped the masks array with the labels '\0' separated string into a struct. They are always used together anyway and by grouping them we save one parameter for every call. Yeah, Linux BSD coding style is great, but its better to be consequent so I typedef'ed as requested to fit better in busybox style. The biggest win is in hdparm, but this time there was a win in both fdisk and arp too so i submit pathes for those too. There are probably more places print_flags() could be used but I could not find them. Bloatcheck on my hardened uclibc x86 gcc-3.4.6: function old new delta hdparm_main 1067 4894 +3827 print_flags_separated - 169 +169 print_flags - 76 +76 .rodata 31784 31833 +49 static.ml - 8 +8 static.ultra_modes2 - 4 +4 static.ultra_modes1 - 4 +4 static.pio_modes - 4 +4 static.labels - 4 +4 static.dma_wmodes - 4 +4 xbsd_print_disklabel 927 892 -35 arp_main 2474 2439 -35 ipaddr_list_or_flush 2732 2455 -277 process_dev 4446 - -4446 ------------------------------------------------------------------------------ (add/remove: 8/1 grow/shrink: 2/3 up/down: 4149/-4793) Total: -644 bytes text data bss dec hex filename 135156 2173 4500 141829 22a05 busybox_old 134540 2361 4500 141401 22859 busybox_unstripped Thanks! -nc -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags2-arp.patch Type: text/x-patch Size: 1246 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080607/caa8509e/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags2-fdisk.patch Type: text/x-patch Size: 1137 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080607/caa8509e/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags2-hdparm.patch Type: text/x-patch Size: 3437 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080607/caa8509e/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags2-ip.patch Type: text/x-patch Size: 1031 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080607/caa8509e/attachment-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: print_flags2-libbb.patch Type: text/x-patch Size: 1996 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080607/caa8509e/attachment-0004.bin From vda.linux at googlemail.com Sat Jun 7 08:03:47 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 7 Jun 2008 17:03:47 +0200 Subject: [PATCH] print_flags() take 2: -644 bytes In-Reply-To: <484A837B.1000209@gmail.com> References: <484A837B.1000209@gmail.com> Message-ID: <200806071703.47335.vda.linux@googlemail.com> On Saturday 07 June 2008 14:47, Natanael Copa wrote: > So I collected the ideas/suggestions and prepared another set of patches. > > The biggest win is in hdparm, but this time there was a win in both > fdisk and arp too so i submit pathes for those too. Allyesconfig build revealed that there is another print_flags() already in the tree. > I grouped the masks array with the labels '\0' separated string into a > struct. They are always used together anyway and by grouping them we > save one parameter for every call. Not always. You cheated in hdparm because there one mask is used with two different labels. Result: > ? ?text ? ? ? data ? ? ? ?bss ? ? ? ?dec ? ? ? ?hex ? ?filename > ?135156 ? ? ? 2173 ? ? ? 4500 ? ? 141829 ? ? ?22a05 ? ?busybox_old > ?134540 ? ? ? 2361 ? ? ? 4500 ? ? 141401 ? ? ?22859 ? ?busybox_unstripped ^^^^ here It took some effort to bring allyesconfig busybox's data+bss to fit into 8k on i386. You grew data by 190 bytes. I proporse the following variant: text data bss dec hex filename 810564 624 7060 818248 c7c48 busybox_old 810002 624 7060 817686 c7a16 busybox_unstripped See attached. Can you confirm that it works for you too? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 3.patch Type: text/x-diff Size: 12270 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080607/fca820b1/attachment-0001.patch From natanael.copa at gmail.com Sat Jun 7 08:17:16 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Sat, 07 Jun 2008 17:17:16 +0200 Subject: [PATCH] print_flags() take 2: -644 bytes In-Reply-To: <200806071703.47335.vda.linux@googlemail.com> References: <484A837B.1000209@gmail.com> <200806071703.47335.vda.linux@googlemail.com> Message-ID: <484AA67C.3050308@gmail.com> Denys Vlasenko wrote: > I proporse the following variant: > > text data bss dec hex filename > 810564 624 7060 818248 c7c48 busybox_old > 810002 624 7060 817686 c7a16 busybox_unstripped > > See attached. Can you confirm that it works for you too? > Yes, looks good. Seems to work. Thanks! -nc From martinb at zeelandnet.nl Sat Jun 7 10:19:46 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Sat, 7 Jun 2008 19:19:46 +0200 Subject: Wrong result on simple hush script (nommu / arm) In-Reply-To: <484AA67C.3050308@gmail.com> Message-ID: I have the following script: ---------------------------------------------------- #!/bin/hush if false then echo "test line 1" tmp=`ping -justawrongoption 127.0.0.1` fi ---------------------------------------------------- if i execute i get: /hdd/bustest # ./test.sh ping: illegal option -- j BusyBox v1.10.0 (2008-04-23 23:53:40 CEST) multi-call binary Usage: ping [OPTION]... host Send ICMP ECHO_REQUEST packets to network hosts Options: -4, -6 Force IPv4 or IPv6 hostname resolution -c CNT Send only CNT pings -s SIZE Send SIZE data bytes in packets (default=56) -I iface/IP Use interface or IP address as source -q Quiet, only displays output at start and when finished (i understand that i cant use the -justawongoption, but its just for testing) The result is wrong it should never run the 2e line "tmp=`ping -justawongoption 127.0.0.1` is this a know bug? do i make some error? if i change the script to: ---------------------------------------------------- #!/bin/hush if false then echo "test line 1" tmp=`echo test` fi ---------------------------------------------------- and a do a strace i get: /hdd/bustest # strace ./test.sh execve("./test.sh", ["./test.sh"], [/* 4 vars */]) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, 0, 0) = 0x1ca0000 getcwd("/hdd/bustest", 192) = 13 open("/etc/profile", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, TCGETS, 0x15bce58) = -1 ENOTTY (Inappropriate ioctl for device) old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, 0, 0) = 0x1cbe000 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, 0, 0) = 0x1cc3000 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 read(3, "# ~/.bashrc: executed by bash(1)"..., 4096) = 158 wait4(-1, 0x15bce30, WNOHANG|WUNTRACED, NULL) = -1 ECHILD (No child processes) read(3, "", 4096) = 0 close(3) = 0 open("./test.sh", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, TCGETS, 0x15bce50) = -1 ENOTTY (Inappropriate ioctl for device) fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 read(3, "#!/bin/sh\n\nif false\nthen\n\techo \""..., 4096) = 66 pipe([4, 5]) = 0 vfork() = 94 --- SIGCHLD (Child exited) @ 0 (0) --- close(5) = 0 fcntl(4, F_GETFL) = 0 (flags O_RDONLY) ioctl(4, TCGETS, 0x15bcd24) = -1 EINVAL (Invalid argument) old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, 0, 0) = 0x1cb1000 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 read(4, "test\n", 4096) = 5 read(4, "", 4096) = 0 close(4) = 0 vfork() = 95 wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WUNTRACED, NULL) = 94 wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 1], WUNTRACED, NULL) = 95 --- SIGCHLD (Child exited) @ 0 (0) --- wait4(-1, 0x15bcdbc, WNOHANG|WUNTRACED, NULL) = -1 ECHILD (No child processes) wait4(-1, 0x15bce30, WNOHANG|WUNTRACED, NULL) = -1 ECHILD (No child processes) read(3, "", 4096) = 0 _exit(1) = ? /hdd/bustest # config is attached -------------- next part -------------- A non-text attachment was scrubbed... Name: .config Type: application/octet-stream Size: 24810 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080607/6b8362c5/attachment-0001.obj From vda.linux at googlemail.com Sat Jun 7 16:39:49 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 8 Jun 2008 01:39:49 +0200 Subject: [patch] Let busybox use monotonical clock with old glibc (<2.3.4) In-Reply-To: <200806061735.12511.lich@math.spbu.ru> References: <200806061735.12511.lich@math.spbu.ru> Message-ID: <200806080139.49903.vda.linux@googlemail.com> On Friday 06 June 2008 15:35, Kirill K. Smirnov wrote: > Hi! > > This patch helps busybox built with old glibc use monotonical clock > (CLOCK_MONOTONIC). Applied, thanks! -- vda From cristian.ionescu-idbohrn at axis.com Sat Jun 7 18:23:39 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 8 Jun 2008 03:23:39 +0200 (CEST) Subject: [patch] include/usage.h In-Reply-To: <200806070742.14570.vda.linux@googlemail.com> References: <0806052014280.8921@somehost> <200806070742.14570.vda.linux@googlemail.com> Message-ID: <0806080258070.26504@somehost> On Sat, 7 Jun 2008, Denys Vlasenko wrote: > On Thursday 05 June 2008 20:18, Cristian Ionescu-Idbohrn wrote: > > Wouldn't this be more in line with the code? > > Not really. Only last six X's are required and subsequently replaced > by random chars. Yes, I saw that. But then I must have missed the point with changing the source, but not the documentation :( Thing is the generated file template suffix consists of 10 characters: # ./busybox mktemp tmp.XXXX8khaJC As I see it, the help is lieing. At least use the (partial) pid to fill up. Debian's mktemp does that (last part of the name): -rw------- 1 0 Jun 8 03:17 f.udPJH32269 -rw------- 1 0 Jun 8 02:50 x.ZehRz30532 -rw------- 1 153 Jun 7 23:34 serverauth.YZmiwh6819 drwx------ 2 80 Jun 7 23:34 ssh-lyMPxT6759/ Cheers, -- Cristian From vda.linux at googlemail.com Sun Jun 8 01:03:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 8 Jun 2008 10:03:50 +0200 Subject: [patch] include/usage.h In-Reply-To: <0806080258070.26504@somehost> References: <0806052014280.8921@somehost> <200806070742.14570.vda.linux@googlemail.com> <0806080258070.26504@somehost> Message-ID: <200806081003.50843.vda.linux@googlemail.com> On Sunday 08 June 2008 03:23, Cristian Ionescu-Idbohrn wrote: > On Sat, 7 Jun 2008, Denys Vlasenko wrote: > > > On Thursday 05 June 2008 20:18, Cristian Ionescu-Idbohrn wrote: > > > Wouldn't this be more in line with the code? > > > > Not really. Only last six X's are required and subsequently replaced > > by random chars. > > Yes, I saw that. But then I must have missed the point with changing the > source, but not the documentation :( Thing is the generated file > template suffix consists of 10 characters: Yes, for some strange reason default pattern has ten X chars, only last six of those are replaced. This matches coreutils. Help test says nothing about default pattern (in the name of keeping not-so essential info from bloating it). So where is the lie? > # ./busybox mktemp > tmp.XXXX8khaJC I don't see how this contradicts help text - # ./busybox mktemp --help BusyBox v1.11.0.svn (2008-06-07 21:53:08 CEST) multi-call binary Usage: mktemp [-dt] [-p DIR] [TEMPLATE] Create a temporary file with name based on TEMPLATE and print its name. TEMPLATE must end with XXXXXX (i.e., /tmp/temp.XXXXXX). Options: -d Make a directory instead of a file -t Generate a path rooted in temporary directory -p DIR Use DIR as a temporary directory (implies -t) For -t or -p, directory is chosen as follows: $TMPDIR if set, else -p DIR, else /tmp Do you feel that "(i.e., /tmp/temp.XXXXXX)" implies that that is the default? Will "(e.g. [/dir]/nameXXXXXX)" do better? -- vda From cristian.ionescu-idbohrn at axis.com Sun Jun 8 03:16:52 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 8 Jun 2008 12:16:52 +0200 (CEST) Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <0806051209180.6722@somehost> References: <0806032202570.16214@somehost> <200806051018.16958.vda.linux@googlemail.com> <0806051209180.6722@somehost> Message-ID: <0806081209471.26504@somehost> On Thu, 5 Jun 2008, Cristian Ionescu-Idbohrn wrote: > On Thu, 5 Jun 2008, Denys Vlasenko wrote: > > > On Tuesday 03 June 2008 22:06, Cristian Ionescu-Idbohrn wrote: > > > When using gdb, one would expect to have the source compiled with > > > '-g -O0', and not '-g -Os'. > > > > There were people who disagree (they say "debug what you ship"). > > I see only one way to leave BOTH camps happy. Create a CONFIG_DEBUG0 > > option (dependent on CONFIG_DEBUG) which forces -O0 build. > > Otherwise, -Os would be used. > > > > Can you do this? > > I'll have a look at it. Well, I found traces of this old controverse in topdir Config.in, DEBUG_PESSIMIZE commented out, so I just revived that. Attached the result. What do you think? Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_pessimize.patch Type: text/x-diff Size: 2392 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080608/0f362165/attachment.patch From cristian.ionescu-idbohrn at axis.com Sun Jun 8 03:18:02 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 8 Jun 2008 12:18:02 +0200 (CEST) Subject: [patch] include/usage.h In-Reply-To: <200806081003.50843.vda.linux@googlemail.com> References: <0806052014280.8921@somehost> <200806070742.14570.vda.linux@googlemail.com> <0806080258070.26504@somehost> <200806081003.50843.vda.linux@googlemail.com> Message-ID: <0806081117470.26504@somehost> On Sun, 8 Jun 2008, Denys Vlasenko wrote: > Help test says nothing about default pattern (in the name of keeping > not-so essential info from bloating it). So where is the lie? Please, don't pay too much attention to my rambings :) > > # ./busybox mktemp > > tmp.XXXX8khaJC > > I don't see how this contradicts help text - Maybe not... > # ./busybox mktemp --help > BusyBox v1.11.0.svn (2008-06-07 21:53:08 CEST) multi-call binary > > Usage: mktemp [-dt] [-p DIR] [TEMPLATE] > > Create a temporary file with name based on TEMPLATE and print its name. > TEMPLATE must end with XXXXXX (i.e., /tmp/temp.XXXXXX). > > Options: > -d Make a directory instead of a file > -t Generate a path rooted in temporary directory > -p DIR Use DIR as a temporary directory (implies -t) > > For -t or -p, directory is chosen as follows: > $TMPDIR if set, else -p DIR, else /tmp ...but it doesn't give any clue to why the default temp file/dir looks like this: # ./busybox mktemp -t;echo $? /tmp/tmp.XXXXvMGoLS ^^^^ And, by the way, the 4 added X:s don't add any entropy to the generated name. Just makes the name longer. Now, that I look more carefully at the code, I realize that as long as the 'mkdtemp' and 'mkstemp' are used, things won't get more entropic. So I have difficulties understanding the point with changing mktemp :( > Do you feel that "(i.e., /tmp/temp.XXXXXX)" implies that that is the > default? Seeing the extra X:s in the names, confused me. > Will "(e.g. [/dir]/nameXXXXXX)" do better? It might. But the important thing, in my opinion, would be to document the default behaviour. Cheers, -- Cristian From wharms at bfs.de Sun Jun 8 05:06:38 2008 From: wharms at bfs.de (walter harms) Date: Sun, 08 Jun 2008 14:06:38 +0200 Subject: [patch] include/usage.h In-Reply-To: <200806070742.14570.vda.linux@googlemail.com> References: <0806052014280.8921@somehost> <200806070742.14570.vda.linux@googlemail.com> Message-ID: <484BCB4E.7060705@bfs.de> Denys Vlasenko wrote: > On Thursday 05 June 2008 20:18, Cristian Ionescu-Idbohrn wrote: >> Wouldn't this be more in line with the code? > > Not really. Only last six X's are required and subsequently replaced > by random chars. > -- just for the books, ... this is not what my desktop version (Opensuse 10.0) of mktemp does: (based on OpenBSD: http://www.mktemp.org/) mktemp -t example.XXXXXXXXXX /tmp/example.wbqRL14143 mktemp /tmp/tmp.aTZTj14166 obviously there are more than 1 version in use and we can deside what it right. re, wh From aconrad.tlv at magic.fr Sun Jun 8 08:23:22 2008 From: aconrad.tlv at magic.fr (Alexandre Conrad) Date: Sun, 08 Jun 2008 17:23:22 +0200 Subject: regex tab in sed Message-ID: <484BF96A.3050808@magic.fr> Hi, I'm having a hard time to figure out how to represent the tab character in my regular expression pattern using sed: this works fine: cat foo.txt | sed 's/foo/bar/' this doesn't interpret the tab: cat foo.txt | sed 's/\tfoo/\tbar/' I've been reading the FAQ and sed manual, I find nothing. I tried with the "-r" option for sed described as "Use extended regular expression syntax". This works just fine under the "normal" sed. Any ideas ? Thanks. Regards, -- Alexandre CONRAD From vda.linux at googlemail.com Sun Jun 8 08:58:21 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 8 Jun 2008 17:58:21 +0200 Subject: regex tab in sed In-Reply-To: <484BF96A.3050808@magic.fr> References: <484BF96A.3050808@magic.fr> Message-ID: <200806081758.21819.vda.linux@googlemail.com> On Sunday 08 June 2008 17:23, Alexandre Conrad wrote: > Hi, > > I'm having a hard time to figure out how to represent the tab character > in my regular expression pattern using sed: > > this works fine: > cat foo.txt | sed 's/foo/bar/' > > this doesn't interpret the tab: > cat foo.txt | sed 's/\tfoo/\tbar/' > > I've been reading the FAQ and sed manual, I find nothing. I tried with > the "-r" option for sed described as "Use extended regular expression > syntax". > > This works just fine under the "normal" sed. Any ideas ? Thanks. Which version of busybox is yours? Mine works: # cat Makefile | ./busybox sed 's/\t/\BOO!/' | grep BOO! | head -10 BOO!$(if $(KBUILD_VERBOSE:1=),@)$(MAKE) -C $(KBUILD_OUTPUT) \ BOO!KBUILD_SRC=$(CURDIR) \ BOO!KBUILD_EXTMOD="$(KBUILD_EXTMOD)" -f $(CURDIR)/Makefile $@ srctreeBOO! := $(if $(KBUILD_SRC),$(KBUILD_SRC),$(CURDIR)) TOPDIRBOO! := $(srctree) objtreeBOO! := $(CURDIR) srcBOO! := $(srctree) objBOO! := $(objtree) VPATHBOO! := $(srctree)$(if $(KBUILD_EXTMOD),:$(KBUILD_EXTMOD)) BOO! -e s/arm.*/arm/ -e s/sa110/arm/ \ -- vda From cristian.ionescu-idbohrn at axis.com Sun Jun 8 09:21:14 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 8 Jun 2008 18:21:14 +0200 (CEST) Subject: regex tab in sed In-Reply-To: <484BF96A.3050808@magic.fr> References: <484BF96A.3050808@magic.fr> Message-ID: <0806081759090.26504@somehost> On Sun, 8 Jun 2008, Alexandre Conrad wrote: > I'm having a hard time to figure out how to represent the tab character > in my regular expression pattern using sed: > > this doesn't interpret the tab: > cat foo.txt | sed 's/\tfoo/\tbar/' By the way: $ sed 's/\tfoo/\tbar/' foo.txt is cheeper :) Various ways to do that. Would this help? $ ./busybox --help 2>&1 | head -n1 BusyBox v1.11.0.svn (2008-06-08 18:02:03 CEST) multi-call binary $ echo "abc foo 123" | hxdmp 00000000: 6162 6309 0966 6F6F 0931 3233 0A abc..foo.123. $ ./busybox echo "abc foo 123" | ./busybox sed -e "s/\tfoo/\tbar/" | hxdmp 00000000: 6162 6309 0962 6172 0931 3233 0A abc..bar.123. $ ./busybox echo "abc foo 123" | ./busybox sed -e "s/\011foo/\tbar/" | hxdmp 00000000: 6162 6309 0966 6F6F 0931 3233 0A abc..foo.123. $ ./busybox echo "abc foo 123" | ./busybox sed -e "s/[[:space:]]foo/\tbar/" | hxdmp 00000000: 6162 6309 0962 6172 0931 3233 0A abc..bar.123. Cheers, -- Cristian From aconrad.tlv at magic.fr Sun Jun 8 09:10:52 2008 From: aconrad.tlv at magic.fr (Alexandre Conrad) Date: Sun, 08 Jun 2008 18:10:52 +0200 Subject: regex tab in sed In-Reply-To: <200806081758.21819.vda.linux@googlemail.com> References: <484BF96A.3050808@magic.fr> <200806081758.21819.vda.linux@googlemail.com> Message-ID: <484C048C.2060904@magic.fr> Denys Vlasenko wrote: > Which version of busybox is yours? Mine works: Sorry, I thought I had given that: I'm using "BusyBox 1.1.3 (Debian 1:1.1.3-5ubuntu12) multi-call binary". It's a busybox shell running from the Ubuntu Hardy CD install (apparently, that's what the debian-installer is running on). Regards, -- Alexandre CONRAD From vda.linux at googlemail.com Sun Jun 8 09:34:24 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 8 Jun 2008 18:34:24 +0200 Subject: regex tab in sed In-Reply-To: <484C048C.2060904@magic.fr> References: <484BF96A.3050808@magic.fr> <200806081758.21819.vda.linux@googlemail.com> <484C048C.2060904@magic.fr> Message-ID: <200806081834.24923.vda.linux@googlemail.com> On Sunday 08 June 2008 18:10, Alexandre Conrad wrote: > Denys Vlasenko wrote: > > > Which version of busybox is yours? Mine works: > > Sorry, I thought I had given that: > > I'm using "BusyBox 1.1.3 (Debian 1:1.1.3-5ubuntu12) multi-call binary". > It's a busybox shell running from the Ubuntu Hardy CD install > (apparently, that's what the debian-installer is running on). Yes, as expected. It was fixed in a later version. -- vda From vda.linux at googlemail.com Sun Jun 8 09:43:48 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 8 Jun 2008 18:43:48 +0200 Subject: Wrong result on simple hush script (nommu / arm) In-Reply-To: References: Message-ID: <200806081843.48364.vda.linux@googlemail.com> On Saturday 07 June 2008 19:19, Martinb_ARM_NOMMU_KISSDVD wrote: > I have the following script: > > ---------------------------------------------------- > #!/bin/hush > > if false > then > echo "test line 1" > tmp=`ping -justawrongoption 127.0.0.1` > fi > ---------------------------------------------------- > > if i execute i get: > > /hdd/bustest # ./test.sh > ping: illegal option -- j > BusyBox v1.10.0 (2008-04-23 23:53:40 CEST) multi-call binary > > Usage: ping [OPTION]... host > > Send ICMP ECHO_REQUEST packets to network hosts > > Options: > -4, -6 Force IPv4 or IPv6 hostname resolution > -c CNT Send only CNT pings > -s SIZE Send SIZE data bytes in packets (default=56) > -I iface/IP Use interface or IP address as source > -q Quiet, only displays output at start > and when finished > > > (i understand that i cant use the -justawongoption, but its just for > testing) > > The result is wrong > it should never run the 2e line "tmp=`ping -justawongoption 127.0.0.1` > > is this a know bug? Yes :( I added it to hush testsuite for now -- vda From cristian.ionescu-idbohrn at axis.com Sun Jun 8 10:16:33 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 8 Jun 2008 19:16:33 +0200 (CEST) Subject: [patch] include/usage.h In-Reply-To: <0806081117470.26504@somehost> References: <0806052014280.8921@somehost> <200806070742.14570.vda.linux@googlemail.com> <0806080258070.26504@somehost> <200806081003.50843.vda.linux@googlemail.com> <0806081117470.26504@somehost> Message-ID: <0806081856010.26504@somehost> On Sun, 8 Jun 2008, Cristian Ionescu-Idbohrn wrote: > On Sun, 8 Jun 2008, Denys Vlasenko wrote: > > > # ./busybox mktemp --help > > BusyBox v1.11.0.svn (2008-06-07 21:53:08 CEST) multi-call binary > > > > Usage: mktemp [-dt] [-p DIR] [TEMPLATE] > > > > Create a temporary file with name based on TEMPLATE and print its name. > > TEMPLATE must end with XXXXXX (i.e., /tmp/temp.XXXXXX). By the way, I just pulled down coreutils from gnu.org and built. $ ./src/mktemp --version mktemp (GNU coreutils) 6.12.23-68158 Could the TEMPLATE line provide a better wording? $ ./src/mktemp --help Usage: ./src/mktemp [OPTION]... [TEMPLATE] Create a temporary file or directory, safely, and print its name. If TEMPLATE is not specified, use tmp.XXXXXXXXXX. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I checked the coreutils mktemp and debian ditto. They're different. coreutils$ ./src/mktemp -u /tmp/tmp.$(perl -e 'print "X"x40;') /tmp/tmp.Z4mPq71tp4LmiDovdemUHZNG4ig4Fktb7E2evlqt debian$ mktemp -u /tmp/tmp.$(perl -e 'print "X"x40;') /tmp/tmp.jkFdNGmRBHONugOgGRaRNwsMntSnIpPFnzH19308 ^^^^^ Debian's uses the pid for the last characters in the generated name. They don't use 'mkdtemp' or 'mkstemp' and the produced names provide the advertised randomness. Cheers, -- Cristian From cristian.ionescu-idbohrn at axis.com Sun Jun 8 10:42:03 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 8 Jun 2008 19:42:03 +0200 (CEST) Subject: just seen a warning I didn't notice before Message-ID: <0806081921000.26504@somehost> Showing up with 'make {menu,old}config': HOSTCC scripts/kconfig/zconf.tab.o scripts/kconfig/lex.zconf.c:1609: warning: 'input' defined but not used HOSTLD scripts/kconfig/conf Have no clue as how to sort that out. May be unimportant. Still, looking at the preprocessed code, that point is never reached: ,---- | static int input (void) | { | int c; | | *(yy_c_buf_p) = (yy_hold_char); | | if ( *(yy_c_buf_p) == 0 ) | { | if ( (yy_c_buf_p) < &(yy_buffer_stack)[(yy_buffer_stack_top)]->yy_ch_buf[(yy_n_chars)] ) | | *(yy_c_buf_p) = '\0'; | | else | { | int offset = (yy_c_buf_p) - (zconftext); | ++(yy_c_buf_p); | | switch ( yy_get_next_buffer( ) ) | { | case 2: | # 1643 "scripts/kconfig/lex.zconf.c" | zconfrestart(zconfin ); | | case 1: | { | -> if ( 1 ) | -> return (-1); | | if ( ! (yy_did_buffer_switch_on_eof) ) | zconfrestart(zconfin ); | | -> return input(); | } | | case 0: | (yy_c_buf_p) = (zconftext) + offset; | break; | } | } | } | | c = *(unsigned char *) (yy_c_buf_p); | *(yy_c_buf_p) = '\0'; | (yy_hold_char) = *++(yy_c_buf_p); | | return c; | } `---- Cheers, -- Cristian From wharms at bfs.de Sun Jun 8 12:19:25 2008 From: wharms at bfs.de (walter harms) Date: Sun, 08 Jun 2008 21:19:25 +0200 Subject: just seen a warning I didn't notice before In-Reply-To: <0806081921000.26504@somehost> References: <0806081921000.26504@somehost> Message-ID: <484C30BD.4070604@bfs.de> does the same apply to the original kernel zconf version ? re, wh Cristian Ionescu-Idbohrn wrote: > Showing up with 'make {menu,old}config': > > HOSTCC scripts/kconfig/zconf.tab.o > scripts/kconfig/lex.zconf.c:1609: warning: 'input' defined but not used > HOSTLD scripts/kconfig/conf > > Have no clue as how to sort that out. May be unimportant. Still, looking > at the preprocessed code, that point is never reached: > > ,---- > | static int input (void) > | { > | int c; > | > | *(yy_c_buf_p) = (yy_hold_char); > | > | if ( *(yy_c_buf_p) == 0 ) > | { > | if ( (yy_c_buf_p) < &(yy_buffer_stack)[(yy_buffer_stack_top)]->yy_ch_buf[(yy_n_chars)] ) > | > | *(yy_c_buf_p) = '\0'; > | > | else > | { > | int offset = (yy_c_buf_p) - (zconftext); > | ++(yy_c_buf_p); > | > | switch ( yy_get_next_buffer( ) ) > | { > | case 2: > | # 1643 "scripts/kconfig/lex.zconf.c" > | zconfrestart(zconfin ); > | > | case 1: > | { > | -> if ( 1 ) > | -> return (-1); > | > | if ( ! (yy_did_buffer_switch_on_eof) ) > | zconfrestart(zconfin ); > | > | -> return input(); > | } > | > | case 0: > | (yy_c_buf_p) = (zconftext) + offset; > | break; > | } > | } > | } > | > | c = *(unsigned char *) (yy_c_buf_p); > | *(yy_c_buf_p) = '\0'; > | (yy_hold_char) = *++(yy_c_buf_p); > | > | return c; > | } > `---- > > > Cheers, > From rep.dot.nop at gmail.com Sun Jun 8 12:31:24 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 8 Jun 2008 21:31:24 +0200 Subject: just seen a warning I didn't notice before In-Reply-To: <0806081921000.26504@somehost> References: <0806081921000.26504@somehost> Message-ID: <20080608193124.GC10040@mx.loc> On Sun, Jun 08, 2008 at 07:42:03PM +0200, Cristian Ionescu-Idbohrn wrote: >Showing up with 'make {menu,old}config': > > HOSTCC scripts/kconfig/zconf.tab.o >scripts/kconfig/lex.zconf.c:1609: warning: 'input' defined but not used I think you should discuss that with the kconfig people and fix it there. From cristian.ionescu-idbohrn at axis.com Sun Jun 8 12:49:23 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 8 Jun 2008 21:49:23 +0200 (CEST) Subject: just seen a warning I didn't notice before In-Reply-To: <20080608193124.GC10040@mx.loc> References: <0806081921000.26504@somehost> <20080608193124.GC10040@mx.loc> Message-ID: <0806082145160.26504@somehost> On Sun, 8 Jun 2008, Bernhard Fischer wrote: > On Sun, Jun 08, 2008 at 07:42:03PM +0200, Cristian Ionescu-Idbohrn wrote: > >Showing up with 'make {menu,old}config': > > > > HOSTCC scripts/kconfig/zconf.tab.o > >scripts/kconfig/lex.zconf.c:1609: warning: 'input' defined but not used > > I think you should discuss that with the kconfig people and fix it > there. Really? Why? Is it important? If that's the case, why not "fix" it here and ackowledge the "kconfig people" instead? Cheers, -- Cristian From vapier at gentoo.org Sun Jun 8 13:40:46 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 8 Jun 2008 16:40:46 -0400 Subject: just seen a warning I didn't notice before In-Reply-To: <0806082145160.26504@somehost> References: <0806081921000.26504@somehost> <20080608193124.GC10040@mx.loc> <0806082145160.26504@somehost> Message-ID: <200806081640.47967.vapier@gentoo.org> On Sunday 08 June 2008, Cristian Ionescu-Idbohrn wrote: > On Sun, 8 Jun 2008, Bernhard Fischer wrote: > > On Sun, Jun 08, 2008 at 07:42:03PM +0200, Cristian Ionescu-Idbohrn wrote: > > >Showing up with 'make {menu,old}config': > > > > > > HOSTCC scripts/kconfig/zconf.tab.o > > >scripts/kconfig/lex.zconf.c:1609: warning: 'input' defined but not used > > > > I think you should discuss that with the kconfig people and fix it > > there. > > Really? Why? Is it important? > > If that's the case, why not "fix" it here and ackowledge the "kconfig > people" instead? because the point of using kconfig is we dont have to maintain it -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080608/06f65952/attachment.pgp From vda.linux at googlemail.com Sun Jun 8 15:53:34 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 9 Jun 2008 00:53:34 +0200 Subject: just seen a warning I didn't notice before In-Reply-To: <200806081640.47967.vapier@gentoo.org> References: <0806081921000.26504@somehost> <0806082145160.26504@somehost> <200806081640.47967.vapier@gentoo.org> Message-ID: <200806090053.34591.vda.linux@googlemail.com> On Sunday 08 June 2008 22:40, Mike Frysinger wrote: > > > >Showing up with 'make {menu,old}config': > > > > > > > > HOSTCC scripts/kconfig/zconf.tab.o > > > >scripts/kconfig/lex.zconf.c:1609: warning: 'input' defined but not used > > > > > > I think you should discuss that with the kconfig people and fix it > > > there. > > > > Really? Why? Is it important? > > > > If that's the case, why not "fix" it here and ackowledge the "kconfig > > people" instead? > > because the point of using kconfig is we dont have to maintain it I didn't test, but I think getting that warning is possible only if HOSTCFLAGS is modified, no? -- vda From gururajakr at sanyo.co.in Mon Jun 9 02:37:50 2008 From: gururajakr at sanyo.co.in (Gururaja Hebbar K R) Date: Mon, 9 Jun 2008 15:07:50 +0530 Subject: Need help solve " We unsupport $((arith)) " Syntax Error Message-ID: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCB@blrms.slti.sanyo.co.in> Hi All, I am using Busybox-1.10.2 (full patch applied) built with CodeSourcery ARM926EJS toolchain to compile Busybox to run on customized arm versatile board, i am using few init scripts to run and while running /etc/init.d/rc i get error as Syntax error: We unsupport $((arith)) when i checked the file, it had something like this step=$(($step + $step_change)) I tried to remove the double brackets and make it look as step=$($step + $step_change) this stopped the error to appear at this point and started appearing at other points. This file has a lot of such declarations. I tried removing all those double brackets but i think its wrong to do that. Any help,advice, updates, changes is highly helpful TIA Regards Gururaja From vapier at gentoo.org Mon Jun 9 02:37:21 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 9 Jun 2008 05:37:21 -0400 Subject: Need help solve " We unsupport $((arith)) " Syntax Error In-Reply-To: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCB@blrms.slti.sanyo.co.in> References: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCB@blrms.slti.sanyo.co.in> Message-ID: <200806090537.21964.vapier@gentoo.org> On Monday 09 June 2008, Gururaja Hebbar K R wrote: > i am using few init scripts to run and while running /etc/init.d/rc i > get error as > > Syntax error: We unsupport $((arith)) well if you dont enable math support in the busybox config, you really shouldnt be surprised when it doesnt work > when i checked the file, it had something like this > > step=$(($step + $step_change)) > > I tried to remove the double brackets and make it look as > > step=$($step + $step_change) that's clearly wrong seeing as how those statements arent close to having the same meaning -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080609/b3d21692/attachment.pgp From gururajakr at sanyo.co.in Mon Jun 9 03:39:47 2008 From: gururajakr at sanyo.co.in (Gururaja Hebbar K R) Date: Mon, 9 Jun 2008 16:09:47 +0530 Subject: Need help solve " We unsupport $((arith)) " Syntax Error References: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCB@blrms.slti.sanyo.co.in> <200806090537.21964.vapier@gentoo.org> Message-ID: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCF@blrms.slti.sanyo.co.in> Hi >> i am using few init scripts to run and while running /etc/init.d/rc i >> get error as >> >> Syntax error: We unsupport $((arith)) >well if you dont enable math support in the busybox config, you really shouldnt be surprised when it doesnt work > when i checked the file, it had something like this > > step=$(($step + $step_change)) > > I tried to remove the double brackets and make it look as > > step=$($step + $step_change) >that's clearly wrong seeing as how those statements arent close to having the same meaning -mike Thanks for the quick solution. my mistake that i hadn't enabled it. Regards Gururaja From g.esp at free.fr Mon Jun 9 04:39:30 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Mon, 09 Jun 2008 13:39:30 +0200 Subject: Need help solve " We unsupport $((arith)) " Syntax Error In-Reply-To: <200806090537.21964.vapier@gentoo.org> References: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCB@blrms.slti.sanyo.co.in> <200806090537.21964.vapier@gentoo.org> Message-ID: <1213011570.484d1672bb59c@imp.free.fr> Selon Mike Frysinger : > On Monday 09 June 2008, Gururaja Hebbar K R wrote: > > i am using few init scripts to run and while running /etc/init.d/rc i > > get error as > > > > Syntax error: We unsupport $((arith)) > > well if you dont enable math support in the busybox config, you really > shouldnt be surprised when it doesnt work > Would it not more clear to answer something like 'math support no selected' than 'We unsupport $((arith))'? Gilles From rep.dot.nop at gmail.com Mon Jun 9 04:49:19 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 9 Jun 2008 13:49:19 +0200 Subject: Need help solve " We unsupport $((arith)) " Syntax Error In-Reply-To: <1213011570.484d1672bb59c@imp.free.fr> References: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCB@blrms.slti.sanyo.co.in> <200806090537.21964.vapier@gentoo.org> <1213011570.484d1672bb59c@imp.free.fr> Message-ID: <20080609114919.GC21017@mx.loc> On Mon, Jun 09, 2008 at 01:39:30PM +0200, Gilles Espinasse wrote: >Would it not more clear to answer something like 'math support no selected' than >'We unsupport $((arith))'? see r22276 From manuprivat at gmx.de Mon Jun 9 06:35:36 2008 From: manuprivat at gmx.de (Manu) Date: Mon, 09 Jun 2008 15:35:36 +0200 Subject: udhcpd In-Reply-To: <200806061528.29021.vda.linux@googlemail.com> References: <48493540.3000705@gmx.de> <200806061528.29021.vda.linux@googlemail.com> Message-ID: <484D31A8.8060506@gmx.de> Denys Vlasenko schrieb: > On Friday 06 June 2008 15:01, Manu wrote: > >> Hi there, >> >> I encountered a problem with udhcpd in combination with a ISP, that >> drops every ping request! >> I can only surf with IP not by name - the DNS doesn't work! >> Tvcabo is a big cable isp in Portugal and ex-portugal colonies. >> On a fixed I-net-IP tvcabo net, with ping allowed the name resolution >> works fine. >> On DSL with ping allowed, the name resolution works fine. >> On NON-fixed-IP tvcabo net, with ping not allowed, the name resolution >> doesn't work!!! >> >> I can confiure 2 nameservers. >> In the fix I-net-IP test I set in 'nameserver' = 196.46.0.236 ( tvcabo >> dns WITH PING DROP ) >> and in 'Nameserver2' = 80.58.0.33 (telefonica dns WITHOUT PING DROP ) >> I receive by dhcp, the telefonica dns!! I dont understand it!? >> Is there a possibility to configure udhcpd to not test the DNS servers! >> > > Show your udhcpc command line and log; tcpdump trace and the like. > As of now, the description you gave lacks details needed to diagnose > the problem. > > I don't use udhcpc as client. I have a small linux system with busybox an the udhcpd from busybox running. This system acts like a router. There are two Networkinterfaces LAN1=WAN; LAN2=LAN - and there are many PC's, laptop with different operating systems connected via LAN2. The small linux systems provides them IP-addresses with udhcpd. I going to get a tcpdump trace! what do you mean with the like? >> Is there a ping in the background to check if the DNS-Server is available?! >> > > No, udhcpc does not do any tests by pinging. > -- > vda > > Thank you very much for the fast response! what about the udhcpd - does the daemon do a ping on the nameserver? regards, manu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080609/0d29c389/attachment.htm From joakim.tjernlund at transmode.se Mon Jun 9 04:53:27 2008 From: joakim.tjernlund at transmode.se (Joakim Tjernlund) Date: Mon, 9 Jun 2008 13:53:27 +0200 Subject: [PATCH] seq_file: make seq_lseek accept SEEK_END In-Reply-To: <200806091501.13170.adobriyan@parallels.com> References: <200806091501.13170.adobriyan@parallels.com> Message-ID: <1213012375.16530.9.camel@gentoo-jocke.transmode.se> busybox has been fixed, at least in trunk, not to do xlseek(fd, 0, SEEK_END) anymore to address this problem. Perhaps there are other apps out there that needs this too, but I don't know of any. Older busyboxes needs this change though. I have moved on and don't have a setup handy where I can test this. Perhaps someone at the bb list has, CC:ing bb list. Jocke On Mon, 2008-06-09 at 15:01 +0400, Alexey Dobriyan wrote: > Apologies for delay, such simple thing should have been sent long ago. > Joakim, please, confirm. > ------------------------------------------- > [PATCH] seq_file: make seq_lseek accept SEEK_END > > and pretend seq_files have zero length. This should be enough > to fix busybox start-stop-daemon: > http://marc.info/?t=120836691600002&r=1&w=2 > > It does xlseek(fd, 0, SEEK_END) to estimate amount of memory to malloc > but satisfied with 0. Sudden -EINVAL from lseek(2) breaks it. > > X-Introduced-By: f16278c679aa72e28288435b313ba2d4494d6be5 > Signed-off-by: Alexey Dobriyan > --- > > fs/seq_file.c | 2 ++ > 1 file changed, 2 insertions(+) > > --- a/fs/seq_file.c > +++ b/fs/seq_file.c > @@ -254,6 +254,8 @@ loff_t seq_lseek(struct file *file, loff_t offset, int origin) > switch (origin) { > case 1: > offset += file->f_pos; > + case 2: > + /* pretend it's zero length */ > case 0: > if (offset < 0) > break; > > From alexander.griesser at lkh-vil.or.at Mon Jun 9 07:59:44 2008 From: alexander.griesser at lkh-vil.or.at (Alexander Griesser) Date: Mon, 09 Jun 2008 16:59:44 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card Message-ID: <484D4560.6040507@lkh-vil.or.at> Hi list! I encountered a strange problem today (took me quite some time to find out what's wrong). I'm currently using busybox 1.10.3 and am trying to get an IP address on my RAlink 2501 USB wireless card using the rt73 driver from ralinktech.com. When I start `udhcpc -i rausb0` it never completes: # strace -f -o /tmp/bb-udhcpc.out /sbin/udhcpc -i rausb0 udhcpc (v1.10.3) started Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... I've attached this strace output. When I'm using my distributions `udhcpc`, it works without problems. # strace -f -o /tmp/gnu-udhcpc.out ./udhcpc -i rausb0 -s /bin/udhcpc.sh udhcpc (v0.9.9-pre) started Sending discover... Sending discover... Sending select for 10.35.100.63... Lease of 10.35.100.63 obtained, lease time 2592000 What's wrong with busybox' udhcpc? ciao, -- Alexander Griesser (Netzwerkadministration) E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach Tel.: +43 4242 208 3061 | Fax.: +43 4242 971 3061 -------------- next part -------------- A non-text attachment was scrubbed... Name: bb-udhcpc.out.gz Type: application/x-gzip Size: 3823 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080609/4b7bcabb/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: gnu-udhcpc.out.gz Type: application/x-gzip Size: 4881 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080609/4b7bcabb/attachment-0001.bin From dnlombar at ichips.intel.com Mon Jun 9 08:11:03 2008 From: dnlombar at ichips.intel.com (Lombard, David N) Date: Mon, 9 Jun 2008 08:11:03 -0700 Subject: mdev race conditions In-Reply-To: <484558CA.8070308@largestprime.net> References: <484558CA.8070308@largestprime.net> Message-ID: <20080609151103.GA10743@nlxdcldnl2.cl.intel.com> On Tue, Jun 03, 2008 at 10:44:26PM +0800, Bernard Blackham wrote: > Hi, > > When I switched from udev+udevd to mdev, booting was much faster and it > shaved a decent amount from the total image size. That's why I switched from udev to mdev--it's much, much smaller! > However, I've recently > noticed device nodes sometimes disappearing on boot. The specific > scenario is: > > 1. /dev/ttyS1 exists as a device node in the filesystem on boot - prior > to the actual device existing, and prior to mdev being called. Is that because you're using a serial console? It is in my case. > 2. echo /bin/mdev > /proc/sys/kernel/hotplug Good, that's per documentation. Did you also do this? mdev -s > 3. a module is loaded that provides ttyS1 I'm running a non-modular kernel. > When this module is loaded, most of the time the existing ttyS1 remains. > Sometimes however, it is unlinked from the filesystem and is never seen > again (until mdev -s is run, or next boot, maybe). Do you mean you need to do "mdev -s" more than once? My startup (/etc/init.d/rcS) is: mount -t proc none /proc mount -t sysfs none /sys echo /sbin/mdev > /proc/sys/kernel/hotplug /sbin/mdev -s This works quite reliably for me w/ busybox-1.8.2. -- David N. Lombard, Intel, Irvine, CA I do not speak for Intel Corporation; all comments are strictly my own. From dnlombar at ichips.intel.com Mon Jun 9 08:47:05 2008 From: dnlombar at ichips.intel.com (Lombard, David N) Date: Mon, 9 Jun 2008 08:47:05 -0700 Subject: regex tab in sed In-Reply-To: <484BF96A.3050808@magic.fr> References: <484BF96A.3050808@magic.fr> Message-ID: <20080609154705.GA11155@nlxdcldnl2.cl.intel.com> On Sun, Jun 08, 2008 at 05:23:22PM +0200, Alexandre Conrad wrote: > Hi, > > I'm having a hard time to figure out how to represent the tab character > in my regular expression pattern using sed: Putting a tab directly into the script works fine--but does require care in editing... -- David N. Lombard, Intel, Irvine, CA I do not speak for Intel Corporation; all comments are strictly my own. From vda.linux at googlemail.com Mon Jun 9 09:41:07 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 9 Jun 2008 18:41:07 +0200 Subject: mdev race conditions In-Reply-To: <20080609151103.GA10743@nlxdcldnl2.cl.intel.com> References: <484558CA.8070308@largestprime.net> <20080609151103.GA10743@nlxdcldnl2.cl.intel.com> Message-ID: <200806091841.07038.vda.linux@googlemail.com> On Monday 09 June 2008 17:11, Lombard, David N wrote: > > 3. a module is loaded that provides ttyS1 > > I'm running a non-modular kernel. > > > When this module is loaded, most of the time the existing ttyS1 remains. > > Sometimes however, it is unlinked from the filesystem and is never seen > > again (until mdev -s is run, or next boot, maybe). > > Do you mean you need to do "mdev -s" more than once? No, he means that multiple mdev's race and sometimes creation of device happens before removal. Which results in device node created and then promptly deleted again. -- vda From vda.linux at googlemail.com Mon Jun 9 09:41:53 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 9 Jun 2008 18:41:53 +0200 Subject: regex tab in sed In-Reply-To: <20080609154705.GA11155@nlxdcldnl2.cl.intel.com> References: <484BF96A.3050808@magic.fr> <20080609154705.GA11155@nlxdcldnl2.cl.intel.com> Message-ID: <200806091841.53583.vda.linux@googlemail.com> On Monday 09 June 2008 17:47, Lombard, David N wrote: > On Sun, Jun 08, 2008 at 05:23:22PM +0200, Alexandre Conrad wrote: > > Hi, > > > > I'm having a hard time to figure out how to represent the tab character > > in my regular expression pattern using sed: > > Putting a tab directly into the script works fine--but does require > care in editing... ash awaits a hero who will implement a $'...\t...' bash-ism -- vda From gururajakr at sanyo.co.in Mon Jun 9 01:48:17 2008 From: gururajakr at sanyo.co.in (Gururaja Hebbar K R) Date: Mon, 9 Jun 2008 14:18:17 +0530 Subject: Need help solve " We unsupport $((arith)) " Syntax Error References: Message-ID: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDFCA@blrms.slti.sanyo.co.in> Hi All, I am using Busybox-1.10.2 (full patch applied) built with CodeSourcery ARM926EJS toolchain to compile Busybox to run on customized arm versatile board, i am using few init scripts to run and while running /etc/init.d/rc i get error as Syntax error: We unsupport $((arith)) when i checked the file, it had something like this step=$(($step + $step_change)) I tried to remove the double brackets and make it look as step=$($step + $step_change) this stopped the error to appear at this point and started appearing at other points. This file has a lot of such declarations. I tried removing all those double brackets but i think its wrong to do that. Any help,advice, updates, changes is highly helpful TIA Regards Gururaja From wharms at bfs.de Tue Jun 10 09:52:05 2008 From: wharms at bfs.de (walter harms) Date: Tue, 10 Jun 2008 18:52:05 +0200 Subject: using -fPIE (was Re: mdev race conditions) In-Reply-To: <200806070755.41507.vda.linux@googlemail.com> References: <484558CA.8070308@largestprime.net> <200806041327.50192.vda.linux@googlemail.com> <4846888A.60906@bfs.de> <200806070755.41507.vda.linux@googlemail.com> Message-ID: <484EB135.7080705@bfs.de> Denys Vlasenko wrote: > On Wednesday 04 June 2008 14:20, walter harms wrote: >> maybe this explanation is helpful >> >> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00145.html > > Well, it explains what PIE is, but does not explain in which > situations PIE bring some substantial benefits. > We need a snippet of text which lets a user who didn't hear > about PIE *at all* decide whether he needs it or not. > -- SO far i understand PIE is only useful as countermeasure against exploids using buffer overflows since it is no more easy to assume the address. (perhaps that can be circumvented using PIE injection code, no idea). For now i thing this is a custom compile option. re, wh From vda.linux at googlemail.com Tue Jun 10 13:13:22 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 10 Jun 2008 22:13:22 +0200 Subject: Wrong result on simple hush script (nommu / arm) In-Reply-To: References: Message-ID: <200806102213.22251.vda.linux@googlemail.com> On Saturday 07 June 2008 19:19, Martinb_ARM_NOMMU_KISSDVD wrote: > I have the following script: > > ---------------------------------------------------- > #!/bin/hush > > if false > then > echo "test line 1" > tmp=`ping -justawrongoption 127.0.0.1` > fi > ---------------------------------------------------- > > if i execute i get: > > /hdd/bustest # ./test.sh > ping: illegal option -- j > BusyBox v1.10.0 (2008-04-23 23:53:40 CEST) multi-call binary > > Usage: ping [OPTION]... host > > Send ICMP ECHO_REQUEST packets to network hosts > > Options: > -4, -6 Force IPv4 or IPv6 hostname resolution > -c CNT Send only CNT pings > -s SIZE Send SIZE data bytes in packets (default=56) > -I iface/IP Use interface or IP address as source > -q Quiet, only displays output at start > and when finished > > (i understand that i cant use the -justawongoption, but its just for > testing) I fixed it now, can you test it? Just replace hush.c with the attached file. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: hush.c.bz2 Type: application/x-bzip2 Size: 30768 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080610/bb67ae42/attachment-0001.bin From impulze at impulze.org Tue Jun 10 17:43:25 2008 From: impulze at impulze.org (Daniel Mierswa) Date: Wed, 11 Jun 2008 02:43:25 +0200 Subject: possible bug in mdev (r21557) In-Reply-To: <200805262201.52321.vda.linux@googlemail.com> References: <483A192E.2040400@impulze.org> <200805261445.29450.vda.linux@googlemail.com> <483ACA60.9030608@impulze.org> <200805262201.52321.vda.linux@googlemail.com> Message-ID: <484F1FAD.8040807@impulze.org> On 26.05.2008 22:01, Denys Vlasenko: > I'm sorry, but where are "PATH" and "DEVICE" strings? > bb+AF8-error+AF8-msg contains them, so they ought to be visible. > > If you want bug to be fixed, you have to spend a bit of your time > writing your responses so that they have a high chance of being > understood by the recipient. Your first post was good (you spent > considerable time tracking bug down), but this one is not. > > For one, 5th char in this path is 'c', and therefore 1.8.3 > would create a char device too: > > type = path[5]=='c' ? S+AF8-IFCHR : S+AF8-IFBLK; > > It means that you are probably showing wrong path. It's not > the path which causes the problem. > -- > vda > I'm not sure what you mean. The revision previous to the one failing for me checked if the path next to /sys is class/block or block (now it's just checking for block by using strncmp(+ACY-path[5],"block/", 6)). But appearently my usbdevice is created with /sys/class/usbendpoint which is why the type = path[5] == 'c' ? S+AF8-IFCHR : S+AF8-IFBLK; determined that just right. Later revisions can't. Now this is either a kernel bug (2.6.25.4) because that device is functioning pretty good yet the kernel docs claim that block devices are no longer detected this way. Or it's something I didn't understand yet. I attached the output of the 21556 rev and 21557 rev. Both are created via: mdev -s >log 2>+ACY-1 +ACYAJg- blkid >> log 2>+ACY-1 If there's anything you need to know in advance please let me know. -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mdev-fail-log Url: http:+AC8ALw-busybox.net+AC8-lists+AC8-busybox+AC8-attachments+AC8-20080611+AC8-0ebc1136+AC8-attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mdev-good-log Url: http:+AC8ALw-busybox.net+AC8-lists+AC8-busybox+AC8-attachments+AC8-20080611+AC8-0ebc1136+AC8-attachment-0001.txt From roberto.foglietta at gmail.com Wed Jun 11 00:45:58 2008 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Wed, 11 Jun 2008 09:45:58 +0200 Subject: msh if not Message-ID: Hi to all, I would know how I can write this if ! true; then echo ciao; fi in msh's dialet because msh does not recognize ! (not) Thanks, -- /roberto From rep.dot.nop at gmail.com Wed Jun 11 01:09:45 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 11 Jun 2008 10:09:45 +0200 Subject: msh if not In-Reply-To: References: Message-ID: <20080611080945.GF1688@mx.loc> On Wed, Jun 11, 2008 at 09:45:58AM +0200, Roberto A. Foglietta wrote: >Hi to all, > > I would know how I can write this > > if ! true; then echo ciao; fi if test ! true; then echo use test;fi From Ralf.Friedl at online.de Wed Jun 11 03:55:05 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Wed, 11 Jun 2008 12:55:05 +0200 Subject: msh if not In-Reply-To: References: Message-ID: <484FAF09.3070402@online.de> Roberto A. Foglietta wrote: > I would know how I can write this > > if ! true; then echo ciao; fi > > in msh's dialet because msh does not recognize ! (not) You can use the else part: if true; then :; else echo ciao; fi Regards Ralf Friedl From dnlombar at ichips.intel.com Wed Jun 11 06:25:57 2008 From: dnlombar at ichips.intel.com (Lombard, David N) Date: Wed, 11 Jun 2008 06:25:57 -0700 Subject: msh if not In-Reply-To: References: Message-ID: <20080611132557.GA26494@nlxdcldnl2.cl.intel.com> On Wed, Jun 11, 2008 at 09:45:58AM +0200, Roberto A. Foglietta wrote: > Hi to all, > > I would know how I can write this > > if ! true; then echo ciao; fi true || echo ciao -- David N. Lombard, Intel, Irvine, CA I do not speak for Intel Corporation; all comments are strictly my own. From martinb at zeelandnet.nl Wed Jun 11 12:24:57 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Wed, 11 Jun 2008 21:24:57 +0200 Subject: Wrong result on simple hush script (nommu / arm) In-Reply-To: <200806102213.22251.vda.linux@googlemail.com> Message-ID: if i try it on current 1.10.3 i get: CC shell/hush.o shell/hush.c:89:2: warning: #warning On NOMMU, hush command substitution is dangerous. shell/hush.c:90:2: warning: #warning Dont use it for commands which produce lots of output. shell/hush.c:91:2: warning: #warning For more info see shell/hush.c, generate_stream_from_list(). shell/hush.c: In function `builtin_read': shell/hush.c:1075: error: too many arguments to function `xmalloc_reads' make[1]: *** [shell/hush.o] Fout 1 do i need cvs ? > -----Oorspronkelijk bericht----- > Van: Denys Vlasenko [mailto:vda.linux at googlemail.com] > Verzonden: dinsdag 10 juni 2008 22:13 > Aan: Martinb_ARM_NOMMU_KISSDVD > CC: busybox at busybox.net > Onderwerp: Re: Wrong result on simple hush script (nommu / arm) > > > On Saturday 07 June 2008 19:19, Martinb_ARM_NOMMU_KISSDVD wrote: > > I have the following script: > > > > ---------------------------------------------------- > > #!/bin/hush > > > > if false > > then > > echo "test line 1" > > tmp=`ping -justawrongoption 127.0.0.1` > > fi > > ---------------------------------------------------- > > > > if i execute i get: > > > > /hdd/bustest # ./test.sh > > ping: illegal option -- j > > BusyBox v1.10.0 (2008-04-23 23:53:40 CEST) multi-call binary > > > > Usage: ping [OPTION]... host > > > > Send ICMP ECHO_REQUEST packets to network hosts > > > > Options: > > -4, -6 Force IPv4 or IPv6 hostname resolution > > -c CNT Send only CNT pings > > -s SIZE Send SIZE data bytes in packets (default=56) > > -I iface/IP Use interface or IP address as source > > -q Quiet, only displays output at start > > and when finished > > > > (i understand that i cant use the -justawongoption, but its just for > > testing) > > I fixed it now, can you test it? Just replace hush.c > with the attached file. > -- > vda > From vda.linux at googlemail.com Wed Jun 11 14:38:46 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 11 Jun 2008 23:38:46 +0200 Subject: Wrong result on simple hush script (nommu / arm) In-Reply-To: References: Message-ID: <200806112338.46163.vda.linux@googlemail.com> On Wednesday 11 June 2008 21:24, Martinb_ARM_NOMMU_KISSDVD wrote: > if i try it on current 1.10.3 i get: > > CC shell/hush.o > shell/hush.c:89:2: warning: #warning On NOMMU, hush command substitution is > dangerous. > shell/hush.c:90:2: warning: #warning Dont use it for commands which produce > lots of output. > shell/hush.c:91:2: warning: #warning For more info see shell/hush.c, > generate_stream_from_list(). > shell/hush.c: In function `builtin_read': > shell/hush.c:1075: error: too many arguments to function `xmalloc_reads' > make[1]: *** [shell/hush.o] Fout 1 > > > do i need cvs ? Yes, testing cvs is preferred. -- vda From vda.linux at googlemail.com Thu Jun 12 00:23:53 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 12 Jun 2008 09:23:53 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <484D4560.6040507@lkh-vil.or.at> References: <484D4560.6040507@lkh-vil.or.at> Message-ID: <200806120923.53053.vda.linux@googlemail.com> On Monday 09 June 2008 16:59, Alexander Griesser wrote: > Hi list! > > I encountered a strange problem today (took me quite some time to find > out what's wrong). > I'm currently using busybox 1.10.3 and am trying to get an IP address on > my RAlink 2501 USB wireless card using the rt73 driver from ralinktech.com. > > When I start `udhcpc -i rausb0` it never completes: > > # strace -f -o /tmp/bb-udhcpc.out /sbin/udhcpc -i rausb0 > udhcpc (v1.10.3) started > Sending discover... > Sending discover... > Sending discover... > Sending discover... > Sending discover... > Sending discover... > Sending discover... > Sending discover... > Sending discover... > > I've attached this strace output. Hmmm. Does it help if you delete this code block? if (SERVER_PORT == 67 && CLIENT_PORT == 68) { /* Use only if standard ports are in use */ /* Ignoring error (kernel may lack support for this) */ if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, &filter_prog, sizeof(filter_prog)) >= 0) DEBUG("attached filter to raw socket fd %d", fd); } > When I'm using my distributions `udhcpc`, it works without problems. > > # strace -f -o /tmp/gnu-udhcpc.out ./udhcpc -i rausb0 -s /bin/udhcpc.sh > udhcpc (v0.9.9-pre) started > Sending discover... > Sending discover... > Sending select for 10.35.100.63... > Lease of 10.35.100.63 obtained, lease time 2592000 Can you collect "tcpdump -nlieth0 -s0 -vvv -xX port 67 or port 68" output for both? -- vda From vbuell at gmail.com Thu Jun 12 08:22:05 2008 From: vbuell at gmail.com (Volodymyr Buell) Date: Thu, 12 Jun 2008 18:22:05 +0300 Subject: [patch] ls: better column formatting for unicode characters. Message-ID: <7bed83ad0806120822r69c8500xfc1794940aee2cc4@mail.gmail.com> Hi. Ls command produce file list formatted incorrectly when filenames contain unicode characters: columns are shifted to the left when multibyte chars are present in file names. There is the patch that solve this issue. New option in configuration was added to support widechars as well... wchar.h and ctype.h are needed to be included in libbb.h (mayby) but they were placed here since it's used only in ls.c. -- Thanks Volodymyr Index: coreutils/ls.c =================================================================== --- coreutils/ls.c (revision 22297) +++ coreutils/ls.c (working copy) @@ -31,6 +31,11 @@ #include "libbb.h" +#if ENABLE_FEATURE_LS_WIDECHARS +#include +#include +#endif + /* This is a NOEXEC applet. Be very careful! */ @@ -141,7 +146,10 @@ static struct dnode **list_dir(const char *); static struct dnode **dnalloc(int); -static int list_single(struct dnode *); +static int list_single(const struct dnode *); +#if ENABLE_FEATURE_LS_WIDECHARS +int mbstrlen(const char *string, size_t nbytes); +#endif static unsigned all_fmt; @@ -395,7 +403,11 @@ } else { /* find the longest file name, use that as the column width */ for (i = 0; i < nfiles; i++) { +#if ENABLE_FEATURE_LS_WIDECHARS + int len = mbstrlen(dn[i]->name, strlen(dn[i]->name)); +#else int len = strlen(dn[i]->name); +#endif if (column_width < len) column_width = len; } @@ -544,7 +556,7 @@ static time_t current_time_t; #endif -static int list_single(struct dnode *dn) +static int list_single(const struct dnode *dn) { int i, column = 0; @@ -651,16 +663,23 @@ break; #endif case LIST_FILENAME: - errno = 0; + { + errno = 0; #if ENABLE_FEATURE_LS_COLOR - if (show_color && !lstat(dn->fullname, &info)) { - printf("\033[%d;%dm", bgcolor(info.st_mode), + if (show_color && !lstat(dn->fullname, &info)) { + printf("\033[%d;%dm", bgcolor(info.st_mode), fgcolor(info.st_mode)); - } + } #endif - column += printf("%s", dn->name); - if (show_color) { - printf("\033[0m"); +#if ENABLE_FEATURE_LS_WIDECHARS + printf("%s", dn->name); + column += mbstrlen(dn->name, strlen(dn->name)); +#else + column += printf("%s", dn->name); +#endif + if (show_color) { + printf("\033[0m"); + } } break; case LIST_SYMLINK: @@ -701,6 +720,19 @@ return column; } + +#if ENABLE_FEATURE_LS_WIDECHARS +int mbstrlen(const char *string, size_t nbytes) +{ + wchar_t buf[nbytes]; + int width = mbstowcs(buf, string, nbytes); + if (width == -1) + return nbytes; + + return width; +} +#endif + /* "[-]Cadil1", POSIX mandated options, busybox always supports */ /* "[-]gnsx", POSIX non-mandated options, busybox always supports */ /* "[-]Ak" GNU options, busybox always supports */ Index: coreutils/Config.in =================================================================== --- coreutils/Config.in (revision 22297) +++ coreutils/Config.in (working copy) @@ -340,6 +340,13 @@ help Allow ls to sort file names alphabetically. +config FEATURE_LS_WIDECHARS + bool "Better handling of unicode chars" + default y + depends on LS + help + Allow ls to produce better column formatting for unicode filenames. + config FEATURE_LS_TIMESTAMPS bool "Show file timestamps" default y From rep.dot.nop at gmail.com Thu Jun 12 08:59:58 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 12 Jun 2008 17:59:58 +0200 Subject: bloat in parse_rtattr Message-ID: <20080612155958.GA14337@mx.loc> Hi, parse_rtattr and it's users look like it should zero-out tb on it's own instead of everywhere in it's users. As always, tested patches are welcome. From vda.linux at googlemail.com Thu Jun 12 10:08:44 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 12 Jun 2008 19:08:44 +0200 Subject: [patch] ls: better column formatting for unicode characters. In-Reply-To: <7bed83ad0806120822r69c8500xfc1794940aee2cc4@mail.gmail.com> References: <7bed83ad0806120822r69c8500xfc1794940aee2cc4@mail.gmail.com> Message-ID: <200806121908.44352.vda.linux@googlemail.com> On Thursday 12 June 2008 17:22, Volodymyr Buell wrote: > Hi. > > Ls command produce file list formatted incorrectly when filenames > contain unicode characters: columns are shifted to the left when > multibyte chars are present in file names. There is the patch that > solve this issue. New option in configuration was added to support > widechars as well... wchar.h and ctype.h are needed to be included in > libbb.h (mayby) but they were placed here since it's used only in > ls.c. Thanks, bbox needs some utf-8 work :( I guess you cut-n-pasted your patch and all tab chars got converted to spaces. Can you resent an undamaged patch (e.g. in attachment)? -- vda From htmldeveloper at gmail.com Thu Jun 12 10:20:21 2008 From: htmldeveloper at gmail.com (Peter Teoh) Date: Fri, 13 Jun 2008 01:20:21 +0800 Subject: QEMU running busybox + customized kernel Message-ID: <804dabb00806121020g32be49f7s493b964b46b78b91@mail.gmail.com> Anybody got any suggestion of a howto on running QEMU with busybox filesystem inside guest image? I would like to subsequently use it for kernel testing. Thanks. -- Regards, Peter Teoh From martinb at zeelandnet.nl Thu Jun 12 11:03:02 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Thu, 12 Jun 2008 20:03:02 +0200 Subject: Wrong result on simple hush script (nommu / arm) In-Reply-To: <200806112338.46163.vda.linux@googlemail.com> Message-ID: Thanks, it seems the bug is fixed (i did use the CVS) All other scripts still work And some other thing i notice is: old hush = 46505 bytes (flthdr -z) new hush size = 41470 bytes (flthdr -z) same config options this is even smaller then the lash i was using (42267 bytes) My hat's off for Denys Vlasenko =) > -----Oorspronkelijk bericht----- > Van: Denys Vlasenko [mailto:vda.linux at googlemail.com] > Verzonden: woensdag 11 juni 2008 23:39 > Aan: Martinb_ARM_NOMMU_KISSDVD > CC: busybox at busybox.net > Onderwerp: Re: Wrong result on simple hush script (nommu / arm) > > > On Wednesday 11 June 2008 21:24, Martinb_ARM_NOMMU_KISSDVD wrote: > > if i try it on current 1.10.3 i get: > > > > CC shell/hush.o > > shell/hush.c:89:2: warning: #warning On NOMMU, hush command > substitution is > > dangerous. > > shell/hush.c:90:2: warning: #warning Dont use it for commands > which produce > > lots of output. > > shell/hush.c:91:2: warning: #warning For more info see shell/hush.c, > > generate_stream_from_list(). > > shell/hush.c: In function `builtin_read': > > shell/hush.c:1075: error: too many arguments to function `xmalloc_reads' > > make[1]: *** [shell/hush.o] Fout 1 > > > > > > do i need cvs ? > > Yes, testing cvs is preferred. > -- > vda From cristian.ionescu-idbohrn at axis.com Thu Jun 12 11:14:28 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 12 Jun 2008 20:14:28 +0200 (CEST) Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <0806081209471.26504@somehost> References: <0806032202570.16214@somehost> <200806051018.16958.vda.linux@googlemail.com> <0806051209180.6722@somehost> <0806081209471.26504@somehost> Message-ID: <0806122008390.14584@somehost> On Sun, 8 Jun 2008, Cristian Ionescu-Idbohrn wrote: > On Thu, 5 Jun 2008, Cristian Ionescu-Idbohrn wrote: > > > On Thu, 5 Jun 2008, Denys Vlasenko wrote: > > > > > On Tuesday 03 June 2008 22:06, Cristian Ionescu-Idbohrn wrote: > > > > When using gdb, one would expect to have the source compiled with > > > > '-g -O0', and not '-g -Os'. > > > > > > There were people who disagree (they say "debug what you ship"). > > > I see only one way to leave BOTH camps happy. Create a CONFIG_DEBUG0 > > > option (dependent on CONFIG_DEBUG) which forces -O0 build. > > > Otherwise, -Os would be used. > > > > > > Can you do this? > > > > I'll have a look at it. > > Well, I found traces of this old controverse in topdir Config.in, > DEBUG_PESSIMIZE commented out, so I just revived that. Attached the > result. What do you think? Just wondering if this patch has fallen through cracks. Or there's maybe something wrong with it. RFC, in that case. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_pessimize.patch Type: text/x-diff Size: 2392 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080612/1bc7ef7b/attachment-0001.patch From cristian.ionescu-idbohrn at axis.com Thu Jun 12 12:02:55 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 12 Jun 2008 21:02:55 +0200 (CEST) Subject: [rfc] initializing variables Message-ID: <0806122033180.14584@somehost> Been chasing a bug we added to busybox ourselfs :( The applet is login. We added some extra functionality to that applet. I could provide details if there is intrest. Bottom line is we used variable 'opt_host' without ensuring '(opt & LOGIN_OPT_h)' was true. Talked to the gcc-cris author, while chasing the bug, about one specific declaration (which is supposed to keep gcc from warning about uninitialized variables). In this particular case: char *opt_host = opt_host; /* for compiler */ Yes, doing it like that saves some bytes but it is highly questionable if it's TRT to do, as you can count on gcc-undeterministic behaviour (IOW, be prepared for surprises). Proper thing to do would be: char *opt_host = NULL; Yes, it will cost some bytes in each place that construct is used, but doing it the right way will save some grief. The attached patch adds bytes or shrinks the code depending on the gcc version. Number of bytes is (IIRC) -12 to +3. Thoughts? Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: login.c.3.patch Type: text/x-diff Size: 691 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080612/d615df8e/attachment.patch From jacmet at uclibc.org Thu Jun 12 12:43:59 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Thu, 12 Jun 2008 21:43:59 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth Message-ID: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> From: Peter Korsgaard checkPerm only verified as many characters of the username as provided by the client, so E.G. an empty username would always match. Cleanup and save a few bytes while we are at it: function old new delta checkPerm 359 350 -9 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-9) Total: -9 bytes Based on (incorrect) patch by Lubos Stanek (lubek) sent to the openwrt list: http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/1464 Signed-off-by: Peter Korsgaard --- networking/httpd.c | 28 +++++++++++++--------------- 1 files changed, 13 insertions(+), 15 deletions(-) diff --git a/networking/httpd.c b/networking/httpd.c index 352a97d..db04cde 100644 --- a/networking/httpd.c +++ b/networking/httpd.c @@ -1710,29 +1710,27 @@ static int checkPerm(const char *path, const char *request) if (strncmp(p0, path, l) == 0 && (l == 1 || path[l] == '/' || path[l] == '\0') ) { - char *u; /* path match found. Check request */ /* for check next /path:user:password */ prev = p0; - u = strchr(request, ':'); - if (u == NULL) { - /* bad request, ':' required */ - break; - } if (ENABLE_FEATURE_HTTPD_AUTH_MD5) { char *pp; - if (strncmp(p, request, u - request) != 0) { - /* user doesn't match */ - continue; - } pp = strchr(p, ':'); if (pp && pp[1] == '$' && pp[2] == '1' - && pp[3] == '$' && pp[4] - ) { - char *encrypted = pw_encrypt(u+1, ++pp, 1); - int r = strcmp(encrypted, pp); + && pp[3] == '$' && pp[4]) { + char *encrypted; + int r, len; + + len = 1 + pp - p; + if (strncmp(p, request, len) != 0) { + /* user doesn't match */ + continue; + } + + encrypted = pw_encrypt(request+len, p+len, 1); + r = strcmp(encrypted, p+len); free(encrypted); if (r == 0) goto set_remoteuser_var; /* Ok */ @@ -1743,7 +1741,7 @@ static int checkPerm(const char *path, const char *request) if (strcmp(p, request) == 0) { set_remoteuser_var: - remoteuser = xstrndup(request, u - request); + remoteuser = xstrndup(request, strchr(request, ':') - request); return 1; /* Ok */ } /* unauthorized */ -- 1.5.5.1 From vda.linux at googlemail.com Thu Jun 12 13:25:47 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 12 Jun 2008 22:25:47 +0200 Subject: [patch] Makefile.flags: would this make more sense? In-Reply-To: <0806122008390.14584@somehost> References: <0806032202570.16214@somehost> <0806081209471.26504@somehost> <0806122008390.14584@somehost> Message-ID: <200806122225.47153.vda.linux@googlemail.com> On Thursday 12 June 2008 20:14, Cristian Ionescu-Idbohrn wrote: > > Well, I found traces of this old controverse in topdir Config.in, > > DEBUG_PESSIMIZE commented out, so I just revived that. Attached the > > result. What do you think? > > Just wondering if this patch has fallen through cracks. > Or there's maybe something wrong with it. RFC, in that case. Yes, classic case of maintainer being bigger asshole than needed :( Resending a non-commented-on patch is always ok. I applied it, thanks! -- vda From jsimmons at infradead.org Thu Jun 12 13:59:07 2008 From: jsimmons at infradead.org (James Simmons) Date: Thu, 12 Jun 2008 21:59:07 +0100 (BST) Subject: ash/stty usage In-Reply-To: <200806050302.39621.vda.linux@googlemail.com> References: <200806050302.39621.vda.linux@googlemail.com> Message-ID: > > Hi! > > > > I'm attempting color text but I'm getting "K[37;1mTextK[31;1m". Any > > idea what is wrong? > > What do you do to get it? echo "IP address <$ip>" The $ip would be highlighted in a bright color. It worked with busybox 1.00 but I haven't been able to get it to work for newer versions. > > Also I'm looking to flush the tty. Currently I'm doing > > > > eat_extra_keys() { > > local saved=$(stty -g) > > stty -icanon min 1 time 1 > > cat -N > /dev/null // Modified cat to flush the and not block if no > > stty $saved // data is present. > > } > > > > Do you know of a better way? > > Don't know for sure, maybe this? > > int tcflush(int fd, int queue_selector); I was hoping some app in busybox did that in some way.Will search for tools to do that. From vda.linux at googlemail.com Fri Jun 13 02:56:46 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 11:56:46 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth In-Reply-To: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> References: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> Message-ID: <200806131156.46446.vda.linux@googlemail.com> On Thursday 12 June 2008 21:43, Peter Korsgaard wrote: > From: Peter Korsgaard > > checkPerm only verified as many characters of the username as provided > by the client, so E.G. an empty username would always match. > > Cleanup and save a few bytes while we are at it: > > function old new delta > checkPerm 359 350 -9 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-9) Total: -9 bytes > > Based on (incorrect) patch by Lubos Stanek (lubek) sent to the openwrt list: > http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/1464 > > Signed-off-by: Peter Korsgaard > --- > networking/httpd.c | 28 +++++++++++++--------------- > 1 files changed, 13 insertions(+), 15 deletions(-) > > diff --git a/networking/httpd.c b/networking/httpd.c > index 352a97d..db04cde 100644 > --- a/networking/httpd.c > +++ b/networking/httpd.c > @@ -1710,29 +1710,27 @@ static int checkPerm(const char *path, const char *request) > if (strncmp(p0, path, l) == 0 > && (l == 1 || path[l] == '/' || path[l] == '\0') > ) { > - char *u; > /* path match found. Check request */ > /* for check next /path:user:password */ > prev = p0; > - u = strchr(request, ':'); > - if (u == NULL) { > - /* bad request, ':' required */ > - break; > - } I don't see what ensures ':' is always there. The code we are called from is: if (STRNCASECMP(iobuf, "Authorization:") == 0) { /* We only allow Basic credentials. * It shows up as "Authorization: Basic " where * the userid:password is base64 encoded. */ tptr = skip_whitespace(iobuf + sizeof("Authorization:")-1); if (STRNCASECMP(tptr, "Basic") != 0) continue; tptr += sizeof("Basic")-1; /* decodeBase64() skips whitespace itself */ decodeBase64(tptr); credentials = checkPerm(urlcopy, tptr); <======= } and here user can supply bad without ':'. > > if (ENABLE_FEATURE_HTTPD_AUTH_MD5) { > char *pp; > > - if (strncmp(p, request, u - request) != 0) { > - /* user doesn't match */ > - continue; > - } > pp = strchr(p, ':'); > if (pp && pp[1] == '$' && pp[2] == '1' > - && pp[3] == '$' && pp[4] > - ) { > - char *encrypted = pw_encrypt(u+1, ++pp, 1); > - int r = strcmp(encrypted, pp); > + && pp[3] == '$' && pp[4]) { > + char *encrypted; > + int r, len; > + > + len = 1 + pp - p; > + if (strncmp(p, request, len) != 0) { > + /* user doesn't match */ > + continue; > + } > + > + encrypted = pw_encrypt(request+len, p+len, 1); > + r = strcmp(encrypted, p+len); I spent some ten minutes understanding what is done here. > free(encrypted); > if (r == 0) > goto set_remoteuser_var; /* Ok */ > @@ -1743,7 +1741,7 @@ static int checkPerm(const char *path, const char *request) > > if (strcmp(p, request) == 0) { > set_remoteuser_var: > - remoteuser = xstrndup(request, u - request); > + remoteuser = xstrndup(request, strchr(request, ':') - request); Here where request without ':' will bite us. BTW: any idea why this routine locks on first found path? This code part: p0 = cur->before_colon; if (prev != NULL && strcmp(prev, p0) != 0) continue; /* find next identical */ Also: any idea what is going here in handle_incoming_and_exit()? #if ENABLE_FEATURE_HTTPD_BASIC_AUTH int credentials = -1; /* if not required this is Ok */ #endif ... ... (checks "Authorization: Basic " if present, sets credentials to 0/1) ... #if ENABLE_FEATURE_HTTPD_BASIC_AUTH if (credentials <= 0 && checkPerm(urlcopy, ":") == 0) { send_headers_and_exit(HTTP_UNAUTHORIZED); } #endif So, if there were no "Authorization: Basic", we still check empty username/passwd. ok. But the same will happen if "Authorization: Basic" was given with wrong passwd! Should it be "if (credentials < 0..."? I applied your patch, and then did heavy editing on top - variable names, comments, etc in config file parsing were atrocious. Can you test current svn? Thanks! -- vda From vda.linux at googlemail.com Fri Jun 13 03:11:20 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 12:11:20 +0200 Subject: ash/stty usage In-Reply-To: References: <200806050302.39621.vda.linux@googlemail.com> Message-ID: <200806131211.20392.vda.linux@googlemail.com> On Thursday 12 June 2008 22:59, James Simmons wrote: > > > > Hi! > > > > > > I'm attempting color text but I'm getting "K[37;1mTextK[31;1m". Any > > > idea what is wrong? > > > > What do you do to get it? > > echo "IP address <$ip>" Well, I meant "give me means to reproduce your case" :) # ip=foo; echo "IP address <$ip>" IP address This works, but it's not what you meant. How do you stuff color codes into $ip? > > > Also I'm looking to flush the tty. Currently I'm doing > > > > > > Do you know of a better way? > > > > Don't know for sure, maybe this? > > > > int tcflush(int fd, int queue_selector); > > I was hoping some app in busybox did that in some way. Will search for > tools to do that. If you can confirm that the above code works for you as a tiny standalone executable, it can be added to busybox. -- vda From jacmet at uclibc.org Fri Jun 13 03:26:25 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 13 Jun 2008 12:26:25 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth In-Reply-To: <200806131156.46446.vda.linux@googlemail.com> (Denys Vlasenko's message of "Fri\, 13 Jun 2008 11\:56\:46 +0200") References: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> <200806131156.46446.vda.linux@googlemail.com> Message-ID: <873anhtyum.fsf@macbook.be.48ers.dk> >>>>> "Denys" == Denys Vlasenko writes: [resend with proper from:] Hi, >> /* path match found. Check request */ >> /* for check next /path:user:password */ >> prev = p0; >> - u = strchr(request, ':'); >> - if (u == NULL) { >> - /* bad request, ':' required */ >> - break; >> - } Denys> I don't see what ensures ':' is always there. Ahh, sorry - it's only checked in the MD5 auth case, seems like I didn't test that good enough. We'll need to push that check out of the MD5 case, and error out like before. >> - char *encrypted = pw_encrypt(u+1, ++pp, 1); >> - int r = strcmp(encrypted, pp); >> + && pp[3] == '$' && pp[4]) { >> + char *encrypted; >> + int r, len; >> + >> + len = 1 + pp - p; >> + if (strncmp(p, request, len) != 0) { >> + /* user doesn't match */ >> + continue; >> + } >> + >> + encrypted = pw_encrypt(request+len, p+len, 1); >> + r = strcmp(encrypted, p+len); Denys> I spent some ten minutes understanding what is done here. Yeah, it isn't the cleanest code ;) For a simple cleartext password it just strcmp's what's provided by the client and what's in the conf file, and for the md5 auth case, it strcmp's the username, encrypts the client password and compares the hashes. Denys> Here where request without ':' will bite us. Denys> BTW: any idea why this routine locks on first found path? Denys> This code part: Sorry, I don't. Denys> I applied your patch, and then did heavy editing on top - Denys> variable names, comments, etc in config file parsing were Denys> atrocious. I'll take a look and test. -- Bye, Peter Korsgaard From jacmet at uclibc.org Fri Jun 13 03:27:02 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 13 Jun 2008 12:27:02 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth In-Reply-To: <200806131156.46446.vda.linux@googlemail.com> (Denys Vlasenko's message of "Fri\, 13 Jun 2008 11\:56\:46 +0200") References: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> <200806131156.46446.vda.linux@googlemail.com> Message-ID: <87y759sk95.fsf@macbook.be.48ers.dk> >>>>> "Denys" == Denys Vlasenko writes: [resend with proper from:] Hi, >> if (strcmp(p, request) == 0) { >> set_remoteuser_var: >> - remoteuser = xstrndup(request, u - request); >> + remoteuser = xstrndup(request, strchr(request, ':') - request); Denys> Here where request without ':' will bite us. Actually, thinking about it a bit more - This cannot happen as the strcmp() wouldn't match. Notice that we could use 'p' here instead of 'request' and the result would be the same. -- Bye, Peter Korsgaard From vda.linux at googlemail.com Fri Jun 13 04:20:05 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 13:20:05 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth In-Reply-To: <87wsktve5r.fsf@macbook.be.48ers.dk> References: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> <200806131156.46446.vda.linux@googlemail.com> <87wsktve5r.fsf@macbook.be.48ers.dk> Message-ID: <200806131320.05654.vda.linux@googlemail.com> On Friday 13 June 2008 12:10, Peter Korsgaard wrote: > Denys> I applied your patch, and then did heavy editing on top - > Denys> variable names, comments, etc in config file parsing were > Denys> atrocious. > > I'll take a look and test. Just for the record: "atrocious" part wasn't in your patch. it was preexisting stuff. -- vda From vda.linux at googlemail.com Fri Jun 13 04:24:20 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 13:24:20 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth In-Reply-To: <87skvhvdvv.fsf@macbook.be.48ers.dk> References: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> <200806131156.46446.vda.linux@googlemail.com> <87skvhvdvv.fsf@macbook.be.48ers.dk> Message-ID: <200806131324.20767.vda.linux@googlemail.com> On Friday 13 June 2008 12:16, Peter Korsgaard wrote: > >>>>> "Denys" == Denys Vlasenko writes: > > Hi, > > >> if (strcmp(p, request) == 0) { > >> set_remoteuser_var: > >> - remoteuser = xstrndup(request, u - request); > >> + remoteuser = xstrndup(request, strchr(request, ':') - request); > > Denys> Here where request without ':' will bite us. > > Actually, thinking about it a bit more - This cannot happen as the > strcmp() wouldn't match. There is no code which ensures that ':' exists *in config file*. It seems like there is no code to ensure that leading '/' is there too. Find this comment: //TODO: we do not test for leading "/"?? //also, do we leak cur if BASIC_AUTH is off? > Notice that we could use 'p' here instead of > 'request' and the result would be the same. Thus p can very well be lacking ':'. -- vda From jacmet at uclibc.org Fri Jun 13 04:35:33 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 13 Jun 2008 13:35:33 +0200 Subject: [PATCH] httpd: send HTTP_UNAUTHORIZED on auth failure Message-ID: <1213356933-1915-1-git-send-email-jacmet@uclibc.org> From: Peter Korsgaard r22315 is wrong - We should send HTTP_UNAUTHORIZED both if there wasn't an Authorization: header, AND if authorization failed. Signed-off-by: Peter Korsgaard --- networking/httpd.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/networking/httpd.c b/networking/httpd.c index 382893b..f1afc1d 100644 --- a/networking/httpd.c +++ b/networking/httpd.c @@ -2043,9 +2043,9 @@ static void handle_incoming_and_exit(const len_and_sockaddr *fromAddr) } #if ENABLE_FEATURE_HTTPD_BASIC_AUTH - /* Case: no "Authorization:" was seen, but page does require passwd. - * Check that with dummy user:pass */ - if ((authorized < 0) && check_user_passwd(urlcopy, ":") == 0) { + /* invalid user:pass or no "Authorization:" was seen, but page + * does require passwd. Check that with dummy user:pass */ + if ((authorized <= 0) && check_user_passwd(urlcopy, ":") == 0) { send_headers_and_exit(HTTP_UNAUTHORIZED); } #endif -- 1.5.5.1 From jacmet at uclibc.org Fri Jun 13 04:44:19 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 13 Jun 2008 13:44:19 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth In-Reply-To: <200806131324.20767.vda.linux@googlemail.com> (Denys Vlasenko's message of "Fri\, 13 Jun 2008 13\:24\:20 +0200") References: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> <200806131156.46446.vda.linux@googlemail.com> <87skvhvdvv.fsf@macbook.be.48ers.dk> <200806131324.20767.vda.linux@googlemail.com> Message-ID: <87bq25sgoc.fsf@macbook.be.48ers.dk> >>>>> "Denys" == Denys Vlasenko writes: >> Actually, thinking about it a bit more - This cannot happen as the >> strcmp() wouldn't match. Denys> There is no code which ensures that ':' exists *in config file*. Denys> It seems like there is no code to ensure that leading '/' is there too. Denys> Find this comment: Denys> //TODO: we do not test for leading "/"?? Denys> //also, do we leak cur if BASIC_AUTH is off? >> Notice that we could use 'p' here instead of >> 'request' and the result would be the same. Denys> Thus p can very well be lacking ':'. Ok, but then it's a configuration problem, rather than a remote security issue - Not to say, that we shouldn't be more robust when we parse the conf gile. -- Bye, Peter Korsgaard From vda.linux at googlemail.com Fri Jun 13 06:20:04 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 15:20:04 +0200 Subject: [PATCH] httpd: send HTTP_UNAUTHORIZED on auth failure In-Reply-To: <1213356933-1915-1-git-send-email-jacmet@uclibc.org> References: <1213356933-1915-1-git-send-email-jacmet@uclibc.org> Message-ID: <200806131520.04966.vda.linux@googlemail.com> On Friday 13 June 2008 13:35, Peter Korsgaard wrote: > From: Peter Korsgaard > > r22315 is wrong - We should send HTTP_UNAUTHORIZED both if there wasn't > an Authorization: header, Why? Vast majority of http requests indeed does not have "Authorization:" header just because they request non-protected pages. > #if ENABLE_FEATURE_HTTPD_BASIC_AUTH > - /* Case: no "Authorization:" was seen, but page does require passwd. > - * Check that with dummy user:pass */ > - if ((authorized < 0) && check_user_passwd(urlcopy, ":") == 0) { > + /* invalid user:pass or no "Authorization:" was seen, but page > + * does require passwd. Check that with dummy user:pass */ > + if ((authorized <= 0) && check_user_passwd(urlcopy, ":") == 0) { My point is that "authorized <= 0" is true if there was no "Authorization:" AND if it was seen, checked, and found to contain wrong user/passwd. But those are different situations! In second case, we should not check dummy credentials ":", we already know that user shall not get the page. My fix though was valid too. Now I allow failed auth :( This should be ok: if (authorized < 0) authorized = check_user_passwd(urlcopy, ":"); if (!authorized) send_headers_and_exit(HTTP_UNAUTHORIZED); Does it look right to you? -- vda From vda.linux at googlemail.com Fri Jun 13 06:39:16 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 15:39:16 +0200 Subject: [PATCH] httpd: send HTTP_UNAUTHORIZED on auth failure In-Reply-To: <200806131520.04966.vda.linux@googlemail.com> References: <1213356933-1915-1-git-send-email-jacmet@uclibc.org> <200806131520.04966.vda.linux@googlemail.com> Message-ID: <200806131539.16107.vda.linux@googlemail.com> On Friday 13 June 2008 15:20, Denys Vlasenko wrote: > My fix though was valid too. Now I allow failed auth :( "was NOT valid" From jacmet at uclibc.org Fri Jun 13 06:42:44 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 13 Jun 2008 15:42:44 +0200 Subject: [PATCH] httpd: send HTTP_UNAUTHORIZED on auth failure In-Reply-To: <200806131520.04966.vda.linux@googlemail.com> (Denys Vlasenko's message of "Fri\, 13 Jun 2008 15\:20\:04 +0200") References: <1213356933-1915-1-git-send-email-jacmet@uclibc.org> <200806131520.04966.vda.linux@googlemail.com> Message-ID: <873anhlacr.fsf@macbook.be.48ers.dk> >>>>> "Denys" == Denys Vlasenko writes: Hi, Denys> On Friday 13 June 2008 13:35, Peter Korsgaard wrote: >> From: Peter Korsgaard >> >> r22315 is wrong - We should send HTTP_UNAUTHORIZED both if there wasn't >> an Authorization: header, Denys> Why? Vast majority of http requests indeed does not have Denys> "Authorization:" header just because they request Denys> non-protected pages. True. You misunderstand the comment - Without that fix you never sent HTTP_UNAUTHORIZED if the Authorization header was sent, no matter if it was valid or not. >> #if ENABLE_FEATURE_HTTPD_BASIC_AUTH >> - /* Case: no "Authorization:" was seen, but page does require passwd. >> - * Check that with dummy user:pass */ >> - if ((authorized < 0) && check_user_passwd(urlcopy, ":") == 0) { >> + /* invalid user:pass or no "Authorization:" was seen, but page >> + * does require passwd. Check that with dummy user:pass */ >> + if ((authorized <= 0) && check_user_passwd(urlcopy, ":") == 0) { Denys> My point is that "authorized <= 0" is true if there was no Denys> "Authorization:" AND if it was seen, checked, and found to Denys> contain wrong user/passwd. Denys> But those are different situations! In second case, we should Denys> not check dummy credentials ":", we already know that user Denys> shall not get the page. True, it's more effecient to not do the double check. Denys> My fix though was valid too. Now I allow failed auth :( I guess you mean invalid. Denys> This should be ok: Denys> if (authorized < 0) Denys> authorized = check_user_passwd(urlcopy, ":"); Denys> if (!authorized) Denys> send_headers_and_exit(HTTP_UNAUTHORIZED); Denys> Does it look right to you? Yes, it works here - Thanks! Maybe add to the 1.10.3 fixes? -- Bye, Peter Korsgaard From abc at digithi.de Fri Jun 13 07:47:07 2008 From: abc at digithi.de (=?ISO-8859-15?Q?=22T=2E_Eichst=E4dt=22?=) Date: Fri, 13 Jun 2008 16:47:07 +0200 Subject: BUG in mount nfs, proto=xyz Message-ID: <4852886B.1010300@digithi.de> Hello, I have discovered an error in mount.c. When trying to mount a nfs share with the option "-o proto=tcp..." the mount command bails out with an error that indicates that it can't convert "tcp" into a numeric value. That error occurs because all arguments after a "=" are passed to xatoi_u which tries to convert them into an integer. This is not correct for "proto=xyz" AND for "hostname=xyz". The following "hack" is not nice, but works: --- b/util-linux/mount.c.orig 2007-03-18 17:59:37.000000000 +0100 +++ a/util-linux/mount.c 2008-06-06 12:47:02.000000000 +0200 @@ -912,9 +912,18 @@ /* 20 */ "addr", NULL }; - int val = xatoi_u(opteq + 1); + int val; + int idx; *opteq = '\0'; - switch (index_in_str_array(options, opt)) { + idx=index_in_str_array(options, opt); + if (idx != 18 && idx != 12) { // all commands except prot, mounthost + val = xatoi_u(opteq + 1); + } else { + val = 0; + } + switch (idx) { case 0: // "rsize" data.rsize = val; break; Best regards T. Eichst?dt From vda.linux at googlemail.com Fri Jun 13 09:30:11 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 18:30:11 +0200 Subject: [PATCH] httpd: send HTTP_UNAUTHORIZED on auth failure In-Reply-To: <873anhlacr.fsf@macbook.be.48ers.dk> References: <1213356933-1915-1-git-send-email-jacmet@uclibc.org> <200806131520.04966.vda.linux@googlemail.com> <873anhlacr.fsf@macbook.be.48ers.dk> Message-ID: <200806131830.12004.vda.linux@googlemail.com> On Friday 13 June 2008 15:42, Peter Korsgaard wrote: > >> #if ENABLE_FEATURE_HTTPD_BASIC_AUTH > >> - /* Case: no "Authorization:" was seen, but page does require passwd. > >> - * Check that with dummy user:pass */ > >> - if ((authorized < 0) && check_user_passwd(urlcopy, ":") == 0) { > >> + /* invalid user:pass or no "Authorization:" was seen, but page > >> + * does require passwd. Check that with dummy user:pass */ > >> + if ((authorized <= 0) && check_user_passwd(urlcopy, ":") == 0) { > > Denys> My point is that "authorized <= 0" is true if there was no > Denys> "Authorization:" AND if it was seen, checked, and found to > Denys> contain wrong user/passwd. > > Denys> But those are different situations! In second case, we should > Denys> not check dummy credentials ":", we already know that user > Denys> shall not get the page. > > True, it's more effecient to not do the double check. It's not an efficiency question. check_user_passwd(urlcopy, ":") might SUCCEED, and thus user who supplied wrong user:password pair will be granted access. -- vda From jacmet at uclibc.org Fri Jun 13 10:12:38 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 13 Jun 2008 19:12:38 +0200 Subject: [PATCH] httpd: fix username verification with md5 auth In-Reply-To: <200806131324.20767.vda.linux@googlemail.com> (Denys Vlasenko's message of "Fri\, 13 Jun 2008 13\:24\:20 +0200") References: <1213299839-22600-1-git-send-email-jacmet@uclibc.org> <200806131156.46446.vda.linux@googlemail.com> <87skvhvdvv.fsf@macbook.be.48ers.dk> <200806131324.20767.vda.linux@googlemail.com> Message-ID: <87tzfxfed5.fsf@macbook.be.48ers.dk> >>>>> "Denys" == Denys Vlasenko writes: Hi, >> >> if (strcmp(p, request) == 0) { >> >> set_remoteuser_var: >> >> - remoteuser = xstrndup(request, u - request); >> >> + remoteuser = xstrndup(request, strchr(request, ':') - request); >> Denys> Here where request without ':' will bite us. >> >> Actually, thinking about it a bit more - This cannot happen as the >> strcmp() wouldn't match. Denys> There is no code which ensures that ':' exists *in config file*. Denys> It seems like there is no code to ensure that leading '/' is Denys> there too. Find this comment: Denys> //TODO: we do not test for leading "/"?? Denys> //also, do we leak cur if BASIC_AUTH is off? >> Notice that we could use 'p' here instead of >> 'request' and the result would be the same. Denys> Thus p can very well be lacking ':'. No, as this code will only be entered if the strcmp() matches. -- Bye, Peter Korsgaard From jacmet at uclibc.org Fri Jun 13 10:14:35 2008 From: jacmet at uclibc.org (Peter Korsgaard) Date: Fri, 13 Jun 2008 19:14:35 +0200 Subject: [PATCH] httpd: send HTTP_UNAUTHORIZED on auth failure In-Reply-To: <200806131830.12004.vda.linux@googlemail.com> (Denys Vlasenko's message of "Fri\, 13 Jun 2008 18\:30\:11 +0200") References: <1213356933-1915-1-git-send-email-jacmet@uclibc.org> <200806131520.04966.vda.linux@googlemail.com> <873anhlacr.fsf@macbook.be.48ers.dk> <200806131830.12004.vda.linux@googlemail.com> Message-ID: <87prqlfe9w.fsf@macbook.be.48ers.dk> >>>>> "Denys" == Denys Vlasenko writes: Hi, Denys> But those are different situations! In second case, we should Denys> not check dummy credentials ":", we already know that user Denys> shall not get the page. >> >> True, it's more effecient to not do the double check. Denys> It's not an efficiency question. check_user_passwd(urlcopy, ":") Denys> might SUCCEED, and thus user who supplied wrong user:password Denys> pair will be granted access. Ahh yes. -- Bye, Peter Korsgaard From ccostin.dmu at gmail.com Fri Jun 13 13:00:32 2008 From: ccostin.dmu at gmail.com (ccostin) Date: Fri, 13 Jun 2008 23:00:32 +0300 Subject: CGI scripts exection Message-ID: <68a29da40806131300t25935528k93e4224c0b427125@mail.gmail.com> Hello What is the minimal configuration for httpd.conf required by busybox httpd to run simple CGI scripts ? For this are necessary any special environment exported variables ? When I try to load simple bourne shell scripts, Firefox ask me to save them on disk. Command line for busybox is busybox httpd -h /var/www/ and shell scripts are contained in /var/www/cgi-bin/, and have a+x execution bits. From vda.linux at googlemail.com Fri Jun 13 13:37:18 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 13 Jun 2008 22:37:18 +0200 Subject: CGI scripts exection In-Reply-To: <68a29da40806131300t25935528k93e4224c0b427125@mail.gmail.com> References: <68a29da40806131300t25935528k93e4224c0b427125@mail.gmail.com> Message-ID: <200806132237.18880.vda.linux@googlemail.com> On Friday 13 June 2008 22:00, ccostin wrote: > Hello > > What is the minimal configuration for httpd.conf required by busybox > httpd to run simple CGI scripts ? None, I think. > For this are necessary any special environment exported variables ? > > When I try to load simple bourne shell scripts, Firefox ask me to > save them on disk. > > Command line for busybox is > busybox httpd -h /var/www/ I run mine with "httpd -vvv -i -h /.1/video" and it seems to work (I have a CGI which creates dir listings). > and shell scripts are contained in /var/www/cgi-bin/, and have a+x > execution bits. You possibly have not enabled everything you need in .config when you built busybox. -- vda From jsimmons at infradead.org Fri Jun 13 13:54:11 2008 From: jsimmons at infradead.org (James Simmons) Date: Fri, 13 Jun 2008 21:54:11 +0100 (BST) Subject: ash/stty usage In-Reply-To: <200806131211.20392.vda.linux@googlemail.com> References: <200806050302.39621.vda.linux@googlemail.com> <200806131211.20392.vda.linux@googlemail.com> Message-ID: On Fri, 13 Jun 2008, Denys Vlasenko wrote: > On Thursday 12 June 2008 22:59, James Simmons wrote: > > > > > > Hi! > > > > > > > > I'm attempting color text but I'm getting "K[37;1mTextK[31;1m". Any > > > > idea what is wrong? > > > > > > What do you do to get it? > > > > echo "IP address <$ip>" > > Well, I meant "give me means to reproduce your case" :) Here you go. In bash the text is: Software version: 1.0.0 In ash it prints: Software version: K[37;1m1.0.0K[37;0m #!/busybox-1.6.1/_install/bin/sh _reset='\033[0m' _black='\033[30;00m' _grey='\033[37;0m' _dgrey='\033[30;1m' _white='\033[37;1m' _red='\033[31;1m' _dred='\033[31;0m' _green='\033[32;1m' _dgreen='\033[32;0m' _yellow='\033[33;1m' _brown='\033[33;0m' _blue='\033[34;1m' _dblue='\033[34;0m' _magenta='\033[35;1m' _dmagenta='\033[35;0m' _cyan='\033[36;1m' _dcyan='\033[36;0m' color() { local c="$1" local name case "$c" in ""|default) c=grey ;; grey) ;; dgrey) ;; white) ;; red) ;; dred) ;; green) ;; dgreen) ;; yellow) ;; brown) ;; blue) ;; dblue) ;; magenta) ;; dmagenta) ;; cyan) ;; dcyan) ;; *) return 1 ;; esac name="_${c}" CURRENT_COLOR="$c" eval CURRENT_COLOR_ESC=\"\$${name}\" echo -en "${CURRENT_COLOR_ESC}" } echo_with_bold() { [ -n "$CURRENT_COLOR_ESC" ] || color default local tmp="$2" tmp=${tmp///${CURRENT_COLOR_ESC}} echo -e "${tmp}" } VERSION=1.0.0 ver_color=${_white} text="Software version: <${VERSION}>" echo_with_bold "${ver_color}" " ${text}" > > > > Also I'm looking to flush the tty. Currently I'm doing > > > > > > > > Do you know of a better way? > > > > > > Don't know for sure, maybe this? > > > > > > int tcflush(int fd, int queue_selector); > > > > I was hoping some app in busybox did that in some way. Will search for > > tools to do that. > > If you can confirm that the above code works for you > as a tiny standalone executable, it can be added to busybox. Hum. I'm going to dig into this some more. There must be a terminal control code to flush the buffer. Prehaps ^O to the terminal. From vda.linux at googlemail.com Fri Jun 13 21:47:09 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 14 Jun 2008 06:47:09 +0200 Subject: ash/stty usage In-Reply-To: References: <200806131211.20392.vda.linux@googlemail.com> Message-ID: <200806140647.09243.vda.linux@googlemail.com> On Friday 13 June 2008 22:54, James Simmons wrote: > > On Fri, 13 Jun 2008, Denys Vlasenko wrote: > > > On Thursday 12 June 2008 22:59, James Simmons wrote: > > > > > > > > Hi! > > > > > > > > > > I'm attempting color text but I'm getting "K[37;1mTextK[31;1m". Any > > > > > idea what is wrong? > > > > > > > > What do you do to get it? > > > > > > echo "IP address <$ip>" > > > > Well, I meant "give me means to reproduce your case" :) > > Here you go. In bash the text is: > Software version: 1.0.0 > > In ash it prints: > Software version: K[37;1m1.0.0K[37;0m >... Smaller testcase: a='a) TODO: write testsuite! :) -- vda From vda.linux at googlemail.com Fri Jun 13 21:59:31 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 14 Jun 2008 06:59:31 +0200 Subject: ash/stty usage In-Reply-To: <200806140647.09243.vda.linux@googlemail.com> References: <200806140647.09243.vda.linux@googlemail.com> Message-ID: <200806140659.31921.vda.linux@googlemail.com> On Saturday 14 June 2008 06:47, Denys Vlasenko wrote: > Smaller testcase: > > a='a b='\033#' > r=${a// echo $r > > Results: > > # sh zz > a\033#b > # ./busybox ash zz > aK#b > > '<' is not special. Replacing 'b' in 'abc' would work the same. > The culprit is '\' in replacement. Bug is here: c = (c << 3) + atoi(arg); Should be: c = (c << 3) + (*arg - '0'); Can you confirm? -- vda From vda.linux at googlemail.com Fri Jun 13 23:03:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 14 Jun 2008 08:03:50 +0200 Subject: ash/stty usage In-Reply-To: <200806140659.31921.vda.linux@googlemail.com> References: <200806140647.09243.vda.linux@googlemail.com> <200806140659.31921.vda.linux@googlemail.com> Message-ID: <200806140803.50901.vda.linux@googlemail.com> On Saturday 14 June 2008 06:59, Denys Vlasenko wrote: > On Saturday 14 June 2008 06:47, Denys Vlasenko wrote: > > Smaller testcase: > > > > a='a > b='\033#' > > r=${a// > echo $r > > > > Results: > > > > # sh zz > > a\033#b > > # ./busybox ash zz > > aK#b > > > > '<' is not special. Replacing 'b' in 'abc' would work the same. > > The culprit is '\' in replacement. > > Bug is here: > > c = (c << 3) + atoi(arg); > > Should be: > > c = (c << 3) + (*arg - '0'); > > Can you confirm? Scratch that, it's wrong. Try this one. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: a.patch Type: text/x-diff Size: 2170 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080614/4f1c8997/attachment.patch From vda.linux at googlemail.com Sat Jun 14 04:04:26 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 14 Jun 2008 13:04:26 +0200 Subject: msh if not In-Reply-To: References: Message-ID: <200806141304.26549.vda.linux@googlemail.com> On Wednesday 11 June 2008 09:45, Roberto A. Foglietta wrote: > Hi to all, > > I would know how I can write this > > if ! true; then echo ciao; fi > > in msh's dialet because msh does not recognize ! (not) I just implemented it in hush. Sorry, don't know msh code as good as hush, can't promise anything for msh. But you can try hush. Let me know what breaks. -- vda From cristian.ionescu-idbohrn at axis.com Sat Jun 14 12:20:08 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sat, 14 Jun 2008 21:20:08 +0200 (CEST) Subject: [rfc] macros and macro usage Message-ID: <0806142002290.3557@somehost> $ egrep _ARPING include/autoconf.h #define CONFIG_ARPING 1 #define ENABLE_ARPING 1 #define USE_ARPING(...) __VA_ARGS__ #define SKIP_ARPING(...) #define CONFIG_FEATURE_UDHCPC_ARPING 1 #define ENABLE_FEATURE_UDHCPC_ARPING 1 #define USE_FEATURE_UDHCPC_ARPING(...) __VA_ARGS__ #define SKIP_FEATURE_UDHCPC_ARPING(...) $ egrep _MMU applets/usage.c ./applets/usage.c:#define BB_MMU 0 ./applets/usage.c:#define USE_FOR_MMU(...) ./applets/usage.c:#define BB_MMU 1 ./applets/usage.c:#define USE_FOR_MMU(...) __VA_ARGS__ For consistancy, I would have expected something similar to this instead: #define USE_BB_MMU(...) __VA_ARGS__ #define SKIP_BB_MMU(...) ... Is applets/usage.c the best place? Shouldn't this: USE_FEATURE_UDHCPC_ARPING(OPTBIT_a,) be prefered, instead of this: #if ENABLE_FEATURE_UDHCPC_ARPING OPTBIT_a, #endif The attchment shows how networking/udhcp/dhcpc.c may be changed. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcpc.c.patch Type: text/x-diff Size: 2882 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080614/cc66de69/attachment.patch From vda.linux at googlemail.com Sat Jun 14 12:24:14 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 14 Jun 2008 21:24:14 +0200 Subject: [rfc] initializing variables In-Reply-To: <0806122033180.14584@somehost> References: <0806122033180.14584@somehost> Message-ID: <200806142124.14692.vda.linux@googlemail.com> On Thursday 12 June 2008 21:02, Cristian Ionescu-Idbohrn wrote: > Been chasing a bug we added to busybox ourselfs :( > The applet is login. We added some extra functionality to that applet. > I could provide details if there is intrest. > > Bottom line is we used variable 'opt_host' without ensuring > '(opt & LOGIN_OPT_h)' was true. > > Talked to the gcc-cris author, while chasing the bug, about one specific > declaration (which is supposed to keep gcc from warning about > uninitialized variables). In this particular case: > > char *opt_host = opt_host; /* for compiler */ > > Yes, doing it like that saves some bytes but it is highly questionable if > it's TRT to do, as you can count on gcc-undeterministic behaviour (IOW, be > prepared for surprises). I would expect that opt_host stays undefined, but compiler no longer complains. Hopefully, it also does not generate any actual instructions here. > Proper thing to do would be: > > char *opt_host = NULL; > > Yes, it will cost some bytes in each place that construct is used, but > doing it the right way will save some grief. In what sense is it "the right way"? I agree that it has an advantage of not just shutting up the compiler, but also providing a deterministic value for the variable. But it results in bigger code. The people who started busybox project were very paranoid about size. I am less paranoid, but I want to respect the spirit of the project and not enlarge code needlessly. In case when applet is not too complex, smaller code is much preferred. login.c is about ten screenfuls of text on my non-oversized display, I guess it qualifies as "not too complex". "Complex applet" would be a shell, or httpd, etc. -- vda From vda.linux at googlemail.com Sat Jun 14 12:37:54 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 14 Jun 2008 21:37:54 +0200 Subject: [patch] archival/tar.c: unused parameter 'gzip' warning In-Reply-To: <0805300938050.6722@somehost> References: <0805300938050.6722@somehost> Message-ID: <200806142137.54650.vda.linux@googlemail.com> On Friday 30 May 2008 09:43, Cristian Ionescu-Idbohrn wrote: > When .config contains this combination: > > CONFIG_FEATURE_TAR_GZIP=y > # CONFIG_FEATURE_TAR_BZIP2 is not set > > this warning shows up: > > archival/tar.c: In function 'vfork_compressor': > archival/tar.c:508: warning: unused parameter 'gzip' > > The attached patch attempts to correct that. This may lead to parameter being actually passed (useless code will be generated). Sometimes gcc optimizes it out, but don't count on that. This way, you do not generate this extra code: -- vda diff -d -urpN busybox.4/archival/tar.c busybox.5/archival/tar.c --- busybox.4/archival/tar.c 2008-06-07 06:25:53.000000000 +0200 +++ busybox.5/archival/tar.c 2008-06-14 21:35:56.000000000 +0200 @@ -504,6 +504,9 @@ static int writeFileToTarball(const char } #if ENABLE_FEATURE_TAR_GZIP || ENABLE_FEATURE_TAR_BZIP2 +#if !(ENABLE_FEATURE_TAR_GZIP && ENABLE_FEATURE_TAR_BZIP2) +#define vfork_compressor(tar_fd, gzip) vfork_compressor(tar_fd) +#endif /* Don't inline: vfork scares gcc and pessimizes code */ static void NOINLINE vfork_compressor(int tar_fd, int gzip) { From rep.dot.nop at gmail.com Sat Jun 14 12:51:30 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sat, 14 Jun 2008 21:51:30 +0200 Subject: [rfc] macros and macro usage In-Reply-To: <0806142002290.3557@somehost> References: <0806142002290.3557@somehost> Message-ID: <20080614195130.GD10734@mx.loc> On Sat, Jun 14, 2008 at 09:20:08PM +0200, Cristian Ionescu-Idbohrn wrote: >--- networking/udhcp/dhcpc.c.~1~ 2008-06-14 19:37:37.000000000 +0200 >+++ networking/udhcp/dhcpc.c 2008-06-14 20:24:20.000000000 +0200 >@@ -201,40 +197,26 @@ > OPT_f = 1 << 20, > /* The rest has variable bit positions, need to be clever */ -> OPTBIT_f = 20, + OPTBIT_f = 20 ->+ USE_FOR_MMU(OPTBIT_b,) ->+ USE_FEATURE_UDHCPC_ARPING(OPTBIT_a,) ->+ USE_FEATURE_UDHCP_PORT(OPTBIT_P,) ->+ USE_FOR_MMU(OPT_b = 1 << OPTBIT_b,) ->+ USE_FEATURE_UDHCPC_ARPING(OPT_a = 1 << OPTBIT_a,) ->+ USE_FEATURE_UDHCP_PORT(OPT_P = 1 << OPTBIT_P,) + USE_FOR_MMU(,OPTBIT_b) + USE_FEATURE_UDHCPC_ARPING(,OPTBIT_a) + USE_FEATURE_UDHCP_PORT(,OPTBIT_P) + USE_FOR_MMU(,OPT_b = 1 << OPTBIT_b) + USE_FEATURE_UDHCPC_ARPING(,OPT_a = 1 << OPTBIT_a) + USE_FEATURE_UDHCP_PORT(,OPT_P = 1 << OPTBIT_P) > }; From cristian.ionescu-idbohrn at axis.com Sat Jun 14 15:01:40 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 15 Jun 2008 00:01:40 +0200 (CEST) Subject: [rfc] macros and macro usage In-Reply-To: <20080614195130.GD10734@mx.loc> References: <0806142002290.3557@somehost> <20080614195130.GD10734@mx.loc> Message-ID: <0806142352340.3557@somehost> On Sat, 14 Jun 2008, Bernhard Fischer wrote: > On Sat, Jun 14, 2008 at 09:20:08PM +0200, Cristian Ionescu-Idbohrn wrote: > >--- networking/udhcp/dhcpc.c.~1~ 2008-06-14 19:37:37.000000000 +0200 > >+++ networking/udhcp/dhcpc.c 2008-06-14 20:24:20.000000000 +0200 > >@@ -201,40 +197,26 @@ > > OPT_f = 1 << 20, > > /* The rest has variable bit positions, need to be clever */ > -> OPTBIT_f = 20, > + OPTBIT_f = 20 > > ->+ USE_FOR_MMU(OPTBIT_b,) > ->+ USE_FEATURE_UDHCPC_ARPING(OPTBIT_a,) > ->+ USE_FEATURE_UDHCP_PORT(OPTBIT_P,) > ->+ USE_FOR_MMU(OPT_b = 1 << OPTBIT_b,) > ->+ USE_FEATURE_UDHCPC_ARPING(OPT_a = 1 << OPTBIT_a,) > ->+ USE_FEATURE_UDHCP_PORT(OPT_P = 1 << OPTBIT_P,) > + USE_FOR_MMU(,OPTBIT_b) > + USE_FEATURE_UDHCPC_ARPING(,OPTBIT_a) > + USE_FEATURE_UDHCP_PORT(,OPTBIT_P) > + USE_FOR_MMU(,OPT_b = 1 << OPTBIT_b) > + USE_FEATURE_UDHCPC_ARPING(,OPT_a = 1 << OPTBIT_a) > + USE_FEATURE_UDHCP_PORT(,OPT_P = 1 << OPTBIT_P) > > > }; Right. I see your point. And there's more that could be done to cleanup insane amount of ifdefs. But the first measure should be to move all such macros to header files in a consistant way. Thoughts? Cheers, -- Cristian From vda.linux at googlemail.com Sat Jun 14 22:46:27 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 15 Jun 2008 07:46:27 +0200 Subject: [rfc] macros and macro usage In-Reply-To: <0806142002290.3557@somehost> References: <0806142002290.3557@somehost> Message-ID: <200806150746.28009.vda.linux@googlemail.com> On Saturday 14 June 2008 21:20, Cristian Ionescu-Idbohrn wrote: > $ egrep _ARPING include/autoconf.h > #define CONFIG_ARPING 1 > #define ENABLE_ARPING 1 > #define USE_ARPING(...) __VA_ARGS__ > #define SKIP_ARPING(...) > #define CONFIG_FEATURE_UDHCPC_ARPING 1 > #define ENABLE_FEATURE_UDHCPC_ARPING 1 > #define USE_FEATURE_UDHCPC_ARPING(...) __VA_ARGS__ > #define SKIP_FEATURE_UDHCPC_ARPING(...) > > $ egrep _MMU applets/usage.c > ./applets/usage.c:#define BB_MMU 0 > ./applets/usage.c:#define USE_FOR_MMU(...) > ./applets/usage.c:#define BB_MMU 1 > ./applets/usage.c:#define USE_FOR_MMU(...) __VA_ARGS__ > > For consistancy, I would have expected something similar to this instead: > #define USE_BB_MMU(...) __VA_ARGS__ > #define SKIP_BB_MMU(...) The point is, SKIP_xxx(foo) is misnamed. It doesn't skip anything. It includes foo if xxx is not selected. BTW, USE_ARPING(foo) is misnamed *too*. It's not "using arping", it's "using foo if arping [is selected]". USE_IF_ARPING would be more readable. For MMU, I decided to try to make up better names and see how they will stick. > ... > > Is applets/usage.c the best place? Propose another one. -- vda From vda.linux at googlemail.com Sat Jun 14 22:48:04 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 15 Jun 2008 07:48:04 +0200 Subject: [rfc] macros and macro usage In-Reply-To: <0806142002290.3557@somehost> References: <0806142002290.3557@somehost> Message-ID: <200806150748.04620.vda.linux@googlemail.com> On Saturday 14 June 2008 21:20, Cristian Ionescu-Idbohrn wrote: > Shouldn't this: > > USE_FEATURE_UDHCPC_ARPING(OPTBIT_a,) > > be prefered, instead of this: > > #if ENABLE_FEATURE_UDHCPC_ARPING > OPTBIT_a, > #endif Yes, generally, if USE_xxx(foo) doesn't stretch across more than one line. That looks worse (less readable) than ifdef. > The attchment shows how networking/udhcp/dhcpc.c may be changed. Applied, thanks! -- vda From cristian.ionescu-idbohrn at axis.com Sun Jun 15 01:01:31 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 15 Jun 2008 10:01:31 +0200 (CEST) Subject: [rfc] macros and macro usage In-Reply-To: <200806150746.28009.vda.linux@googlemail.com> References: <0806142002290.3557@somehost> <200806150746.28009.vda.linux@googlemail.com> Message-ID: <0806150911120.3557@somehost> On Sun, 15 Jun 2008, Denys Vlasenko wrote: > On Saturday 14 June 2008 21:20, Cristian Ionescu-Idbohrn wrote: > > $ egrep _ARPING include/autoconf.h > > #define CONFIG_ARPING 1 > > #define ENABLE_ARPING 1 > > #define USE_ARPING(...) __VA_ARGS__ > > #define SKIP_ARPING(...) > > #define CONFIG_FEATURE_UDHCPC_ARPING 1 > > #define ENABLE_FEATURE_UDHCPC_ARPING 1 > > #define USE_FEATURE_UDHCPC_ARPING(...) __VA_ARGS__ > > #define SKIP_FEATURE_UDHCPC_ARPING(...) > > > > $ egrep _MMU applets/usage.c > > ./applets/usage.c:#define BB_MMU 0 > > ./applets/usage.c:#define USE_FOR_MMU(...) > > ./applets/usage.c:#define BB_MMU 1 > > ./applets/usage.c:#define USE_FOR_MMU(...) __VA_ARGS__ > > > > For consistancy, I would have expected something similar to this instead: > > #define USE_BB_MMU(...) __VA_ARGS__ > > #define SKIP_BB_MMU(...) > > The point is, SKIP_xxx(foo) is misnamed. It doesn't skip anything. > It includes foo if xxx is not selected. > BTW, USE_ARPING(foo) is misnamed *too*. It's not "using arping", > it's "using foo if arping [is selected]". USE_IF_ARPING would be > more readable. Yes, you have a point. USE_IF_FEATURE_X and SKIP_IF_FEATURE_X would be better. > For MMU, I decided to try to make up better names and see how they will > stick. Yes. > > ... > > > > Is applets/usage.c the best place? > > Propose another one. It should be a header file. Some are autogenerated to include/autoconf.h. We already have an include/bbconfigopts.h. How does include/bbconf.h or include/bbdefs.h or already existing include/busybox.h sound? Cheers, -- Cristian From cristian.ionescu-idbohrn at axis.com Sun Jun 15 01:26:26 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 15 Jun 2008 10:26:26 +0200 (CEST) Subject: [patch] networking/udhcp/dhcpc.c: smalll whitespace damage Message-ID: <0806151025180.3557@somehost> Cleanup patch. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcpc.c.patch Type: text/x-diff Size: 340 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080615/bb646b7e/attachment.patch From cristian.ionescu-idbohrn at axis.com Sun Jun 15 01:37:31 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 15 Jun 2008 10:37:31 +0200 (CEST) Subject: [patch] networking/udhcp/dhcpc.h: USE_ vs #if ENABLE_ Message-ID: <0806151032550.3557@somehost> Small patch. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcpc.h.patch Type: text/x-diff Size: 669 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080615/c1445c2d/attachment.patch From cristian.ionescu-idbohrn at axis.com Sun Jun 15 01:56:13 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 15 Jun 2008 10:56:13 +0200 (CEST) Subject: [rfc] macros and macro usage In-Reply-To: <200806150748.04620.vda.linux@googlemail.com> References: <0806142002290.3557@somehost> <200806150748.04620.vda.linux@googlemail.com> Message-ID: <0806151045150.3557@somehost> On Sun, 15 Jun 2008, Denys Vlasenko wrote: > On Saturday 14 June 2008 21:20, Cristian Ionescu-Idbohrn wrote: > > Shouldn't this: > > > > USE_FEATURE_UDHCPC_ARPING(OPTBIT_a,) > > > > be prefered, instead of this: > > > > #if ENABLE_FEATURE_UDHCPC_ARPING > > OPTBIT_a, > > #endif > > Yes, generally, if USE_xxx(foo) doesn't stretch across more than one line. > That looks worse (less readable) than ifdef. > > > The attchment shows how networking/udhcp/dhcpc.c may be changed. > > Applied, thanks! Great. And now there are just a gazillion other places that need similar adjustments ;) But before starting with that I feel it's important to make some preparations and agree on the general principles. It was the paragraph "No ifdefs in .c Code" in this article: http://www.linuxjournal.com/article/5780 Natanael Copa pointed to the other day that got me started ;) Cheers, -- Cristian From vda.linux at googlemail.com Sun Jun 15 02:49:23 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 15 Jun 2008 11:49:23 +0200 Subject: [patch] networking/udhcp/dhcpc.c: smalll whitespace damage In-Reply-To: <0806151025180.3557@somehost> References: <0806151025180.3557@somehost> Message-ID: <200806151149.23715.vda.linux@googlemail.com> On Sunday 15 June 2008 10:26, Cristian Ionescu-Idbohrn wrote: > Cleanup patch. Applied. -- vda From vda.linux at googlemail.com Sun Jun 15 02:59:35 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 15 Jun 2008 11:59:35 +0200 Subject: [patch] networking/udhcp/dhcpc.h: USE_ vs #if ENABLE_ In-Reply-To: <0806151032550.3557@somehost> References: <0806151032550.3557@somehost> Message-ID: <200806151159.35310.vda.linux@googlemail.com> On Sunday 15 June 2008 10:37, Cristian Ionescu-Idbohrn wrote: > Small patch. Oh no!!... death from 2.5 gazillions of small patches... -- vda From wharms at bfs.de Sun Jun 15 06:08:46 2008 From: wharms at bfs.de (walter harms) Date: Sun, 15 Jun 2008 15:08:46 +0200 Subject: [rfc] macros and macro usage In-Reply-To: <0806150911120.3557@somehost> References: <0806142002290.3557@somehost> <200806150746.28009.vda.linux@googlemail.com> <0806150911120.3557@somehost> Message-ID: <4855145E.2040102@bfs.de> Cristian Ionescu-Idbohrn wrote: > On Sun, 15 Jun 2008, Denys Vlasenko wrote: > >> On Saturday 14 June 2008 21:20, Cristian Ionescu-Idbohrn wrote: >>> $ egrep _ARPING include/autoconf.h >>> #define CONFIG_ARPING 1 >>> #define ENABLE_ARPING 1 >>> #define USE_ARPING(...) __VA_ARGS__ >>> #define SKIP_ARPING(...) >>> #define CONFIG_FEATURE_UDHCPC_ARPING 1 >>> #define ENABLE_FEATURE_UDHCPC_ARPING 1 >>> #define USE_FEATURE_UDHCPC_ARPING(...) __VA_ARGS__ >>> #define SKIP_FEATURE_UDHCPC_ARPING(...) >>> >>> $ egrep _MMU applets/usage.c >>> ./applets/usage.c:#define BB_MMU 0 >>> ./applets/usage.c:#define USE_FOR_MMU(...) >>> ./applets/usage.c:#define BB_MMU 1 >>> ./applets/usage.c:#define USE_FOR_MMU(...) __VA_ARGS__ >>> >>> For consistancy, I would have expected something similar to this instead: >>> #define USE_BB_MMU(...) __VA_ARGS__ >>> #define SKIP_BB_MMU(...) >> The point is, SKIP_xxx(foo) is misnamed. It doesn't skip anything. >> It includes foo if xxx is not selected. >> BTW, USE_ARPING(foo) is misnamed *too*. It's not "using arping", >> it's "using foo if arping [is selected]". USE_IF_ARPING would be >> more readable. > > Yes, you have a point. > USE_IF_FEATURE_X and SKIP_IF_FEATURE_X would be better. assume that: skip = ! use that means you can write: USE_IF_FEATURE(!x) that would reduce the number of macros by one (type). ntl: your point is correct, we have way to many macros someone should write down how the names (USE,ENABLE,DISABLE) are used. Anything else will lead to a temporay cleanup only. re, wh > >> For MMU, I decided to try to make up better names and see how they will >> stick. > From rep.dot.nop at gmail.com Sun Jun 15 06:58:08 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 15 Jun 2008 15:58:08 +0200 Subject: [rfc] macros and macro usage In-Reply-To: <4855145E.2040102@bfs.de> References: <0806142002290.3557@somehost> <200806150746.28009.vda.linux@googlemail.com> <0806150911120.3557@somehost> <4855145E.2040102@bfs.de> Message-ID: <20080615135808.GG10734@mx.loc> On Sun, Jun 15, 2008 at 03:08:46PM +0200, walter harms wrote: > > >Cristian Ionescu-Idbohrn wrote: >> On Sun, 15 Jun 2008, Denys Vlasenko wrote: >> >>> On Saturday 14 June 2008 21:20, Cristian Ionescu-Idbohrn wrote: >>>> $ egrep _ARPING include/autoconf.h >>>> #define CONFIG_ARPING 1 >>>> #define ENABLE_ARPING 1 >>>> #define USE_ARPING(...) __VA_ARGS__ >>>> #define SKIP_ARPING(...) >>>> #define CONFIG_FEATURE_UDHCPC_ARPING 1 >>>> #define ENABLE_FEATURE_UDHCPC_ARPING 1 >>>> #define USE_FEATURE_UDHCPC_ARPING(...) __VA_ARGS__ >>>> #define SKIP_FEATURE_UDHCPC_ARPING(...) >>>> >>>> $ egrep _MMU applets/usage.c >>>> ./applets/usage.c:#define BB_MMU 0 >>>> ./applets/usage.c:#define USE_FOR_MMU(...) >>>> ./applets/usage.c:#define BB_MMU 1 >>>> ./applets/usage.c:#define USE_FOR_MMU(...) __VA_ARGS__ >>>> >>>> For consistancy, I would have expected something similar to this instead: >>>> #define USE_BB_MMU(...) __VA_ARGS__ >>>> #define SKIP_BB_MMU(...) >>> The point is, SKIP_xxx(foo) is misnamed. It doesn't skip anything. >>> It includes foo if xxx is not selected. >>> BTW, USE_ARPING(foo) is misnamed *too*. It's not "using arping", >>> it's "using foo if arping [is selected]". USE_IF_ARPING would be >>> more readable. >> >> Yes, you have a point. >> USE_IF_FEATURE_X and SKIP_IF_FEATURE_X would be better. I don't think explicitely adding the implied "_IF" buys anything. > >assume that: > skip = ! use > >that means you can write: > USE_IF_FEATURE(!x) no, you cannot. Think about e.g.: /* If not blah, then we have to foo */ SKIP_FEATURE_BLAH(unsigned foo_stuff); a '!' doesn't help there. > >that would reduce the number of macros by one (type). > >ntl: your point is correct, we have way to many macros I disagree. There is USE_ and SKIP_ that use varargs. For bigger blocks or where it is more readable, there is ENABLE and !ENABLE I propose you look at TODO instead and pick a random item to take care of. That would IMHO make more sense :) From cristian.ionescu-idbohrn at axis.com Sun Jun 15 07:48:54 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 15 Jun 2008 16:48:54 +0200 (CEST) Subject: [rfc] macros and macro usage In-Reply-To: <20080615135808.GG10734@mx.loc> References: <0806142002290.3557@somehost> <200806150746.28009.vda.linux@googlemail.com> <0806150911120.3557@somehost> <4855145E.2040102@bfs.de> <20080615135808.GG10734@mx.loc> Message-ID: <0806151639050.3557@somehost> On Sun, 15 Jun 2008, Bernhard Fischer wrote: > >> USE_IF_FEATURE_X and SKIP_IF_FEATURE_X would be better. > > I don't think explicitely adding the implied "_IF" buys anything. True. Costs 3 extra characters, but makes more obvious what the macro is supposed to do. > I disagree. There is USE_ and SKIP_ that use varargs. For bigger blocks > or where it is more readable, there is ENABLE and !ENABLE Not always possible (without doing more changes). The attachment is a POC for a ifdef free networking/udhcp/dhcpc.c (skipped indentation whitespace for clarity). Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcpc.c.3.patch Type: text/x-diff Size: 1881 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080615/e8c4a7f7/attachment.patch From vda.linux at googlemail.com Sun Jun 15 11:23:20 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 15 Jun 2008 20:23:20 +0200 Subject: [rfc] macros and macro usage In-Reply-To: <0806151639050.3557@somehost> References: <0806142002290.3557@somehost> <20080615135808.GG10734@mx.loc> <0806151639050.3557@somehost> Message-ID: <200806152023.20886.vda.linux@googlemail.com> On Sunday 15 June 2008 16:48, Cristian Ionescu-Idbohrn wrote: > On Sun, 15 Jun 2008, Bernhard Fischer wrote: > > > >> USE_IF_FEATURE_X and SKIP_IF_FEATURE_X would be better. > > > > I don't think explicitely adding the implied "_IF" buys anything. > > True. Costs 3 extra characters, but makes more obvious what the macro is > supposed to do. SKIP_IF_x is wrong. USE_IF_NOT_x! To see it, pick real examples: ... USE_IF_ARPING(int x = y;) SKIP_IF_ARPING(const int x = 5;) <==== ?!! ... ... USE_IF_ARPING(int x = y;) USE_IF_NOT_ARPING(const int x = 5;) ... From cristian.ionescu-idbohrn at axis.com Sun Jun 15 11:29:17 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 15 Jun 2008 20:29:17 +0200 (CEST) Subject: [rfc] macros and macro usage In-Reply-To: <200806152023.20886.vda.linux@googlemail.com> References: <0806142002290.3557@somehost> <20080615135808.GG10734@mx.loc> <0806151639050.3557@somehost> <200806152023.20886.vda.linux@googlemail.com> Message-ID: <0806152028260.13795@somehost> On Sun, 15 Jun 2008, Denys Vlasenko wrote: > On Sunday 15 June 2008 16:48, Cristian Ionescu-Idbohrn wrote: > > On Sun, 15 Jun 2008, Bernhard Fischer wrote: > > > > > >> USE_IF_FEATURE_X and SKIP_IF_FEATURE_X would be better. > > > > > > I don't think explicitely adding the implied "_IF" buys anything. > > > > True. Costs 3 extra characters, but makes more obvious what the macro is > > supposed to do. > > SKIP_IF_x is wrong. USE_IF_NOT_x! To see it, pick real examples: > > ... > USE_IF_ARPING(int x = y;) > SKIP_IF_ARPING(const int x = 5;) <==== ?!! > ... > > ... > USE_IF_ARPING(int x = y;) > USE_IF_NOT_ARPING(const int x = 5;) > ... I'm all with you :) Cheers, -- Cristian From wharms at bfs.de Sun Jun 15 11:29:36 2008 From: wharms at bfs.de (walter harms) Date: Sun, 15 Jun 2008 20:29:36 +0200 Subject: [rfc] macros and macro usage In-Reply-To: <20080615135808.GG10734@mx.loc> References: <0806142002290.3557@somehost> <200806150746.28009.vda.linux@googlemail.com> <0806150911120.3557@somehost> <4855145E.2040102@bfs.de> <20080615135808.GG10734@mx.loc> Message-ID: <48555F90.9070603@bfs.de> Bernhard Fischer wrote: > > > I don't think explicitely adding the implied "_IF" buys anything. >> assume that: >> skip = ! use >> >> that means you can write: >> USE_IF_FEATURE(!x) > no, you cannot. Think about e.g.: > > /* If not blah, then we have to foo */ > SKIP_FEATURE_BLAH(unsigned foo_stuff); this was symbolic. you can also think of IF_FOO_ENABLED( ... ) IF_NOT_FOO_ENABLED( ... ) > a '!' doesn't help there. >> that would reduce the number of macros by one (type). >> >> ntl: your point is correct, we have way to many macros > > I disagree. There is USE_ and SKIP_ that use varargs. For bigger blocks > or where it is more readable, there is ENABLE and !ENABLE grep -ir "#define" * | wc -l 8977 of cause this is only an upper limit but we should ask our self "do we need that ???" i know no every #define is a macro in the sense use above > I propose you look at TODO instead and pick a random item to take care > of. That would IMHO make more sense :) this is correct but open source is about "scratching an itch" and if vda does not like it changes will not be accepted. NTL introducing different names for thinks that do actualy the same is not very clever an will only lead to confusion. just my 2 cents, walter From farmatito at tiscali.it Sun Jun 15 14:06:17 2008 From: farmatito at tiscali.it (Tito) Date: Sun, 15 Jun 2008 23:06:17 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases Message-ID: <200806152306.17955.farmatito@tiscali.it> Hi, while inspecting the last changes in busybox code I hit some issues in libbb/strrstr.c. The strrtstr function fails on some corner cases of a little test program I wrote (and bombs out on NULL pointers): char* strrstr(const char *haystack, const char *needle) { char *tmp = strrchr(haystack, *needle); if (tmp == NULL || strcmp(tmp, needle) != 0) return NULL; return tmp; } ./test 'baaabaaab' vs. 'aaa' : FAILED 'baaabaaaab' vs. 'aaa' : FAILED 'baaabaab' vs. 'aaa' : FAILED 'aaa' vs. 'aaa' : FAILED 'aaa' vs. 'a' : PASSED 'aaa' vs. 'bbb' : PASSED 'a' vs. 'aaa' : PASSED 'aaa' vs. '' : FAILED '' vs. 'aaa' : PASSED '' vs. '' : FAILED Segmentation fault I've tried to write a more robust variant: /* * The strrstr() function finds the last occurrence of the nul terminated * substring needle in the nul terminated string haystack. The terminating * nul characters or NULL pointers are not compared. */ char* strrstr(const char *haystack, const char *needle) { char *p = (char *)haystack; char *s1; char *s2; if (!haystack || !needle) return NULL; while (*p++) /* VOID */; p--; while (p-- != haystack) { s1 = p; s2 = (char *)needle; while (*s1 && *s1++ == *s2++) { if (!*s2) return p; } } return NULL; } This function passes all of the test cases I could think about: ./test 'baaabaaab' vs. 'aaa' : PASSED 'baaabaaaab' vs. 'aaa' : PASSED 'baaabaab' vs. 'aaa' : PASSED 'aaa' vs. 'aaa' : PASSED 'aaa' vs. 'a' : PASSED 'aaa' vs. 'bbb' : PASSED 'a' vs. 'aaa' : PASSED 'aaa' vs. '' : PASSED '' vs. 'aaa' : PASSED '' vs. '' : PASSED 'NULL' vs. 'NULL' : PASSED '' vs. 'NULL' : PASSED 'NULL' vs. '' : PASSED 'aaa' vs. 'NULL' : PASSED 'NULL' vs. 'aaa' : PASSED For the moment there is no diff but just a drop in replacement for strrstr.c for testing and improvement by the list members. There is a little size increase: scripts/bloat-o-meter busybox_old busybox_unstripped function old new delta strrstr 53 73 +20 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/0 up/down: 20/0) Total: 20 bytes The strrstr function at the moment is used only in depmod so the depmod author should check if this new implementation is suitable to be used. Hints, critics and improvements are ,as always, welcome. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: strrstr.c Type: text/x-csrc Size: 2810 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080615/ea5de4a5/attachment.c From rep.dot.nop at gmail.com Sun Jun 15 14:21:43 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 15 Jun 2008 23:21:43 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <200806152306.17955.farmatito@tiscali.it> References: <200806152306.17955.farmatito@tiscali.it> Message-ID: <20080615212143.GO10734@mx.loc> On Sun, Jun 15, 2008 at 11:06:17PM +0200, Tito wrote: >Hi, >while inspecting the last changes in busybox code I hit some issues in >libbb/strrstr.c. The strrtstr function fails on some corner cases of a little >test program I wrote (and bombs out on NULL pointers): This was intended, see below. >For the moment there is no diff but just a drop in replacement >for strrstr.c for testing and improvement by the list members. >There is a little size increase: heh, i wouldn't call 50% a "little", but ok. Ultimately i don't care, though. I just put in the smallest version for depmod knowing that it will segfault left and right if somebody throws NULL on it, since it was enough for depmod. Doesn't it suffice if we just if (haystack == NULL || needle == NULL) return NULL and keep the strcmp? >scripts/bloat-o-meter busybox_old busybox_unstripped >function old new delta >strrstr 53 73 +20 >------------------------------------------------------------------------------ >(add/remove: 0/0 grow/shrink: 1/0 up/down: 20/0) Total: 20 bytes > >The strrstr function at the moment is used only in depmod >so the depmod author should check if this new implementation >is suitable to be used. From farmatito at tiscali.it Sun Jun 15 14:34:06 2008 From: farmatito at tiscali.it (Tito) Date: Sun, 15 Jun 2008 23:34:06 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <20080615212143.GO10734@mx.loc> References: <200806152306.17955.farmatito@tiscali.it> <20080615212143.GO10734@mx.loc> Message-ID: <200806152334.06686.farmatito@tiscali.it> On Sunday 15 June 2008 23:21:43 Bernhard Fischer wrote: > On Sun, Jun 15, 2008 at 11:06:17PM +0200, Tito wrote: > >Hi, > >while inspecting the last changes in busybox code I hit some issues in > >libbb/strrstr.c. The strrtstr function fails on some corner cases of a little > >test program I wrote (and bombs out on NULL pointers): > > This was intended, see below. > > >For the moment there is no diff but just a drop in replacement > >for strrstr.c for testing and improvement by the list members. > >There is a little size increase: > > heh, i wouldn't call 50% a "little", but ok. > > Ultimately i don't care, though. I just put in the smallest version for > depmod knowing that it will segfault left and right if somebody throws > NULL on it, since it was enough for depmod. Hi, To be honest I was tempted to remove the code that handles NULL pointers in which case the size is about the same as before. scripts/bloat-o-meter busybox_old busybox_unstripped function old new delta strrstr 53 61 +8 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/0 up/down: 8/0) Total: 8 bytes My point was that: 1) actually it fails to detect "aa" in "aaa" 2) this and other limitations shown by my test program are not described in the code nor in the function name so people in the future will think they have a correct working implementation of strrstr 3) if it is good enough for depmod and used only by depmod then move it into depmod.c or fix it for future use. Ciao, Tito > Doesn't it suffice if we just > if (haystack == NULL || needle == NULL) return NULL and keep the strcmp? > > > >scripts/bloat-o-meter busybox_old busybox_unstripped > >function old new delta > >strrstr 53 73 +20 > >------------------------------------------------------------------------------ > >(add/remove: 0/0 grow/shrink: 1/0 up/down: 20/0) Total: 20 bytes > > > >The strrstr function at the moment is used only in depmod > >so the depmod author should check if this new implementation > >is suitable to be used. > From vda.linux at googlemail.com Sun Jun 15 21:33:35 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 16 Jun 2008 06:33:35 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <200806152306.17955.farmatito@tiscali.it> References: <200806152306.17955.farmatito@tiscali.it> Message-ID: <200806160633.35543.vda.linux@googlemail.com> On Sunday 15 June 2008 23:06, Tito wrote: > Hi, > while inspecting the last changes in busybox code I hit some issues in > libbb/strrstr.c. The strrtstr function fails on some corner cases of a little > test program I wrote (and bombs out on NULL pointers): > > char* strrstr(const char *haystack, const char *needle) > { > char *tmp = strrchr(haystack, *needle); > if (tmp == NULL || strcmp(tmp, needle) != 0) > return NULL; > return tmp; > } > > > ./test > 'baaabaaab' vs. 'aaa' : FAILED > 'baaabaaaab' vs. 'aaa' : FAILED > 'baaabaab' vs. 'aaa' : FAILED > 'aaa' vs. 'aaa' : FAILED > 'aaa' vs. 'a' : PASSED > 'aaa' vs. 'bbb' : PASSED > 'a' vs. 'aaa' : PASSED > 'aaa' vs. '' : FAILED > '' vs. 'aaa' : PASSED > '' vs. '' : FAILED > Segmentation fault > > I've tried to write a more robust variant: > > /* > * The strrstr() function finds the last occurrence of the nul terminated > * substring needle in the nul terminated string haystack. The terminating > * nul characters or NULL pointers are not compared. > */ Why is it important to work with NULLs? E.g. strlen would SEGV on NULL. Mine version is: char* strrstr(const char *haystack, const char *needle) { char *r = NULL; if (!needle[0]) return r; while (1) { char *p = strstr(haystack, needle); if (!p) return r; r = p; haystack = p + 1; } } # ./a.out 'baaabaaab' vs. 'aaa' : PASSED 'baaabaaaab' vs. 'aaa' : PASSED 'baaabaab' vs. 'aaa' : PASSED 'aaa' vs. 'aaa' : PASSED 'aaa' vs. 'a' : PASSED 'aaa' vs. 'bbb' : PASSED 'a' vs. 'aaa' : PASSED 'aaa' vs. '' : PASSED '' vs. 'aaa' : PASSED '' vs. '' : PASSED (cases with NULLs are not tested) Comparing with current busybox: function old new delta strrstr 53 42 -11 BTW, is it normal: ret |= !(n = (strrstr("aaa", "") == NULL)); printf("'aaa' vs. '' : %s\n", n ? "PASSED" : "FAILED"); ret |= !(n = (strrstr("", "") == NULL)); printf("'' vs. '' : %s\n", n ? "PASSED" : "FAILED"); "" needle definitely CAN be found in (any) haystack. Why we return NULL?! -- vda From farmatito at tiscali.it Sun Jun 15 23:45:18 2008 From: farmatito at tiscali.it (Tito) Date: Mon, 16 Jun 2008 08:45:18 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <200806160633.35543.vda.linux@googlemail.com> References: <200806152306.17955.farmatito@tiscali.it> <200806160633.35543.vda.linux@googlemail.com> Message-ID: <200806160845.18643.farmatito@tiscali.it> On Monday 16 June 2008 06:33:35 you wrote: > On Sunday 15 June 2008 23:06, Tito wrote: > > Hi, > > while inspecting the last changes in busybox code I hit some issues in > > libbb/strrstr.c. The strrtstr function fails on some corner cases of a little > > test program I wrote (and bombs out on NULL pointers): > > > > char* strrstr(const char *haystack, const char *needle) > > { > > char *tmp = strrchr(haystack, *needle); > > if (tmp == NULL || strcmp(tmp, needle) != 0) > > return NULL; > > return tmp; > > } > > > > > > ./test > > 'baaabaaab' vs. 'aaa' : FAILED > > 'baaabaaaab' vs. 'aaa' : FAILED > > 'baaabaab' vs. 'aaa' : FAILED > > 'aaa' vs. 'aaa' : FAILED > > 'aaa' vs. 'a' : PASSED > > 'aaa' vs. 'bbb' : PASSED > > 'a' vs. 'aaa' : PASSED > > 'aaa' vs. '' : FAILED > > '' vs. 'aaa' : PASSED > > '' vs. '' : FAILED > > Segmentation fault > > > > I've tried to write a more robust variant: > > > > /* > > * The strrstr() function finds the last occurrence of the nul terminated > > * substring needle in the nul terminated string haystack. The terminating > > * nul characters or NULL pointers are not compared. > > */ > > Why is it important to work with NULLs? > E.g. strlen would SEGV on NULL. Hi, It is just my way of doing things, I don't like functions that segfault on NULL as usually most of the times you have to add guards in the calling code, but as said this part of the code could easily be removed so that the size is almost the same as before. There was one more reason to avoid strlen, but it was just my personal stupid paranoia: as we don't know the lenght of the strings it was difficult to decide the correct type for the result to avoid possible overflows OTOH using the biggest looked like overkill, so I decided to walk to the end of the string instead. > Mine version is: > > char* strrstr(const char *haystack, const char *needle) > { > char *r = NULL; > > if (!needle[0]) > return r; > while (1) { > char *p = strstr(haystack, needle); > if (!p) > return r; > r = p; > haystack = p + 1; > } > } > > # ./a.out > 'baaabaaab' vs. 'aaa' : PASSED > 'baaabaaaab' vs. 'aaa' : PASSED > 'baaabaab' vs. 'aaa' : PASSED > 'aaa' vs. 'aaa' : PASSED > 'aaa' vs. 'a' : PASSED > 'aaa' vs. 'bbb' : PASSED > 'a' vs. 'aaa' : PASSED > 'aaa' vs. '' : PASSED > '' vs. 'aaa' : PASSED > '' vs. '' : PASSED > (cases with NULLs are not tested) > > Comparing with current busybox: > > function old new delta > strrstr 53 42 -11 > > BTW, is it normal: > > ret |= !(n = (strrstr("aaa", "") == NULL)); > printf("'aaa' vs. '' : %s\n", n ? "PASSED" : "FAILED"); > ret |= !(n = (strrstr("", "") == NULL)); > printf("'' vs. '' : %s\n", n ? "PASSED" : "FAILED"); > > "" needle definitely CAN be found in (any) haystack. Why we return NULL?! I misunderstood the man page: DESCRIPTION The strstr() function finds the first occurrence of the substring needle in the string haystack. The terminating ?\0? characters are not compared. I thought "" is '\0' and should not be compared. But by running a little test program the behaviour of strstr seems to be different, so this certainly needs to be fixed : int main(int argc, char **argv) { printf("strstr(aaa,'') returns %sNULL\n", (strstr("aaa", "") == NULL) ? "" :"not-"); printf("%s\n", strstr("aaa", "")); printf("strstr('','') returns %sNULL\n", (strstr("", "") == NULL) ? "" :"not-"); printf("%s\n", strstr("", "")); return 0; } ./test2 strstr(aaa,"") returns not-NULL aaa strstr("","") returns not-NULL debian:~/Desktop# Ciao, Tito > -- > vda > From vda.linux at googlemail.com Mon Jun 16 00:12:16 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 16 Jun 2008 09:12:16 +0200 Subject: pxe server support. In-Reply-To: <50326.192.168.10.101.1209029197.squirrel@193.253.62.30> References: <50326.192.168.10.101.1209029197.squirrel@193.253.62.30> Message-ID: <200806160912.16990.vda.linux@googlemail.com> On Thursday 24 April 2008 11:26, Pascal Bellard wrote: > Hello, > > Please find attached a patch-file to add pxe server support. > Used by http://www.slitaz.org/en > > function old new delta > tftp_protocol 1465 1633 +168 > tftp_get_option - 102 +102 > tftpd_main 506 547 +41 > .rodata 134832 134864 +32 > tftp_main 232 234 +2 > tftp_get_blksize 103 - -103 > ------------------------------------------------------------------------------ > (add/remove: 1/1 grow/shrink: 4/0 up/down: 345/-103) Total: 242 > bytes Applied, thanks. -- vda From rep.dot.nop at gmail.com Mon Jun 16 00:47:31 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 16 Jun 2008 09:47:31 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <200806160845.18643.farmatito@tiscali.it> References: <200806152306.17955.farmatito@tiscali.it> <200806160633.35543.vda.linux@googlemail.com> <200806160845.18643.farmatito@tiscali.it> Message-ID: <20080616074731.GA19499@mx.loc> On Mon, Jun 16, 2008 at 08:45:18AM +0200, Tito wrote: >On Monday 16 June 2008 06:33:35 you wrote: >There was one more reason to avoid strlen, but it was just my personal stupid paranoia: > >as we don't know the lenght of the strings it was difficult to decide >the correct type for the result to avoid possible overflows >OTOH using the biggest looked like overkill, >so I decided to walk to the end of the string instead. > >> Mine version is: >> >> char* strrstr(const char *haystack, const char *needle) >> { >> char *r = NULL; >> >> if (!needle[0]) >> return r; >> while (1) { >> char *p = strstr(haystack, needle); >> if (!p) >> return r; >> r = p; >> haystack = p + 1; >> } >> } >> >> # ./a.out >> 'baaabaaab' vs. 'aaa' : PASSED >> 'baaabaaaab' vs. 'aaa' : PASSED >> 'baaabaab' vs. 'aaa' : PASSED >> 'aaa' vs. 'aaa' : PASSED >> 'aaa' vs. 'a' : PASSED >> 'aaa' vs. 'bbb' : PASSED >> 'a' vs. 'aaa' : PASSED >> 'aaa' vs. '' : PASSED >> '' vs. 'aaa' : PASSED >> '' vs. '' : PASSED >> (cases with NULLs are not tested) >> >> Comparing with current busybox: >> >> function old new delta >> strrstr 53 42 -11 Sounds good. Please apply. >./test2 >strstr(aaa,"") returns not-NULL >aaa >strstr("","") returns not-NULL For practical reasons i would return NULL if one of them is NULL or "" to avoid checks in the callers. From mkaehlcke at e2s.net Mon Jun 16 04:08:01 2008 From: mkaehlcke at e2s.net (Matthias Kaehlcke) Date: Mon, 16 Jun 2008 13:08:01 +0200 Subject: [PATCH] Fix typo in udhcp_send_raw_packet() Message-ID: <48564991.5000601@e2s.net> The attached patch fixes a typo in udhcp_send_raw_packet() renaming the enum values IP_UPD_DHCP_SIZE and UPD_DHCP_SIZE to IP_UDP_DHCP_SIZE and UDP_DHCP_SIZE Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: udhcp-udp-typo.patch Type: text/x-patch Size: 1648 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080616/d994d91e/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mkaehlcke.vcf Type: text/x-vcard Size: 315 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080616/d994d91e/attachment.vcf From jsimmons at infradead.org Mon Jun 16 06:36:19 2008 From: jsimmons at infradead.org (James Simmons) Date: Mon, 16 Jun 2008 14:36:19 +0100 (BST) Subject: ash/stty usage In-Reply-To: <200806140647.09243.vda.linux@googlemail.com> References: <200806131211.20392.vda.linux@googlemail.com> <200806140647.09243.vda.linux@googlemail.com> Message-ID: > Smaller testcase: > > a='a b='\033#' > r=${a// echo $r > > Results: > > # sh zz > a\033#b > # ./busybox ash zz > aK#b > > '<' is not special. Replacing 'b' in 'abc' would work the same. > The culprit is '\' in replacement. > > BTW: I found out who's the author of ${var//s/r} code in ash. It's... you: :-( > r21481 | vda | 2008-03-25 02:17:40 +0100 | 17 lines > > ash: optional bash-like pattern subst and substring opts > (by James Simmons ) > TODO: write testsuite! The patch is much nicer than mine. Unfortunely it still doesn't work. Will track it down today. From jsimmons at infradead.org Mon Jun 16 06:40:17 2008 From: jsimmons at infradead.org (James Simmons) Date: Mon, 16 Jun 2008 14:40:17 +0100 (BST) Subject: ash/stty usage In-Reply-To: References: <200806131211.20392.vda.linux@googlemail.com> <200806140647.09243.vda.linux@googlemail.com> Message-ID: > The patch is much nicer than mine. Unfortunely it still doesn't work. > Will track it down today. Ooops. I take that back. It does work. Tested with wrong shell. Thank you. From d.samuel at courantmultimedia.fr Mon Jun 16 07:18:44 2008 From: d.samuel at courantmultimedia.fr (SAMUEL Dinesh) Date: Mon, 16 Jun 2008 16:18:44 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card Message-ID: <20080616141650.419DF1C000AA@mwinf2703.orange.fr> Hello We have the same problem as described in this link. http://busybox.net/lists/busybox/2008-June/031835.html We don't use WLAN card. Just the two Ethernet cards included in the taihu evaluation board (ppc 405ep). We tried the solution supplied in the topic linked below and it worked for us. Tcpdump output on the dhcp server looks pretty normal. Here's the debug output we had before modifying clientsocket.c with(out) your code block : busybox-1.10.3/busybox udhcpc -i eth1 ### adapter index 2 ### adapter hardware address 50:00:00:00:26:01 udhcpc (v1.10.3) started ### vfork'ing and execle'ing /etc/init.d/udhcpc.script ### entering raw listen mode ### opening raw socket on ifindex 2 ### got raw socket fd 6 ### attached filter to raw socket fd 6 ### bound to raw socket fd 6 ### adding option 0x35 ### adding option 0x3d ### adding option 0x3c ### adding option 0x39 Sending discover... ### Waiting on select... ### Unrelated/bogus packet ### Waiting on select... ### adding option 0x35 ### adding option 0x3d ### adding option 0x3c ### adding option 0x39 Sending discover... ### Waiting on select... ### adding option 0x35 ### adding option 0x3d ### adding option 0x3c ### adding option 0x39 Sending discover... Could you please provide us an explanation for this. If removing the code block you specified is enough, please let us know too :-) Thank you for your help Dinesh, Joseph -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080616/ed72872d/attachment.htm From dronnikov at gmail.com Mon Jun 16 11:32:23 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Mon, 16 Jun 2008 11:32:23 -0700 (PDT) Subject: =?utf-8?B?TU9EUFJPQkU6IG1vZHVsZXMuZGVwIHdpdGggYnVuZGxlZCBhbGlhc2Vz?= Message-ID: <4856b1b7.2234440a.035e.6d8d@mx.google.com> Hello, Bernhard! Seems modprobe gets stuck (SEGV) on subj. It assumes modules.dep contain only module dependencies of format module: dep [ ...] where ":" delimits the parts of definition. Bundled alias definitions of form alias usb:* * result in false positives at line 396 in modprobe.c. Plz, fix this issue. -- Vladimir From rep.dot.nop at gmail.com Mon Jun 16 11:43:25 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 16 Jun 2008 20:43:25 +0200 Subject: MODPROBE: modules.dep with bundled aliases In-Reply-To: <4856b1b7.2234440a.035e.6d8d@mx.google.com> References: <4856b1b7.2234440a.035e.6d8d@mx.google.com> Message-ID: <20080616184325.GE22089@mx.loc> On Mon, Jun 16, 2008 at 11:32:23AM -0700, dronnikov at gmail.com wrote: >Hello, Bernhard! > >Seems modprobe gets stuck (SEGV) on subj. > >It assumes modules.dep contain only module dependencies of format >module: dep [ ...] >where ":" delimits the parts of definition. > >Bundled alias definitions of form >alias usb:* * >result in false positives at line 396 in modprobe.c. What do you mean with "Bundled alias"? Please give an exact example for me to reproduce. > >Plz, fix this issue. Erm, "please", please ;) Also, i suspect you don't have alias-parsing enabled in modprobe, do you? Please show me your $ grep ALIAS .config Thanks, From dronnikov at gmail.com Mon Jun 16 11:58:24 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Mon, 16 Jun 2008 18:58:24 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_MODPROBE:_modules.dep_with_bundled_aliases?= In-Reply-To: <20080616184325.GE22089@mx.loc> References: <4856b1b7.2234440a.035e.6d8d@mx.google.com> <20080616184325.GE22089@mx.loc> Message-ID: <6784529b0806161158n262ff1bdsaf17e0a72376fa4e@mail.gmail.com> BB depmod has ability to dump alias= definitions to modules.dep. When I later run BB modprobe which uses modules.dep which was generated with BB depmod (which has dumped alias= definitions :) I get SEGV. Modprobe indeed has alias support. Wrong is the way modprobe treats some alias definitions (which contain ":") as if they were dependencies definitions which in turn use ":" as the delimiter too! I'll send a quick and dirty patch in separate. -- Vladimir 2008/6/16, Bernhard Fischer : > On Mon, Jun 16, 2008 at 11:32:23AM -0700, dronnikov at gmail.com wrote: >>Hello, Bernhard! >> >>Seems modprobe gets stuck (SEGV) on subj. >> >>It assumes modules.dep contain only module dependencies of format >>module: dep [ ...] >>where ":" delimits the parts of definition. >> >>Bundled alias definitions of form >>alias usb:* * >>result in false positives at line 396 in modprobe.c. > > What do you mean with "Bundled alias"? Please give an exact example for > me to reproduce. >> >>Plz, fix this issue. > > Erm, "please", please ;) > Also, i suspect you don't have alias-parsing enabled in modprobe, do > you? > Please show me your > $ grep ALIAS .config > > Thanks, > From rep.dot.nop at gmail.com Mon Jun 16 12:07:19 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 16 Jun 2008 21:07:19 +0200 Subject: =?utf-8?B?0J7RgtCy0LXRgg==?= =?utf-8?Q?=3A?= MODPROBE: modules.dep with bundled aliases In-Reply-To: <6784529b0806161158n262ff1bdsaf17e0a72376fa4e@mail.gmail.com> References: <4856b1b7.2234440a.035e.6d8d@mx.google.com> <20080616184325.GE22089@mx.loc> <6784529b0806161158n262ff1bdsaf17e0a72376fa4e@mail.gmail.com> Message-ID: <20080616190719.GA23154@mx.loc> On Mon, Jun 16, 2008 at 06:58:24PM +0000, Vladimir Dronnikov wrote: >BB depmod has ability to dump alias= definitions to modules.dep. When >I later run BB modprobe which uses modules.dep which was generated >with BB depmod (which has dumped alias= definitions :) I get SEGV. >Modprobe indeed has alias support. Wrong is the way modprobe treats >some alias definitions (which contain ":") as if they were >dependencies definitions which in turn use ":" as the delimiter too! >I'll send a quick and dirty patch in separate. Ah, i see. modprobe tries to use a separate file for the aliases! How odd. I was tricked into putting the aliases into the same file since i only looked at the output of $ depmod -n /lib/modules/$(uname -r)/kernel/drivers/parport/parport_cs.ko /lib/modules/.../kernel/drivers/parport/parport_cs.ko: # pci module vendor device subvendor subdevice class # class_mask driver_data # usb module match_flags idVendor idProduct bcdDevice_lo # bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol # bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info # ccw module match_flags cu_type cu_model dev_type dev_model # ieee1394 module match_flags vendor_id model_id specifier_id version # isapnp module cardvendor carddevice driver_data vendor # function ... # module matchBits bustype vendor product version evBits keyBits # relBits absBits mscBits ledBits sndBits ffBits [swBits] driver_info # of module name type # compatible # serio module type extra id proto # Aliases extracted from modules themselves. alias pcmcia:m*c*f03fn*pfn*pa*pb*pc*pd* parport_cs alias pcmcia:m0137c0003f*fn*pfn*pa*pb*pc*pd* parport_cs # Aliases for symbols, used by symbol_request(). Perhaps it would be saner to just teach modprobe to grock alias info everywhere and not just in a separate "/lib/modules/%s/modules.alias", un.release Yann, what do you think? From farmatito at tiscali.it Mon Jun 16 12:48:07 2008 From: farmatito at tiscali.it (Tito) Date: Mon, 16 Jun 2008 21:48:07 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <20080616074731.GA19499@mx.loc> References: <200806152306.17955.farmatito@tiscali.it> <200806160845.18643.farmatito@tiscali.it> <20080616074731.GA19499@mx.loc> Message-ID: <200806162148.07296.farmatito@tiscali.it> On Monday 16 June 2008 09:47:31 Bernhard Fischer wrote: > On Mon, Jun 16, 2008 at 08:45:18AM +0200, Tito wrote: > >On Monday 16 June 2008 06:33:35 you wrote: > > >There was one more reason to avoid strlen, but it was just my personal stupid paranoia: > > > >as we don't know the lenght of the strings it was difficult to decide > >the correct type for the result to avoid possible overflows > >OTOH using the biggest looked like overkill, > >so I decided to walk to the end of the string instead. > > > >> Mine version is: > >> > >> char* strrstr(const char *haystack, const char *needle) > >> { > >> char *r = NULL; > >> > >> if (!needle[0]) > >> return r; > >> while (1) { > >> char *p = strstr(haystack, needle); > >> if (!p) > >> return r; > >> r = p; > >> haystack = p + 1; > >> } > >> } > >> > >> # ./a.out > >> 'baaabaaab' vs. 'aaa' : PASSED > >> 'baaabaaaab' vs. 'aaa' : PASSED > >> 'baaabaab' vs. 'aaa' : PASSED > >> 'aaa' vs. 'aaa' : PASSED > >> 'aaa' vs. 'a' : PASSED > >> 'aaa' vs. 'bbb' : PASSED > >> 'a' vs. 'aaa' : PASSED > >> 'aaa' vs. '' : PASSED > >> '' vs. 'aaa' : PASSED > >> '' vs. '' : PASSED > >> (cases with NULLs are not tested) > >> > >> Comparing with current busybox: > >> > >> function old new delta > >> strrstr 53 42 -11 > > Sounds good. Please apply. > >./test2 > >strstr(aaa,"") returns not-NULL > >aaa > >strstr("","") returns not-NULL > > For practical reasons i would return NULL if one of them is NULL or "" > to avoid checks in the callers. > Hi, just for fun, one more variant that seems to pass the tests as modified (for "") char* strrstr(const char *haystack, const char *needle) { char *s = NULL; while (*haystack) { s = (strstr(haystack++, needle)) ? : s; } return s; } but size on my system is the same as Denys' version.... :( scripts/bloat-o-meter busybox_old busybox_unstripped function old new delta strrstr 53 42 -11 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-11) Total: -11 bytes Ciao, Tito From cristian.ionescu-idbohrn at axis.com Mon Jun 16 13:22:16 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 16 Jun 2008 22:22:16 +0200 (CEST) Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <20080616141650.419DF1C000AA@mwinf2703.orange.fr> References: <20080616141650.419DF1C000AA@mwinf2703.orange.fr> Message-ID: <0806162211280.23635@somehost> On Mon, 16 Jun 2008, SAMUEL Dinesh wrote: > We have the same problem as described in this link. > > http://busybox.net/lists/busybox/2008-June/031835.html > > We don't use WLAN card. Just the two Ethernet cards included in the taihu > evaluation board (ppc 405ep). > > We tried the solution supplied in the topic linked below and it worked for > us. > > Tcpdump output on the dhcp server looks pretty normal. Here's the debug > output we had before modifying clientsocket.c with(out) your code block : [snip] > Could you please provide us an explanation for this. If removing the > code block you specified is enough, please let us know too :-) Could you please provide that trace, as Denys asked for? On Thu, 12 Jun 2008, Denys Vlasenko wrote: > > Can you collect "tcpdump -nlieth0 -s0 -vvv -xX port 67 or port 68" > output for both? Write it to a file and post it. If you don't want to make it public, please post to our private addresses. Acctualy: $ tcpdump -nlieth0 -s0 -w 'udp and port (67 or 68)' would be more interesting. I'm interested too, as it was on my initiative that filtering code was added. Cheers, -- Cristian From KokHow.Teh at infineon.com Mon Jun 16 20:48:55 2008 From: KokHow.Teh at infineon.com (KokHow.Teh at infineon.com) Date: Tue, 17 Jun 2008 11:48:55 +0800 Subject: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_t undefined Message-ID: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> Hi; I turn on ENABLE_FEATURE_TASKSET_FANCY and cpu_set_t is undefined. Linux kernel source has cpumask_t defined in include/linux/cpumask.h. Please advise. Regards, KH From vda.linux at googlemail.com Mon Jun 16 21:49:08 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 17 Jun 2008 06:49:08 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <20080616141650.419DF1C000AA@mwinf2703.orange.fr> References: <20080616141650.419DF1C000AA@mwinf2703.orange.fr> Message-ID: <200806170649.08088.vda.linux@googlemail.com> On Monday 16 June 2008 16:18, SAMUEL Dinesh wrote: > Hello > > We have the same problem as described in this link. > > http://busybox.net/lists/busybox/2008-June/031835.html > > We don't use WLAN card. Just the two Ethernet cards included in the taihu > evaluation board (ppc 405ep). > > We tried the solution supplied in the topic linked below and it worked for > us. I see nothing "linked below". Please let me know what exactly did you try, I want to make this fix available to others. > > > > Tcpdump output on the dhcp server looks pretty normal. Here's the debug > output we had before modifying clientsocket.c with(out) your code block : > > > > busybox-1.10.3/busybox udhcpc -i eth1 > > ### adapter index 2 > > ### adapter hardware address 50:00:00:00:26:01 > > udhcpc (v1.10.3) started > > ### vfork'ing and execle'ing /etc/init.d/udhcpc.script > > ### entering raw listen mode > > ### opening raw socket on ifindex 2 > > ### got raw socket fd 6 > > ### attached filter to raw socket fd 6 > > ### bound to raw socket fd 6 > > ### adding option 0x35 > > ### adding option 0x3d > > ### adding option 0x3c > > ### adding option 0x39 > > Sending discover... > > ### Waiting on select... > > ### Unrelated/bogus packet > > ### Waiting on select... > > ### adding option 0x35 > > ### adding option 0x3d > > ### adding option 0x3c > > ### adding option 0x39 > > Sending discover... > > ### Waiting on select... > > ### adding option 0x35 > > ### adding option 0x3d > > ### adding option 0x3c > > ### adding option 0x39 > > Sending discover... > > > > > > Could you please provide us an explanation for this. If removing the code > block you specified is enough, please let us know too :-) > > > > Thank you for your help > > > > Dinesh, Joseph > > > > > > > > From vda.linux at googlemail.com Tue Jun 17 00:28:07 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 17 Jun 2008 09:28:07 +0200 Subject: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_t undefined In-Reply-To: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> References: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> Message-ID: <200806170928.07082.vda.linux@googlemail.com> On Tuesday 17 June 2008 05:48, KokHow.Teh at infineon.com wrote: > Hi; > I turn on ENABLE_FEATURE_TASKSET_FANCY and cpu_set_t is > undefined. Linux kernel source has cpumask_t defined in > include/linux/cpumask.h. Please advise. Against which libc (glibc? uclibc? version?) do you build? -- vda From rep.dot.nop at gmail.com Tue Jun 17 00:41:36 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 17 Jun 2008 09:41:36 +0200 Subject: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_t undefined In-Reply-To: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> References: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> Message-ID: <20080617074135.GB25428@mx.loc> On Tue, Jun 17, 2008 at 11:48:55AM +0800, KokHow.Teh at infineon.com wrote: >Hi; > I turn on ENABLE_FEATURE_TASKSET_FANCY and cpu_set_t is >undefined. Linux kernel source has cpumask_t defined in >include/linux/cpumask.h. Please advise. Let's see. You ask about "cpu_set_t" and "taskset" which would be: http://www.google.com/search?num=50&hl=en&q=cpu_set_t+taskset First hit (RH9) no. Second hit, no. third hit: http://busybox.net/bugs/view.php?id=1769 Please reopen that issue if you still encounter problems. From rep.dot.nop at gmail.com Tue Jun 17 00:43:54 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 17 Jun 2008 09:43:54 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <200806162148.07296.farmatito@tiscali.it> References: <200806152306.17955.farmatito@tiscali.it> <200806160845.18643.farmatito@tiscali.it> <20080616074731.GA19499@mx.loc> <200806162148.07296.farmatito@tiscali.it> Message-ID: <20080617074354.GC25428@mx.loc> On Mon, Jun 16, 2008 at 09:48:07PM +0200, Tito wrote: >On Monday 16 June 2008 09:47:31 Bernhard Fischer wrote: >> On Mon, Jun 16, 2008 at 08:45:18AM +0200, Tito wrote: >> >On Monday 16 June 2008 06:33:35 you wrote: >> >> char* strrstr(const char *haystack, const char *needle) >> >> { >> >> char *r = NULL; >> >> >> >> if (!needle[0]) >> >> return r; >> >> while (1) { >> >> char *p = strstr(haystack, needle); >> >> if (!p) >> >> return r; >> >> r = p; >> >> haystack = p + 1; >Hi, just for fun, >one more variant that seems to pass the tests as modified (for "") > >char* strrstr(const char *haystack, const char *needle) >{ > char *s = NULL; > > while (*haystack) { > s = (strstr(haystack++, needle)) ? : s; > } > return s; >} > >but size on my system is the same as Denys' version.... :( > >scripts/bloat-o-meter busybox_old busybox_unstripped >function old new delta >strrstr 53 42 -11 >------------------------------------------------------------------------------ >(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-11) Total: -11 bytes Tito, can you pick one (your decision) and send me the full file (including your nice testcases)? TIA and cheers, From wharms at bfs.de Tue Jun 17 00:46:36 2008 From: wharms at bfs.de (walter harms) Date: Tue, 17 Jun 2008 09:46:36 +0200 Subject: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_t undefined In-Reply-To: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> References: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> Message-ID: <48576BDC.4080307@bfs.de> KokHow.Teh at infineon.com wrote: > Hi; > I turn on ENABLE_FEATURE_TASKSET_FANCY and cpu_set_t is > undefined. Linux kernel source has cpumask_t defined in > include/linux/cpumask.h. Please advise. > cpumask_t is not defined in older kernels. re, wh From rep.dot.nop at gmail.com Tue Jun 17 01:20:30 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 17 Jun 2008 10:20:30 +0200 Subject: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_t undefined In-Reply-To: <48576BDC.4080307@bfs.de> References: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> <48576BDC.4080307@bfs.de> Message-ID: <20080617082030.GE25428@mx.loc> On Tue, Jun 17, 2008 at 09:46:36AM +0200, walter harms wrote: >cpumask_t is not defined in older kernels. cpumask_t is not used by taskset. cpu_set_t comes from libc and he very, very likely just uses an inappropriate libc. Oh, and note that unless you have more than (let's say) 64 CPUs in you box, the simple printing is enough. I admit that i forgot up to which NCPUs the simple printer works but it should be relatively obvious from the code. If somebody goes to look then we could record that hint in the helptext.. From farmatito at tiscali.it Tue Jun 17 04:52:20 2008 From: farmatito at tiscali.it (Tito) Date: Tue, 17 Jun 2008 13:52:20 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <20080617074354.GC25428@mx.loc> References: <200806152306.17955.farmatito@tiscali.it> <200806162148.07296.farmatito@tiscali.it> <20080617074354.GC25428@mx.loc> Message-ID: <200806171352.20621.farmatito@tiscali.it> On Tuesday 17 June 2008 09:43:54 Bernhard Fischer wrote: > On Mon, Jun 16, 2008 at 09:48:07PM +0200, Tito wrote: > >On Monday 16 June 2008 09:47:31 Bernhard Fischer wrote: > >> On Mon, Jun 16, 2008 at 08:45:18AM +0200, Tito wrote: > >> >On Monday 16 June 2008 06:33:35 you wrote: > > >> >> char* strrstr(const char *haystack, const char *needle) > >> >> { > >> >> char *r = NULL; > >> >> > >> >> if (!needle[0]) > >> >> return r; > >> >> while (1) { > >> >> char *p = strstr(haystack, needle); > >> >> if (!p) > >> >> return r; > >> >> r = p; > >> >> haystack = p + 1; > > >Hi, just for fun, > >one more variant that seems to pass the tests as modified (for "") > > > >char* strrstr(const char *haystack, const char *needle) > >{ > > char *s = NULL; > > > > while (*haystack) { > > s = (strstr(haystack++, needle)) ? : s; > > } > > return s; > >} > > > >but size on my system is the same as Denys' version.... :( > > > >scripts/bloat-o-meter busybox_old busybox_unstripped > >function old new delta > >strrstr 53 42 -11 > >------------------------------------------------------------------------------ > >(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-11) Total: -11 bytes > > Tito, can you pick one (your decision) and send me the full file > (including your nice testcases)? > TIA and cheers, > HI, Attached you can find a test.c file with both strrstr, mine and Denys', they show little differences on "" vs. "" test case. The test cases are improved and checked against the real strstr for consistency. As you and Denys are more experienced it is up yo you to decide what to do. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 2983 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080617/85615543/attachment.c From rep.dot.nop at gmail.com Tue Jun 17 05:13:49 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 17 Jun 2008 14:13:49 +0200 Subject: [RFC] strrstr function in libbb failes on some corner cases In-Reply-To: <200806171352.20621.farmatito@tiscali.it> References: <200806152306.17955.farmatito@tiscali.it> <200806162148.07296.farmatito@tiscali.it> <20080617074354.GC25428@mx.loc> <200806171352.20621.farmatito@tiscali.it> Message-ID: <20080617121349.GA27077@mx.loc> On Tue, Jun 17, 2008 at 01:52:20PM +0200, Tito wrote: >HI, >Attached you can find a test.c file with both strrstr, mine and Denys', they show little >differences on "" vs. "" test case. >The test cases are improved and checked against the real strstr for consistency. I picked vda's since yours used the non-standard foo?:bar extension. Thanks! From alexander.griesser at lkh-vil.or.at Tue Jun 17 06:41:05 2008 From: alexander.griesser at lkh-vil.or.at (Alexander Griesser) Date: Tue, 17 Jun 2008 15:41:05 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <200806120923.53053.vda.linux@googlemail.com> References: <484D4560.6040507@lkh-vil.or.at> <200806120923.53053.vda.linux@googlemail.com> Message-ID: <4857BEF1.2080909@lkh-vil.or.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Denys Vlasenko wrote: |> I've attached this strace output. | | Hmmm. Does it help if you delete this code block? Can't test this at the moment, because I switched to the opensource ralink driver which works a treat. But when I get this machine back for maintenance, I'll give your suggestion a try and'll report back, of course. | Can you collect "tcpdump -nlieth0 -s0 -vvv -xX port 67 or port 68" output | for both? Yes, I'll do, might take some time. ciao, - -- Alexander Griesser (Netzwerkadministration) E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach Tel.: +43 4242 208 3061 | Fax.: +43 4242 971 3061 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhXvvEACgkQ66HVD6KUm1qUWgCfWW5VX+6SZia+XXGoe40sXPwh HzQAn0SHvoKpS9F1RypOGTyJBzRMsRFD =J/MX -----END PGP SIGNATURE----- From alexander.griesser at lkh-vil.or.at Tue Jun 17 06:45:14 2008 From: alexander.griesser at lkh-vil.or.at (Alexander Griesser) Date: Tue, 17 Jun 2008 15:45:14 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <200806170649.08088.vda.linux@googlemail.com> References: <20080616141650.419DF1C000AA@mwinf2703.orange.fr> <200806170649.08088.vda.linux@googlemail.com> Message-ID: <4857BFEA.6010909@lkh-vil.or.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Denys Vlasenko wrote: |> We tried the solution supplied in the topic linked below and it worked for |> us. | | I see nothing "linked below". Please let me know what exactly did you try, | I want to make this fix available to others. I think he meant "linked above" and was referring to your advise to comment out some codelines in clientsocket.c, so yes, it seems as if commenting out the port check fixes this issue. Would it make sense to create a config option for this check? ciao, - -- Alexander Griesser (Netzwerkadministration) E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach Tel.: +43 4242 208 3061 | Fax.: +43 4242 971 3061 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhXv+oACgkQ66HVD6KUm1o9iQCeOapElGpuMzhb7NgQ/R0AfGRp AtwAn1u10q10MNPslT6lpCpTUenBIXYq =kg3V -----END PGP SIGNATURE----- From vda.linux at googlemail.com Tue Jun 17 07:22:11 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 17 Jun 2008 16:22:11 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <4857BEF1.2080909@lkh-vil.or.at> References: <484D4560.6040507@lkh-vil.or.at> <200806120923.53053.vda.linux@googlemail.com> <4857BEF1.2080909@lkh-vil.or.at> Message-ID: <200806171622.11969.vda.linux@googlemail.com> On Tuesday 17 June 2008 15:41, Alexander Griesser wrote: > Denys Vlasenko wrote: > |> I've attached this strace output. > | > | Hmmm. Does it help if you delete this code block? > > Can't test this at the moment, because I switched to the opensource > ralink driver which works a treat. But when I get this machine back for Hmm. It works with one driver but doesn't with another? Are you sure? -- vda From vda.linux at googlemail.com Tue Jun 17 07:32:52 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 17 Jun 2008 16:32:52 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <4857BFEA.6010909@lkh-vil.or.at> References: <20080616141650.419DF1C000AA@mwinf2703.orange.fr> <200806170649.08088.vda.linux@googlemail.com> <4857BFEA.6010909@lkh-vil.or.at> Message-ID: <200806171632.52370.vda.linux@googlemail.com> On Tuesday 17 June 2008 15:45, Alexander Griesser wrote: > Denys Vlasenko wrote: > |> We tried the solution supplied in the topic linked below and it > worked for > |> us. > | > | I see nothing "linked below". Please let me know what exactly did you try, > | I want to make this fix available to others. > > I think he meant "linked above" and was referring to your advise to > comment out some codelines in clientsocket.c, so yes, it seems as if > commenting out the port check fixes this issue. > > Would it make sense to create a config option for this check? I'd rather disable it for now, but I want someone else to confirm it independently. -- vda From alexander.griesser at lkh-vil.or.at Tue Jun 17 07:33:45 2008 From: alexander.griesser at lkh-vil.or.at (Alexander Griesser) Date: Tue, 17 Jun 2008 16:33:45 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <200806171622.11969.vda.linux@googlemail.com> References: <484D4560.6040507@lkh-vil.or.at> <200806120923.53053.vda.linux@googlemail.com> <4857BEF1.2080909@lkh-vil.or.at> <200806171622.11969.vda.linux@googlemail.com> Message-ID: <4857CB49.5060903@lkh-vil.or.at> Denys Vlasenko wrote: |> Can't test this at the moment, because I switched to the opensource |> ralink driver which works a treat. But when I get this machine back for | | Hmm. It works with one driver but doesn't with another? | Are you sure? Yes, I'm 99,99% sure, at least it was reproducible at that rate. But as I said, I can do more testing when I get this hardware back at my desk in a few days hopefully. ciao, -- Alexander Griesser (Netzwerkadministration) E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach Tel.: +43 4242 208 3061 | Fax.: +43 4242 971 3061 From rep.dot.nop at gmail.com Tue Jun 17 08:49:31 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 17 Jun 2008 17:49:31 +0200 Subject: MODPROBE: modules.dep with bundled aliases In-Reply-To: <6784529b0806170833m775bc0b3y8d169b8d5c45b828@mail.gmail.com> References: <4856c157.1498600a.1f13.4a03@mx.google.com> <20080617074834.GD25428@mx.loc> <6784529b0806170833m775bc0b3y8d169b8d5c45b828@mail.gmail.com> Message-ID: <20080617154931.GH27792@mx.loc> On Tue, Jun 17, 2008 at 03:33:39PM +0000, Vladimir Dronnikov wrote: >I would go further, Bernhard. Look. I added bundling modules.symbols >to depmod. Modules.dep became beyond 100Kb in size. Parsing it every >time modprobe is invoked is a pain for system. Moreover, we have to >"encrypt" dependencies and aliases in one place (depmod) and then >"decrypt" them in the other (modprobe). >I suggest to invent some kind of binary representation of modules.dep >for BB. That way we could get rid of a lot of weird code both in >depmod and in modprobe, shrink them and make them much faster. The >rationale is that a user can edit /etc/modprobe.d/* for customization, >then run depmod to compile binary modules.dep. Since intrinsic >dependencies and aliases are hardly a subject to edit, this sounds >reasonable. I suggest to make in FEATUREd so that one can choose >modules.dep at configuration time. > >Would you rephrase the idea in better English and post to the list, Bernhard? Your english is perfectly fine, let's see what other people think about the idea. Yann, vda, ping? > >TIA, >-- >Vladimir > > >2008/6/17, Bernhard Fischer : >> On Mon, Jun 16, 2008 at 12:39:03PM -0700, dronnikov at gmail.com wrote: >>>Hello! >> >> hi >>> >>>IMHO it is a fruitful idea to keep all intrinsic module info in just one >>> file: modules.dep. >>>Attached patch frees 300 bytes if we employ this idea. >> >> Sounds promising. >> I think that p = skip_whitespace(p); is just fine, no? >> >>>Could you apply it so I could use vanilla svn version for my system nightly >>> build? >> >> Please send your patch to the list and CC Yann (the modprobe maintainer) >> so he can comment on it. >>> >>>TIA, >>> >>>-- >>>Vladimir >>> >>>P.S. TODO file states we still have no depmod in BB... >> >> Ah, thanks for the hint, i'll remove it in a minute. >> cheers, >> From dronnikov at gmail.com Tue Jun 17 10:24:29 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Tue, 17 Jun 2008 10:24:29 -0700 (PDT) Subject: =?utf-8?B?TU9EUFJPQkU6IG5leHQgZ2VuZXJhdGlvbg==?= Message-ID: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> 0. Intro depmod + modprobe is some kind of complicated codec. Though the syntax of modprobe.conf and friends is human-friendly most of module dependencies is intrinsic and are hardly a subject to be customized manually. du modules.* gives 150Kb on my reasonably small system and this amount of loosely defined textual data must be parsed at every modprobe invocation. I suggest to invent for BB a custom modules.dep format which bites all above issues. 1. Format of modules.dep (draft) Consider a module X which depends on Y and Z, has aliases X1 and X2 and must be loaded with options O1 and O2. We could write this definition down as follows: ------- X Y Z X1 X2 O1 O2 ------- If any of parts of definition is missed we use empty line for it. No more continuation lines, delimiters and so on! Just mmap() the whole file and count for well-known amount of EOLs for each module and use skip_whitespace(). I wish we had gzmmap() invented (or have we?) Extensions to such a format can be done trivially. 9. Miscellany depmod can be trivially (IMO) updated to generate new modules.dep Personally I think of depmod as of something redundant in terms of BB. modules.dep could be generated on-the-fly during the first call to modprobe if it is missed. To not interfere with "old-style" modutils "new" modules.dep should be named, say, modules.bb. Comments? -- Vladimir From farmatito at tiscali.it Tue Jun 17 12:38:38 2008 From: farmatito at tiscali.it (Tito) Date: Tue, 17 Jun 2008 21:38:38 +0200 Subject: [PATCH] fix last corner case in strrstr.c Message-ID: <200806172138.38600.farmatito@tiscali.it> Hi, current implementation fails to be coherent with real strstr() on the last test case: ./test 'baaabaaab' vs. 'aaa' : PASSED 'baaabaaaab' vs. 'aaa' : PASSED 'baaabaab' vs. 'aaa' : PASSED 'aaa' vs. 'aaa' : PASSED 'aaa' vs. 'a' : PASSED 'aaa' vs. 'bbb' : PASSED 'a' vs. 'aaa' : PASSED 'aaa' vs. '' : PASSED '' vs. 'aaa' : PASSED '' vs. '' : FAILED this patch fixes this with no size increase: ./test 'baaabaaab' vs. 'aaa' : PASSED 'baaabaaaab' vs. 'aaa' : PASSED 'baaabaab' vs. 'aaa' : PASSED 'aaa' vs. 'aaa' : PASSED 'aaa' vs. 'a' : PASSED 'aaa' vs. 'bbb' : PASSED 'a' vs. 'aaa' : PASSED 'aaa' vs. '' : PASSED '' vs. 'aaa' : PASSED '' vs. '' : PASSED ./scripts/bloat-o-meter busybox_old busybox_unstripped function old new delta ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes Function is changed to: char *strrstr(const char *haystack, const char *needle) { char *r = NULL; do { char *p = strstr(haystack, needle); if (p) r = p; } while (*haystack++); return r; } The contra is that it is probably a little more cpu intensive :) Please apply if you like it. Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: strrstr.patch Type: text/x-diff Size: 711 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080617/5f272f54/attachment.patch From natanael.copa at gmail.com Tue Jun 17 23:28:43 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed, 18 Jun 2008 08:28:43 +0200 Subject: MODPROBE: next generation In-Reply-To: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> References: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> Message-ID: <1213770523.22584.24.camel@nc.nor.wtbts.org> On Tue, 2008-06-17 at 10:24 -0700, dronnikov at gmail.com wrote: > I suggest to invent for BB a custom modules.dep format which bites all above issues. ... > Comments? Please no. My alpine linux distro is based on uclibc/busybox. If hte busybox utility is not good enough for user, then it is possible to install the "real" utility that just overrides the busybox version. This requires that they behave similar. Otherwise scripts and things tend to break. (so far its only the sendmail applet that causes problems so i had to turn it off) So, please, continue make busybox compatible with POSIX/GNU standards. -nc From KokHow.Teh at infineon.com Tue Jun 17 23:45:57 2008 From: KokHow.Teh at infineon.com (KokHow.Teh at infineon.com) Date: Wed, 18 Jun 2008 14:45:57 +0800 Subject: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_tundefined In-Reply-To: <20080617082030.GE25428@mx.loc> References: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> <48576BDC.4080307@bfs.de> <20080617082030.GE25428@mx.loc> Message-ID: <31E09F73562D7A4D82119D7F6C1729860444C0FB@sinse303.ap.infineon.com> Hi; I build against uClibc-0.9.28. Is there any specific uClibc version that is prerequisite to build the latest busybox-1.10.3 without that error (with cpu_set_t definition in some header files)? In the meantime, I turned off the feature after reading from the help text that it is not required in my embedded device with only maximum 4 CPUs. Regards, KH -----Original Message----- From: Bernhard Fischer [mailto:rep.dot.nop at gmail.com] Sent: Tuesday, June 17, 2008 4:21 PM To: walter harms Cc: Teh Kok How (IFAP DC COM WL SD); busybox at busybox.net Subject: Re: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_tundefined On Tue, Jun 17, 2008 at 09:46:36AM +0200, walter harms wrote: >cpumask_t is not defined in older kernels. cpumask_t is not used by taskset. cpu_set_t comes from libc and he very, very likely just uses an inappropriate libc. Oh, and note that unless you have more than (let's say) 64 CPUs in you box, the simple printing is enough. I admit that i forgot up to which NCPUs the simple printer works but it should be relatively obvious from the code. If somebody goes to look then we could record that hint in the helptext.. From rep.dot.nop at gmail.com Wed Jun 18 00:15:35 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 18 Jun 2008 09:15:35 +0200 Subject: Busybox-1.10.3: ENABLE_FEATURE_TASKSET_FANCY -> cpu_set_tundefined In-Reply-To: <31E09F73562D7A4D82119D7F6C1729860444C0FB@sinse303.ap.infineon.com> References: <31E09F73562D7A4D82119D7F6C1729860441824F@sinse303.ap.infineon.com> <48576BDC.4080307@bfs.de> <20080617082030.GE25428@mx.loc> <31E09F73562D7A4D82119D7F6C1729860444C0FB@sinse303.ap.infineon.com> Message-ID: <20080618071535.GB32192@mx.loc> On Wed, Jun 18, 2008 at 02:45:57PM +0800, KokHow.Teh at infineon.com wrote: >Hi; > I build against uClibc-0.9.28. Is there any specific uClibc >version that is prerequisite to build the latest busybox-1.10.3 without >that error (with cpu_set_t definition in some header files)? In the Please read all mails in this thread. From d.samuel at courantmultimedia.fr Wed Jun 18 00:56:21 2008 From: d.samuel at courantmultimedia.fr (SAMUEL Dinesh) Date: Wed, 18 Jun 2008 09:56:21 +0200 Subject: udhcpc in 1.10.3 doesn't like my WLAN card In-Reply-To: <200806171622.11969.vda.linux@googlemail.com> Message-ID: <20080618075421.AA0961C0008E@mwinf2713.orange.fr> Hello, Here are some informations about my test on dhcpc. Here is my configuration : * Busybox : 1.10.3 * Kernel : linux-2.6.19.2 * Target: PowerPC * Hardware :mpc405ep Here is the dump on the DHCP server without any modifications : 09:37:25.015286 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:00:26:01 (oui Unknown), length 548 09:37:26.019857 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, Reply, length 300 09:37:28.029020 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:00:26:01 (oui Unknown), length 548 09:37:28.032545 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, Reply, length 300 Here is the dump on the DHCP server by changing without any modifications : if (SERVER_PORT == 67 && CLIENT_PORT == 68) { /* Use only if standard ports are in use */ /* Ignoring error (kernel may lack support for this) */ if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, &filter_prog, sizeof(filter_prog)) >= 0) DEBUG("attached filter to raw socket fd %d", fd); } 09:36:12.339382 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:00:26:01 (oui Unknown), length 548 09:36:12.351751 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, Reply, length 300 09:36:12.362863 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:00:26:01 (oui Unknown), length 548 09:36:12.367958 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, Reply, length 300 Hope this will help you. -----Message d'origine----- De?: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net] De la part de Denys Vlasenko Envoy??: mardi 17 juin 2008 16:22 ??: Alexander Griesser Cc?: busybox at busybox.net Objet?: Re: udhcpc in 1.10.3 doesn't like my WLAN card On Tuesday 17 June 2008 15:41, Alexander Griesser wrote: > Denys Vlasenko wrote: > |> I've attached this strace output. > | > | Hmmm. Does it help if you delete this code block? > > Can't test this at the moment, because I switched to the opensource > ralink driver which works a treat. But when I get this machine back for Hmm. It works with one driver but doesn't with another? Are you sure? -- vda _______________________________________________ busybox mailing list busybox at busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox From rep.dot.nop at gmail.com Wed Jun 18 01:33:44 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 18 Jun 2008 10:33:44 +0200 Subject: [PATCH] fix last corner case in strrstr.c In-Reply-To: <200806172138.38600.farmatito@tiscali.it> References: <200806172138.38600.farmatito@tiscali.it> Message-ID: <20080618083344.GD32192@mx.loc> On Tue, Jun 17, 2008 at 09:38:38PM +0200, Tito wrote: >Hi, >current implementation fails to be coherent with real strstr() >on the last test case: >./test >'baaabaaab' vs. 'aaa' : PASSED >'baaabaaaab' vs. 'aaa' : PASSED >'baaabaab' vs. 'aaa' : PASSED >'aaa' vs. 'aaa' : PASSED >'aaa' vs. 'a' : PASSED >'aaa' vs. 'bbb' : PASSED >'a' vs. 'aaa' : PASSED >'aaa' vs. '' : PASSED >'' vs. 'aaa' : PASSED >'' vs. '' : FAILED > >this patch fixes this with no size increase: > > ./test >'baaabaaab' vs. 'aaa' : PASSED >'baaabaaaab' vs. 'aaa' : PASSED >'baaabaab' vs. 'aaa' : PASSED >'aaa' vs. 'aaa' : PASSED >'aaa' vs. 'a' : PASSED >'aaa' vs. 'bbb' : PASSED >'a' vs. 'aaa' : PASSED >'aaa' vs. '' : PASSED >'' vs. 'aaa' : PASSED >'' vs. '' : PASSED > >./scripts/bloat-o-meter busybox_old busybox_unstripped >function old new delta >------------------------------------------------------------------------------ >(add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes Thanks, applied. From cristian.ionescu-idbohrn at axis.com Wed Jun 18 01:48:17 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Wed, 18 Jun 2008 10:48:17 +0200 (CEST) Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <20080618075421.AA0961C0008E@mwinf2713.orange.fr> References: <20080618075421.AA0961C0008E@mwinf2713.orange.fr> Message-ID: <0806181035210.15834@somehost> Samuel, Could you please provide some info about your dhcp-server? Brand, version, OS, version , age, etc. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: > 09:36:12.339382 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 50:00:00:00:26:01 (oui Unknown), length 548 > 09:36:12.351751 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, > Reply, length 300 > 09:36:12.362863 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 50:00:00:00:26:01 (oui Unknown), length 548 > 09:36:12.367958 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, > Reply, length 300 > > Hope this will help you. No, not really. To give you an idea of what Denys meant with: On Thu, 12 Jun 2008, Denys Vlasenko wrote: > > Can you collect "tcpdump -nlieth0 -s0 -vvv -xX port 67 or port 68" > output for both? and what I meant with: On Mon, 16 Jun 2008, Cristian Ionescu-Idbohrn wrote: > > Acctualy: > > $ tcpdump -nlieth0 -s0 -w 'udp and port (67 or 68)' > > would be more interesting. Here is an example: # tcpdump -nnnlieth0 -s0 -vvv -xX 'udp and port (67 or 68)' tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:25:03.157828 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:40:8c:73:05:23, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 00:40:8c:73:05:23 Hostname Option 12, length 17: "axis-00408c730523" Vendor-Class Option 60, length 34: "AXIS,Video Server,241S,HEAD 080506" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c 5ef0 0101 0600 .....D.C.,^..... 0x0020: c71e bb6c 0000 0000 0000 0000 0000 0000 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d ........c.Sc5..= 0x0110: 0701 0040 8c73 0523 0c11 6178 6973 2d30 ... at .s.#..axis-0 0x0120: 3034 3038 6337 3330 3532 333c 2241 5849 0408c730523<"AXI 0x0130: 532c 5669 6465 6f20 5365 7276 6572 2c32 S,Video.Server,2 0x0140: 3431 532c 4845 4144 2030 3830 3530 3639 41S,HEAD.0805069 0x0150: 0202 4037 0701 0306 0c0f 1c2a ff00 0000 .. at 7.......*.... 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 10:25:03.167046 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 192.168.222.42.67 > 192.168.222.200.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Your-IP 192.168.222.200 Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.222.42 Lease-Time Option 51, length 4: 29010 Subnet-Mask Option 1, length 4: 255.255.255.0 Domain-Name-Server Option 6, length 4: 192.168.222.44 Domain-Name Option 15, length 11: "se.axis.com" BR Option 28, length 4: 192.168.222.255 NTP Option 42, length 16: 192.168.222.123,192.168.222.44,192.168.222.42,192.168.222.40 0x0000: 4500 0240 0000 0000 4011 3a69 c0a8 de2a E.. at ....@.:i...* 0x0010: c0a8 dec8 0043 0044 022c cc26 0201 0600 .....C.D.,.&.... 0x0020: c71e bb6c 0000 0000 0000 0000 c0a8 dec8 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0236 ........c.Sc5..6 0x0110: 04c0 a8de 2a33 0400 0071 5201 04ff ffff ....*3...qR..... 0x0120: 0006 04c0 a8de 2c0f 0b73 652e 6178 6973 ......,..se.axis 0x0130: 2e63 6f6d 1c04 c0a8 deff 2a10 c0a8 de7b .com......*....{ 0x0140: c0a8 de2c c0a8 de2a c0a8 de28 ff00 0000 ...,...*...(.... 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 10:25:03.247768 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:40:8c:73:05:23, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 00:40:8c:73:05:23 Hostname Option 12, length 17: "axis-00408c730523" Vendor-Class Option 60, length 34: "AXIS,Video Server,241S,HEAD 080506" Requested-IP Option 50, length 4: 192.168.222.200 Server-ID Option 54, length 4: 192.168.222.42 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c 5185 0101 0600 .....D.C.,Q..... 0x0020: c71e bb6c 0000 0000 0000 0000 0000 0000 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 033d ........c.Sc5..= 0x0110: 0701 0040 8c73 0523 0c11 6178 6973 2d30 ... at .s.#..axis-0 0x0120: 3034 3038 6337 3330 3532 333c 2241 5849 0408c730523<"AXI 0x0130: 532c 5669 6465 6f20 5365 7276 6572 2c32 S,Video.Server,2 0x0140: 3431 532c 4845 4144 2030 3830 3530 3632 41S,HEAD.0805062 0x0150: 04c0 a8de c836 04c0 a8de 2a37 0701 0306 .....6....*7.... 0x0160: 0c0f 1c2a ff00 0000 0000 0000 0000 0000 ...*............ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 10:25:03.259039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 192.168.222.42.67 > 192.168.222.200.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Your-IP 192.168.222.200 Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 192.168.222.42 Lease-Time Option 51, length 4: 43200 Subnet-Mask Option 1, length 4: 255.255.255.0 Domain-Name-Server Option 6, length 4: 192.168.222.44 Domain-Name Option 15, length 11: "se.axis.com" BR Option 28, length 4: 192.168.222.255 NTP Option 42, length 16: 192.168.222.123,192.168.222.44,192.168.222.42,192.168.222.40 0x0000: 4500 0240 0000 0000 4011 3a69 c0a8 de2a E.. at ....@.:i...* 0x0010: c0a8 dec8 0043 0044 022c 5aef 0201 0600 .....C.D.,Z..... 0x0020: c71e bb6c 0000 0000 0000 0000 c0a8 dec8 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0536 ........c.Sc5..6 0x0110: 04c0 a8de 2a33 0400 00a8 c001 04ff ffff ....*3.......... 0x0120: 0006 04c0 a8de 2c0f 0b73 652e 6178 6973 ......,..se.axis 0x0130: 2e63 6f6d 1c04 c0a8 deff 2a10 c0a8 de7b .com......*....{ 0x0140: c0a8 de2c c0a8 de2a c0a8 de28 ff00 0000 ...,...*...(.... 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Can you produce something similar? Cheers, -- Cristian From GeorgeB at Linux.ca Wed Jun 18 06:15:10 2008 From: GeorgeB at Linux.ca (George Boudreau) Date: Wed, 18 Jun 2008 09:15:10 -0400 Subject: snapshot-20080618 'ls' inverted return status Message-ID: Hi, While building busybox-20080618, with defconfig, I stumbled upon a problem with 'ls'. ./busybox ls; echo $? 1 ./busybox ls qwert; echo $? 0 Looks like the status logic is inverted. if (ENABLE_FEATURE_CLEAN_UP) dfree(dnp, nfiles); return (exit_failure == 0); should be return (exit_failure == 1); or return (exit_failure); regards George From wharms at bfs.de Wed Jun 18 06:50:08 2008 From: wharms at bfs.de (walter harms) Date: Wed, 18 Jun 2008 15:50:08 +0200 Subject: snapshot-20080618 'ls' inverted return status In-Reply-To: References: Message-ID: <48591290.1020003@bfs.de> George Boudreau wrote: > Hi, > While building busybox-20080618, with defconfig, I stumbled upon a > problem with 'ls'. > > ./busybox ls; echo $? > 1 > ./busybox ls qwert; echo $? > 0 > > Looks like the status logic is inverted. > > if (ENABLE_FEATURE_CLEAN_UP) > dfree(dnp, nfiles); > return (exit_failure == 0); > > should be > > return (exit_failure == 1); > or > return (exit_failure); > > may i misst something, EXIT_FAILURE should come in uppcase. return(EXIT_FAILURE); re, wh From dnlombar at ichips.intel.com Wed Jun 18 07:23:07 2008 From: dnlombar at ichips.intel.com (Lombard, David N) Date: Wed, 18 Jun 2008 07:23:07 -0700 Subject: snapshot-20080618 'ls' inverted return status In-Reply-To: <48591290.1020003@bfs.de> References: <48591290.1020003@bfs.de> Message-ID: <20080618142307.GA2979@nlxdcldnl2.cl.intel.com> On Wed, Jun 18, 2008 at 03:50:08PM +0200, walter harms wrote: > George Boudreau wrote: > > Hi, > > While building busybox-20080618, with defconfig, I stumbled upon a > > problem with 'ls'. > > > > ./busybox ls; echo $? > > 1 > > ./busybox ls qwert; echo $? > > 0 > > > > Looks like the status logic is inverted. > > > > if (ENABLE_FEATURE_CLEAN_UP) > > dfree(dnp, nfiles); > > return (exit_failure == 0); > > > > should be > > > > return (exit_failure == 1); > > or > > return (exit_failure); > > > > > > may i misst something, EXIT_FAILURE should come in uppcase. > > return(EXIT_FAILURE); Hang on. EXIT_FAILURE and EXIT_SUCCESS are standard exit return code macros indicating failure or success respectively. In the code above, exit_failure is a variable. And yes, looking at the code, this is correct: return (exit_failure); -- David N. Lombard, Intel, Irvine, CA I do not speak for Intel Corporation; all comments are strictly my own. From d.samuel at courantmultimedia.fr Wed Jun 18 05:40:26 2008 From: d.samuel at courantmultimedia.fr (SAMUEL Dinesh) Date: Wed, 18 Jun 2008 14:40:26 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <0806181035210.15834@somehost> Message-ID: <20080618123826.A21701C00042@mwinf2709.orange.fr> Hello, Please find bellow tcpdump captures. ========================================================================== ================== Not working DHCPD ==================================== ========================================================================== # tcpdump -nnnlieth1 -s0 -vvv -xX 'udp and port (67 or 68)' tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: "udhcp 1.10.3" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c bc26 0101 0600 .....D.C.,.&.... 0x0020: 51d5 37f3 0000 0000 0000 0000 0000 0000 Q.7............. 0x0030: 0000 0000 0000 0000 5000 0000 2600 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d ........c.Sc5..= 0x0110: 0701 5000 0000 2600 3c0c 7564 6863 7020 ..P...&.<.udhcp. 0x0120: 312e 3130 2e33 3902 0240 3707 0103 060c 1.10.39.. at 7..... 0x0130: 0f1c 2aff 0000 0000 0000 0000 0000 0000 ..*............. 0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x0000) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 0x0000: 4510 0148 0000 0000 4011 e720 c0a8 08fe E..H.... at ....... 0x0010: c0a8 0826 0043 0044 0134 10ff 0201 0600 ...&.C.D.4...... 0x0020: 51d5 37f3 0000 0000 0000 0000 c0a8 0826 Q.7............& 0x0030: c0a8 08fe 0000 0000 5000 0000 2600 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0236 ........c.Sc5..6 0x0110: 04c0 a808 fe33 0400 0151 8001 04ff ffff .....3...Q...... 0x0120: 0003 04c0 a808 fe06 08c0 a808 3250 0af6 ............2P.. 0x0130: 02ff 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 ........ 14:20:30.642218 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: "udhcp 1.10.3" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c bc26 0101 0600 .....D.C.,.&.... 0x0020: 51d5 37f3 0000 0000 0000 0000 0000 0000 Q.7............. 0x0030: 0000 0000 0000 0000 5000 0000 2600 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d ........c.Sc5..= 0x0110: 0701 5000 0000 2600 3c0c 7564 6863 7020 ..P...&.<.udhcp. 0x0120: 312e 3130 2e33 3902 0240 3707 0103 060c 1.10.39.. at 7..... 0x0130: 0f1c 2aff 0000 0000 0000 0000 0000 0000 ..*............. 0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 14:20:30.646431 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x0000) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 0x0000: 4510 0148 0000 0000 4011 e720 c0a8 08fe E..H.... at ....... 0x0010: c0a8 0826 0043 0044 0134 10ff 0201 0600 ...&.C.D.4...... 0x0020: 51d5 37f3 0000 0000 0000 0000 c0a8 0826 Q.7............& 0x0030: c0a8 08fe 0000 0000 5000 0000 2600 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0236 ........c.Sc5..6 0x0110: 04c0 a808 fe33 0400 0151 8001 04ff ffff .....3...Q...... 0x0120: 0003 04c0 a808 fe06 08c0 a808 3250 0af6 ............2P.. 0x0130: 02ff 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 ........ 14:20:33.655931 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: "udhcp 1.10.3" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c bc26 0101 0600 .....D.C.,.&.... 0x0020: 51d5 37f3 0000 0000 0000 0000 0000 0000 Q.7............. 0x0030: 0000 0000 0000 0000 5000 0000 2600 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d ........c.Sc5..= 0x0110: 0701 5000 0000 2600 3c0c 7564 6863 7020 ..P...&.<.udhcp. 0x0120: 312e 3130 2e33 3902 0240 3707 0103 060c 1.10.39.. at 7..... 0x0130: 0f1c 2aff 0000 0000 0000 0000 0000 0000 ..*............. 0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 14:20:33.659968 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x0000) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 0x0000: 4510 0148 0000 0000 4011 e720 c0a8 08fe E..H.... at ....... 0x0010: c0a8 0826 0043 0044 0134 10ff 0201 0600 ...&.C.D.4...... 0x0020: 51d5 37f3 0000 0000 0000 0000 c0a8 0826 Q.7............& 0x0030: c0a8 08fe 0000 0000 5000 0000 2600 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0236 ........c.Sc5..6 0x0110: 04c0 a808 fe33 0400 0151 8001 04ff ffff .....3...Q...... 0x0120: 0003 04c0 a808 fe06 08c0 a808 3250 0af6 ............2P.. 0x0130: 02ff 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 ........ ========================================================================== ================== working DHCPD ==================================== ========================================================================== # tcpdump -nnnlieth1 -s0 -vvv -xX 'udp and port (67 or 68)' tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:17:41.196467 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:01, length 548, xid 0x321efde8, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:01 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:01 Vendor-Class Option 60, length 12: "udhcp 1.10.3" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c 15e6 0101 0600 .....D.C.,...... 0x0020: 321e fde8 0000 0000 0000 0000 0000 0000 2............... 0x0030: 0000 0000 0000 0000 5000 0000 2601 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d ........c.Sc5..= 0x0110: 0701 5000 0000 2601 3c0c 7564 6863 7020 ..P...&.<.udhcp. 0x0120: 312e 3130 2e33 3902 0240 3707 0103 060c 1.10.39.. at 7..... 0x0130: 0f1c 2aff 0000 0000 0000 0000 0000 0000 ..*............. 0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 14:17:42.238549 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.39.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x321efde8, Flags [ none ] (0x0000) Your-IP 192.168.8.39 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:01 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 0x0000: 4510 0148 0000 0000 4011 e71f c0a8 08fe E..H.... at ....... 0x0010: c0a8 0827 0043 0044 0134 6abd 0201 0600 ...'.C.D.4j..... 0x0020: 321e fde8 0000 0000 0000 0000 c0a8 0827 2..............' 0x0030: c0a8 08fe 0000 0000 5000 0000 2601 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0236 ........c.Sc5..6 0x0110: 04c0 a808 fe33 0400 0151 8001 04ff ffff .....3...Q...... 0x0120: 0003 04c0 a808 fe06 08c0 a808 3250 0af6 ............2P.. 0x0130: 02ff 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 ........ 14:17:42.248379 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:01, length 548, xid 0x321efde8, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:01 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 50:00:00:00:26:01 Vendor-Class Option 60, length 12: "udhcp 1.10.3" Requested-IP Option 50, length 4: 192.168.8.39 Server-ID Option 54, length 4: 192.168.8.254 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c 54a9 0101 0600 .....D.C.,T..... 0x0020: 321e fde8 0000 0000 0000 0000 0000 0000 2............... 0x0030: 0000 0000 0000 0000 5000 0000 2601 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 033d ........c.Sc5..= 0x0110: 0701 5000 0000 2601 3c0c 7564 6863 7020 ..P...&.<.udhcp. 0x0120: 312e 3130 2e33 3204 c0a8 0827 3604 c0a8 1.10.32....'6... 0x0130: 08fe 3707 0103 060c 0f1c 2aff 0000 0000 ..7.......*..... 0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 14:17:42.258325 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.39.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x321efde8, Flags [ none ] (0x0000) Your-IP 192.168.8.39 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:01 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 0x0000: 4510 0148 0000 0000 4011 e71f c0a8 08fe E..H.... at ....... 0x0010: c0a8 0827 0043 0044 0134 67bd 0201 0600 ...'.C.D.4g..... 0x0020: 321e fde8 0000 0000 0000 0000 c0a8 0827 2..............' 0x0030: c0a8 08fe 0000 0000 5000 0000 2601 0000 ........P...&... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0536 ........c.Sc5..6 0x0110: 04c0 a808 fe33 0400 0151 8001 04ff ffff .....3...Q...... 0x0120: 0003 04c0 a808 fe06 08c0 a808 3250 0af6 ............2P.. 0x0130: 02ff 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 ........ ========================================================================== ========================================================================== My DHCPD server is: * Running under Linux Debian * version : Dhcp 2.0pl5-19.1 Bye. -----Message d'origine----- De?: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net] De la part de Cristian Ionescu-Idbohrn Envoy??: mercredi 18 juin 2008 10:48 ??: busybox at busybox.net Objet?: Re: udhcpc in 1.10.3 doesnt like my WLAN card Samuel, Could you please provide some info about your dhcp-server? Brand, version, OS, version , age, etc. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: > 09:36:12.339382 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 50:00:00:00:26:01 (oui Unknown), length 548 > 09:36:12.351751 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, > Reply, length 300 > 09:36:12.362863 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 50:00:00:00:26:01 (oui Unknown), length 548 > 09:36:12.367958 IP 192.168.8.254.bootps > 192.168.8.39.bootpc: BOOTP/DHCP, > Reply, length 300 > > Hope this will help you. No, not really. To give you an idea of what Denys meant with: On Thu, 12 Jun 2008, Denys Vlasenko wrote: > > Can you collect "tcpdump -nlieth0 -s0 -vvv -xX port 67 or port 68" > output for both? and what I meant with: On Mon, 16 Jun 2008, Cristian Ionescu-Idbohrn wrote: > > Acctualy: > > $ tcpdump -nlieth0 -s0 -w 'udp and port (67 or 68)' > > would be more interesting. Here is an example: # tcpdump -nnnlieth0 -s0 -vvv -xX 'udp and port (67 or 68)' tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:25:03.157828 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:40:8c:73:05:23, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 00:40:8c:73:05:23 Hostname Option 12, length 17: "axis-00408c730523" Vendor-Class Option 60, length 34: "AXIS,Video Server,241S,HEAD 080506" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c 5ef0 0101 0600 .....D.C.,^..... 0x0020: c71e bb6c 0000 0000 0000 0000 0000 0000 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 013d ........c.Sc5..= 0x0110: 0701 0040 8c73 0523 0c11 6178 6973 2d30 ... at .s.#..axis-0 0x0120: 3034 3038 6337 3330 3532 333c 2241 5849 0408c730523<"AXI 0x0130: 532c 5669 6465 6f20 5365 7276 6572 2c32 S,Video.Server,2 0x0140: 3431 532c 4845 4144 2030 3830 3530 3639 41S,HEAD.0805069 0x0150: 0202 4037 0701 0306 0c0f 1c2a ff00 0000 .. at 7.......*.... 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 10:25:03.167046 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 192.168.222.42.67 > 192.168.222.200.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Your-IP 192.168.222.200 Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.222.42 Lease-Time Option 51, length 4: 29010 Subnet-Mask Option 1, length 4: 255.255.255.0 Domain-Name-Server Option 6, length 4: 192.168.222.44 Domain-Name Option 15, length 11: "se.axis.com" BR Option 28, length 4: 192.168.222.255 NTP Option 42, length 16: 192.168.222.123,192.168.222.44,192.168.222.42,192.168.222.40 0x0000: 4500 0240 0000 0000 4011 3a69 c0a8 de2a E.. at ....@.:i...* 0x0010: c0a8 dec8 0043 0044 022c cc26 0201 0600 .....C.D.,.&.... 0x0020: c71e bb6c 0000 0000 0000 0000 c0a8 dec8 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0236 ........c.Sc5..6 0x0110: 04c0 a8de 2a33 0400 0071 5201 04ff ffff ....*3...qR..... 0x0120: 0006 04c0 a8de 2c0f 0b73 652e 6178 6973 ......,..se.axis 0x0130: 2e63 6f6d 1c04 c0a8 deff 2a10 c0a8 de7b .com......*....{ 0x0140: c0a8 de2c c0a8 de2a c0a8 de28 ff00 0000 ...,...*...(.... 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 10:25:03.247768 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:40:8c:73:05:23, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 00:40:8c:73:05:23 Hostname Option 12, length 17: "axis-00408c730523" Vendor-Class Option 60, length 34: "AXIS,Video Server,241S,HEAD 080506" Requested-IP Option 50, length 4: 192.168.222.200 Server-ID Option 54, length 4: 192.168.222.42 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x0000: 4500 0240 0000 0000 4011 78ae 0000 0000 E.. at ....@.x..... 0x0010: ffff ffff 0044 0043 022c 5185 0101 0600 .....D.C.,Q..... 0x0020: c71e bb6c 0000 0000 0000 0000 0000 0000 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 033d ........c.Sc5..= 0x0110: 0701 0040 8c73 0523 0c11 6178 6973 2d30 ... at .s.#..axis-0 0x0120: 3034 3038 6337 3330 3532 333c 2241 5849 0408c730523<"AXI 0x0130: 532c 5669 6465 6f20 5365 7276 6572 2c32 S,Video.Server,2 0x0140: 3431 532c 4845 4144 2030 3830 3530 3632 41S,HEAD.0805062 0x0150: 04c0 a8de c836 04c0 a8de 2a37 0701 0306 .....6....*7.... 0x0160: 0c0f 1c2a ff00 0000 0000 0000 0000 0000 ...*............ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 10:25:03.259039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 192.168.222.42.67 > 192.168.222.200.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xc71ebb6c, Flags [ none ] (0x0000) Your-IP 192.168.222.200 Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 192.168.222.42 Lease-Time Option 51, length 4: 43200 Subnet-Mask Option 1, length 4: 255.255.255.0 Domain-Name-Server Option 6, length 4: 192.168.222.44 Domain-Name Option 15, length 11: "se.axis.com" BR Option 28, length 4: 192.168.222.255 NTP Option 42, length 16: 192.168.222.123,192.168.222.44,192.168.222.42,192.168.222.40 0x0000: 4500 0240 0000 0000 4011 3a69 c0a8 de2a E.. at ....@.:i...* 0x0010: c0a8 dec8 0043 0044 022c 5aef 0201 0600 .....C.D.,Z..... 0x0020: c71e bb6c 0000 0000 0000 0000 c0a8 dec8 ...l............ 0x0030: 0000 0000 0000 0000 0040 8c73 0523 0000 ......... at .s.#.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0536 ........c.Sc5..6 0x0110: 04c0 a8de 2a33 0400 00a8 c001 04ff ffff ....*3.......... 0x0120: 0006 04c0 a8de 2c0f 0b73 652e 6178 6973 ......,..se.axis 0x0130: 2e63 6f6d 1c04 c0a8 deff 2a10 c0a8 de7b .com......*....{ 0x0140: c0a8 de2c c0a8 de2a c0a8 de28 ff00 0000 ...,...*...(.... 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Can you produce something similar? Cheers, -- Cristian _______________________________________________ busybox mailing list busybox at busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox From vda.linux at googlemail.com Wed Jun 18 09:38:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 18 Jun 2008 18:38:50 +0200 Subject: snapshot-20080618 'ls' inverted return status In-Reply-To: References: Message-ID: <200806181838.50371.vda.linux@googlemail.com> On Wednesday 18 June 2008 15:15, George Boudreau wrote: > Hi, > While building busybox-20080618, with defconfig, I stumbled upon a > problem with 'ls'. > > ./busybox ls; echo $? > 1 > ./busybox ls qwert; echo $? > 0 > > Looks like the status logic is inverted. > > if (ENABLE_FEATURE_CLEAN_UP) > dfree(dnp, nfiles); > return (exit_failure == 0); > > should be > > return (exit_failure == 1); > or > return (exit_failure); Thanks for catching this. I renamed the variable to exit_code now, and fixed the logic. -- vda From rep.dot.nop at gmail.com Wed Jun 18 11:01:49 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 18 Jun 2008 20:01:49 +0200 Subject: snapshot-20080618 'ls' inverted return status In-Reply-To: <200806181838.50371.vda.linux@googlemail.com> References: <200806181838.50371.vda.linux@googlemail.com> Message-ID: <20080618180149.GQ10734@mx.loc> On Wed, Jun 18, 2008 at 06:38:50PM +0200, Denys Vlasenko wrote: >On Wednesday 18 June 2008 15:15, George Boudreau wrote: >> Hi, >> While building busybox-20080618, with defconfig, I stumbled upon a >> problem with 'ls'. >> >> ./busybox ls; echo $? >> 1 >> ./busybox ls qwert; echo $? >> 0 >> >> Looks like the status logic is inverted. >> >> if (ENABLE_FEATURE_CLEAN_UP) >> dfree(dnp, nfiles); >> return (exit_failure == 0); >> >> should be >> >> return (exit_failure == 1); >> or >> return (exit_failure); > >Thanks for catching this. >I renamed the variable to exit_code now, and fixed the logic. George, mind to provide (some?) testsuite checks for these exit-codes? From vda.linux at googlemail.com Wed Jun 18 12:52:37 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 18 Jun 2008 21:52:37 +0200 Subject: [PATCH] fix last corner case in strrstr.c In-Reply-To: <200806172138.38600.farmatito@tiscali.it> References: <200806172138.38600.farmatito@tiscali.it> Message-ID: <200806182152.37271.vda.linux@googlemail.com> On Tuesday 17 June 2008 21:38, Tito wrote: > this patch fixes this with no size increase: > > ./test > 'baaabaaab' vs. 'aaa' : PASSED > 'baaabaaaab' vs. 'aaa' : PASSED > 'baaabaab' vs. 'aaa' : PASSED > 'aaa' vs. 'aaa' : PASSED > 'aaa' vs. 'a' : PASSED > 'aaa' vs. 'bbb' : PASSED > 'a' vs. 'aaa' : PASSED > 'aaa' vs. '' : PASSED > '' vs. 'aaa' : PASSED > '' vs. '' : PASSED > > ./scripts/bloat-o-meter busybox_old busybox_unstripped > function old new delta > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes > > Function is changed to: > > char *strrstr(const char *haystack, const char *needle) > { > char *r = NULL; > > do { > char *p = strstr(haystack, needle); > if (p) > r = p; > } while (*haystack++); > return r; > } > > The contra is that it is probably a little more cpu intensive :) I'm sorry but cubic running time is a bit extreme to my tastes. Especially that quadratic time version is just 2 bytes bigger. -- vda From cristian.ionescu-idbohrn at axis.com Thu Jun 19 05:43:18 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 19 Jun 2008 14:43:18 +0200 (CEST) Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <20080618123826.A21701C00042@mwinf2709.orange.fr> References: <20080618123826.A21701C00042@mwinf2709.orange.fr> Message-ID: <0806191256020.15834@somehost> The problem seems to be that your wlan-card does not see/catch the dhcp-offer. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: > My DHCPD server is: > * Running under Linux Debian > * version : Dhcp 2.0pl5-19.1 Is this a Debian sarge (oldstable) or woody (even older) distribution? I do no longer have access to anything like that. Did you check the "non-working" version with another dhcp-server? What arch are you using? I see no such problems when using Debian etch dhcp3-server 3.0.4-13, some misterious m$ dhcp server, dnsmasq various versions, udhcpd 0.9.8cvs20050303-2. Is the mac address 50:00:00:00:26:00 the real thing or just an obfuscation? Maybe that BPF filter should be made into an option. Cheers, -- Cristian From wharms at bfs.de Thu Jun 19 06:49:03 2008 From: wharms at bfs.de (walter harms) Date: Thu, 19 Jun 2008 15:49:03 +0200 Subject: vi.c coredump Message-ID: <485A63CF.2000501@bfs.de> hi list, i can produce a nasty bug in vi. I noticed it first with 10.3 but it seems to be present in earlier versions. I can produce the bug this way: start vi goto insert mode select a screenfull of data with Xcursor clip data into vi Your mileage may vary; picking only a few data will cause no harm. btw: it is very unlikely that the problem is related to the compiler since it happens on my desktop and in the embedded (non x86) system. The following crash is with snapshot busybox-2008-03-04 Program received signal SIGSEGV, Segmentation fault. 0x08052895 in prev_line (p=0x0) at vi.c:1308 1308 if (p[-1] == '\n' && p > text) re, wh ps: the .config is attached pps: i have reported the bug early because i guess that the c&p approach may be used by more people. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _config Url: http://busybox.net/lists/busybox/attachments/20080619/58673bba/attachment-0001.txt From wharms at bfs.de Thu Jun 19 07:36:22 2008 From: wharms at bfs.de (walter harms) Date: Thu, 19 Jun 2008 16:36:22 +0200 Subject: vi.c coredump In-Reply-To: <485A63CF.2000501@bfs.de> References: <485A63CF.2000501@bfs.de> Message-ID: <485A6EE6.4010701@bfs.de> Hi list, some news about the bug: It is present at least in 1.9.1 maybe earlier It happens in insert_char when ENABLE_FEATURE_VI_SETOPTS is set p = stupid_insert(p, c); // insert the char #if ENABLE_FEATURE_VI_SETOPTS if (showmatch && strchr(")]}", *sp) != NULL) { showmatching(sp); } if (autoindent && c == '\n') { // auto indent the new line char *q; this code here assumes that is valid BUT /* please ignore the testcode */ if (p!=NULL) { q = prev_line(p); // use prev line as templet for (; isblank(*q); q++) { p = stupid_insert(p, *q); // insert the char } } else { printf("eeek\n"); } this is not true. stupid_insert() can return NULL (see:text_hole_make() error path) the crash can be prevented with "if (autoindent && c == '\n' && !p )" but i have no clue what side effects that may have. Other occurrences of stupid_insert() should be visited also. re, wh ps: i am sorry i forget to add the backtrace last mail walter harms wrote: > hi list, > i can produce a nasty bug in vi. > I noticed it first with 10.3 but it seems to be present in earlier versions. > > I can produce the bug this way: > start vi > goto insert mode > select a screenfull of data with Xcursor > clip data into vi > > Your mileage may vary; picking only a few data will cause no harm. > > btw: it is very unlikely that the problem is related to the compiler > since it happens on my desktop and in the embedded (non x86) system. > > The following crash is with snapshot busybox-2008-03-04 > > Program received signal SIGSEGV, Segmentation fault. > 0x08052895 in prev_line (p=0x0) at vi.c:1308 > 1308 if (p[-1] == '\n' && p > text) > > > re, > wh > > ps: the .config is attached > > pps: i have reported the bug early because i guess that the c&p approach may be used > by more people. > > > ------------------------------------------------------------------------ > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From dronnikov at gmail.com Thu Jun 19 09:15:26 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Thu, 19 Jun 2008 16:15:26 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_MODPROBE:_next_generation?= In-Reply-To: <1213770523.22584.24.camel@nc.nor.wtbts.org> References: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> <1213770523.22584.24.camel@nc.nor.wtbts.org> Message-ID: <6784529b0806190915t66bf8e20j1b7f133856782c0b@mail.gmail.com> Hello! 1. Noone wants to bury existing modprobe. I mean a new format for intermediate data for an utility which will provide the same functionality but is planned to be smaller, faster and cleaner. Have you ever edited modules.dep or modules.symbols files manually? Guess no. And they are the vast majority of (potentially invariant) data which we have to parse expensively on every module operation. Why not to try to advance? Or, as they say, "don't touch a sewing tube unless it leaks"?! 2. BB depmod right now generates (having FEATURE_ALIAS defined, my case) modules.dep which can not be parsed correctly with BB modprobe. This is modprobe's issue. Since modprobe's maintaner is now offline the updates are blocked. How people who shifted from production to BB modutils (my case again) are supposed to cope this lockout? 3. What's wrong with BB sendmail? Please do request for feature if it does not fit your needs. Regards, -- Vladimir 2008/6/18, Natanael Copa : > On Tue, 2008-06-17 at 10:24 -0700, dronnikov at gmail.com wrote: > >> I suggest to invent for BB a custom modules.dep format which bites all >> above issues. > > ... > >> Comments? > > Please no. > > My alpine linux distro is based on uclibc/busybox. If hte busybox > utility is not good enough for user, then it is possible to install the > "real" utility that just overrides the busybox version. > > This requires that they behave similar. Otherwise scripts and things > tend to break. (so far its only the sendmail applet that causes problems > so i had to turn it off) > > So, please, continue make busybox compatible with POSIX/GNU standards. > > -nc > > > > From wharms at bfs.de Thu Jun 19 09:53:38 2008 From: wharms at bfs.de (walter harms) Date: Thu, 19 Jun 2008 18:53:38 +0200 Subject: vi.c coredump In-Reply-To: <485A6EE6.4010701@bfs.de> References: <485A63CF.2000501@bfs.de> <485A6EE6.4010701@bfs.de> Message-ID: <485A8F12.7090502@bfs.de> I looked into the other place where stupid_insert() and it guess they will break also. re wh walter harms wrote: > Hi list, > some news about the bug: It is present at least in 1.9.1 maybe earlier > > It happens in insert_char when ENABLE_FEATURE_VI_SETOPTS is set > > p = stupid_insert(p, c); // insert the char > #if ENABLE_FEATURE_VI_SETOPTS > if (showmatch && strchr(")]}", *sp) != NULL) { > showmatching(sp); > } > if (autoindent && c == '\n') { // auto indent the new line > char *q; > > this code here assumes that is valid BUT /* please ignore the testcode */ ups something missing: "that p is valid" (read != NULL ) > > if (p!=NULL) { > q = prev_line(p); // use prev line as templet > for (; isblank(*q); q++) { > p = stupid_insert(p, *q); // insert the char > } > } else { > printf("eeek\n"); > } > > this is not true. stupid_insert() can return NULL (see:text_hole_make() error path) > > the crash can be prevented with "if (autoindent && c == '\n' && !p )" but i have no clue > what side effects that may have. Other occurrences of stupid_insert() should be visited also. > > re, > wh > > ps: i am sorry i forget to add the backtrace last mail > > > walter harms wrote: >> hi list, >> i can produce a nasty bug in vi. >> I noticed it first with 10.3 but it seems to be present in earlier versions. >> >> I can produce the bug this way: >> start vi >> goto insert mode >> select a screenfull of data with Xcursor >> clip data into vi >> >> Your mileage may vary; picking only a few data will cause no harm. >> >> btw: it is very unlikely that the problem is related to the compiler >> since it happens on my desktop and in the embedded (non x86) system. >> >> The following crash is with snapshot busybox-2008-03-04 >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x08052895 in prev_line (p=0x0) at vi.c:1308 >> 1308 if (p[-1] == '\n' && p > text) >> >> >> re, >> wh >> >> ps: the .config is attached >> >> pps: i have reported the bug early because i guess that the c&p approach may be used >> by more people. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> busybox mailing list >> busybox at busybox.net >> http://busybox.net/cgi-bin/mailman/listinfo/busybox > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > From dronnikov at gmail.com Thu Jun 19 10:50:32 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Thu, 19 Jun 2008 10:50:32 -0700 (PDT) Subject: =?utf-8?B?TU9EUFJPQkU6IG5leHQgZ2VuZXJhdGlvbg==?= Message-ID: <485a9c68.1c5c4e0a.3c6e.2949@mx.google.com> Made a proof-of-concept patch. It replaces standard depmod+modprobe sweet pair if config option "simplified modutils" is checked. 1482 octets in size for both (debug statements commented out). Uses the following format of modules.dep (draft 2) Consider a module named X located at P which depends on Y and Z, has aliases X1 and X2 and must be loaded with options O1 and O2. We could write this definition down as follows: ------- X X1 X2 Y Z P O1 O2 ------- If any of parts of definition is missed we simply use empty line as placeholder. modprobe by the moment can only load modules and runs in verbose mode to help debugging. Please, do find time to try and test! TIA, -- Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: modprobe.patch Type: application/octet-stream Size: 9896 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080619/6b5e59d5/attachment-0001.obj From vda.linux at googlemail.com Thu Jun 19 11:58:19 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 19 Jun 2008 20:58:19 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <0806191256020.15834@somehost> References: <20080618123826.A21701C00042@mwinf2709.orange.fr> <0806191256020.15834@somehost> Message-ID: <200806192058.19029.vda.linux@googlemail.com> On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: > The problem seems to be that your wlan-card does not see/catch the > dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet "from us": 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: "udhcp 1.10.3" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x0000) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. > On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: > > > My DHCPD server is: > > * Running under Linux Debian > > * version : Dhcp 2.0pl5-19.1 > > Is this a Debian sarge (oldstable) or woody (even older) distribution? > I do no longer have access to anything like that. > > Did you check the "non-working" version with another dhcp-server? > What arch are you using? > > I see no such problems when using Debian etch dhcp3-server 3.0.4-13, > some misterious m$ dhcp server, dnsmasq various versions, udhcpd > 0.9.8cvs20050303-2. > > Is the mac address 50:00:00:00:26:00 the real thing or just an > obfuscation? > > Maybe that BPF filter should be made into an option. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! Read here: http://en.wikipedia.org/wiki/Ethernet "Ethernet frame types and the EtherType field" section. -- vda From cristian.ionescu-idbohrn at axis.com Thu Jun 19 13:22:27 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 19 Jun 2008 22:22:27 +0200 (CEST) Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <200806192058.19029.vda.linux@googlemail.com> References: <20080618123826.A21701C00042@mwinf2709.orange.fr> <0806191256020.15834@somehost> <200806192058.19029.vda.linux@googlemail.com> Message-ID: <0806192131001.10470@somehost> On Thu, 19 Jun 2008, Denys Vlasenko wrote: > On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: > > The problem seems to be that your wlan-card does not see/catch the > > dhcp-offer. > > Cristian, this is not true. Yes it is :) > In tcpdump I see > > This is the packet "from us": > > 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: > UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] > BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, > Flags [ none ] (0x0000) Right. > and this is the reply: > > 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: > UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.38.68: [udp sum ok] > BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x0000) Sure. > The fact that it is seen by tcpdump means that WLAN card (or whatever > other link is used) _did_ receive the packet. The application won't see it if the kernel (as instructed) will filter it out. > My wild guess is that BPF filter assumes some specific Ethernet frame > format, and unfortunately there are several of those. And especially in > wireless LAN world it's still incredibly messy. (I've been there. I was > developing a wireless driver). We can't do better than assume the kernel is doing TRT. > That explains how BPF filter works for Alexander with one WLAN device > but doesn't work with another: the second device translates WLAN frames > into different Ethernet frame format! That's still weird, wouldn't you say? > Read here: > > http://en.wikipedia.org/wiki/Ethernet > > "Ethernet frame types and the EtherType field" section. I'll do that in a moment. But, until we get "clever" WRT that, to solve the current hickup, we should better do the BPF filter optional. We'd need a full trace to be able to find out if the frame types may be the cause. There's another thing I thought about: byte order. There could be something fishy there. I somehow got the impression the problem occured on a mips-arch, but let's wait for a confirmation. The BPF filter may have a bug, there may be a bug in the kernel too. I'll Bcc: the start of this thread to a couple of my collegues (much more knowledgeable than I am in this area) and see if they can make more sense out of it: http://busybox.net/lists/busybox/2008-June/031820.html and the file we're talking about: http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/networking/udhcp/clientsocket.c?rev=21487&sortby=file&view=markup It's the 'raw_socket' function and the BPF filter there. Cheers, -- Cristian From roy at marples.name Thu Jun 19 13:25:41 2008 From: roy at marples.name (Roy Marples) Date: Thu, 19 Jun 2008 21:25:41 +0100 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <200806192058.19029.vda.linux@googlemail.com> References: <20080618123826.A21701C00042@mwinf2709.orange.fr> <0806191256020.15834@somehost> <200806192058.19029.vda.linux@googlemail.com> Message-ID: <200806192125.41927.roy@marples.name> On Thursday 19 June 2008 19:58:19 Denys Vlasenko wrote: > On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: > > The problem seems to be that your wlan-card does not see/catch the > > dhcp-offer. > > Cristian, this is not true. In tcpdump I see > > This is the packet "from us": > > and this is the reply: > > The fact that it is seen by tcpdump means that WLAN card (or whatever other > link is used) _did_ receive the packet. > > > Maybe that BPF filter should be made into an option. Or should be made to work with buggy Linux versions. Some kernels don't allow a packet length of -1 to pass the full packet. Instead use a large enough number for the packet, but small enough for BPF to work. I used 65535. http://bugs.gentoo.org/show_bug.cgi?id=215174 Thanks Roy From d.samuel at courantmultimedia.fr Fri Jun 20 00:14:35 2008 From: d.samuel at courantmultimedia.fr (SAMUEL Dinesh) Date: Fri, 20 Jun 2008 09:14:35 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <200806192058.19029.vda.linux@googlemail.com> Message-ID: <20080620071241.D2C511C00090@mwinf2717.orange.fr> Hello, Hope you remember that the probleme I have is not on a Wireless Card. The kernel and all the tools that I am using are not fancy tools. The probleme must come from 'BPF filter' hecause when I comment this line the DHCPC works correctly: -----Message d'origine----- De?: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net] De la part de Denys Vlasenko Envoy??: jeudi 19 juin 2008 20:58 ??: busybox at busybox.net; Cristian Ionescu-Idbohrn; Alexander Griesser (LKH Villach) Objet?: Re: udhcpc in 1.10.3 doesnt like my WLAN card On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: > The problem seems to be that your wlan-card does not see/catch the > dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet "from us": 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: "udhcp 1.10.3" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x0000) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. > On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: > > > My DHCPD server is: > > * Running under Linux Debian > > * version : Dhcp 2.0pl5-19.1 > > Is this a Debian sarge (oldstable) or woody (even older) distribution? > I do no longer have access to anything like that. > > Did you check the "non-working" version with another dhcp-server? > What arch are you using? > > I see no such problems when using Debian etch dhcp3-server 3.0.4-13, > some misterious m$ dhcp server, dnsmasq various versions, udhcpd > 0.9.8cvs20050303-2. > > Is the mac address 50:00:00:00:26:00 the real thing or just an > obfuscation? > > Maybe that BPF filter should be made into an option. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! Read here: http://en.wikipedia.org/wiki/Ethernet "Ethernet frame types and the EtherType field" section. -- vda _______________________________________________ busybox mailing list busybox at busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox From d.samuel at courantmultimedia.fr Fri Jun 20 00:18:27 2008 From: d.samuel at courantmultimedia.fr (SAMUEL Dinesh) Date: Fri, 20 Jun 2008 09:18:27 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <200806192058.19029.vda.linux@googlemail.com> Message-ID: <20080620071631.51C4A1C0008D@mwinf2717.orange.fr> Hello, Hope you remember that the problem I have is not on a Wireless Card. The kernel and all the tools that I am using are not fancy tools. The problem must come from 'BPF filter' because when I comment this line the DHCPC works correctly: Clientsocket.c if (SERVER_PORT == 67 && CLIENT_PORT == 68) { /* Use only if standard ports are in use */ /* Ignoring error (kernel may lack support for this) */ if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, &filter_prog, sizeof(filter_prog)) >= 0) DEBUG("attached filter to raw socket fd %d", fd); } -----Message d'origine----- De?: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net] De la part de Denys Vlasenko Envoy??: jeudi 19 juin 2008 20:58 ??: busybox at busybox.net; Cristian Ionescu-Idbohrn; Alexander Griesser (LKH Villach) Objet?: Re: udhcpc in 1.10.3 doesnt like my WLAN card On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: > The problem seems to be that your wlan-card does not see/catch the > dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet "from us": 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x0000) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: "udhcp 1.10.3" MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 > 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x0000) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. > On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: > > > My DHCPD server is: > > * Running under Linux Debian > > * version : Dhcp 2.0pl5-19.1 > > Is this a Debian sarge (oldstable) or woody (even older) distribution? > I do no longer have access to anything like that. > > Did you check the "non-working" version with another dhcp-server? > What arch are you using? > > I see no such problems when using Debian etch dhcp3-server 3.0.4-13, > some misterious m$ dhcp server, dnsmasq various versions, udhcpd > 0.9.8cvs20050303-2. > > Is the mac address 50:00:00:00:26:00 the real thing or just an > obfuscation? > > Maybe that BPF filter should be made into an option. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! Read here: http://en.wikipedia.org/wiki/Ethernet "Ethernet frame types and the EtherType field" section. -- vda _______________________________________________ busybox mailing list busybox at busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox From vda.linux at googlemail.com Fri Jun 20 05:20:15 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 20 Jun 2008 14:20:15 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <0806192131001.10470@somehost> References: <20080618123826.A21701C00042@mwinf2709.orange.fr> <200806192058.19029.vda.linux@googlemail.com> <0806192131001.10470@somehost> Message-ID: <200806201420.15180.vda.linux@googlemail.com> On Thursday 19 June 2008 22:22, Cristian Ionescu-Idbohrn wrote: > On Thu, 19 Jun 2008, Denys Vlasenko wrote: > > > On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: > > > The problem seems to be that your wlan-card does not see/catch the > > > dhcp-offer. > > > > Cristian, this is not true. > > Yes it is :) ... > > The application won't see it if the kernel (as instructed) will filter it > out. You said "your wlan-card does not see/catch the dhcp-offer". "wlan-card", not "application". Here the card did see the offer. -- vda From vda.linux at googlemail.com Fri Jun 20 05:20:54 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 20 Jun 2008 14:20:54 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <200806192125.41927.roy@marples.name> References: <20080618123826.A21701C00042@mwinf2709.orange.fr> <200806192058.19029.vda.linux@googlemail.com> <200806192125.41927.roy@marples.name> Message-ID: <200806201420.54985.vda.linux@googlemail.com> On Thursday 19 June 2008 22:25, Roy Marples wrote: > On Thursday 19 June 2008 19:58:19 Denys Vlasenko wrote: > > On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: > > > The problem seems to be that your wlan-card does not see/catch the > > > dhcp-offer. > > > > Cristian, this is not true. In tcpdump I see > > > > This is the packet "from us": > > > > and this is the reply: > > > > The fact that it is seen by tcpdump means that WLAN card (or whatever other > > link is used) _did_ receive the packet. > > > > > Maybe that BPF filter should be made into an option. > > Or should be made to work with buggy Linux versions. > Some kernels don't allow a packet length of -1 to pass the full packet. > Instead use a large enough number for the packet, but small enough for BPF to > work. I used 65535. > > http://bugs.gentoo.org/show_bug.cgi?id=215174 Thanks! I just committed a fix which uses length 0x0fffffff. -- vda From wharms at bfs.de Fri Jun 20 06:55:18 2008 From: wharms at bfs.de (walter harms) Date: Fri, 20 Jun 2008 15:55:18 +0200 Subject: start-stop daemon regession Message-ID: <485BB6C6.6090308@bfs.de> hello list, we tested BB 10.3 and found a regression from 10.1 does not work with 10.3 start-stop-daemon --start --exec /sbin/syslogd /sbin/syslogd already running 220 (syslogd is not running of cause) while there is no such problem with 10.1. So far i understand the syslogd should not run when the daemon is already running. This does not work, neither in 10.3 nor 10.1. re, wh From vda.linux at googlemail.com Fri Jun 20 07:38:18 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 20 Jun 2008 16:38:18 +0200 Subject: start-stop daemon regession In-Reply-To: <485BB6C6.6090308@bfs.de> References: <485BB6C6.6090308@bfs.de> Message-ID: <200806201638.18698.vda.linux@googlemail.com> On Friday 20 June 2008 15:55, walter harms wrote: > hello list, > we tested BB 10.3 and found a regression from 10.1 > > does not work with 10.3 > start-stop-daemon --start --exec /sbin/syslogd > /sbin/syslogd already running > 220 Is it caused by http://busybox.net/downloads/fixes-1.10.1/busybox-1.10.1-ssd.patch ? IOW: what happens if you revert it? I expect that it well may _still_ not work as intended, with or without that patch. There were more work in ssd, for example: Revision 22002 - (view) (download) (as text) - [select for diffs] Modified Sun May 18 14:17:52 2008 PDT (4 weeks, 4 days ago) by vda File length: 12066 byte(s) Diff to previous 21976 (colored) start_stop_daemon: add -test, fix -x to not match by inode, vastly improve hext text. (mostly by Roy Marples ) function old new delta packed_usage 24124 24190 +66 start_stop_daemon_main 959 991 +32 start_stop_daemon_longopts 149 156 +7 check 1632 1589 -43 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 3/1 up/down: 105/-43) Total: 62 bytes http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/debianutils/start_stop_daemon.c?rev=22002&r1=21976&r2=22002&diff_format=h Can you test current svn? If that works, we can just go ahead and backport it. -- vda From vda.linux at googlemail.com Fri Jun 20 07:49:33 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 20 Jun 2008 16:49:33 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <20080620071631.51C4A1C0008D@mwinf2717.orange.fr> References: <20080620071631.51C4A1C0008D@mwinf2717.orange.fr> Message-ID: <200806201649.33357.vda.linux@googlemail.com> On Friday 20 June 2008 09:18, SAMUEL Dinesh wrote: > > Hello, > > Hope you remember that the problem I have is not on a Wireless Card. > The kernel and all the tools that I am using are not fancy tools. > > The problem must come from 'BPF filter' because when I comment this line the > DHCPC works correctly: > > Clientsocket.c > if (SERVER_PORT == 67 && CLIENT_PORT == 68) > { > /* Use only if standard ports are in use */ > /* Ignoring error (kernel may lack support for this) */ > if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, > &filter_prog, > sizeof(filter_prog)) >= 0) > DEBUG("attached filter to raw socket fd %d", fd); > } Does this help? http://busybox.net/downloads/fixes-1.10.3/busybox-1.10.3-udhcpc.patch -- vda From vda.linux at googlemail.com Fri Jun 20 07:58:04 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 20 Jun 2008 16:58:04 +0200 Subject: MODPROBE: next generation In-Reply-To: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> References: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> Message-ID: <200806201658.04328.vda.linux@googlemail.com> On Tuesday 17 June 2008 19:24, dronnikov at gmail.com wrote: > 0. Intro > > depmod + modprobe is some kind of complicated codec. > Though the syntax of modprobe.conf and friends is human-friendly most of module dependencies > is intrinsic and are hardly a subject to be customized manually. > du modules.* gives 150Kb on my reasonably small system and this amount of loosely defined textual data > must be parsed at every modprobe invocation. > > I suggest to invent for BB a custom modules.dep format which bites all above issues. > > 1. Format of modules.dep (draft) > > Consider a module X which depends on Y and Z, has aliases X1 and X2 and must be loaded with options O1 and O2. > We could write this definition down as follows: > > ------- > X > Y Z > X1 X2 > O1 O2 > ------- > > If any of parts of definition is missed we use empty line for it. > No more continuation lines, delimiters and so on! > Just mmap() the whole file and count for well-known amount of EOLs for each module and use skip_whitespace(). > I wish we had gzmmap() invented (or have we?) > Extensions to such a format can be done trivially. > > 9. Miscellany > > depmod can be trivially (IMO) updated to generate new modules.dep > Personally I think of depmod as of something redundant in terms of BB. > modules.dep could be generated on-the-fly during the first call to modprobe if it is missed. > > To not interfere with "old-style" modutils "new" modules.dep should be named, say, modules.bb. > > Comments? I must agree with others who say that divergence from "standard" format is undesirable. I see that your main concern is the size of this file (modprobe's execution time is not so important since you do not run it often). How about just teaching modprobe to use modules.dep.gz is it exists, with fallback to modules.dep? We already have open_transformer(), so you just call fd = open_transformer(gzfile_fd, unpack_gz_stream, "gunzip"); and voila - you can gunzip file on the fly :) gzip compresses modules.dep formatted file to ~1/20th of its size: # wc -c References: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> <1213770523.22584.24.camel@nc.nor.wtbts.org> <6784529b0806190915t66bf8e20j1b7f133856782c0b@mail.gmail.com> Message-ID: <200806201701.41713.vda.linux@googlemail.com> On Thursday 19 June 2008 18:15, Vladimir Dronnikov wrote: > 2. BB depmod right now generates (having FEATURE_ALIAS defined, my > case) modules.dep which can not be parsed correctly with BB modprobe. > This is modprobe's issue. Sounds like depmod issue to me. The goal should be "depmod generates correct modprobe.dep, usable either by our or by 'standard' modprobe". Does it do that now? > Since modprobe's maintaner is now offline the updates are blocked. I can take a look. Please describe the problem. > How people who shifted from production to BB > modutils (my case again) are supposed to cope this lockout? -- vda From wharms at bfs.de Fri Jun 20 08:04:59 2008 From: wharms at bfs.de (walter harms) Date: Fri, 20 Jun 2008 17:04:59 +0200 Subject: start-stop daemon regession In-Reply-To: <200806201638.18698.vda.linux@googlemail.com> References: <485BB6C6.6090308@bfs.de> <200806201638.18698.vda.linux@googlemail.com> Message-ID: <485BC71B.6050500@bfs.de> Denys Vlasenko wrote: > On Friday 20 June 2008 15:55, walter harms wrote: >> hello list, >> we tested BB 10.3 and found a regression from 10.1 >> >> does not work with 10.3 >> start-stop-daemon --start --exec /sbin/syslogd >> /sbin/syslogd already running >> 220 > > Is it caused by http://busybox.net/downloads/fixes-1.10.1/busybox-1.10.1-ssd.patch ? > IOW: what happens if you revert it? > > I expect that it well may _still_ not work as intended, > with or without that patch. > > > There were more work in ssd, for example: > > Revision 22002 - (view) (download) (as text) - [select for diffs] > Modified Sun May 18 14:17:52 2008 PDT (4 weeks, 4 days ago) by vda > File length: 12066 byte(s) > Diff to previous 21976 (colored) > > start_stop_daemon: add -test, fix -x to not match by inode, > vastly improve hext text. (mostly by Roy Marples ) > > function old new delta > packed_usage 24124 24190 +66 > start_stop_daemon_main 959 991 +32 > start_stop_daemon_longopts 149 156 +7 > check 1632 1589 -43 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 3/1 up/down: 105/-43) Total: 62 bytes > > http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/debianutils/start_stop_daemon.c?rev=22002&r1=21976&r2=22002&diff_format=h > > > Can you test current svn? If that works, we can just go ahead and backport it. hi denis, yep that is what we have done. we just replaced the 10.3 version with the svn version. at least no more daemons can be started :) FYI: while testing we note something odd, when a daemon is killed sometimes all shells also gets closed. This is new. Unfortunately the guy who found the bug is home, so we will continue testing on monday. should we still test the busybox-1.10.1-ssd.patch ? re, wh From rep.dot.nop at gmail.com Fri Jun 20 08:05:57 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 20 Jun 2008 17:05:57 +0200 Subject: MODPROBE: next generation In-Reply-To: <200806201658.04328.vda.linux@googlemail.com> References: <4857f34d.2135440a.5bf1.1ee6@mx.google.com> <200806201658.04328.vda.linux@googlemail.com> Message-ID: <20080620150557.GI12682@mx.loc> On Fri, Jun 20, 2008 at 04:58:04PM +0200, Denys Vlasenko wrote: >We already have open_transformer(), so you just call > >fd = open_transformer(gzfile_fd, unpack_gz_stream, "gunzip"); > >and voila - you can gunzip file on the fly :) Can we have a libunarchival wrapper that sets up open_transformer for us, depending on supported decompressors and file-extension (see depmod.c for the FIXME) ? tar already has such a thing, ISTR.. perhaps generalize that From d.samuel at courantmultimedia.fr Fri Jun 20 08:17:10 2008 From: d.samuel at courantmultimedia.fr (SAMUEL Dinesh) Date: Fri, 20 Jun 2008 17:17:10 +0200 Subject: udhcpc in 1.10.3 doesnt like my WLAN card In-Reply-To: <200806201649.33357.vda.linux@googlemail.com> Message-ID: <20080620151515.80EDB7000096@mwinf2b17.orange.fr> Hello, Yep this patch is working. Thanks. Bye -----Message d'origine----- De?: Denys Vlasenko [mailto:vda.linux at googlemail.com] Envoy??: vendredi 20 juin 2008 16:50 ??: SAMUEL Dinesh Cc?: busybox at busybox.net; 'Cristian Ionescu-Idbohrn'; 'Alexander Griesser (LKH Villach)' Objet?: Re: udhcpc in 1.10.3 doesnt like my WLAN card On Friday 20 June 2008 09:18, SAMUEL Dinesh wrote: > > Hello, > > Hope you remember that the problem I have is not on a Wireless Card. > The kernel and all the tools that I am using are not fancy tools. > > The problem must come from 'BPF filter' because when I comment this line the > DHCPC works correctly: > > Clientsocket.c > if (SERVER_PORT == 67 && CLIENT_PORT == 68) > { > /* Use only if standard ports are in use */ > /* Ignoring error (kernel may lack support for this) */ > if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, > &filter_prog, > sizeof(filter_prog)) >= 0) > DEBUG("attached filter to raw socket fd %d", fd); > } Does this help? http://busybox.net/downloads/fixes-1.10.3/busybox-1.10.3-udhcpc.patch -- vda From wharms at bfs.de Fri Jun 20 08:34:05 2008 From: wharms at bfs.de (walter harms) Date: Fri, 20 Jun 2008 17:34:05 +0200 Subject: [PATCH]: allow serverroot setting in configfile Message-ID: <485BCDED.8060702@bfs.de> hi list, i had the local request to add the serverroot setting into the configfile to allow configuration in one place, for more easy deployment. re, wh --- networking/httpd.c.org 2008-06-20 17:17:42.000000000 +0200 +++ networking/httpd.c 2008-06-20 17:16:22.000000000 +0200 @@ -37,6 +37,7 @@ * * httpd.conf has the following format: * + * H:/serverroot # define the server root. It will override -h * A:172.20. # Allow address from 172.20.0.0/16 * A:10.0.0.0/25 # Allow any address from 10.0.0.0-10.0.0.127 * A:10.0.0.0/255.255.255.128 # Allow any address that previous set @@ -687,6 +688,13 @@ continue; } + if (*p0 == 'H') { + home_httpd = xstrdup(after_colon); + xchdir(home_httpd); + continue; + } + + #if ENABLE_FEATURE_HTTPD_BASIC_AUTH \ || ENABLE_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES \ || ENABLE_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR -------------- next part -------------- A non-text attachment was scrubbed... Name: httpd.c.diff Type: text/x-patch Size: 744 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080620/802acbb2/attachment.bin From beck0778 at umn.edu Fri Jun 20 09:55:17 2008 From: beck0778 at umn.edu (beck0778 at umn.edu) Date: 20 Jun 2008 11:55:17 -0500 Subject: [PATCH]: Create vim -> vi alias Message-ID: Hello, I'm not sure if this would be useful to anyone else. On our embedded product we don't have support for shell command aliases, and I'm in the habit of typing 'vim' instead of 'vi'. This patch adds a configurable option to allow busybox to respond to both 'vim' and 'vi'. Sorry if this has been discussed before, or if this is not appropriate / desired in busybox. --Matthew -------------- next part -------------- A non-text attachment was scrubbed... Name: vim_vi_alias.patch Type: text/x-patch Size: 1282 bytes Desc: vim_vi_alias.patch Url : http://busybox.net/lists/busybox/attachments/20080620/080564d2/attachment-0001.bin From rep.dot.nop at gmail.com Fri Jun 20 10:02:30 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 20 Jun 2008 19:02:30 +0200 Subject: [PATCH]: Create vim -> vi alias In-Reply-To: References: Message-ID: <20080620170230.GA16114@mx.loc> On Fri, Jun 20, 2008 at 11:55:17AM -0500, beck0778 at umn.edu wrote: > Hello, > > I'm not sure if this would be useful to anyone else. On our embedded > product we don't have support for shell command aliases, and I'm in the > habit of typing 'vim' instead of 'vi'. This patch adds a configurable > option to allow busybox to respond to both 'vim' and 'vi'. Personally, I don't think that such a patch makes sense, fwiw. what about ln -s vi /bin/vim instead? From beck0778 at umn.edu Fri Jun 20 10:10:35 2008 From: beck0778 at umn.edu (beck0778 at umn.edu) Date: 20 Jun 2008 12:10:35 -0500 Subject: [PATCH]: Create vim -> vi alias In-Reply-To: <20080620170230.GA16114@mx.loc> References: <20080620170230.GA16114@mx.loc> Message-ID: On Jun 20 2008, Bernhard Fischer wrote: >On Fri, Jun 20, 2008 at 11:55:17AM -0500, beck0778 at umn.edu wrote: >> Hello, >> >> I'm not sure if this would be useful to anyone else. On our embedded >> product we don't have support for shell command aliases, and I'm in the >> habit of typing 'vim' instead of 'vi'. This patch adds a configurable >> option to allow busybox to respond to both 'vim' and 'vi'. > >Personally, I don't think that such a patch makes sense, fwiw. > >what about >ln -s vi /bin/vim >instead? > You mean something like this, where vi is linked to busybox, and vim is linked to vi? /bin > ls -l vi* lrwxrwxrwx 1 root root 7 Jun 20 11:21 vi -> busybox lrwxrwxrwx 1 root root 2 Jun 20 12:07 vim -> vi I tried this, and it appears that even though vim is linked to busybox "through" vi, busybox still figures out that it's being called as vim, an applet name it doesn't recognize. If you know of another way to accomplish this, please let me know. From vda.linux at googlemail.com Fri Jun 20 11:34:07 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 20 Jun 2008 20:34:07 +0200 Subject: start-stop daemon regession In-Reply-To: <485BC71B.6050500@bfs.de> References: <485BB6C6.6090308@bfs.de> <200806201638.18698.vda.linux@googlemail.com> <485BC71B.6050500@bfs.de> Message-ID: <200806202034.07685.vda.linux@googlemail.com> On Friday 20 June 2008 17:04, walter harms wrote: > > Can you test current svn? If that works, we can just go ahead and backport it. > > hi denis, > yep that is what we have done. we just replaced the 10.3 version with the svn version. > at least no more daemons can be started :) > FYI: while testing we note something odd, when a daemon is killed sometimes all shells > also gets closed. This is new. That is a symptom of a particular flavor of ssd which matches processes by their executable's inode number. When you try to kill syslogd, it kills syslogd... and all other processes which are run by same executable. If your syslogd was busyboxed and e.g. telnetd and/or sh were busyboxed too, they will be killed too. ssd was suffering from multiple people having a problem with the way it handles --exec, devising a quick fix accourding to their particular idea what --exec means, fixing it, not updating documentation (or should I say "not creating documenttion" - nobody bothered to actually doc