From mats.andersson64 at comhem.se Sat Mar 1 03:28:36 2008 From: mats.andersson64 at comhem.se (Mats Erik Andersson) Date: Sat, 01 Mar 2008 12:28:36 +0100 Subject: [PATCH] Sed: remove outdated infile capacities Message-ID: <1204370916.6772.4.camel@asus.bellman.mea> Hello folks, now that the documentation sed_summary.htm exists it should be apropriate to remove the outdated list of capabilities that is kept within sed.c. A possible patch is attached here! Regards Mats Erik Andersson -------------- next part -------------- A non-text attachment was scrubbed... Name: sed_no_outdated_capacity.diff Type: text/x-patch Size: 820 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080301/635bba4b/attachment.bin From mats.andersson64 at comhem.se Sat Mar 1 04:12:20 2008 From: mats.andersson64 at comhem.se (Mats Erik Andersson) Date: Sat, 01 Mar 2008 13:12:20 +0100 Subject: [PATCH] Sed_summary: mention 'I' flag Message-ID: <1204373540.6772.9.camel@asus.bellman.mea> Hello folks, The document sed_summary.htm fails to mention the flag 'I' for the search action. Additionally, the very last line is ill-formed since it lacks a newline. Regards Mats E Andersson -------------- next part -------------- A non-text attachment was scrubbed... Name: sed_summary_with_I.diff Type: text/x-patch Size: 689 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080301/657a4380/attachment.bin From vda.linux at googlemail.com Sat Mar 1 11:26:29 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 1 Mar 2008 20:26:29 +0100 Subject: [PATCH] Sed_summary: mention 'I' flag In-Reply-To: <1204373540.6772.9.camel@asus.bellman.mea> References: <1204373540.6772.9.camel@asus.bellman.mea> Message-ID: <200803012026.29365.vda.linux@googlemail.com> On Saturday 01 March 2008 13:12, Mats Erik Andersson wrote: > Hello folks, > > The document sed_summary.htm fails to mention the > flag 'I' for the search action. Additionally, the > very last line is ill-formed since it lacks a newline. Applied part about "I", the rest doesn't apply to svn. -- vda From vda.linux at googlemail.com Sat Mar 1 11:28:31 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 1 Mar 2008 20:28:31 +0100 Subject: [PATCH] Sed: remove outdated infile capacities In-Reply-To: <1204370916.6772.4.camel@asus.bellman.mea> References: <1204370916.6772.4.camel@asus.bellman.mea> Message-ID: <200803012028.31759.vda.linux@googlemail.com> On Saturday 01 March 2008 12:28, Mats Erik Andersson wrote: > Hello folks, > > now that the documentation sed_summary.htm exists > it should be apropriate to remove the outdated list > of capabilities that is kept within sed.c. sed_summary.htm is not a documentation for bbox sed. It says: Command Summary for sed (sed & awk, Second Edition) It's just a conveniently located piece of doc for the rest of us, who don't know sed and awk by heart. -- vda From mats.andersson64 at comhem.se Sat Mar 1 12:16:10 2008 From: mats.andersson64 at comhem.se (Mats Erik Andersson) Date: Sat, 01 Mar 2008 21:16:10 +0100 Subject: [PATCH] Sed: documentation inside source Message-ID: <1204402570.6772.16.camel@asus.bellman.mea> Hello vda, since I depend heavily on the capacities of Busybox-sed, and thus would appreciate to have listed access to them, let me make a renewed effort to get them explicit into the source code. I did some "greping" in the svn file and came up with some more details that deserve mention. Best regards, Mats E Andersson -------------- next part -------------- A non-text attachment was scrubbed... Name: sed_insource_docs.diff Type: text/x-patch Size: 975 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080301/e4aa12f1/attachment.bin From vda.linux at googlemail.com Sat Mar 1 13:08:59 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 1 Mar 2008 22:08:59 +0100 Subject: [patch] - bbsplash In-Reply-To: <1204206136.30494.4.camel@pigreco> References: <1202921878.7846.4.camel@pigreco> <200802251757.36565.vda.linux@googlemail.com> <1204206136.30494.4.camel@pigreco> Message-ID: <200803012208.59101.vda.linux@googlemail.com> On Thursday 28 February 2008 14:42, Michele Sanges wrote: > Please, consider the new version of the patch. Somebody said it works for them, but slowly. Let's take a look. +static void fb_drawrectangle(int nx1pos, int ny1pos, int nx2pos, int ny2pos, + unsigned char nred24, unsigned char ngreen24, unsigned char nblue24) +{ + int x, y, idx; + unsigned char nred16 = (nred24) >> 3; // 5-bit red + unsigned char ngreen16 = (ngreen24) >> 2; // 6-bit green + unsigned char nblue16 = (nblue24) >> 3; // 5-bit blue + + unsigned nrgb_2bytes = nblue16 + (ngreen16<<5) + (nred16<<(5+6)); + DATA thispix = nrgb_2bytes; + + // horizontal lines + for (x = nx1pos; x <= nx2pos; x++) { + idx = (ny1pos * G.screen_infovar.xres + x) * (G.screen_infovar.bits_per_pixel / 8); + *(DATA *)(G.addr + idx) = thispix; + + idx = (ny2pos * G.screen_infovar.xres + x) * (G.screen_infovar.bits_per_pixel / 8); + *(DATA *)(G.addr + idx) = thispix; + } gcc compiles it into this (x86 asm, use "make miscutils/bbsplash.s" to see it): .L11: movl %edi, %eax # D.6492, tmp104 imull 72(%ebx), %eax # .screen_infovar.xres, tmp104 leal (%esi,%eax), %eax #, tmp105 movl 96(%ebx), %edx # .screen_infovar.bits_per_pixel, tmp106 shrl $3, %edx #, tmp106 imull %edx, %eax # tmp106, tmp105 movl 8(%ebx), %ecx # .addr, .addr movw %bp, (%ecx,%eax) # thispix, movl 16(%esp), %eax # D.6494, tmp110 imull 72(%ebx), %eax # .screen_infovar.xres, tmp110 leal (%esi,%eax), %eax #, tmp111 imull %edx, %eax # tmp106, tmp111 movw %bp, (%ecx,%eax) # thispix, incl %esi # x .L10: cmpl 24(%esp), %esi # D.6498, x jle .L11 #, *four* multiplications! Using the fact that cuurently there is only support for 16 bits per pixel, it can be rewritten as follows: int cnt; DATA thispix; DATA *ptr1, *ptr2; nred >>= 3; // 5-bit red ngreen >>= 2; // 6-bit green nblue >>= 3; // 5-bit blue thispix = nblue + (ngreen << 5) + (nred << (5+6)); // horizontal lines ptr1 = (DATA*)(G.addr + (ny1pos * G.screen_infovar.xres + nx1pos) * BYTES_PER_PIXEL); ptr2 = (DATA*)(G.addr + (ny2pos * G.screen_infovar.xres + nx1pos) * BYTES_PER_PIXEL); cnt = nx2pos - nx1pos; do { *ptr1++ = thispix; *ptr2++ = thispix; } while (--cnt >= 0); No multiplications now, likely x10 faster or so: .L10: movw %bp, (%eax) # thispix,* ptr1 addl $2, %eax #, ptr1 movw %bp, (%esi) # thispix,* ptr2 addl $2, %esi #, ptr2 decl %ecx # cnt jns .L10 #, Please speed up "filled rectangle" function similarly. pinifile = xfopen("/etc/bbsplash/bbsplash.ini", "r"); Can this be a command line switch? "bbsplash -i -f -d " etc... sprintf(G.strsplash_theme, "/etc/bbsplash/%s", pvalue); Use char *str instead of char str[FIXED_SIZE] for it, and do G.strsplash_theme = xasprintf(...); This way you use as much memory as needed, and don't have artificial size limit. I rebased the patch to current svn, please see it attached. fb_drawrectangle() is edited, the rest is not touched (except for s/PTR_TO_GLOBALS/SET_PTR_TO_GLOBALS/). You can download current svn and base your work on it using this command: svn co svn://busybox.net/trunk/busybox -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.patch Type: text/x-diff Size: 15342 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080301/dc70b14b/attachment.bin From bock at blacknet.de Sat Mar 1 12:36:25 2008 From: bock at blacknet.de (Goetz Bock) Date: Sat, 1 Mar 2008 21:36:25 +0100 Subject: Encryption In-Reply-To: <200803010210.35455.vapier@gentoo.org> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> Message-ID: <20080301203625.GZ14356@priv.blacknet.de> On Sat, Mar 01 '08 at 02:10, Mike Frysinger wrote: > On Friday 29 February 2008, Kevin Holland wrote: > > Is there a quick and dirty way to encrypt and decrypt a tar with the > > current busybox utilities? > > there are no encrypt/decrypt utils in busybox to bad. > > I'm pulling updates from a public FTP and I would like to secure it. > > that doesnt really make sense. if it's public ftp, then anyone can fetch it, > therefore protecting the content by encryption is pointless. that made about as much sence as saying: AIDS is a sexualy transmitted desease. everyoe is having sexi, so using a condom is pointless. Encryption is probably the only way to secure Kevins data. -- /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting \ / (c) 2008 Creative Commons, Attribution-ShareAlike 2.0 de X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] From christian.michon at gmail.com Sat Mar 1 13:26:06 2008 From: christian.michon at gmail.com (Christian MICHON) Date: Sat, 1 Mar 2008 22:26:06 +0100 Subject: [patch] - bbsplash In-Reply-To: <200803012208.59101.vda.linux@googlemail.com> References: <1202921878.7846.4.camel@pigreco> <200802251757.36565.vda.linux@googlemail.com> <1204206136.30494.4.camel@pigreco> <200803012208.59101.vda.linux@googlemail.com> Message-ID: <46d6db660803011326x3caf07b8g981c9e4834ee68fd@mail.gmail.com> 2008/3/1 Denys Vlasenko : > On Thursday 28 February 2008 14:42, Michele Sanges wrote: > > Please, consider the new version of the patch. > > Somebody said it works for them, but slowly. > Let's take a look. > (...) that'll be me. I'll try the patch soon and confirm the speed up -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! From vapier at gentoo.org Sat Mar 1 13:50:01 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 1 Mar 2008 16:50:01 -0500 Subject: Encryption In-Reply-To: <20080301203625.GZ14356@priv.blacknet.de> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> Message-ID: <200803011650.01741.vapier@gentoo.org> On Saturday 01 March 2008, Goetz Bock wrote: > On Sat, Mar 01 '08 at 02:10, Mike Frysinger wrote: > > On Friday 29 February 2008, Kevin Holland wrote: > > > Is there a quick and dirty way to encrypt and decrypt a tar with the > > > current busybox utilities? > > > > there are no encrypt/decrypt utils in busybox > > to bad. > > > > I'm pulling updates from a public FTP and I would like to secure it. > > > > that doesnt really make sense. if it's public ftp, then anyone can fetch > > it, therefore protecting the content by encryption is pointless. > > that made about as much sence as saying: AIDS is a sexualy transmitted > desease. everyoe is having sexi, so using a condom is pointless. that's a stupid (and incorrect) analogy > Encryption is probably the only way to secure Kevins data. if it's a public FTP, then there's nothing to be secured. if someone is sniffing traffic and the traffic is encrypted, then the attacker merely needs to go to the public FTP and fetch the files themselves. -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/20080301/e5a74e20/attachment-0001.pgp From farmatito at tiscali.it Sat Mar 1 14:21:24 2008 From: farmatito at tiscali.it (Tito) Date: Sat, 1 Mar 2008 23:21:24 +0100 Subject: [PATCH] check user and group names for illegal chars in adduser and addgroup Message-ID: <200803012321.25282.farmatito@tiscali.it> Hi, this patch adds the new function xcheck_name() void xcheck_name(const char *name) { int i = 0; do { if (!isalnum(*name) && !(*name == '_') && !(*name == '.') && !(*name == '@') && !(*name == '-' && i) && !(*name == '$' && !*(name + 1)) ) bb_error_msg_and_die("illegal character '%c'", *name); i++; } while (*++name); } to libbb that is used by adduser and addroup to check for illegal characters in user and group names. The rules enforced are: the username should consist only of letters, digits, underscores, periods, at signs and dashes, and not start with a dash (as defined by IEEE Std 1003.1-2001). For compatibility with Samba machine accounts $ is also supported at the end of the username. This feature is optional and off by default. It can be turned on with the switch Login/Password Management Utilities ---> [*] Enable sanity check on user and group names in adduser and addgroup that is visible only if adduser or addgroup are selected. This menuconfig solution seems suboptimal to me but iwas not able to find a better way. Bloat-o-meter says: scripts/bloat-o-meter busybox_old busybox_unstripped function old new delta xcheck_name - 88 +88 .rodata 118977 119000 +23 adduser_main 625 634 +9 addgroup_main 364 372 +8 UNSPEC_print 70 72 +2 cut_main 1047 1046 -1 get_next_line 145 143 -2 display_speed 96 91 -5 arith 2071 2062 -9 mainSort 2592 2560 -32 ------------------------------------------------------------------------------ (add/remove: 1/0 grow/shrink: 4/5 up/down: 130/-49) Total: 81 bytes The patch applies to current svn, is tested a little and seems to work for me. Hints, critics and help by the list members are as always welcome. ;-) Ciao, Tito -------------- next part -------------- A non-text attachment was scrubbed... Name: xcheckname.patch Type: text/x-diff Size: 3801 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080301/21fd15cd/attachment.bin From christian.michon at gmail.com Sat Mar 1 14:25:51 2008 From: christian.michon at gmail.com (Christian MICHON) Date: Sat, 1 Mar 2008 22:25:51 +0000 Subject: [patch] - bbsplash In-Reply-To: <46d6db660803011326x3caf07b8g981c9e4834ee68fd@mail.gmail.com> References: <1202921878.7846.4.camel@pigreco> <200802251757.36565.vda.linux@googlemail.com> <1204206136.30494.4.camel@pigreco> <200803012208.59101.vda.linux@googlemail.com> <46d6db660803011326x3caf07b8g981c9e4834ee68fd@mail.gmail.com> Message-ID: <46d6db660803011425n58c1ef69wacb5c81d3c40a2de@mail.gmail.com> On Sat, Mar 1, 2008 at 9:26 PM, Christian MICHON wrote: > 2008/3/1 Denys Vlasenko : > > > On Thursday 28 February 2008 14:42, Michele Sanges wrote: > > > Please, consider the new version of the patch. > > > > Somebody said it works for them, but slowly. > > Let's take a look. > > > (...) > > that'll be me. I'll try the patch soon and confirm the speed up test finished... it does not look any faster, unfortunately. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! From farmatito at tiscali.it Sat Mar 1 14:24:34 2008 From: farmatito at tiscali.it (Tito) Date: Sat, 1 Mar 2008 23:24:34 +0100 Subject: Encryption In-Reply-To: <200803011650.01741.vapier@gentoo.org> References: <1204308927.6393.1.camel@kevin-laptop> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> Message-ID: <200803012324.34834.farmatito@tiscali.it> On Saturday 01 March 2008 22:50:01 Mike Frysinger wrote: > On Saturday 01 March 2008, Goetz Bock wrote: > > On Sat, Mar 01 '08 at 02:10, Mike Frysinger wrote: > > > On Friday 29 February 2008, Kevin Holland wrote: > > > > Is there a quick and dirty way to encrypt and decrypt a tar with the > > > > current busybox utilities? > > > > > > there are no encrypt/decrypt utils in busybox > > > > to bad. > > > > > > I'm pulling updates from a public FTP and I would like to secure it. > > > > > > that doesnt really make sense. if it's public ftp, then anyone can fetch > > > it, therefore protecting the content by encryption is pointless. > > > > that made about as much sence as saying: AIDS is a sexualy transmitted > > desease. everyoe is having sexi, so using a condom is pointless. > > that's a stupid (and incorrect) analogy > > > Encryption is probably the only way to secure Kevins data. > > if it's a public FTP, then there's nothing to be secured. if someone is > sniffing traffic and the traffic is encrypted, then the attacker merely needs > to go to the public FTP and fetch the files themselves. > -mike > Hi, maybe the problem is to post a file on a public ftp server in a way that its contents are not public..........? Ciao, Tito From vapier at gentoo.org Sat Mar 1 15:00:04 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 1 Mar 2008 18:00:04 -0500 Subject: Encryption In-Reply-To: <200803012324.34834.farmatito@tiscali.it> References: <1204308927.6393.1.camel@kevin-laptop> <200803011650.01741.vapier@gentoo.org> <200803012324.34834.farmatito@tiscali.it> Message-ID: <200803011800.04918.vapier@gentoo.org> On Saturday 01 March 2008, Tito wrote: > On Saturday 01 March 2008 22:50:01 Mike Frysinger wrote: > > On Saturday 01 March 2008, Goetz Bock wrote: > > > On Sat, Mar 01 '08 at 02:10, Mike Frysinger wrote: > > > > On Friday 29 February 2008, Kevin Holland wrote: > > > > > Is there a quick and dirty way to encrypt and decrypt a tar with > > > > > the current busybox utilities? > > > > > > > > there are no encrypt/decrypt utils in busybox > > > > > > to bad. > > > > > > > > I'm pulling updates from a public FTP and I would like to secure > > > > > it. > > > > > > > > that doesnt really make sense. if it's public ftp, then anyone can > > > > fetch it, therefore protecting the content by encryption is > > > > pointless. > > > > > > that made about as much sence as saying: AIDS is a sexualy transmitted > > > desease. everyoe is having sexi, so using a condom is pointless. > > > > that's a stupid (and incorrect) analogy > > > > > Encryption is probably the only way to secure Kevins data. > > > > if it's a public FTP, then there's nothing to be secured. if someone is > > sniffing traffic and the traffic is encrypted, then the attacker merely > > needs to go to the public FTP and fetch the files themselves. > > maybe the problem is to post a file on a public ftp server > in a way that its contents are not public..........? maybe if you were talking about an anonymous write-only setup (an ftp "drop box"), but that isnt what the OP stated: ... pulling updates from a public FTP ... in any case though, the ftp server would need to support the encryption as well ... a random util in busybox isnt going to magically make it happen. that means the only options are the OP has a secure shell on the FTP server (in which case you should be using scp), or the OP has admin on the FTP server (so he can insert the encrypt algo into the stream), or the server supports openssl/TLS (the only "standard" ive seen for securing FTP transactions). that's about the only thing worth adding imo to busybox's ftp/wget clients: optional openssl support. -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/20080301/70ff3202/attachment.pgp From Alexander at Kriegisch.name Sat Mar 1 15:49:58 2008 From: Alexander at Kriegisch.name (Alexander Kriegisch) Date: Sun, 02 Mar 2008 00:49:58 +0100 Subject: [PATCH] Sed: documentation inside source In-Reply-To: <1204402570.6772.16.camel@asus.bellman.mea> References: <1204402570.6772.16.camel@asus.bellman.mea> Message-ID: <47C9EBA6.6070406@Kriegisch.name> > + - miltiline edit: append (N)extline, (D)elete, (P)rint You probably mean multi-line. ;-) From Alexander at Kriegisch.name Sat Mar 1 15:51:59 2008 From: Alexander at Kriegisch.name (Alexander Kriegisch) Date: Sun, 02 Mar 2008 00:51:59 +0100 Subject: Encryption In-Reply-To: <20080301203625.GZ14356@priv.blacknet.de> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> Message-ID: <47C9EC1F.9040802@Kriegisch.name> Instead of going polemic you could have opted for explaining to us what you seem to have understood, while have obviously have not (otherwise we would not have asked). -- Alexander Kriegisch > that made about as much sence as saying: AIDS is a sexualy transmitted > desease. everyoe is having sexi, so using a condom is pointless. > > Encryption is probably the only way to secure Kevins data. From Alexander at Kriegisch.name Sat Mar 1 15:54:10 2008 From: Alexander at Kriegisch.name (Alexander Kriegisch) Date: Sun, 02 Mar 2008 00:54:10 +0100 Subject: Encryption In-Reply-To: <200803012324.34834.farmatito@tiscali.it> References: <1204308927.6393.1.camel@kevin-laptop> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> <200803012324.34834.farmatito@tiscali.it> Message-ID: <47C9ECA2.1010100@Kriegisch.name> > maybe the problem is to post a file on a public ftp server > in a way that its contents are not public..........? Why not let him answer by himself? He spoke of "pulling files", not "pushing/uploading files". Alexander Kriegisch From pascal.bellard at ads-lu.com Sun Mar 2 05:31:35 2008 From: pascal.bellard at ads-lu.com (Pascal Bellard) Date: Sun, 2 Mar 2008 14:31:35 +0100 (CET) Subject: unlzma shrink Message-ID: <56256.192.168.10.101.1204464695.squirrel@193.253.62.30> Reorder code to help the optimizer function old new delta unpack_lzma_stream 2398 2367 -31 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-31) Total: -31 bytes -------------- next part -------------- A non-text attachment was scrubbed... Name: decompress_unlzma.u Type: application/octet-stream Size: 1081 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080302/87470c43/attachment.obj From pascal.bellard at ads-lu.com Sun Mar 2 05:48:28 2008 From: pascal.bellard at ads-lu.com (Pascal Bellard) Date: Sun, 2 Mar 2008 14:48:28 +0100 (CET) Subject: unlzma shrink In-Reply-To: <56256.192.168.10.101.1204464695.squirrel@193.253.62.30> References: <56256.192.168.10.101.1204464695.squirrel@193.253.62.30> Message-ID: <51918.192.168.10.101.1204465708.squirrel@193.253.62.30> next step: function old new delta unpack_lzma_stream 2398 2251 -147 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-147) Total: -147 bytes -------------- next part -------------- A non-text attachment was scrubbed... Name: decompress_unlzma.u Type: application/octet-stream Size: 2193 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080302/28e4061a/attachment-0001.obj From vda.linux at googlemail.com Sun Mar 2 06:53:48 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 2 Mar 2008 15:53:48 +0100 Subject: unlzma shrink In-Reply-To: <51918.192.168.10.101.1204465708.squirrel@193.253.62.30> References: <56256.192.168.10.101.1204464695.squirrel@193.253.62.30> <51918.192.168.10.101.1204465708.squirrel@193.253.62.30> Message-ID: <200803021553.48610.vda.linux@googlemail.com> On Sunday 02 March 2008 14:48, Pascal Bellard wrote: > next step: > > function old new delta > unpack_lzma_stream 2398 2251 -147 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-147) Total: -147 > bytes On this file: http://gnu.ethz.ch/lzma/linux/linux-2.6.23.tar.lzma "time unlzma /dev/null" before patch I it takes ~8.75 seconds "user" time, after patch it's going up to ~9.04 seconds. -- vda From vda.linux at googlemail.com Sun Mar 2 07:06:15 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 2 Mar 2008 16:06:15 +0100 Subject: [patch] - bbsplash In-Reply-To: <46d6db660803011425n58c1ef69wacb5c81d3c40a2de@mail.gmail.com> References: <1202921878.7846.4.camel@pigreco> <46d6db660803011326x3caf07b8g981c9e4834ee68fd@mail.gmail.com> <46d6db660803011425n58c1ef69wacb5c81d3c40a2de@mail.gmail.com> Message-ID: <200803021606.15771.vda.linux@googlemail.com> On Saturday 01 March 2008 23:25, Christian MICHON wrote: > On Sat, Mar 1, 2008 at 9:26 PM, Christian MICHON > wrote: > > 2008/3/1 Denys Vlasenko : > > > > > On Thursday 28 February 2008 14:42, Michele Sanges wrote: > > > > Please, consider the new version of the patch. > > > > > > Somebody said it works for them, but slowly. > > > Let's take a look. > > > > > (...) > > > > that'll be me. I'll try the patch soon and confirm the speed up > > test finished... > > it does not look any faster, unfortunately. Well, I sped up function which draws rectangle borders only. There is another which is used to draw filled rectangle, and it needs the same speed up. Since filled rect has several orders of magnitude more dots, its speed dominates the whole process. -- vda From vda.linux at googlemail.com Sun Mar 2 10:57:19 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 2 Mar 2008 19:57:19 +0100 Subject: unlzma shrink In-Reply-To: <200803021553.48610.vda.linux@googlemail.com> References: <56256.192.168.10.101.1204464695.squirrel@193.253.62.30> <51918.192.168.10.101.1204465708.squirrel@193.253.62.30> <200803021553.48610.vda.linux@googlemail.com> Message-ID: <200803021957.19397.vda.linux@googlemail.com> hi Pascal, On Sunday 02 March 2008 15:53, Denys Vlasenko wrote: > > function old new delta > > unpack_lzma_stream 2398 2251 -147 > > ------------------------------------------------------------------------------ > > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-147) Total: -147 > > bytes > > On this file: > > http://gnu.ethz.ch/lzma/linux/linux-2.6.23.tar.lzma > > "time unlzma /dev/null" > before patch I it takes ~8.75 seconds "user" time, > after patch it's going up to ~9.04 seconds. I applied your patch but activated code-saving variant only if CONFIG_FEATURE_LZMA_FAST is not selected - please take a look at current svn. Thanks! -- vda From farmatito at tiscali.it Sun Mar 2 13:20:15 2008 From: farmatito at tiscali.it (Tito) Date: Sun, 2 Mar 2008 22:20:15 +0100 Subject: www.busybox.net seems to be down Message-ID: <200803022220.15642.farmatito@tiscali.it> Hi, i'm unable to connect to the busybox web site. I've tried two different ISPs with no luck, nonetheless i'm able to ping the host... PING www.busybox.net (140.211.166.42) 56(84) bytes of data. 64 bytes from busybox.net (140.211.166.42): icmp_seq=1 ttl=52 time=1123 ms 64 bytes from busybox.net (140.211.166.42): icmp_seq=2 ttl=52 time=2106 ms 64 bytes from busybox.net (140.211.166.42): icmp_seq=3 ttl=52 time=3100 ms 64 bytes from busybox.net (140.211.166.42): icmp_seq=4 ttl=52 time=4097 ms 64 bytes from busybox.net (140.211.166.42): icmp_seq=6 ttl=52 time=3888 ms and there are some open ports nmap -sT -PI -PT 140.211.166.42 Starting Nmap 4.53 ( http://insecure.org ) at 2008-03-02 22:16 CET Interesting ports on busybox.net (140.211.166.42): Not shown: 1710 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 873/tcp open rsync Nmap done: 1 IP address (1 host up) scanned in 94.811 seconds but no web server.............. Ciao, Tito From martinb at zeelandnet.nl Sun Mar 2 16:39:30 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Mon, 3 Mar 2008 01:39:30 +0100 Subject: hush problem with the exec command Message-ID: If I try to use the exec from a script it will fail I?m not sure if this is a old bug because i never did use the hush as a active shell (I always did use lash 1.1) to reproduce i did: 1- make a simple script named testscript /paste #!/bin/hush export TVOFF=`echo hallo` echo $TVOFF /endpaste Run this from prompt will run ok If I run this with the exec my telnet is exiting If I try to run strace from a other console and I attach I get: --- SIGCHLD (Child exited) @ 0 (0) --- read(3, "hallo\r\n", 4000) = 7 select(4, [0 3], [1], NULL, NULL) = 2 (in [3], out [1]) write(1, "hallo\r\n", 7) = 7 read(3, 0x1cdafdf, 3993) = -1 EIO (Input/output error) write(1, "\r\n", 2) = 2 _exit(0) = ? Process 66 detached I repeat: if i just run this from console with: ./testscript its ok If I run this from console with: exec ./testscript It will exit / fail The problem for me is that i use the exec inside scripts and this is broken I guess its related to the NOMMU Would be nice if someone can give this a look, so I can finally get rid of lash and the old hush From hamish at cloud.net.au Sun Mar 2 18:43:47 2008 From: hamish at cloud.net.au (Hamish Moffatt) Date: Mon, 3 Mar 2008 13:43:47 +1100 Subject: Encryption In-Reply-To: <200803011800.04918.vapier@gentoo.org> References: <1204308927.6393.1.camel@kevin-laptop> <200803011650.01741.vapier@gentoo.org> <200803012324.34834.farmatito@tiscali.it> <200803011800.04918.vapier@gentoo.org> Message-ID: <20080303024347.GA2737@cloud.net.au> On Sat, Mar 01, 2008 at 06:00:04PM -0500, Mike Frysinger wrote: > in any case though, the ftp server would need to support the encryption as > well ... a random util in busybox isnt going to magically make it happen. Umm, what? Perhaps OP wants to encrypt a file, place it on a public server he controls, and have his busybox target download the file and decrypt it. In that case, encryption serves to prevent other people from accessing the file contents, even though they can download the file. I use the command-line utilities that accompany OpenSSL to do something similar. Hamish -- Hamish Moffatt VK3SB From bock at blacknet.de Mon Mar 3 00:24:09 2008 From: bock at blacknet.de (Goetz Bock) Date: Mon, 3 Mar 2008 09:24:09 +0100 Subject: Encryption In-Reply-To: <200803011650.01741.vapier@gentoo.org> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> Message-ID: <20080303082409.GA14356@priv.blacknet.de> On Sat, Mar 01 '08 at 16:50, Mike Frysinger wrote: > that's a stupid (and incorrect) analogy yes, it is a stupid analogy, but it's not incorrect. > if it's a public FTP, then there's nothing to be secured. if someone is > sniffing traffic and the traffic is encrypted, then the attacker merely needs > to go to the public FTP and fetch the files themselves. For me it was so very obviose that OP did not want to encrypt the traffic but the file. OP has a public ftp server (ftp.company.com) where he would like to place the update files. While there everyone can get the file, they should not be able to _USE_ them. So encryption is what he asked for. -- /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting \ / (c) 2007 Creative Commons, Attribution-ShareAlike 2.0 de X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] From pascal.bellard at ads-lu.com Mon Mar 3 02:23:29 2008 From: pascal.bellard at ads-lu.com (Pascal Bellard) Date: Mon, 3 Mar 2008 11:23:29 +0100 (CET) Subject: unlzma shrink In-Reply-To: <200803021553.48610.vda.linux@googlemail.com> References: <56256.192.168.10.101.1204464695.squirrel@193.253.62.30> <51918.192.168.10.101.1204465708.squirrel@193.253.62.30> <200803021553.48610.vda.linux@googlemail.com> Message-ID: <46360.192.168.10.101.1204539809.squirrel@193.253.62.30> With this patch it takes about the same time : function old new delta unpack_lzma_stream 2482 2400 -82 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-82) Total: -82 bytes $ grep LZMA_FAST .config CONFIG_FEATURE_LZMA_FAST=y $ ./busybox_old unlzma < ../linux-2.6.23.tar.lzma > /dev/null Using fallback suid method real 0m10.957s user 0m10.901s sys 0m0.044s $ ./busybox_unstripped unlzma < ../linux-2.6.23.tar.lzma > /dev/null Using fallback suid method real 0m10.781s user 0m10.713s sys 0m0.056s $ ./busybox_old unlzma < ../linux-2.6.23.tar.lzma | md5sum Using fallback suid method 853c87de6fe51e57a0b10eb4dbb12113 - $ ./busybox_unstripped unlzma < ../linux-2.6.23.tar.lzma | md5sum Using fallback suid method 853c87de6fe51e57a0b10eb4dbb12113 - > On Sunday 02 March 2008 14:48, Pascal Bellard wrote: >> next step: >> >> function old new delta >> unpack_lzma_stream 2398 2251 -147 >> ------------------------------------------------------------------------------ >> (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-147) Total: -147 >> bytes > > On this file: > > http://gnu.ethz.ch/lzma/linux/linux-2.6.23.tar.lzma > > "time unlzma /dev/null" > before patch I it takes ~8.75 seconds "user" time, > after patch it's going up to ~9.04 seconds. > -- > vda > -------------- next part -------------- A non-text attachment was scrubbed... Name: decompress_unlzma.u Type: application/octet-stream Size: 1963 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080303/3893149f/attachment.obj From khollan at daktronics.com Mon Mar 3 08:26:46 2008 From: khollan at daktronics.com (Kevin Holland) Date: Mon, 03 Mar 2008 10:26:46 -0600 Subject: Encryption In-Reply-To: <20080303082409.GA14356@priv.blacknet.de> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> <20080303082409.GA14356@priv.blacknet.de> Message-ID: <1204561606.6306.6.camel@kevin-laptop> Sorry I was gone this weekend, But this is statement is correct. I don't want to encrypt the traffic just the contents of a tar archive. The archive is on an ftp server where an anonymous person can log in and download anything. I just want to keep people from snooping around in the update files. I understand that someone determined to get into them probably will, I just want to keep out the less determined people. I want something where I can create the archive run it through an encryption utility, then upload it to the ftp server. Then my embedded board will download it and run it through its decryption utility and make the needed updates. I hope this is clearer to everyone. Kevin On Mon, 2008-03-03 at 09:24 +0100, Goetz Bock wrote: > On Sat, Mar 01 '08 at 16:50, Mike Frysinger wrote: > > that's a stupid (and incorrect) analogy > > yes, it is a stupid analogy, but it's not incorrect. > > > if it's a public FTP, then there's nothing to be secured. if someone is > > sniffing traffic and the traffic is encrypted, then the attacker merely needs > > to go to the public FTP and fetch the files themselves. > > For me it was so very obviose that OP did not want to encrypt the > traffic but the file. > > OP has a public ftp server (ftp.company.com) where he would like to > place the update files. While there everyone can get the file, they > should not be able to _USE_ them. So encryption is what he asked for. > -- > /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting > \ / (c) 2007 Creative Commons, Attribution-ShareAlike 2.0 de > X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] > / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From WHarms at bfs.de Mon Mar 3 08:43:42 2008 From: WHarms at bfs.de (walter harms) Date: Mon, 03 Mar 2008 17:43:42 +0100 Subject: Encryption In-Reply-To: <1204561606.6306.6.camel@kevin-laptop> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> <20080303082409.GA14356@priv.blacknet.de> <1204561606.6306.6.camel@kevin-laptop> Message-ID: <47CC2ABE.8030206@bfs.de> Kevin Holland wrote: > Sorry I was gone this weekend, > But this is statement is correct. I don't want to encrypt the traffic > just the contents of a tar archive. The archive is on an ftp server > where an anonymous person can log in and download anything. I just want > to keep people from snooping around in the update files. I understand > that someone determined to get into them probably will, I just want to > keep out the less determined people. > I want something where I can create the archive run it through an > encryption utility, then upload it to the ftp server. Then my embedded > board will download it and run it through its decryption utility and > make the needed updates. > > I hope this is clearer to everyone. > > Kevin what is about pgp ? let them download if they like. re, wh From Alexander at Kriegisch.name Mon Mar 3 09:30:11 2008 From: Alexander at Kriegisch.name (Alexander Kriegisch) Date: Mon, 03 Mar 2008 18:30:11 +0100 Subject: Encryption In-Reply-To: <1204561606.6306.6.camel@kevin-laptop> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> <20080303082409.GA14356@priv.blacknet.de> <1204561606.6306.6.camel@kevin-laptop> Message-ID: <47CC35A3.7070501@Kriegisch.name> Well, Kevin, now that you have answered yourself, we can stop speculating ans start offering suggestions. :-) If this is not too simple for your purpose, you can quite cheaply en-/decrypt files using 'tr' by scrambling arbitrary characters with a fixed key. This way you can either achieve a Caesar cipher or something more complicated, but definitely not strong encryption. Anyway, it would work. In case you are interested, I might hack a little sample for you. It should be enough to keep the lamers out. Regards -- Alexander Kriegisch Certified ScrumMaster http://scrum-master.de Kevin Holland: > I want something where I can create the archive run it through an > encryption utility, then upload it to the ftp server. Then my > embedded board will download it and run it through its decryption > utility and make the needed updates. From khollan at daktronics.com Mon Mar 3 10:17:11 2008 From: khollan at daktronics.com (Kevin Holland) Date: Mon, 03 Mar 2008 12:17:11 -0600 Subject: Encryption In-Reply-To: <47CC35A3.7070501@Kriegisch.name> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> <20080303082409.GA14356@priv.blacknet.de> <1204561606.6306.6.camel@kevin-laptop> <47CC35A3.7070501@Kriegisch.name> Message-ID: <1204568231.6306.10.camel@kevin-laptop> That sounds good, I'd like to see that as long as you think it will work on gziped archives. Thanks Kevin On Mon, 2008-03-03 at 18:30 +0100, Alexander Kriegisch wrote: > Well, Kevin, > > now that you have answered yourself, we can stop speculating ans start > offering suggestions. :-) If this is not too simple for your purpose, > you can quite cheaply en-/decrypt files using 'tr' by scrambling > arbitrary characters with a fixed key. This way you can either achieve a > Caesar cipher or something more complicated, but definitely not strong > encryption. Anyway, it would work. In case you are interested, I might > hack a little sample for you. It should be enough to keep the lamers out. > > Regards > -- > Alexander Kriegisch > Certified ScrumMaster > http://scrum-master.de > > Kevin Holland: > > I want something where I can create the archive run it through an > > encryption utility, then upload it to the ftp server. Then my > > embedded board will download it and run it through its decryption > > utility and make the needed updates. > From masta at perlgolf.de Mon Mar 3 10:17:55 2008 From: masta at perlgolf.de (Nico Erfurth) Date: Mon, 03 Mar 2008 19:17:55 +0100 Subject: [PATCH] udhcpd configfile parsing Message-ID: <47CC40D3.9040702@perlgolf.de> Hi, networking/udhcp/files.c has a nasty little mixup in read_opt. index_in_strings is called with the parameters swapped. So parsing of "opt" and "option" is broken. This patch fixes it. Nico --- busybox-1.9.1/networking/udhcp/files.c.org 2008-03-03 19:11:11.000000000 +0100 +++ busybox-1.9.1/networking/udhcp/files.c 2008-03-03 19:12:17.000000000 +0100 @@ -167,7 +167,7 @@ if (!opt) return 0; - idx = index_in_strings(opt, dhcp_option_strings); /* NB: was strcasecmp! */ + idx = index_in_strings(dhcp_option_strings, opt); /* NB: was strcasecmp! */ if (idx < 0) return 0; option = &dhcp_options[idx]; From GeorgeB at Linux.ca Mon Mar 3 10:35:22 2008 From: GeorgeB at Linux.ca (George Boudreau) Date: Mon, 3 Mar 2008 13:35:22 -0500 Subject: BB-1.91 patch applet problem Message-ID: Hi. System svn:uClibc, BB-1.91 I recently needed to apply a patch (using BB:patch) to an executable script. I was surprised when I found the permissions changed from 755 to 644. The same patch applied with GNU/patch does not affect the permissions. I did not have an opportunity to track down the problem and had to force the permission manually and continue. Could this be unique to my BB config? regards, George Boudreau From Alexander at Kriegisch.name Mon Mar 3 15:09:51 2008 From: Alexander at Kriegisch.name (Alexander Kriegisch) Date: Tue, 04 Mar 2008 00:09:51 +0100 Subject: Encryption In-Reply-To: <1204568231.6306.10.camel@kevin-laptop> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> <20080303082409.GA14356@priv.blacknet.de> <1204561606.6306.6.camel@kevin-laptop> <47CC35A3.7070501@Kriegisch.name> <1204568231.6306.10.camel@kevin-laptop> Message-ID: <47CC853F.8040501@Kriegisch.name> Well, this is extremely simple and not very refined, but try something like this: # Alphabets for en-/decoding (must contain same characters, only in different order) decoded_chars='A-Za-z0-9\n _;.:#+*/"!' encoded_chars='mn0opj\nYZk _;.rGJX6IHu12tsWVU5ql3a:e#+zFTEDRS4CBAyxwvd*b/f"9gQPONch8!iMKL7' # Encode file cat myfile.gz | tr "$decoded_chars" "$encoded_chars" > myfile.gz.enc # Decode file cat myfile.gz.enc | tr "$encoded_chars" "$decoded_chars" > myfile.gz.dec # Make sure decoded file equals original md5sum myfile.gz* e7720032bb3f6579d7e9cc2edcf1f9df myfile.gz e7720032bb3f6579d7e9cc2edcf1f9df myfile.gz.dec 4b630933f0ebf0af2e159bf41272a30f myfile.gz.enc Just a quick hack. Now you can start improving this little sample by adding more characters (even control characters or full 256-character alphabets), adding a shell function automatically creating keys from given alphabets etc. -- Alexander Kriegisch Certified ScrumMaster http://scrum-master.de Kevin Holland: > That sounds good, > I'd like to see that as long as you think it will work on gziped > archives. > Thanks > > Kevin > > On Mon, 2008-03-03 at 18:30 +0100, Alexander Kriegisch wrote: >> Well, Kevin, >> >> now that you have answered yourself, we can stop speculating ans start >> offering suggestions. :-) If this is not too simple for your purpose, >> you can quite cheaply en-/decrypt files using 'tr' by scrambling >> arbitrary characters with a fixed key. This way you can either achieve a >> Caesar cipher or something more complicated, but definitely not strong >> encryption. Anyway, it would work. In case you are interested, I might >> hack a little sample for you. It should be enough to keep the lamers out. From khollan at daktronics.com Mon Mar 3 15:16:06 2008 From: khollan at daktronics.com (Kevin Holland) Date: Mon, 03 Mar 2008 17:16:06 -0600 Subject: Encryption In-Reply-To: <47CC853F.8040501@Kriegisch.name> References: <1204308927.6393.1.camel@kevin-laptop> <200803010210.35455.vapier@gentoo.org> <20080301203625.GZ14356@priv.blacknet.de> <200803011650.01741.vapier@gentoo.org> <20080303082409.GA14356@priv.blacknet.de> <1204561606.6306.6.camel@kevin-laptop> <47CC35A3.7070501@Kriegisch.name> <1204568231.6306.10.camel@kevin-laptop> <47CC853F.8040501@Kriegisch.name> Message-ID: <1204586166.6306.15.camel@kevin-laptop> Thanks this should work great! Kevin On Tue, 2008-03-04 at 00:09 +0100, Alexander Kriegisch wrote: > Well, this is extremely simple and not very refined, > but try something like this: > > > # Alphabets for en-/decoding (must contain same characters, only in different order) > decoded_chars='A-Za-z0-9\n _;.:#+*/"!' > encoded_chars='mn0opj\nYZk _;.rGJX6IHu12tsWVU5ql3a:e#+zFTEDRS4CBAyxwvd*b/f"9gQPONch8!iMKL7' > > # Encode file > cat myfile.gz | tr "$decoded_chars" "$encoded_chars" > myfile.gz.enc > # Decode file > cat myfile.gz.enc | tr "$encoded_chars" "$decoded_chars" > myfile.gz.dec > > # Make sure decoded file equals original > md5sum myfile.gz* > e7720032bb3f6579d7e9cc2edcf1f9df myfile.gz > e7720032bb3f6579d7e9cc2edcf1f9df myfile.gz.dec > 4b630933f0ebf0af2e159bf41272a30f myfile.gz.enc > > > Just a quick hack. > > Now you can start improving this little sample by adding more > characters (even control characters or full 256-character alphabets), > adding a shell function automatically creating keys from given > alphabets etc. > > -- > Alexander Kriegisch > Certified ScrumMaster > http://scrum-master.de > > > > Kevin Holland: > > That sounds good, > > I'd like to see that as long as you think it will work on gziped > > archives. > > Thanks > > > > Kevin > > > > On Mon, 2008-03-03 at 18:30 +0100, Alexander Kriegisch wrote: > >> Well, Kevin, > >> > >> now that you have answered yourself, we can stop speculating ans start > >> offering suggestions. :-) If this is not too simple for your purpose, > >> you can quite cheaply en-/decrypt files using 'tr' by scrambling > >> arbitrary characters with a fixed key. This way you can either achieve a > >> Caesar cipher or something more complicated, but definitely not strong > >> encryption. Anyway, it would work. In case you are interested, I might > >> hack a little sample for you. It should be enough to keep the lamers out. > From michele.sanges at otomelara.it Tue Mar 4 02:51:46 2008 From: michele.sanges at otomelara.it (Michele Sanges) Date: Tue, 04 Mar 2008 11:51:46 +0100 Subject: [patch] - bbsplash In-Reply-To: <200803012208.59101.vda.linux@googlemail.com> References: <1202921878.7846.4.camel@pigreco> <200802251757.36565.vda.linux@googlemail.com> <1204206136.30494.4.camel@pigreco> <200803012208.59101.vda.linux@googlemail.com> Message-ID: <1204627906.2662.22.camel@pigreco> Il giorno sab, 01/03/2008 alle 22.08 +0100, Denys Vlasenko ha scritto: > Somebody said it works for them, but slowly. > Let's take a look. > Please speed up "filled rectangle" function similarly. I change the code for 'fb_drawfullrectangle' function in a similar way, but I think that isn't slow the drawing of the progress bar, but it's slow the initial drawing of the image. Probably the ppm format is not exactly the most suitable because it's not compressed and so too big. Christian, can you confirm this? In the future I would like manage other images formats. > pinifile = xfopen("/etc/bbsplash/bbsplash.ini", "r"); > > Can this be a command line switch? > "bbsplash -i -f -d " etc... Ok, I add this options. > sprintf(G.strsplash_theme, "/etc/bbsplash/%s", pvalue); > > Use char *str instead of char str[FIXED_SIZE] for it, and do > > G.strsplash_theme = xasprintf(...); > > This way you use as much memory as needed, and don't have artificial > size limit. Ok > I rebased the patch to current svn, please see it attached. > fb_drawrectangle() is edited, the rest is not touched > (except for s/PTR_TO_GLOBALS/SET_PTR_TO_GLOBALS/). > > You can download current svn and base your work on it > using this command: > > svn co svn://busybox.net/trunk/busybox I'm behind a firewall that does not allow to contact the svn port. I will base the work on the latest daily snapshot. Regards. Michele From masta at perlgolf.de Tue Mar 4 03:42:12 2008 From: masta at perlgolf.de (Nico Erfurth) Date: Tue, 04 Mar 2008 12:42:12 +0100 Subject: [patch] - bbsplash In-Reply-To: <1204627906.2662.22.camel@pigreco> References: <1202921878.7846.4.camel@pigreco> <200802251757.36565.vda.linux@googlemail.com> <1204206136.30494.4.camel@pigreco> <200803012208.59101.vda.linux@googlemail.com> <1204627906.2662.22.camel@pigreco> Message-ID: <47CD3594.4020609@perlgolf.de> Michele Sanges schrieb: >> Please speed up "filled rectangle" function similarly. > > I change the code for 'fb_drawfullrectangle' function in a similar way, > but I think that isn't slow the drawing of the progress bar, but it's > slow the initial drawing of the image. > Probably the ppm format is not exactly the most suitable because it's > not compressed and so too big. I think the problem is that the image is drawn pixel by pixel. This is always slow. Nico From christian.michon at gmail.com Tue Mar 4 05:50:58 2008 From: christian.michon at gmail.com (Christian MICHON) Date: Tue, 4 Mar 2008 14:50:58 +0100 Subject: [patch] - bbsplash In-Reply-To: <1204627906.2662.22.camel@pigreco> References: <1202921878.7846.4.camel@pigreco> <200802251757.36565.vda.linux@googlemail.com> <1204206136.30494.4.camel@pigreco> <200803012208.59101.vda.linux@googlemail.com> <1204627906.2662.22.camel@pigreco> Message-ID: <46d6db660803040550k86754bby4d84656963401b23@mail.gmail.com> On 3/4/08, Michele Sanges wrote: > > Please speed up "filled rectangle" function similarly. > > I change the code for 'fb_drawfullrectangle' function in a similar way, > but I think that isn't slow the drawing of the progress bar, but it's > slow the initial drawing of the image. > Probably the ppm format is not exactly the most suitable because it's > not compressed and so too big. > > Christian, can you confirm this? yes, I can confirm this is the case: the original drawing is the slowest part. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! From pgf at brightstareng.com Tue Mar 4 06:54:57 2008 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 04 Mar 2008 09:54:57 -0500 Subject: [patch] - bbsplash applet In-Reply-To: michele.sanges's message of Wed, 27 Feb 2008 08:55:18 +0100. <1204098918.2657.10.camel@pigreco> Message-ID: <25059.1204642497@brightstareng.com> > About the slow drawing, probably the ppm format is not exactly the most > suitable because it's not compressed and so too big. > In the future I would like to manage: > -- other images formats no -- there is no reason for the box to have to interpret image formats at boot time, and you shouldn't force busybox bloat this way. you should replace ppm with just one image format -- a raw binary format that exactly matches the framebuffer format. your code that loads the fb should move into a separate utility that creates such a file. then the raw splash images can be generated offline. and your boot-time code could perhaps be reduced to "dd /dev/fb0". the code to generate the raw images can be in busybox, if you like, but it should be possible to build busybox with bbsplash, and without bbsplash_image_prepare, or whatever you call the raw file converter. there may even already be a pnm utility to convert pnm images to raw rgb data, though i don't think there was, last time i looked -- i had to write my own pnmto565.c (which looked much like your drawimage() routine). paul =--------------------- paul fox, pgf at brightstareng.com From Ralf.Friedl at online.de Tue Mar 4 07:15:14 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Tue, 04 Mar 2008 16:15:14 +0100 Subject: [patch] - bbsplash applet In-Reply-To: <25059.1204642497@brightstareng.com> References: <25059.1204642497@brightstareng.com> Message-ID: <47CD6782.2060704@online.de> Paul Fox wrote: > you should replace ppm with just one image format -- a raw binary > format that exactly matches the framebuffer format. > > your code that loads the fb should move into a separate utility > that creates such a file. then the raw splash images can be > generated offline. and your boot-time code could perhaps be > reduced to "dd /dev/fb0". > > the code to generate the raw images can be in busybox, if you > like, but it should be possible to build busybox with bbsplash, > and without bbsplash_image_prepare, or whatever you call the raw > file converter. there may even already be a pnm utility to > convert pnm images to raw rgb data, though i don't think there > was, last time i looked -- i had to write my own pnmto565.c (which > looked much like your drawimage() routine). > The binary PPM format as almost as raw as it can get, while keeping information about the file size. The conversion of binary PPM to raw rgb can normally be done with "tail -n +4", although a program "ppmtorgb3" is also available for files with unusual line breaks or bit depths. Regards Ralf Friedl From pgf at brightstareng.com Tue Mar 4 07:41:36 2008 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 04 Mar 2008 10:41:36 -0500 Subject: [patch] - bbsplash applet In-Reply-To: Ralf.Friedl's message of Tue, 04 Mar 2008 16:15:14 +0100. <47CD6782.2060704@online.de> Message-ID: <26197.1204645296@brightstareng.com> ralf wrote: > Paul Fox wrote: > > you should replace ppm with just one image format -- a raw binary > > format that exactly matches the framebuffer format. ... > The binary PPM format as almost as raw as it can get, while keeping > information about the file size. i don't understand how a single PPM binary format can match various framebuffer depths. (and -- i may be wrong on this -- don't framebuffers differ in pixel encoding, as well? RGB vs. BGR, 565 vs. 556, etc?) > The conversion of binary PPM to raw rgb can normally be done with "tail > -n +4", although a program "ppmtorgb3" is also available for files with > unusual line breaks or bit depths. again, i don't understand. ppmtorgb3 creates three files. how does this help with writing a framebuffer? paul =--------------------- paul fox, pgf at brightstareng.com From Ralf.Friedl at online.de Tue Mar 4 07:54:11 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Tue, 04 Mar 2008 16:54:11 +0100 Subject: [patch] - bbsplash applet In-Reply-To: <26197.1204645296@brightstareng.com> References: <26197.1204645296@brightstareng.com> Message-ID: <47CD70A3.7010604@online.de> Paul Fox wrote: > ralf wrote: > > Paul Fox wrote: > > > you should replace ppm with just one image format -- a raw binary > > > format that exactly matches the framebuffer format. > ... > > The binary PPM format as almost as raw as it can get, while keeping > > information about the file size. > > i don't understand how a single PPM binary format can match various > framebuffer depths. (and -- i may be wrong on this -- don't framebuffers > differ in pixel encoding, as well? RGB vs. BGR, 565 vs. 556, etc?) > PPM is normally RGB 888. I assumed that is also the format of the frame buffer, as these days every graphics adapter should have enough memory for 24 bit. > > The conversion of binary PPM to raw rgb can normally be done with "tail > > -n +4", although a program "ppmtorgb3" is also available for files with > > unusual line breaks or bit depths. > > again, i don't understand. ppmtorgb3 creates three files. how > does this help with writing a framebuffer? I was wrong in my assumption about ppmtorgb3. Regards Ralf Friedl From pgf at brightstareng.com Tue Mar 4 08:24:05 2008 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 04 Mar 2008 11:24:05 -0500 Subject: [patch] - bbsplash applet In-Reply-To: Ralf.Friedl's message of Tue, 04 Mar 2008 16:54:11 +0100. <47CD70A3.7010604@online.de> Message-ID: <27523.1204647845@brightstareng.com> > > > > i don't understand how a single PPM binary format can match various > > framebuffer depths. (and -- i may be wrong on this -- don't framebuffers > > differ in pixel encoding, as well? RGB vs. BGR, 565 vs. 556, etc?) > > > PPM is normally RGB 888. > I assumed that is also the format of the frame buffer, as these days > every graphics adapter should have enough memory for 24 bit. but we're talking about embedded systems. of, at least, that's what i talk about when i talk about busybox. 16-bit colordepths and non-standard pixel orders are fairly common, and will be, for some time. in fact, the code from the current bbsplash patch is obviously for a 565 display: + thispix = (((short)pix[0] << 8) & 0xf800) + | (((short)pix[1] << 3) & 0x07e0) + | ((short)pix[2] >> 3); + paul =--------------------- paul fox, pgf at brightstareng.com From WHarms at bfs.de Tue Mar 4 09:34:25 2008 From: WHarms at bfs.de (walter harms) Date: Tue, 04 Mar 2008 18:34:25 +0100 Subject: (PATCH) latest-snapshot: =?UTF-8?B?4oCYREVCVUfigJkgdW5kZWNsYXJlZA==?= =?UTF-8?B?IA==?= Message-ID: <47CD8821.4000103@bfs.de> libbb/getpty.c: In function ?getpty?: libbb/getpty.c:43: error: ?DEBUG? undeclared (first use in this function) libbb/getpty.c:43: error: (Each undeclared identifier is reported only once libbb/getpty.c:43: error: for each function it appears in.) make[1]: *** [libbb/getpty.o] Fehler 1 --- libbb/getpty.c.org 2008-03-04 18:31:08.000000000 +0100 +++ libbb/getpty.c 2008-03-04 18:31:26.000000000 +0100 @@ -40,7 +40,7 @@ } for (j = 0; j < 16; j++) { line[9] = j < 10 ? j + '0' : j - 10 + 'a'; - if (DEBUG) + if (CONFIG_DEBUG) fprintf(stderr, "Trying to open device: %s\n", line); p = open(line, O_RDWR | O_NOCTTY); if (p >= 0) { From dronnikov at gmail.com Tue Mar 4 12:44:24 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Tue, 04 Mar 2008 12:44:24 -0800 (PST) Subject: =?utf-8?B?VEZUUEQ6IG5ldyBhcHBsZXQ=?= Message-ID: <47cdb4a8.2315300a.2af2.09ac@mx.google.com> Added bare bones TFTP Daemon. +285 bytes. Tested with BB tftp. Works. Plz, do consider. Any requests for features and/or comments are welcome. -- Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: tftpd.patch Type: application/octet-stream Size: 4371 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080304/1cba5259/attachment.obj From michele.sanges at otomelara.it Wed Mar 5 05:24:24 2008 From: michele.sanges at otomelara.it (Michele Sanges) Date: Wed, 05 Mar 2008 14:24:24 +0100 Subject: bbsplash applet In-Reply-To: <25059.1204642497@brightstareng.com> References: <25059.1204642497@brightstareng.com> Message-ID: <1204723464.2803.71.camel@pigreco> Thanks to all for the suggestions. As has been said by others, the ppm is already a raw format (it has only a small header) with three bytes for pixel (RGB). Generally the framebuffer is set to 16 bits per pixel, with data packaged in 565 format. Il giorno mar, 04/03/2008 alle 09.54 -0500, Paul Fox ha scritto: > no -- there is no reason for the box to have to interpret image > formats at boot time, and you shouldn't force busybox bloat this > way. > > you should replace ppm with just one image format -- a raw binary > format that exactly matches the framebuffer format. > > your code that loads the fb should move into a separate utility > that creates such a file. then the raw splash images can be > generated offline. and your boot-time code could perhaps be > reduced to "dd /dev/fb0". I thought that was useful convert the ppm data runtime in order to be independent from other tools. Before changing further the code I would like a confirmation that I must remove the function that performs the conversion between ppm and the framebuffer format. In addition, it should be created an applet that performs this conversion or we rely on external tools? Regards. Michele From michele.sanges at otomelara.it Wed Mar 5 05:27:09 2008 From: michele.sanges at otomelara.it (Michele Sanges) Date: Wed, 05 Mar 2008 14:27:09 +0100 Subject: mdev problem Message-ID: <1204723629.2803.74.camel@pigreco> I have a problem with 'mdev' used for dynamic device update: - system based on kernel 2.6.23, busybox 1.9.1 and with mdev installed as hotplug program (echo /sbin/mdev > /proc/sys/kernel/hotplug) - system boots from a usb stick (/dev/sda1); it has also a disk on chip disk seen as /dev/sdb. The disk on chip has initially one only primary partion; after booting I see the device /dev/sdb1 so the command 'mdev -s' works fine. With fdisk I remove this partion and then I create two primary partion --> I see only the device /dev/sdb2. So I created 'my_hotplug_program.sh' script: #!/bin/sh /usr/bin/env >> /root/hotplug_env.txt and installed it as hotplug program: # echo /root/my_hotplug_program.sh > /proc/sys/kernel/hotplug With the above sequence of operation, the hotplug_env.txt file contains: ACTION=add HOME=/ SEQNUM=390 MAJOR=8 DEVPATH=/block/sdb/sdb1 SUBSYSTEM=block PATH=/sbin:/bin:/usr/sbin:/usr/bin PHYSDEVPATH=/devices/pci0000:00/0000:00:07.1/host2/target2:0:0/2:0:0:0 MINOR=17 PHYSDEVDRIVER=sd PWD=/ PHYSDEVBUS=scsi ACTION=remove HOME=/ SEQNUM=389 MAJOR=8 DEVPATH=/block/sdb/sdb1 SUBSYSTEM=block PATH=/sbin:/bin:/usr/sbin:/usr/bin PHYSDEVPATH=/devices/pci0000:00/0000:00:07.1/host2/target2:0:0/2:0:0:0 MINOR=17 PHYSDEVDRIVER=sd PWD=/ PHYSDEVBUS=scsi ACTION=add HOME=/ SEQNUM=391 MAJOR=8 DEVPATH=/block/sdb/sdb2 SUBSYSTEM=block PATH=/sbin:/bin:/usr/sbin:/usr/bin PHYSDEVPATH=/devices/pci0000:00/0000:00:07.1/host2/target2:0:0/2:0:0:0 MINOR=18 PHYSDEVDRIVER=sd PWD=/ PHYSDEVBUS=scsi It seems that events don't arrive in order; does 'mdev' take into account the variable SEQNUM? Thanks. Michele From pgf at brightstareng.com Wed Mar 5 06:08:12 2008 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 05 Mar 2008 09:08:12 -0500 Subject: bbsplash applet In-Reply-To: michele.sanges's message of Wed, 05 Mar 2008 14:24:24 +0100. <1204723464.2803.71.camel@pigreco> Message-ID: <8333.1204726092@brightstareng.com> michele wrote: > Il giorno mar, 04/03/2008 alle 09.54 -0500, Paul Fox ha scritto: > > no -- there is no reason for the box to have to interpret image > > formats at boot time, and you shouldn't force busybox bloat this > > way. > > > > you should replace ppm with just one image format -- a raw binary > > format that exactly matches the framebuffer format. > > > > your code that loads the fb should move into a separate utility > > that creates such a file. then the raw splash images can be > > generated offline. and your boot-time code could perhaps be > > reduced to "dd /dev/fb0". > > > I thought that was useful convert the ppm data runtime in order to be > independent from other tools. yes, you're right -- it is. and since it's such a primitive format, and the code to interpret it is so small, it might as well remain. i was mainly thinking that you shouldn't add code to support PNG/JPEG/GIF/etc -- just add one more format -- 565 for now, but later which can be configured to match the framebuffer of the box busybox is running on. that will give maximum performance, and will be very flexible. if you provide the conversion tool, i suppose it should be an applet that can be configured independently of bbsplash itself. but if you find a common tool that can do the conversion instead (for instance, can "convert" from ImageMagick do it? can the Gimp?), then you don't need to provide the conversion applet -- anyone working with splash screens will already have graphical tools available, and there's no real reason to provide another. (just my opinion). paul =--------------------- paul fox, pgf at brightstareng.com From krahn at niehs.nih.gov Wed Mar 5 08:54:12 2008 From: krahn at niehs.nih.gov (Joe Krahn) Date: Wed, 05 Mar 2008 11:54:12 -0500 Subject: [PATCH] compatibility fix for compilers with __NO_INLINE__ Message-ID: <47CED034.9080403@niehs.nih.gov> Some GCC compilers do not honor inlining, in which case they are supposed to define __NO_INLINE__. In that case, inline keywords can generate a lot of warnings. This patch skips the inline declarations for those compilers. --- busybox-1.9.1.orig/include/platform.h 2008-02-12 11:03:10.000000000 -0500 +++ busybox-1.9.1/include/platform.h 2008-03-04 11:56:27.000000000 -0500 @@ -52,7 +52,7 @@ # define ATTRIBUTE_NORETURN __attribute__ ((__noreturn__)) # define ATTRIBUTE_PACKED __attribute__ ((__packed__)) # define ATTRIBUTE_ALIGNED(m) __attribute__ ((__aligned__(m))) -# if __GNUC_PREREQ (3,0) +#if __GNUC_PREREQ (3,0) && !defined(__NO_INLINE__) # define ALWAYS_INLINE __attribute__ ((always_inline)) inline /* I've seen a toolchain where I needed __noinline__ instead of noinline */ # define NOINLINE __attribute__((__noinline__)) From krahn at niehs.nih.gov Wed Mar 5 08:57:09 2008 From: krahn at niehs.nih.gov (Joe Krahn) Date: Wed, 05 Mar 2008 11:57:09 -0500 Subject: [PATCH] fix 'auto' declaration in findutils/find.c (only for warning messages) Message-ID: <47CED0E5.1070600@niehs.nih.gov> In findutils/find.c, the 'static' keyword was dropped, for GCC 4.x compatibility. The right keyword is 'auto', which I have added here. On my 3.0 and 4.2.0 compilers, I still get a no-prototype warning even with the 'auto' keyword, so I also inserted a prototype just before the actual function. It looks a bit silly, but it seems to be what gcc wants. Here's a diff: *** busybox-1.9.1.orig/findutils/find.c 2008-02-12 11:03:12.000000000 -0500 --- busybox-1.9.1/findutils/find.c 2008-03-04 12:19:13.000000000 -0500 *************** *** 513,519 **** USE_FEATURE_FIND_NOT( bool invert_flag = 0; ) /* 'static' doesn't work here! (gcc 4.1.2) */ ! action* alloc_action(int sizeof_struct, action_fp f) { action *ap; appp[cur_group] = xrealloc(appp[cur_group], (cur_action+2) * sizeof(*appp)); --- 513,521 ---- USE_FEATURE_FIND_NOT( bool invert_flag = 0; ) /* 'static' doesn't work here! (gcc 4.1.2) */ ! /* GCC may give a warning without the prototype. */ ! auto action* alloc_action(int sizeof_struct, action_fp f); ! auto action* alloc_action(int sizeof_struct, action_fp f) { action *ap; appp[cur_group] = xrealloc(appp[cur_group], (cur_action+2) * sizeof(*appp)); From krahn at niehs.nih.gov Wed Mar 5 09:02:44 2008 From: krahn at niehs.nih.gov (Joe Krahn) Date: Wed, 05 Mar 2008 12:02:44 -0500 Subject: [PATCH] missing onditionals for GET/SET QDMA Message-ID: <47CED234.4000002@niehs.nih.gov> There are some conditionals to check for QDMA definitions in miscutils/hdparm.c, but they are incomplete. This is needed to get DMA controls when one or both QDMA features are absent from the target OS. Like the existing conditionals, I assume that SET_QDMA only exists if GET_QDMA does, but the latter can be available by itself. *** busybox-1.9.1.orig/miscutils/hdparm.c 2008-02-12 11:03:10.000000000 -0500 --- busybox-1.9.1/miscutils/hdparm.c 2008-03-04 12:38:00.000000000 -0500 *************** *** 245,251 **** smallint set_readonly, get_readonly; smallint set_unmask, get_unmask; smallint set_mult, get_mult; - smallint set_dma_q, get_dma_q; smallint set_nowerr, get_nowerr; smallint set_keep, get_keep; smallint set_io32bit, get_io32bit; --- 245,250 ---- *************** *** 254,263 **** unsigned long readonly; unsigned long unmask; unsigned long mult; - unsigned long dma_q; unsigned long nowerr; unsigned long keep; unsigned long io32bit; #if ENABLE_FEATURE_HDPARM_HDIO_GETSET_DMA unsigned long dma; smallint set_dma, get_dma; --- 253,268 ---- unsigned long readonly; unsigned long unmask; unsigned long mult; unsigned long nowerr; unsigned long keep; unsigned long io32bit; + #ifdef HDIO_GET_QDMA + smallint get_dma_q; + #ifdef HDIO_SET_QDMA + smallint set_dma_q; + unsigned long dma_q; + #endif + #endif #if ENABLE_FEATURE_HDPARM_HDIO_GETSET_DMA unsigned long dma; smallint set_dma, get_dma; *************** *** 1604,1613 **** --- 1609,1620 ---- ioctl_or_warn(fd, HDIO_SET_DMA, (int *)dma); } #endif /* FEATURE_HDPARM_HDIO_GETSET_DMA */ + #ifdef HDIO_SET_QDMA if (set_dma_q) { print_flag_on_off(get_dma_q, "DMA queue_depth", dma_q); ioctl_or_warn(fd, HDIO_SET_QDMA, (int *)dma_q); } + #endif if (set_nowerr) { print_flag_on_off(get_nowerr, "nowerr", nowerr); ioctl_or_warn(fd, HDIO_SET_NOWERR, (int *)nowerr); *************** *** 1780,1789 **** --- 1787,1798 ---- } } #endif + #ifdef HDIO_GET_QDMA if (get_dma_q) { if(!ioctl_or_warn(fd, HDIO_GET_QDMA, &parm)) print_value_on_off("queue_depth", parm); } + #endif if (get_keep) { if(!ioctl_or_warn(fd, HDIO_GET_KEEPSETTINGS, &parm)) print_value_on_off("keepsettings", parm); From krahn at niehs.nih.gov Wed Mar 5 09:16:26 2008 From: krahn at niehs.nih.gov (Joe Krahn) Date: Wed, 05 Mar 2008 12:16:26 -0500 Subject: [PATCH] print format correctness for uid, gid, pid, mode in "util-linux/ipcs.c" Message-ID: <47CED56A.2070708@niehs.nih.gov> In "util-linux/ipcs.c", gid, uid, pid and mode values are all assumed to be default-size ints. I have patched the formats to use long ints, and cast all arguments to longs. This seems to be the common approach. The one exception is that I cast arguments with (mode&0777) as default-size ints. In reality, most busybox target platforms have the same size for int and long-int, but there are some 64-bit platforms where these values really are larger than default ints. The only way to be exact is to use macros as in , which gets rather ugly. OTOH, that approach might avoid unnecessary casting in some case, and might really be a better fit for the very-light-weight design goal. --- busybox-1.9.1.orig/util-linux/ipcs.c 2008-02-12 11:03:13.000000000 -0500 +++ busybox-1.9.1/util-linux/ipcs.c 2008-03-04 13:34:30.000000000 -0500 @@ -97,21 +97,21 @@ struct passwd *pw; struct group *gr; - printf("%-10d %-10o", id, ipcp->mode & 0777); + printf("%-10d %-10o", id, (unsigned)ipcp->mode & 0777); pw = getpwuid(ipcp->cuid); if (pw) printf(" %-10s", pw->pw_name); - else printf(" %-10d", ipcp->cuid); + else printf(" %-10ld", (long)ipcp->cuid); gr = getgrgid(ipcp->cgid); if (gr) printf(" %-10s", gr->gr_name); - else printf(" %-10d", ipcp->cgid); + else printf(" %-10ld", (long)ipcp->cgid); pw = getpwuid(ipcp->uid); if (pw) printf(" %-10s", pw->pw_name); - else printf(" %-10d", ipcp->uid); + else printf(" %-10ld", (long)ipcp->uid); gr = getgrgid(ipcp->gid); if (gr) printf(" %-10s\n", gr->gr_name); - else printf(" %-10d\n", ipcp->gid); + else printf(" %-10ld\n", (long)ipcp->gid); } @@ -201,7 +201,7 @@ if (pw) printf("%-10d %-10.10s", shmid, pw->pw_name); else - printf("%-10d %-10d", shmid, ipcp->uid); + printf("%-10d %-10ld", shmid, (long)ipcp->uid); /* ctime uses static buffer: use separate calls */ printf(" %-20.16s", shmseg.shm_atime ? ctime(&shmseg.shm_atime) + 4 : "Not set"); @@ -214,8 +214,8 @@ if (pw) printf("%-10d %-10.10s", shmid, pw->pw_name); else - printf("%-10d %-10d", shmid, ipcp->uid); - printf(" %-10d %-10d\n", shmseg.shm_cpid, shmseg.shm_lpid); + printf("%-10d %-10ld", shmid, (long)ipcp->uid); + printf(" %-10ld %-10ld\n", (long)shmseg.shm_cpid, (long)shmseg.shm_lpid); break; default: @@ -223,8 +223,8 @@ if (pw) printf("%-10d %-10.10s", shmid, pw->pw_name); else - printf("%-10d %-10d", shmid, ipcp->uid); - printf(" %-10o %-10lu %-10ld %-6s %-6s\n", ipcp->mode & 0777, + printf("%-10d %-10ld", shmid, (long)ipcp->uid); + printf(" %-10o %-10lu %-10ld %-6s %-6s\n", (unsigned)ipcp->mode & 0777, /* * earlier: int, Austin has size_t */ @@ -234,8 +234,8 @@ * Austin has shmatt_t */ (long) shmseg.shm_nattch, - ipcp->mode & SHM_DEST ? "dest" : " ", - ipcp->mode & SHM_LOCKED ? "locked" : " "); + (unsigned long)ipcp->mode & SHM_DEST ? "dest" : " ", + (unsigned long)ipcp->mode & SHM_LOCKED ? "locked" : " "); break; } } @@ -318,7 +318,7 @@ if (pw) printf("%-8d %-10.10s", semid, pw->pw_name); else - printf("%-8d %-10d", semid, ipcp->uid); + printf("%-8d %-10ld", semid, (long)ipcp->uid); /* ctime uses static buffer: use separate calls */ printf(" %-26.24s", semary.sem_otime ? ctime(&semary.sem_otime) : "Not set"); @@ -333,8 +333,8 @@ if (pw) printf("%-10d %-10.9s", semid, pw->pw_name); else - printf("%-10d %-9d", semid, ipcp->uid); - printf(" %-10o %-10ld\n", ipcp->mode & 0777, + printf("%-10d %-9ld", semid, (long)ipcp->uid); + printf(" %-10o %-10ld\n", (unsigned)ipcp->mode & 0777, /* * glibc-2.1.3 and earlier has unsigned short; * glibc-2.1.91 has variation between @@ -420,7 +420,7 @@ if (pw) printf("%-8d %-10.10s", msqid, pw->pw_name); else - printf("%-8d %-10d", msqid, ipcp->uid); + printf("%-8d %-10ld", msqid, (long)ipcp->uid); printf(" %-20.16s", msgque.msg_stime ? ctime(&msgque.msg_stime) + 4 : "Not set"); printf(" %-20.16s", msgque.msg_rtime @@ -432,7 +432,7 @@ if (pw) printf("%-8d %-10.10s", msqid, pw->pw_name); else - printf("%-8d %-10d", msqid, ipcp->uid); + printf("%-8d %-10ld", msqid, (long)ipcp->uid); printf(" %5d %5d\n", msgque.msg_lspid, msgque.msg_lrpid); break; @@ -441,8 +441,8 @@ if (pw) printf("%-10d %-10.10s", msqid, pw->pw_name); else - printf("%-10d %-10d", msqid, ipcp->uid); - printf(" %-10o %-12ld %-12ld\n", ipcp->mode & 0777, + printf("%-10d %-10ld", msqid, (long)ipcp->uid); + printf(" %-10o %-12ld %-12ld\n", (unsigned)ipcp->mode & 0777, /* * glibc-2.1.3 and earlier has unsigned short; * glibc-2.1.91 has variation between @@ -467,13 +467,13 @@ } printf("\nShared memory Segment shmid=%d\n" - "uid=%d\tgid=%d\tcuid=%d\tcgid=%d\n" - "mode=%#o\taccess_perms=%#o\n" - "bytes=%ld\tlpid=%d\tcpid=%d\tnattch=%ld\n", + "uid=%ld\tgid=%ld\tcuid=%ld\tcgid=%ld\n" + "mode=%#lo\taccess_perms=%#o\n" + "bytes=%ld\tlpid=%ld\tcpid=%ld\tnattch=%ld\n", shmid, - ipcp->uid, ipcp->gid, ipcp->cuid, ipcp->cgid, - ipcp->mode, ipcp->mode & 0777, - (long) shmds.shm_segsz, shmds.shm_lpid, shmds.shm_cpid, + (long)ipcp->uid, (long)ipcp->gid, (long)ipcp->cuid, (long)ipcp->cgid, + (unsigned long)ipcp->mode, (unsigned)ipcp->mode & 0777, + (long) shmds.shm_segsz, (long)shmds.shm_lpid, (long)shmds.shm_cpid, (long) shmds.shm_nattch); printf("att_time=%-26.24s\n", shmds.shm_atime ? ctime(&shmds.shm_atime) : "Not set"); @@ -494,9 +494,10 @@ } printf("\nMessage Queue msqid=%d\n" - "uid=%d\tgid=%d\tcuid=%d\tcgid=%d\tmode=%#o\n" + "uid=%ld\tgid=%ld\tcuid=%ld\tcgid=%ld\tmode=%#lo\n" "cbytes=%ld\tqbytes=%ld\tqnum=%ld\tlspid=%d\tlrpid=%d\n", - msqid, ipcp->uid, ipcp->gid, ipcp->cuid, ipcp->cgid, ipcp->mode, + msqid, (long)ipcp->uid, (long)ipcp->gid, (long)ipcp->cuid, + (long)ipcp->cgid, (unsigned long)ipcp->mode, /* * glibc-2.1.3 and earlier has unsigned short; * glibc-2.1.91 has variation between @@ -528,13 +529,13 @@ } printf("\nSemaphore Array semid=%d\n" - "uid=%d\t gid=%d\t cuid=%d\t cgid=%d\n" - "mode=%#o, access_perms=%#o\n" + "uid=%ld\t gid=%ld\t cuid=%ld\t cgid=%ld\n" + "mode=%#lo, access_perms=%#o\n" "nsems = %ld\n" "otime = %-26.24s\n", semid, - ipcp->uid, ipcp->gid, ipcp->cuid, ipcp->cgid, - ipcp->mode, ipcp->mode & 0777, + (long)ipcp->uid, (long)ipcp->gid, (long)ipcp->cuid, (long)ipcp->cgid, + (unsigned long)ipcp->mode, (unsigned)ipcp->mode & 0777, (long) semds.sem_nsems, semds.sem_otime ? ctime(&semds.sem_otime) : "Not set"); printf("ctime = %-26.24s\n" From krahn at niehs.nih.gov Wed Mar 5 09:58:33 2008 From: krahn at niehs.nih.gov (Joe Krahn) Date: Wed, 05 Mar 2008 12:58:33 -0500 Subject: [PATCH] Segfault in INIT_G() due to insufficient 'Magic'? Message-ID: <47CEDF49.6000504@niehs.nih.gov> The 1.9.1 release exposes a bug that seems to affect a lot of gcc 3.x compilers. I get segfaults with a large number of applets, due to a compiler bug in handling (*ptr_to_globals). I found this recent problem report which demonstrates the compiler being at fault: http://bugs.busybox.net/view.php?id=2344 I also found this report on OpenWRT indicating that busybox 1.7.2 probably exposes the same bug: https://dev.openwrt.org/ticket/2627 I was just going to post this to help other users be aware of the problem, but I found this in "include/libbb.h" which makes me wonder if it is not entirely the toolchain's fault: /* '*const' ptr makes gcc optimize code much better. * Magic prevents ptr_to_globals from going into rodata. * If you want to assign a value, use PTR_TO_GLOBALS = xxx */ extern struct globals *const ptr_to_globals; #define PTR_TO_GLOBALS (*(struct globals**)&ptr_to_globals) Is it possible that GCC 4.x is a prerequisite for this 'Magic', and that it is not really standard-conforming? I added the following patch which seems to fix the problem, although I have not done very thorough testing yet. Maybe someone with more knowledge of GCC internals and ptr_to_globals can do a better job. I am really just guessing. --- busybox-1.9.1.orig/include/libbb.h 2008-02-12 11:10:25.000000000 -0500 +++ busybox-1.9.1/include/libbb.h 2008-03-05 12:40:57.000000000 -0500 @@ -1137,7 +1137,11 @@ /* '*const' ptr makes gcc optimize code much better. * Magic prevents ptr_to_globals from going into rodata. * If you want to assign a value, use PTR_TO_GLOBALS = xxx */ +#if __GNUC_PREREQ (4,0) extern struct globals *const ptr_to_globals; +#else +extern struct globals *ptr_to_globals; +#endif #define PTR_TO_GLOBALS (*(struct globals**)&ptr_to_globals) --- busybox-1.9.1.orig/libbb/messages.c 2008-02-12 11:03:08.000000000 -0500 +++ busybox-1.9.1/libbb/messages.c 2008-03-05 12:43:01.000000000 -0500 @@ -74,4 +74,8 @@ struct globals; /* Make it reside in R/W memory: */ +#if __GNUC_PREREQ (4,0) struct globals *const ptr_to_globals __attribute__ ((section (".data"))); +#else +struct globals *ptr_to_globals __attribute__ ((section (".data"))); +#endif From krahn at niehs.nih.gov Wed Mar 5 17:20:04 2008 From: krahn at niehs.nih.gov (Joe krahn) Date: Wed, 05 Mar 2008 20:20:04 -0500 Subject: [PATCH] Segfault in INIT_G() due to insufficient 'Magic'? In-Reply-To: <47CEDF49.6000504@niehs.nih.gov> References: <47CEDF49.6000504@niehs.nih.gov> Message-ID: <47CF46C4.5070706@niehs.nih.gov> After more testing, this seems to fix the segfault problem I have had. But, there are other pointers declared with the same syntax like: ... *const ptr __attribute__ ((section (".data"))); Maybe these could all be handled by a DECLARE_PTR_GLOBAL() macro. Joe From WHarms at bfs.de Thu Mar 6 01:16:37 2008 From: WHarms at bfs.de (walter harms) Date: Thu, 06 Mar 2008 10:16:37 +0100 Subject: [PATCH] print format correctness for uid, gid, pid, mode in "util-linux/ipcs.c" In-Reply-To: <47CED56A.2070708@niehs.nih.gov> References: <47CED56A.2070708@niehs.nih.gov> Message-ID: <47CFB675.90903@bfs.de> Joe Krahn wrote: > In "util-linux/ipcs.c", gid, uid, pid and mode values are all assumed to be default-size ints. I > have patched the formats to use long ints, and cast all arguments to longs. This seems to be the > common approach. The one exception is that I cast arguments with (mode&0777) as default-size ints. > > In reality, most busybox target platforms have the same size for int and long-int, but there are > some 64-bit platforms where these values really are larger than default ints. The only way to be > exact is to use macros as in , which gets rather ugly. OTOH, that approach might avoid > unnecessary casting in some case, and might really be a better fit for the very-light-weight design > goal. > Hi Joe, your comment is correct: some system have a funny long/int ratio. the ipcs stuff if only useful in linux context and the current code defines e.g. uid_t == __kernel_uid32_t == unsigned int while __kernel_mode_t == unsigned short long is used only with off_t and time_t IMHO int is a save bet (what may change in future !). Do you have architecture where this is a really wrong assumption ? ntl: we should use %u more often From pgf at brightstareng.com Thu Mar 6 05:14:52 2008 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 06 Mar 2008 08:14:52 -0500 Subject: vi bug fixes Message-ID: <29294.1204809292@brightstareng.com> once in a while i happen to do more "real" editing using busybox vi than usual. yesterday was one of those days, and i noticed several bugs, which i fixed, and have committed. - if you "/pattern", and then immediately "?" to repeat in the other direction (or vice versa) , vi now changes search direction correctly - the "dot" (i.e. '.') command now properly re-inits its buffer between redoable commands. the command recording buffer wasn't being terminated properly, and could end up with extra characters at the end, which when "played back" could give surprising results. - the 'c', 'd', and 'y' commands now properly distinguish between both motions that represent just part of a line vs. whole lines, and also those that are multiline vs. single line. among commands that now work correctly are "c%" and "2cw", whether the motions span lines or not. also, partial-line backward motions (like 'b', '0', '^') no longer include the current character in their action span. (e.g. "db", with the cursor on the 'b' in 'foobar' will leave 'bar', not 'ar' as it did before.) - made a few more motions work with 'c' and 'd': 'l', SPACE, BS, and DEL. (it was trying to use 'c' to change a character that got me going on all of this.) i did enough testing that i'm pretty sure nothing is worse than it was, but please mention it if you notice that anything bad has happened. paul =--------------------- paul fox, pgf at brightstareng.com From asif.kalim at gmail.com Thu Mar 6 05:13:41 2008 From: asif.kalim at gmail.com (asif kaleem) Date: Thu, 6 Mar 2008 18:13:41 +0500 Subject: How to check memory footprint in embedded linux Message-ID: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> Hi, I need some information that how to check the physical and virtual memory footprint consumed by a certain application in embedded linux. Thanks, asif -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080306/d5256506/attachment.htm From WHarms at bfs.de Thu Mar 6 05:47:41 2008 From: WHarms at bfs.de (walter harms) Date: Thu, 06 Mar 2008 14:47:41 +0100 Subject: How to check memory footprint in embedded linux In-Reply-To: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> References: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> Message-ID: <47CFF5FD.2080601@bfs.de> asif kaleem wrote: > Hi, > > I need some information that how to check the physical and virtual memory > footprint consumed by a certain application in embedded linux. > > Thanks, > asif > > hi, is cat /proc//maps what you need ? otherwise ps has a lot of option that help with that. re, wh From eemingliu at hotmail.com Thu Mar 6 07:00:09 2008 From: eemingliu at hotmail.com (MingLiu) Date: Thu, 6 Mar 2008 15:00:09 +0000 Subject: How to check memory footprint in embedded linux In-Reply-To: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> References: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> Message-ID: readelf command on the desktop host linux. There is also a similar command in your cross-compiler package, for example powerpc-405-linux-gnu-readelf for my powerpc embedded linux. You can try to see if they work. BR Ming Date: Thu, 6 Mar 2008 18:13:41 +0500 From: asif.kalim at gmail.com To: busybox at busybox.net Subject: How to check memory footprint in embedded linux Hi, I need some information that how to check the physical and virtual memory footprint consumed by a certain application in embedded linux. Thanks, asif _________________________________________________________________ ????? MSN ?????????? http://mobile.msn.com.cn/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080306/5a0a49fc/attachment.htm From roberto.foglietta at gmail.com Thu Mar 6 07:20:31 2008 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Thu, 6 Mar 2008 16:20:31 +0100 Subject: busybox config Message-ID: Hi to all, I think busybox --config should show the original .config content from which has been generate (better if stored in compressed form). Kernel use .config too but share it via /proc (for obvious reasons). I know people can save .config somewhere in the target system (where?) but usually they do not do it. So default .config should replicate itself in busybox and those want to minimize the footprint would disable the option. What do you think about? Cheers, -- /roberto From roberto.foglietta at gmail.com Thu Mar 6 07:20:31 2008 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Thu, 6 Mar 2008 16:20:31 +0100 Subject: busybox config Message-ID: Hi to all, I think busybox --config should show the original .config content from which has been generate (better if stored in compressed form). Kernel use .config too but share it via /proc (for obvious reasons). I know people can save .config somewhere in the target system (where?) but usually they do not do it. So default .config should replicate itself in busybox and those want to minimize the footprint would disable the option. What do you think about? Cheers, -- /roberto From Johnicholas-Hines at IDEXX.com Thu Mar 6 07:26:59 2008 From: Johnicholas-Hines at IDEXX.com (Hines, Johnicholas) Date: Thu, 6 Mar 2008 10:26:59 -0500 Subject: How to check memory footprint in embedded linux References: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> Message-ID: I have had some success using a tool called Codesighs - it's essentially a postprocessor of readelf. http://wiki.mozilla.org/Codesighs Johnicholas -----Original Message----- From: busybox-bounces at busybox.net on behalf of MingLiu Sent: Thu 3/6/2008 10:00 AM To: asif kaleem; busybox at busybox.net Subject: RE: How to check memory footprint in embedded linux readelf command on the desktop host linux. There is also a similar command in your cross-compiler package, for example powerpc-405-linux-gnu-readelf for my powerpc embedded linux. You can try to see if they work. BR Ming Date: Thu, 6 Mar 2008 18:13:41 +0500 From: asif.kalim at gmail.com To: busybox at busybox.net Subject: How to check memory footprint in embedded linux Hi, I need some information that how to check the physical and virtual memory footprint consumed by a certain application in embedded linux. Thanks, asif _________________________________________________________________ ????? MSN ???,?????! http://mobile.msn.com.cn/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080306/c526f685/attachment.htm From mailinglist.cache at gmail.com Thu Mar 6 07:49:12 2008 From: mailinglist.cache at gmail.com (Christoph Gysin) Date: Thu, 6 Mar 2008 16:49:12 +0100 Subject: [patch] hdparm: -q not supported Message-ID: <8fb844ee0803060749x4b53e023s3b14bfb0be2342b8@mail.gmail.com> The -q flag is not supported by busybox, even though it is mentioned in the usage. $ busybox hdparm 2>&1 | grep -- '-q\W' -q Change next setting quietly $ busybox hdparm -q -c1 /dev/sdb hdparm: invalid option -- q /dev/sdb: setting 32-bit IO_support flag to 1 I tried to write a patch, but it doesn't make much sense. Theres over 200 places where printf() is used throughout miscutils/hdparm.c. The easier way is to remove the line from the usage, and me redirecting output to /dev/null... Patch attached. Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-hdparm-quiet.patch Type: text/x-patch Size: 520 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080306/b570c2ad/attachment-0001.bin From pgf at brightstareng.com Thu Mar 6 08:31:58 2008 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 06 Mar 2008 11:31:58 -0500 Subject: vi bug fixes Message-ID: <15127.1204821118@brightstareng.com> someone just asked me privately for this: > can you also add the + option ? unless vi's option processing switches from getopt(), that's not trivial, and i probably won't do it. (besides -- i never use that option. ;-) in the meantime, use "vi -c NN" for the same effect. except that there's a bug that prevents the result of -c commands from displaying properly -- you need to type ^L to refresh the screen immediately after starting vi. (i've just committed the fix for that.) i also fixed the usage() message so it now displays commandline options correctly. (all it would show before was vi's internal help text.) this may make it more obvious that the '-c' option exists. paul =--------------------- paul fox, pgf at brightstareng.com From rubini at gnudd.com Thu Mar 6 08:33:25 2008 From: rubini at gnudd.com (Alessandro Rubini) Date: Thu, 6 Mar 2008 17:33:25 +0100 Subject: busybox config In-Reply-To: References: Message-ID: <20080306163325.GA1526@mail.gnudd.com> Hi Roberto. > So default .config should replicate > itself in busybox and those want to minimize the footprint would > disable the option. If you call busybox with no arguments it prints the list of applets it includes. This is enough for me, isn't it for you? (Yes, once I've been it by nfs-mount not being enabled in the mount applet and I couldn't verify it easily) /alessandro From pgf at brightstareng.com Thu Mar 6 08:35:35 2008 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 06 Mar 2008 11:35:35 -0500 Subject: busybox config In-Reply-To: roberto.foglietta's message of Thu, 06 Mar 2008 16:20:31 +0100. Message-ID: <15428.1204821335@brightstareng.com> > I think busybox --config should show the original .config content > from which has been generate (better if stored in compressed form). > Kernel use .config too but share it via /proc (for obvious reasons). I > know people can save .config somewhere in the target system (where?) > but usually they do not do it. So default .config should replicate > itself in busybox and those want to minimize the footprint would > disable the option. > What do you think about? i believe what you want is already present, in the bbconfig applet: CONFIG_BBCONFIG=y =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Thu Mar 6 09:07:22 2008 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 06 Mar 2008 12:07:22 -0500 Subject: busybox config In-Reply-To: roberto.foglietta's message of Thu, 06 Mar 2008 17:48:28 +0100. Message-ID: <16416.1204823242@brightstareng.com> [ moving this back to the list ] > 2008/3/6, Paul Fox : > > > I think busybox --config should show the original .config content > > > from which has been generate (better if stored in compressed form). > > > Kernel use .config too but share it via /proc (for obvious reasons). I > > > know people can save .config somewhere in the target system (where?) > > > but usually they do not do it. So default .config should replicate > > > itself in busybox and those want to minimize the footprint would > > > disable the option. > > > What do you think about? > > > > > > i believe what you want is already present, in the bbconfig applet: > > CONFIG_BBCONFIG=y > > > > Thanks is exactly what I would have. > Would be better enable per default? not as it is currently. perhaps, if a) the text were compressed, in a manner similar to the usage messages and/or b) the bbconfig applet presented only the "enabled" features, rather that both the enabled and disabled features. but as it is its something like 25K of strings. (it would be 4K compressed.) paul =--------------------- paul fox, pgf at brightstareng.com From roberto.foglietta at gmail.com Thu Mar 6 08:49:06 2008 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Thu, 6 Mar 2008 17:49:06 +0100 Subject: busybox config In-Reply-To: References: <15428.1204821335@brightstareng.com> Message-ID: 2008/3/6, Paul Fox : > > I think busybox --config should show the original .config content > > from which has been generate (better if stored in compressed form). > > Kernel use .config too but share it via /proc (for obvious reasons). I > > know people can save .config somewhere in the target system (where?) > > but usually they do not do it. So default .config should replicate > > itself in busybox and those want to minimize the footprint would > > disable the option. > > What do you think about? > > > i believe what you want is already present, in the bbconfig applet: > CONFIG_BBCONFIG=y > Thanks is exactly what I would have. Would be better enable per default? Starting from the list of applets which busybox prints out if it has been called without parameters take too much time for having a .config file. Cheers, -- /roberto From vda.linux at googlemail.com Thu Mar 6 10:03:36 2008 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Thu, 6 Mar 2008 19:03:36 +0100 Subject: internet problems Message-ID: <1158166a0803061003x515544bej112acb145bfe4d45@mail.gmail.com> Hi guys, I moved to new flat and as a result, I have no internet access for now. I expect it to be arranged RSN. As a result I cannot review your patches guys. Sorry about that. I am spending time fixing crond and inetd (both are not NOMMU capable, inetd also seems to be ignorant about IPv6). Best regards, Denys. -- vda From WHarms at bfs.de Thu Mar 6 10:08:32 2008 From: WHarms at bfs.de (walter harms) Date: Thu, 06 Mar 2008 19:08:32 +0100 Subject: busybox config In-Reply-To: <16416.1204823242@brightstareng.com> References: <16416.1204823242@brightstareng.com> Message-ID: <47D03320.7030901@bfs.de> Paul Fox wrote: > [ moving this back to the list ] > > > 2008/3/6, Paul Fox : > > > > I think busybox --config should show the original .config content > > > > from which has been generate (better if stored in compressed form). > > > > Kernel use .config too but share it via /proc (for obvious reasons). I > > > > know people can save .config somewhere in the target system (where?) > > > > but usually they do not do it. So default .config should replicate > > > > itself in busybox and those want to minimize the footprint would > > > > disable the option. > > > > What do you think about? > > > > > > > > > i believe what you want is already present, in the bbconfig applet: > > > CONFIG_BBCONFIG=y > > > > > > > Thanks is exactly what I would have. > > Would be better enable per default? > > not as it is currently. perhaps, if a) the text were compressed, > in a manner similar to the usage messages and/or b) the bbconfig > applet presented only the "enabled" features, rather that both > the enabled and disabled features. > > but as it is its something like 25K of strings. (it would be 4K > compressed.) > it would be useful to enable if config_debug is enabled. a developer may simply post the busybox --config output and we can recreate the problem (or even send a bb version). my 2 cents. wh From krahn at niehs.nih.gov Thu Mar 6 11:25:48 2008 From: krahn at niehs.nih.gov (Joe Krahn) Date: Thu, 06 Mar 2008 14:25:48 -0500 Subject: [PATCH] print format correctness for uid, gid, pid, mode in "util-linux/ipcs.c" In-Reply-To: <47CFB675.90903@bfs.de> References: <47CED56A.2070708@niehs.nih.gov> <47CFB675.90903@bfs.de> Message-ID: <47D0453C.7080905@niehs.nih.gov> walter harms wrote: > > Joe Krahn wrote: >> In "util-linux/ipcs.c", gid, uid, pid and mode values are all assumed to be default-size ints. I >> have patched the formats to use long ints, and cast all arguments to longs. This seems to be the >> common approach. The one exception is that I cast arguments with (mode&0777) as default-size ints. >> >> In reality, most busybox target platforms have the same size for int and long-int, but there are >> some 64-bit platforms where these values really are larger than default ints. The only way to be >> exact is to use macros as in , which gets rather ugly. OTOH, that approach might avoid >> unnecessary casting in some case, and might really be a better fit for the very-light-weight design >> goal. >> > > Hi Joe, > your comment is correct: some system have a funny long/int ratio. > > the ipcs stuff if only useful in linux context and the current code defines > e.g. uid_t == __kernel_uid32_t == unsigned int > while __kernel_mode_t == unsigned short > long is used only with off_t and time_t > > IMHO int is a save bet (what may change in future !). Do you have architecture > where this is a really wrong assumption ? > > ntl: we should use %u more often Broadcom's gcc-3.0 MIPS compilers uses long signed int for uid and gid in struct ipc_perm. That is also why I thought signed formats were OK (i.e. some people write -2 as the nobody uid), but in fact Linux defines them as unsigned. Does the signedness actually depend on the platform? I just checked and found that later Broadcom GCC versions are not this way, so this is an unusual case. But, I am stuck using 3.0 for compatibility with some binary-only object files. Maybe the safe approach would be to add (unsigned int) casts, and leave the format strings alone. Joe From WHarms at bfs.de Fri Mar 7 00:49:54 2008 From: WHarms at bfs.de (walter harms) Date: Fri, 07 Mar 2008 09:49:54 +0100 Subject: [PATCH] print format correctness for uid, gid, pid, mode in "util-linux/ipcs.c" In-Reply-To: <47D0453C.7080905@niehs.nih.gov> References: <47CED56A.2070708@niehs.nih.gov> <47CFB675.90903@bfs.de> <47D0453C.7080905@niehs.nih.gov> Message-ID: <47D101B2.6030501@bfs.de> Joe Krahn wrote: > walter harms wrote: >> Joe Krahn wrote: >>> In "util-linux/ipcs.c", gid, uid, pid and mode values are all assumed to be default-size ints. I >>> have patched the formats to use long ints, and cast all arguments to longs. This seems to be the >>> common approach. The one exception is that I cast arguments with (mode&0777) as default-size ints. >>> >>> In reality, most busybox target platforms have the same size for int and long-int, but there are >>> some 64-bit platforms where these values really are larger than default ints. The only way to be >>> exact is to use macros as in , which gets rather ugly. OTOH, that approach might avoid >>> unnecessary casting in some case, and might really be a better fit for the very-light-weight design >>> goal. >>> >> Hi Joe, >> your comment is correct: some system have a funny long/int ratio. >> >> the ipcs stuff if only useful in linux context and the current code defines >> e.g. uid_t == __kernel_uid32_t == unsigned int >> while __kernel_mode_t == unsigned short >> long is used only with off_t and time_t >> >> IMHO int is a save bet (what may change in future !). Do you have architecture >> where this is a really wrong assumption ? >> >> ntl: we should use %u more often > > Broadcom's gcc-3.0 MIPS compilers uses long signed int for uid and > gid in struct ipc_perm. That is also why I thought signed formats were > OK (i.e. some people write -2 as the nobody uid), but in fact Linux > defines them as unsigned. Does the signedness actually depend on the platform? > > I just checked and found that later Broadcom GCC versions are not this > way, so this is an unusual case. But, I am stuck using 3.0 for > compatibility with some binary-only object files. > > Maybe the safe approach would be to add (unsigned int) casts, and leave > the format strings alone. > Hi Joe, i quick dive into posix shows that they do not define the sign. The examples do a cast to (unsigned long). I thing your later versions confirm that the earlier version is crap. The whole stuff should come as part of you OS, gcc does not have anything to do with it. You can compare that .h with other .h from the same linux version to identify the culprit. ntl: it should not hurt you will see -1 as large number (if requested) this should not break the system (but perhaps some unwary scripts). re, wh From WHarms at bfs.de Fri Mar 7 02:41:59 2008 From: WHarms at bfs.de (walter harms) Date: Fri, 07 Mar 2008 11:41:59 +0100 Subject: GPL Lawsuit is Settled Message-ID: <47D11BF7.3090906@bfs.de> i case someone is interested in GPL and courts. re, wh http://www.internetnews.com/bus-news/article.php/3732511 Settled http://www.internetnews.com/bus-news/article.php/3732511 BusyBox vs High Gain Antennas From michele.sanges at otomelara.it Fri Mar 7 06:20:18 2008 From: michele.sanges at otomelara.it (Michele Sanges) Date: Fri, 07 Mar 2008 15:20:18 +0100 Subject: [patch] - bbsplash applet Message-ID: <1204899618.15200.8.camel@pigreco> Hello, this is the new patch for the today busybox snapshot. Please, can you add it to svn to be tested? Thanks. Michele -------------- next part -------------- A non-text attachment was scrubbed... Name: bbsplash_07_03_08.diff Type: text/x-patch Size: 16359 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080307/731806e3/attachment-0001.bin From vapier at gentoo.org Sat Mar 8 05:31:36 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 8 Mar 2008 08:31:36 -0500 Subject: mdev problem In-Reply-To: <1204723629.2803.74.camel@pigreco> References: <1204723629.2803.74.camel@pigreco> Message-ID: <200803080831.37302.vapier@gentoo.org> On Wednesday 05 March 2008, Michele Sanges wrote: > I have a problem with 'mdev' used for dynamic device update: > > - system based on kernel 2.6.23, busybox 1.9.1 and with mdev installed > as hotplug program (echo /sbin/mdev > /proc/sys/kernel/hotplug) > - system boots from a usb stick (/dev/sda1); it has also a disk on chip > disk seen as /dev/sdb. > > The disk on chip has initially one only primary partion; after booting I > see the device /dev/sdb1 so the command 'mdev -s' works fine. > > With fdisk I remove this partion and then I create two primary partion > --> I see only the device /dev/sdb2. > > So I created 'my_hotplug_program.sh' script: > > #!/bin/sh > /usr/bin/env >> /root/hotplug_env.txt > > and installed it as hotplug program: > > # echo /root/my_hotplug_program.sh > /proc/sys/kernel/hotplug > > With the above sequence of operation, the hotplug_env.txt file contains: > > ACTION=add > HOME=/ > SEQNUM=390 > MAJOR=8 > DEVPATH=/block/sdb/sdb1 > SUBSYSTEM=block > PATH=/sbin:/bin:/usr/sbin:/usr/bin > PHYSDEVPATH=/devices/pci0000:00/0000:00:07.1/host2/target2:0:0/2:0:0:0 > MINOR=17 > PHYSDEVDRIVER=sd > PWD=/ > PHYSDEVBUS=scsi > ACTION=remove > HOME=/ > SEQNUM=389 > MAJOR=8 > DEVPATH=/block/sdb/sdb1 > SUBSYSTEM=block > PATH=/sbin:/bin:/usr/sbin:/usr/bin > PHYSDEVPATH=/devices/pci0000:00/0000:00:07.1/host2/target2:0:0/2:0:0:0 > MINOR=17 > PHYSDEVDRIVER=sd > PWD=/ > PHYSDEVBUS=scsi > ACTION=add > HOME=/ > SEQNUM=391 > MAJOR=8 > DEVPATH=/block/sdb/sdb2 > SUBSYSTEM=block > PATH=/sbin:/bin:/usr/sbin:/usr/bin > PHYSDEVPATH=/devices/pci0000:00/0000:00:07.1/host2/target2:0:0/2:0:0:0 > MINOR=18 > PHYSDEVDRIVER=sd > PWD=/ > PHYSDEVBUS=scsi > > It seems that events don't arrive in order; does 'mdev' take into > account the variable SEQNUM? no, and there are no plans to do so. that'd require state maintaining or a constantly running daemon or other fun stuff. use udev if you want 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/20080308/e3955238/attachment.pgp From vapier at gentoo.org Sat Mar 8 05:32:45 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 8 Mar 2008 08:32:45 -0500 Subject: How to check memory footprint in embedded linux In-Reply-To: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> References: <7d0f5fcc0803060513m7f4f7f7du7e27741fe2367678@mail.gmail.com> Message-ID: <200803080832.46365.vapier@gentoo.org> On Thursday 06 March 2008, asif kaleem wrote: > I need some information that how to check the physical and virtual memory > footprint consumed by a certain application in embedded linux. this list is about busybox development, not $random-embedded-questions. please seek help on a more general forum. -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/20080308/640bc79b/attachment.pgp From connintel at gmail.com Mon Mar 10 00:01:06 2008 From: connintel at gmail.com (conn intel) Date: Mon, 10 Mar 2008 12:31:06 +0530 Subject: [BusyBox] Query regarding HTTPD File Uploading Message-ID: Dear Friends, I am using busybox version 1.7.2. I am using cgi to upload file from machine to board where httpd is running. Now I want to ask what is the maximum size of file I can transfer from machine to board using File upload control. Below is the HTML code:

Type some text (if you like):

Please specify a file, or a set of files:

Kindly Let me know if you need further information. Thank you, Ankur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080310/3151f923/attachment.htm From fingar at tiscali.co.uk Mon Mar 10 00:42:54 2008 From: fingar at tiscali.co.uk (Chris Humphreys) Date: Mon, 10 Mar 2008 07:42:54 +0000 Subject: Busybox ps problem Message-ID: <20080310075516.2330B12C7B8@busybox.net> Hi I am running Busybox 1.9.1 on Linux version 2.6.21.3. I am using Codesourcery compiler arm-none-linux-gnueabi-gcc and glibc. When I run ls -l or ps I get segmentation fault. I have tracked the problem down to get_cached_username() in libbb/procps.c but I can't get any further. I don't know if it a problem with my etc/passwd file or a Busybox problem. Any help would be appreciated. Best Regards Chris Humphreys Fingar Electronics Ltd. 62 Dudley Road Walton-on-Thames Surrey KT12 2JU Tel 07970 308252 or 07796 516295 Fax 08712 119649 Skype fingarelectronics -- No virus found in this outgoing message. Checked by AVG. Version: 7.5.518 / Virus Database: 269.21.7/1322 - Release Date: 09/03/2008 12:17 From youinuk at empal.com Mon Mar 10 00:52:38 2008 From: youinuk at empal.com (=?ks_c_5601-1987?B?IsCvwM6/7SI=?=) Date: Mon, 10 Mar 2008 16:52:38 +0900 Subject: =?ks_c_5601-1987?B?aHR0cGQgd2l0aCBjZ2k=?= Message-ID: <20080310165238.47d4e8c6000228310022393e.1885$2d0403b5@empal.com> An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080310/ac756df7/attachment.htm From i-yu at melcoinc.co.jp Mon Mar 10 01:31:08 2008 From: i-yu at melcoinc.co.jp (Inuk You) Date: Mon, 10 Mar 2008 17:31:08 +0900 Subject: http with cgi Message-ID: <014001c88289$17309750$8b31a8c0@PNIYOU> Hello I apologize for the prior mail (hard to read it). Please delete it (same title with youinuk at empal.com) if possible. I'd like to run some script with cgi in server accessing from client. i.e. (in server) 1) write a cgi script in /www/cgi-bin e.g. #!/bin/sh # test.cgi echo "run a program!" > /dev/console 2) run httpd (in client) 3) access to server through the browser or something e.g. http://x.x.x.x/cgi-bin/test.cgi I'm a newbie in Busybox. There are only binaries (httpd, inetd, etc) in Busybox httpd so I've no idea how to start (how to configure, which files to need more, and so on). Could you let me know what to do after installing busybox httpd? or good references or sites? Thanks in advance. P.S. In order to these, what I did is: (in server) - install the busybox (built with httpd). - write httpd.conf and inetd.conf in /etc. (document root is /www) - mkdir /www/cgi-bin and write a test script in that. - run httpd. (in client) - http://x.x.x.x/cgi-bin/test.cgi by I.E. Of course, it doesn't work. From connintel at gmail.com Mon Mar 10 06:47:26 2008 From: connintel at gmail.com (conn intel) Date: Mon, 10 Mar 2008 19:17:26 +0530 Subject: [BusyBox] Query regarding HTTPD File Uploading In-Reply-To: References: Message-ID: Dear Friends, Following the attached mail, I have one more problem. Whenever I upload text file, its is received nicely, but when I try other media file or binary it cannot be received. Any suggestions are welcome.. Thank you, Ankur. On Mon, Mar 10, 2008 at 12:31 PM, conn intel wrote: > Dear Friends, > > I am using busybox version 1.7.2. I am using cgi to upload file from > machine to board where httpd is running. Now I want to ask what is the > maximum size of file I can transfer from machine to board using File upload > control. > > Below is the HTML code: > >
enctype="multipart/form-data" method="post"> >

> Type some text (if you like):
> > >

>

> Please specify a file, or a set of files:
> > >

>
> >
>
> > > Kindly Let me know if you need further information. > > Thank you, > Ankur. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080310/3c15a28a/attachment.htm From Alexander at Kriegisch.name Mon Mar 10 08:06:41 2008 From: Alexander at Kriegisch.name (Alexander Kriegisch) Date: Mon, 10 Mar 2008 16:06:41 +0100 Subject: [BusyBox] Query regarding HTTPD File Uploading In-Reply-To: References: Message-ID: <47D54E81.4080207@Kriegisch.name> I suggest using an add-on tool like Haserl (http://haserl.sourceforge.org) for CGI handling, especially for form-based upload. -- Alexander Kriegisch Certified ScrumMaster http://scrum-master.de From WHarms at bfs.de Mon Mar 10 09:07:24 2008 From: WHarms at bfs.de (walter harms) Date: Mon, 10 Mar 2008 17:07:24 +0100 Subject: http with cgi In-Reply-To: <014001c88289$17309750$8b31a8c0@PNIYOU> References: <014001c88289$17309750$8b31a8c0@PNIYOU> Message-ID: <47D55CBC.6080806@bfs.de> there is nothing special about CGI and busybox HTTPD you need to have your cgi-script in //cgi-bin/ thats it, re, wh Inuk You wrote: > Hello > > I apologize for the prior mail (hard to read it). > Please delete it (same title with youinuk at empal.com) if possible. > > I'd like to run some script with cgi in server accessing from client. > i.e. > (in server) > 1) write a cgi script in /www/cgi-bin > e.g. > #!/bin/sh > # test.cgi > echo "run a program!" > /dev/console > > 2) run httpd > (in client) > > 3) access to server through the browser or something > e.g. > http://x.x.x.x/cgi-bin/test.cgi > > I'm a newbie in Busybox. > There are only binaries (httpd, inetd, etc) in Busybox httpd > so I've no idea how to start (how to configure, which files to need more, > and so on). > Could you let me know what to do after installing busybox httpd? > or good references or sites? > > Thanks in advance. > > P.S. > In order to these, what I did is: > (in server) > - install the busybox (built with httpd). > - write httpd.conf and inetd.conf in /etc. > (document root is /www) > - mkdir /www/cgi-bin and write a test script in that. > - run httpd. > (in client) > - http://x.x.x.x/cgi-bin/test.cgi by I.E. > Of course, it doesn't work. > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > From cristian.ionescu-idbohrn at axis.com Mon Mar 10 09:31:32 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 10 Mar 2008 17:31:32 +0100 (CET) Subject: ash r21030 broken? In-Reply-To: <0802201747390.8601@somehost> References: <0802191323180.31221@somehost> <0802201119210.31221@somehost> <200802201737.31722.vda.linux@googlemail.com> <200802201742.57915.vda.linux@googlemail.com> <0802201747390.8601@somehost> Message-ID: <0803101709480.15452@somehost> Hi Denys, On Wed, 20 Feb 2008, Cristian Ionescu-Idbohrn wrote: > On Wed, 20 Feb 2008, Denys Vlasenko wrote: > > > On Wednesday 20 February 2008 17:37, Denys Vlasenko wrote: > > > On Wednesday 20 February 2008 11:46, Cristian Ionescu-Idbohrn wrote: > > > > > > > > I'm still seeing uninitialized data which leeds to segfaults :( > > > > > > > > I run a quite complicated chain of scripts at startup, on my embedded > > > > system. > > > > > > > > See attached. > > > > > > > > sh: (A) LINE 5914 > > > > sh: (B) LINE 5921: name='RCLIB=/sh/dhcp_command_line.sh', name_len=6 > > > > sh: (C) LINE 5923 > > > > sh (pid 31) segfaults for page address 00000000 at pc 355a0828 > > > > Segmentation fault > > > > > > > > Going back to shell/ash.c svn r21020 gives me a clean startup. > > > > So, I think I'll stick to r21020 for now. > > > > > > Can you try attached patch (on top of previous one)? > > I'd like to, but... > > > > It covers a few more cases where we had uninitialized > > > ->next pointers: > > > > > > - sp = stalloc(sizeof(*sp)); > > > + sp = stzalloc(sizeof(*sp)); > > > sp->text = start; > > > > And if it still fails, make both alloc() functions zero out > > allocated block: > > > > static void * > > ckmalloc(size_t nbytes) > > { > > - return ckrealloc(NULL, nbytes); > > + return memset(ckrealloc(NULL, nbytes), 0, nbytes); > > } > > > > static void * > > stalloc(size_t nbytes) > > { > > ... > > g_stacknleft -= aligned; > > + memset(p, 0, nbytes); > > return p; > > } > > > > If this helps, then it's only a matter of finding a ckmalloc/stalloc > > which really needs to be ckzalloc/stzalloc. > > Sorry Denys :( > I've no access to my embedded system now and the comming 2+ weeks. > Holidays ;-) > > When I'm back, I'll check that up, if noone else beats be to it. Alright. Back from holidays. Picked it up from where I left. I first applied the patch. Still segfaults :( Applied the 2 suggested 'memset' changes mentioned above. Kernel boots, linuxrc starts running but ends quite fast showing: Kernel panic - not syncing: Attempted to kill init! Going back to r21020 puts me back on track. Didn't test the latest ash.c r21125 yet. Cheers, -- Cristian From cristian.ionescu-idbohrn at axis.com Mon Mar 10 14:17:46 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 10 Mar 2008 22:17:46 +0100 (CET) Subject: networking/brctl.c: error: duplicate inline Message-ID: <0803102150500.3103@somehost> GNU C version 3.3.6 (Debian 1:3.3.6-15) (i486-linux-gnu) says: networking/brctl.c:39: error: duplicate `inline' networking/brctl.c:52: error: duplicate `inline' line: static inline ALWAYS_INLINE void strtotimeval(struct timeval *tv, is expanded to: static __inline__ __attribute__ ((always_inline)) __inline__ void strtotimeval(struct timeval *tv, On the other hand, GNU C version 4.2.3 (Debian 4.2.3-2) (i486-linux-gnu) does not complain, while expanding to an identical line: static __inline__ __attribute__ ((always_inline)) __inline__ void strtotimeval(struct timeval *tv, The attached patch removes the __inline__ duplication. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: brctl.c.patch Type: text/x-diff Size: 837 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080310/e2eb39db/attachment.bin From dronnikov at gmail.com Mon Mar 10 14:19:15 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Mon, 10 Mar 2008 14:19:15 -0700 (PDT) Subject: =?utf-8?B?VEZUUEQ6IG5ldyBhcHBsZXQsIG5vdyB3aXRoIGJsa3NpemUgb3B0aW9u?= Message-ID: <47d5a5d3.01b6420a.2c66.fffff6c0@mx.google.com> Added bare bones TFTP Daemon. Tested with BB tftp. Works. Plz, do consider. Any requests for features and/or comments are welcome. -- Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: tftpd.patch Type: application/octet-stream Size: 14022 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080310/674cf672/attachment.obj From pgf at brightstareng.com Mon Mar 10 14:54:35 2008 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 10 Mar 2008 17:54:35 -0400 Subject: vi alarm signals Message-ID: <12057.1205186075@brightstareng.com> it seems that vi contains a software watchdog of sorts. the intent is that if a vi command runs too long, a SIGALRM will be generated, and the result will be much as if the user hit ^C -- the operation will be aborted, and the editor will go back to waiting for input. now, i don't quite know why this was implemented, but: a) the current timeout is 3 seconds. this feels too short, especially when you're searching for a string in a long file. b) currently, the alarm signal isn't even caught, so when the timer expires, the editor just dies. there's a comment in the code that implies this wasn't always the case, so i assume it's a recent bug. what should i do? the obvious minimal change is simply to lengthen the timer, to something more reasonable than 3 seconds. the signal should also be caught correctly. but, should i simply delete this code? make it configurable? put it inside a developer-only ifdef of some sort? paul =--------------------- paul fox, pgf at brightstareng.com From krellan at gmail.com Mon Mar 10 18:51:02 2008 From: krellan at gmail.com (JoSH Lehan) Date: Mon, 10 Mar 2008 18:51:02 -0700 Subject: Does lightweight hostname lookup applet exist in BB? Message-ID: <242876bc0803101851o549d5421y1ee07acf16478c97@mail.gmail.com> Does Busybox contain a lightweight hostname lookup applet? I looked, and could not find one. The "host" command would fit the bill, I think. I feed it the hostname that needs to be resolved, and some DNS server IP addresses to use, and it performs the DNS protocol, returning the IP address(es) of the hostname. Alternatives to "host" are "nslookup" and "getent". It seems that "nslookup" is too closely tied to BIND, and "getent" is too closely tied to glibc. Ideally, I could use this hostname lookup applet to look up hostnames and convert them to IP addresses, without needing to install a full NSS library as needed by glibc. That would save considerable space. Then, it should be trivial to pass this to wget, so it can supply the correct "Host:" HTTP header, when connecting to the IP address. Does such a thing already exist? Thanks! Josh From cristian.ionescu-idbohrn at axis.com Tue Mar 11 02:25:01 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 11 Mar 2008 10:25:01 +0100 (CET) Subject: [patch] mount.c Message-ID: <0803111023300.15452@somehost> Something like this seems to be required. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: bb-mount.patch Type: text/x-diff Size: 664 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080311/66456998/attachment.bin From cristian.ionescu-idbohrn at axis.com Tue Mar 11 03:10:59 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 11 Mar 2008 11:10:59 +0100 (CET) Subject: ash r21030 broken? In-Reply-To: <0803101709480.15452@somehost> References: <0802191323180.31221@somehost> <0802201119210.31221@somehost> <200802201737.31722.vda.linux@googlemail.com> <200802201742.57915.vda.linux@googlemail.com> <0802201747390.8601@somehost> <0803101709480.15452@somehost> Message-ID: <0803111045190.15452@somehost> On Mon, 10 Mar 2008, Cristian Ionescu-Idbohrn wrote: > Alright. Back from holidays. Picked it up from where I left. > I first applied the patch. Still segfaults :( > > Applied the 2 suggested 'memset' changes mentioned above. Kernel > boots, linuxrc starts running but ends quite fast showing: > > Kernel panic - not syncing: Attempted to kill init! > > Going back to r21020 puts me back on track. > Didn't test the latest ash.c r21125 yet. I'm now pleased to acknowledge latest (21175) bb svn (including ash.c r21125) works for me. No segfaults :) BusyBox v1.10.0.svn (2008-03-11 09:53:35 CET) multi-call binary cpu : CRIS cpu revision : 11 cpu model : ETRAX 100LX v2 cris-axis-elf-gcc (GCC) 3.2.1 Axis release R64/1.64 libuClibc-0.9.27 Any plans for a new release? Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: bbconfig.2008-03-11:11:04:44.bz2 Type: application/octet-stream Size: 4139 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080311/51f20faf/attachment.obj From GeorgeB at Linux.ca Tue Mar 11 07:23:43 2008 From: GeorgeB at Linux.ca (George Boudreau) Date: Tue, 11 Mar 2008 10:23:43 -0400 Subject: patch applet, file access rights. Message-ID: Hi, I recently encountered a situation where a patch was applied to a bash script using the busybox patch applet. The patched script failed to execute since its rights had changed from 755 to 644. (my umask 022). The included patch allows files to retain their access rights. This has no effect when an applied patch creates a file. regards George toolchain: bb-1.9.1, uclibc-snapshot, gcc-4.2.2 -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.9.1-patch_permissions.patch Type: application/octet-stream Size: 1338 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080311/6fab4f58/attachment.obj From WHarms at bfs.de Tue Mar 11 08:59:03 2008 From: WHarms at bfs.de (walter harms) Date: Tue, 11 Mar 2008 16:59:03 +0100 Subject: Does lightweight hostname lookup applet exist in BB? In-Reply-To: <242876bc0803101851o549d5421y1ee07acf16478c97@mail.gmail.com> References: <242876bc0803101851o549d5421y1ee07acf16478c97@mail.gmail.com> Message-ID: <47D6AC47.4040000@bfs.de> JoSH Lehan wrote: > Does Busybox contain a lightweight hostname lookup applet? > > I looked, and could not find one. > > The "host" command would fit the bill, I think. I feed it the > hostname that needs to be resolved, and some DNS server IP addresses > to use, and it performs the DNS protocol, returning the IP address(es) > of the hostname. > > Alternatives to "host" are "nslookup" and "getent". It seems that > "nslookup" is too closely tied to BIND, and "getent" is too closely > tied to glibc. what is getent ? do you mean the getent-function-family ? that is not glibc specific. neither is nslookup Bind specific. > > Ideally, I could use this hostname lookup applet to look up hostnames > and convert them to IP addresses, without needing to install a full > NSS library as needed by glibc. That would save considerable space. > the NSS libs are part of the glibc suite. if you choose glibc you choose NSS also. If you do not like nss use ulibc,newlib what ever you like. > Then, it should be trivial to pass this to wget, so it can supply the > correct "Host:" HTTP header, when connecting to the IP address. > i am lost now, perhaps this is a naming convention problem: "applet" is something you can call inside busybox like .\busybox echo "foo" "xgetaddrinfo" is a convenience function inside busybox and only busybox that is (possible) used by wget to resolve names. > Does such a thing already exist? > it seems no one is missing it, can you please give a situation where such a function maybe useful ? re, wh From dronnikov at gmail.com Tue Mar 11 11:26:46 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Tue, 11 Mar 2008 18:26:46 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_Does_lightweight_hostn?= =?KOI8-R?Q?ame_lookup_applet_exist_in_BB=3F?= In-Reply-To: <47D6AC47.4040000@bfs.de> References: <242876bc0803101851o549d5421y1ee07acf16478c97@mail.gmail.com> <47D6AC47.4040000@bfs.de> Message-ID: <6784529b0803111126g4d50b7ebt3bb6616651c481ba@mail.gmail.com> Just stop using glibc, Josh! Compile and link BB (I prefer to use statically compiled binary, it's less than "half a metre" :) === 0.5Mb) against uClibc and you will get a neat _lightweight_ tool that you can successfully use anywhere. Stop using glibc and you'll get rid of all those weird stuff (NSS and friends) that nobody knows the origin and/or purpose nowdays... Regards, -- Vladimir 2008/3/11, walter harms : > > > JoSH Lehan wrote: > > Does Busybox contain a lightweight hostname lookup applet? > > > > I looked, and could not find one. > > > > The "host" command would fit the bill, I think. I feed it the > > hostname that needs to be resolved, and some DNS server IP addresses > > to use, and it performs the DNS protocol, returning the IP address(es) > > of the hostname. > > > > Alternatives to "host" are "nslookup" and "getent". It seems that > > "nslookup" is too closely tied to BIND, and "getent" is too closely > > tied to glibc. > > what is getent ? do you mean the getent-function-family ? that is not > glibc specific. neither is nslookup Bind specific. > > > > > > Ideally, I could use this hostname lookup applet to look up hostnames > > and convert them to IP addresses, without needing to install a full > > NSS library as needed by glibc. That would save considerable space. > > > > the NSS libs are part of the glibc suite. if you choose glibc you choose N