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