From andreas.wetzel at bridgeco.net Tue Jul 1 01:26:31 2008 From: andreas.wetzel at bridgeco.net (Andreas Wetzel) Date: Tue, 01 Jul 2008 10:26:31 +0200 Subject: [PATCH] really close all extra fds in bb_daemonize_or_rexec Message-ID: <4869EA37.7020807@bridgeco.net> hi, the current implementation seems not to reliably close all open file descriptors if the flag DAEMON_CLOSE_EXTRA_FDS is set. it is assumed, that the fd returned by opening a file (bb_dev_null) is the top-most fd, but this is not true. open returns the first free fd. so, potentially, some fds remain open. the attached patch fixes this by calling close() on every possible file descriptor (diffed against the busybox_1_9_stable branch). cheers, andi -- Andreas Wetzel Core Software Engineer BridgeCo AG Direct +41 44 802 33 19 Ringstrasse 14 Phone +41 44 802 33 33 CH-8600 D?bendorf Fax +41 44 802 33 39 Switzerland mailto:andreas.wetzel at bridgeco.net http://www.bridgeco.net -------------- next part -------------- A non-text attachment was scrubbed... Name: close_extra_fds.patch Type: text/x-diff Size: 608 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080701/6138a4df/attachment.patch From andreas.wetzel at bridgeco.net Tue Jul 1 01:27:22 2008 From: andreas.wetzel at bridgeco.net (Andreas Wetzel) Date: Tue, 01 Jul 2008 10:27:22 +0200 Subject: [PATCH] start-stop-daemon: close extra fds on --background Message-ID: <4869EA6A.8060901@bridgeco.net> hi again, in start-stop-daemon, if --background is given, i think we should completely detach the called process, including closing all extra file-descriptors. for non-mmu, this seems to be the case. but if BB_MMU is set, we do not set the DAEMON_CLOSE_EXTRA_FDS flag when calling bb_daemonize. the attached patch sets this flag, therefore makes the behaviour consistent for the mmu and non-mmu case (diffed against the busybox_1_9_stable branch). cheers, andi -- Andreas Wetzel Core Software Engineer BridgeCo AG Direct +41 44 802 33 19 Ringstrasse 14 Phone +41 44 802 33 33 CH-8600 D?bendorf Fax +41 44 802 33 39 Switzerland mailto:andreas.wetzel at bridgeco.net http://www.bridgeco.net -------------- next part -------------- A non-text attachment was scrubbed... Name: start_stop_daemon.patch Type: text/x-diff Size: 414 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080701/9a49a8f2/attachment.patch From roy at marples.name Tue Jul 1 01:53:20 2008 From: roy at marples.name (Roy Marples) Date: Tue, 1 Jul 2008 09:53:20 +0100 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <4869EA6A.8060901@bridgeco.net> References: <4869EA6A.8060901@bridgeco.net> Message-ID: <200807010953.20658.roy@marples.name> On Tuesday 01 July 2008 09:27:22 Andreas Wetzel wrote: > hi again, > > in start-stop-daemon, if --background is given, i think we should > completely detach the called process, including closing all extra > file-descriptors. > for non-mmu, this seems to be the case. but if BB_MMU is set, we do not > set the DAEMON_CLOSE_EXTRA_FDS flag when calling bb_daemonize. > > the attached patch sets this flag, therefore makes the behaviour > consistent for the mmu and non-mmu case (diffed against the > busybox_1_9_stable branch). I would expect this to work echo "password" | start-stop-daemon --start --exec /usr/sbin/pppd --background -- plugins passwdfd 0 Your patch would break that yes? Thanks Roy From andreas.wetzel at bridgeco.net Tue Jul 1 02:32:26 2008 From: andreas.wetzel at bridgeco.net (Andreas Wetzel) Date: Tue, 01 Jul 2008 11:32:26 +0200 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807010953.20658.roy@marples.name> References: <4869EA6A.8060901@bridgeco.net> <200807010953.20658.roy@marples.name> Message-ID: <4869F9AA.9060500@bridgeco.net> Roy Marples wrote: > On Tuesday 01 July 2008 09:27:22 Andreas Wetzel wrote: >> hi again, >> >> in start-stop-daemon, if --background is given, i think we should >> completely detach the called process, including closing all extra >> file-descriptors. >> for non-mmu, this seems to be the case. but if BB_MMU is set, we do not >> set the DAEMON_CLOSE_EXTRA_FDS flag when calling bb_daemonize. >> >> the attached patch sets this flag, therefore makes the behaviour >> consistent for the mmu and non-mmu case (diffed against the >> busybox_1_9_stable branch). > > I would expect this to work > > echo "password" | > start-stop-daemon --start --exec /usr/sbin/pppd --background -- plugins > passwdfd 0 > > Your patch would break that yes? Your start-stop-daemon command gets its input from stdin. Setting the DAEMON_CLOSE_EXTRA_FDS flag closes all file descriptors except stdin, stdout and stderr. So it should not change the behaviour of your commandline. But - after reviewing the bb_daemonize_or_rexec code - I think, your command will not work at all. Independent of the DAEMON_CLOSE_EXTRA_FDS flag, bb_daemonize_or_rexec currently does connect the called processes stdin, -out and -err to /dev/null. So if I'm right, it's not possible to pipe "password" to a start-stop-daemon call if --background is given. With or without the patch. Correct me if I'm wrong... cheers, andi From vda.linux at googlemail.com Tue Jul 1 05:01:56 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Jul 2008 14:01:56 +0200 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <4869EA6A.8060901@bridgeco.net> References: <4869EA6A.8060901@bridgeco.net> Message-ID: <200807011401.56464.vda.linux@googlemail.com> On Tuesday 01 July 2008 10:27, Andreas Wetzel wrote: > > hi again, > > in start-stop-daemon, if --background is given, i think we should > completely detach the called process, including closing all extra > file-descriptors. > for non-mmu, this seems to be the case. but if BB_MMU is set, we do not > set the DAEMON_CLOSE_EXTRA_FDS flag when calling bb_daemonize. > > the attached patch sets this flag, therefore makes the behaviour > consistent for the mmu and non-mmu case (diffed against the > busybox_1_9_stable branch). I am applying the following patch. It also addresses no less than 3 (!) other bugs... ssd: do not stat -x EXECUTABLE, it is not needed anymore ssd: use PATH ssd: fix -a without -x case ssd: CLOSE_EXTRA_FDS in MMU case too -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.patch Type: text/x-diff Size: 3279 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080701/5cd1f964/attachment.patch From vda.linux at googlemail.com Tue Jul 1 05:03:00 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Jul 2008 14:03:00 +0200 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807010953.20658.roy@marples.name> References: <4869EA6A.8060901@bridgeco.net> <200807010953.20658.roy@marples.name> Message-ID: <200807011403.00059.vda.linux@googlemail.com> On Tuesday 01 July 2008 10:53, Roy Marples wrote: > On Tuesday 01 July 2008 09:27:22 Andreas Wetzel wrote: > > hi again, > > > > in start-stop-daemon, if --background is given, i think we should > > completely detach the called process, including closing all extra > > file-descriptors. > > for non-mmu, this seems to be the case. but if BB_MMU is set, we do not > > set the DAEMON_CLOSE_EXTRA_FDS flag when calling bb_daemonize. > > > > the attached patch sets this flag, therefore makes the behaviour > > consistent for the mmu and non-mmu case (diffed against the > > busybox_1_9_stable branch). > > I would expect this to work > > echo "password" | > start-stop-daemon --start --exec /usr/sbin/pppd --background -- plugins > passwdfd 0 > > Your patch would break that yes? It already does not work, if I read code correctly (bb_daemonize() closes fds 0,1,2). -- vda From roy at marples.name Tue Jul 1 03:08:23 2008 From: roy at marples.name (Roy Marples) Date: Tue, 1 Jul 2008 11:08:23 +0100 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807011403.00059.vda.linux@googlemail.com> References: <4869EA6A.8060901@bridgeco.net> <200807010953.20658.roy@marples.name> <200807011403.00059.vda.linux@googlemail.com> Message-ID: <200807011108.23454.roy@marples.name> On Tuesday 01 July 2008 13:03:00 Denys Vlasenko wrote: > > I would expect this to work > > > > echo "password" | > > start-stop-daemon --start --exec /usr/sbin/pppd --background -- plugins > > passwdfd 0 > > > > Your patch would break that yes? > > It already does not work, if I read code correctly (bb_daemonize() closes > fds 0,1,2). -- > vda Curses! Well, the only place I know of where is needed is for passing a password to pppd plugin and the Gentoo specific version of dhclient where it accepts a config file via stdin. Neither use the background argument so it will probably be unaffected. Thanks Roy From roy at marples.name Tue Jul 1 03:25:54 2008 From: roy at marples.name (Roy Marples) Date: Tue, 1 Jul 2008 11:25:54 +0100 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807011401.56464.vda.linux@googlemail.com> References: <4869EA6A.8060901@bridgeco.net> <200807011401.56464.vda.linux@googlemail.com> Message-ID: <200807011125.54247.roy@marples.name> On Tuesday 01 July 2008 13:01:56 Denys Vlasenko wrote: > ssd: do not stat -x EXECUTABLE, it is not needed anymore Then userland won't catch an error with ssd --background when the file does not exit :/ Please re-consider this. Thanks Roy From vda.linux at googlemail.com Tue Jul 1 05:44:52 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Jul 2008 14:44:52 +0200 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807011125.54247.roy@marples.name> References: <4869EA6A.8060901@bridgeco.net> <200807011401.56464.vda.linux@googlemail.com> <200807011125.54247.roy@marples.name> Message-ID: <200807011444.52488.vda.linux@googlemail.com> On Tuesday 01 July 2008 12:25, Roy Marples wrote: > On Tuesday 01 July 2008 13:01:56 Denys Vlasenko wrote: > > ssd: do not stat -x EXECUTABLE, it is not needed anymore > > Then userland won't catch an error with ssd --background when the file does > not exit :/ > > Please re-consider this. With that stat(), even "start-stop-daemon -S -x true" does not work. -- vda From rep.dot.nop at gmail.com Tue Jul 1 03:49:51 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 1 Jul 2008 12:49:51 +0200 Subject: svn commit: trunk/busybox: archival archival/libunarchive debianuti etc... In-Reply-To: <20080701104041.F0A7FF800A@busybox.net> References: <20080701104041.F0A7FF800A@busybox.net> Message-ID: <20080701104951.GA20391@mx.loc> On Tue, Jul 01, 2008 at 03:40:41AM -0700, vda at busybox.net wrote: >Author: vda >Date: 2008-07-01 03:40:41 -0700 (Tue, 01 Jul 2008) >New Revision: 22582 > >Log: >*: introduce and use xvfork() >Modified: trunk/busybox/libbb/Kbuild >=================================================================== >--- trunk/busybox/libbb/Kbuild 2008-07-01 10:05:12 UTC (rev 22581) >+++ trunk/busybox/libbb/Kbuild 2008-07-01 10:40:41 UTC (rev 22582) >@@ -109,6 +109,7 @@ > lib-y += xgetcwd.o > lib-y += xgethostbyname.o > lib-y += xreadlink.o >+lib-y += xvfork.o svn add libbb/xvfork.c && svn ci -m 'add missing file' TIA, From roy at marples.name Tue Jul 1 03:55:21 2008 From: roy at marples.name (Roy Marples) Date: Tue, 1 Jul 2008 11:55:21 +0100 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807011444.52488.vda.linux@googlemail.com> References: <4869EA6A.8060901@bridgeco.net> <200807011125.54247.roy@marples.name> <200807011444.52488.vda.linux@googlemail.com> Message-ID: <200807011155.21382.roy@marples.name> On Tuesday 01 July 2008 13:44:52 Denys Vlasenko wrote: > On Tuesday 01 July 2008 12:25, Roy Marples wrote: > > On Tuesday 01 July 2008 13:01:56 Denys Vlasenko wrote: > > > ssd: do not stat -x EXECUTABLE, it is not needed anymore > > > > Then userland won't catch an error with ssd --background when the file > > does not exit :/ > > > > Please re-consider this. > > With that stat(), even "start-stop-daemon -S -x true" does not work. ssd has historically required the full path when starting daemons. Thanks Roy From vda.linux at googlemail.com Tue Jul 1 06:21:51 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Jul 2008 15:21:51 +0200 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807011155.21382.roy@marples.name> References: <4869EA6A.8060901@bridgeco.net> <200807011444.52488.vda.linux@googlemail.com> <200807011155.21382.roy@marples.name> Message-ID: <200807011521.51229.vda.linux@googlemail.com> On Tuesday 01 July 2008 12:55, Roy Marples wrote: > On Tuesday 01 July 2008 13:44:52 Denys Vlasenko wrote: > > On Tuesday 01 July 2008 12:25, Roy Marples wrote: > > > On Tuesday 01 July 2008 13:01:56 Denys Vlasenko wrote: > > > > ssd: do not stat -x EXECUTABLE, it is not needed anymore > > > > > > Then userland won't catch an error with ssd --background when the file > > > does not exit :/ > > > > > > Please re-consider this. > > > > With that stat(), even "start-stop-daemon -S -x true" does not work. > > ssd has historically required the full path when starting daemons. As I see it: Historically, surprising percentage of Unix admins have no clue why $PATH is useful. Whenever they meet a configuration problem causing PATH search to not find their utility, they "fix" it by using full path. Whereas correct fix is to fix $PATH or copy/move/symplink executable to one of the directories which are in $PATH! That cluelessness is the prime cause why so many scripts are littered with e.g. "/usr/sbin/sendmail" instead of just "sendmail". It is not a matter of aestetics. It is a matter of making your scripts independent of where executables are stored on this particular machine. If something can be made to use PATH, it has to use it. (Case where it is not possible: /sbin/hotplug). -- vda From dronnikov at gmail.com Tue Jul 1 08:17:15 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Tue, 1 Jul 2008 15:17:15 +0000 Subject: tar -cjf Message-ID: <6784529b0807010817k1bc10731jb6c2b3b1a01c1afa@mail.gmail.com> Oops! # tar -cjf tar.bz2 some-dir Segmentation fault File tar.bz2 is created and contains the only line bzip2: bunzip error 0 But # strace -f -v 2>2 /bin/tar -cjf tar.bz2 some-dir creates perfectly valid archive. The point is in stderr redirected? -- Vladimir From dronnikov at gmail.com Tue Jul 1 08:21:37 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Tue, 1 Jul 2008 15:21:37 +0000 Subject: tar -cjf Message-ID: <6784529b0807010821g78a7daf3h53c55baf89411b8d@mail.gmail.com> Oops! # tar -cjf tar.bz2 some-dir Segmentation fault File tar.bz2 is created and contains the only line bzip2: bunzip error 0 But # strace -f -v 2>2 /bin/tar -cjf tar.bz2 some-dir creates perfectly valid archive. The point is in stderr redirected? -- Vladimir From vda.linux at googlemail.com Tue Jul 1 11:10:38 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Jul 2008 20:10:38 +0200 Subject: tar -cjf In-Reply-To: <6784529b0807010821g78a7daf3h53c55baf89411b8d@mail.gmail.com> References: <6784529b0807010821g78a7daf3h53c55baf89411b8d@mail.gmail.com> Message-ID: <200807012010.38498.vda.linux@googlemail.com> On Tuesday 01 July 2008 17:21, Vladimir Dronnikov wrote: > Oops! > > # tar -cjf tar.bz2 some-dir > Segmentation fault > > File tar.bz2 is created and contains the only line > bzip2: bunzip error 0 > > But > # strace -f -v 2>2 /bin/tar -cjf tar.bz2 some-dir > > creates perfectly valid archive. > > The point is in stderr redirected? No, it's me being an idiot. After vfork you may not return from a function. strace -f makes vfork work as fork and masks this. -- vda From dronnikov at gmail.com Tue Jul 1 10:00:14 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Tue, 01 Jul 2008 10:00:14 -0700 (PDT) Subject: =?utf-8?B?U09DS0xPRzogcnVuaXQgaGVscGVy?= Message-ID: <486a629e.1d664e0a.6ceb.ffffac1c@mx.google.com> Here comes a very barebone replacement for G. Pape socklog utility. Request for features are welcome. Please, try it. TIA, -- Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: socklog.patch Type: application/octet-stream Size: 5350 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080701/df5c90ff/attachment.obj From ramkumar.research at gmail.com Tue Jul 1 16:15:56 2008 From: ramkumar.research at gmail.com (Ram kumar) Date: Tue, 1 Jul 2008 16:15:56 -0700 Subject: busybox ping not able to reach public IP Message-ID: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> hi, I have compiled the busybox using buildroot along with filesystem for my ATMEL platform at91sam9260(eval kit).I also have a marvell 8686 SDIO wifi card attached to my SDIO interface.I use iwconfig to configure my SDIO wifi card.I also have a ethernet controller attached to the atmel platform...... I am able to ping my default gateway(Access point) by typing............ $ ping -i eth1 192.168.1.1 (-i to use my wifi interface) i get proper output...... $ 64 bytes from 192.168.1.1: seq=0 ttl=64 time=46.315 ms But the same way when i ping any public ip like google or yahoo with their ip address....ping just hangs...... But I am able to ping both my default gateway and public ip using the ethernet...... Please let me know whether i have to enable some options in the busybox to make my ping command work with wifi card ? Please let me know where could be the problem is ? Regards, Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080701/2088e406/attachment.htm From mikes at kuentos.guam.net Tue Jul 1 16:23:55 2008 From: mikes at kuentos.guam.net (Michael D. Setzer II) Date: Tue, 01 Jul 2008 16:23:55 -0700 Subject: busybox ping not able to reach public IP In-Reply-To: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> Message-ID: <486A5A1B.1126.363A04@mikes.kuentos.guam.net> On 1 Jul 2008 at 16:15, Ram kumar wrote: > > hi, > I have compiled the busybox using buildroot along with filesystem for my ATMEL platform > at91sam9260(eval kit).I also have a marvell 8686 SDIO wifi card attached to my SDIO interface.I > use iwconfig to configure my SDIO wifi card.I also have a ethernet controller attached to the atmel > platform...... > > I am able to ping my default gateway(Access point) by typing............ > > $ ping -i eth1 192.168.1.1 (-i to use my wifi interface) > > i get proper output...... > > $ 64 bytes from 192.168.1.1: seq=0 ttl=64 time=46.315 ms > > But the same way when i ping any public ip like google or yahoo with their ip address....ping just > hangs...... Did you try pinging to the ip address of google.com? It might be a named problem rather than a ping problem. Note: There is a problem that I don't know if it has been resolved, but at least in the past, the named option didn't work unless some library files where included, and they don't show up when one does ldd on busybox. If you can ping or traceroute to the ip address but not the name, it is probable the named issue, but I don't recall exactly what the files or where I got the info. Currently 7 timezones away from my main computers. > > But I am able to ping both my default gateway and public ip using the ethernet...... > > Please let me know whether i have to enable some options in the busybox to make my ping > command work with wifi card ? > > Please let me know where could be the problem is ? > > Regards, > Ram +----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes at kuentos.guam.net mailto:msetzerii at gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC at HOME CREDITS SETI 5,856,243.972020 | EINSTEIN 1,785,763.067546 | ROSETTA 552,124.439726 From whegardt at gmail.com Tue Jul 1 17:23:38 2008 From: whegardt at gmail.com (William Hegardt) Date: Tue, 1 Jul 2008 17:23:38 -0700 Subject: Applet proposal - gratuitous ARP daemon Message-ID: <484527250807011723p20324539qa23645f6d44c4763@mail.gmail.com> I've written a small gratuitous ARP daemon that could be modified to become a busybox applet and contributed if there's any interest. It periodically scans the list of network interfaces and sends out gratuitous ARP packets on each interface that has a non-zero MAC address, non-zero IP address and is in the running state. The frequency defaults to once per minute, but is configurable via a command line option. It is useful for wireless clients that don't necessarily generate much traffic themselves and need to announce their presence to forgetful Access Points, etc. - Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080701/ec714152/attachment.htm From roy at marples.name Tue Jul 1 23:31:23 2008 From: roy at marples.name (Roy Marples) Date: Wed, 2 Jul 2008 07:31:23 +0100 Subject: Applet proposal - gratuitous ARP daemon In-Reply-To: <484527250807011723p20324539qa23645f6d44c4763@mail.gmail.com> References: <484527250807011723p20324539qa23645f6d44c4763@mail.gmail.com> Message-ID: <200807020731.23770.roy@marples.name> On Wednesday 02 July 2008 01:23:38 William Hegardt wrote: > I've written a small gratuitous ARP daemon that could be modified to become > a busybox applet and contributed if there's any interest. > > It periodically scans the list of network interfaces and sends out > gratuitous ARP packets on each interface that has > a non-zero MAC address, non-zero IP address and is in the running state. > The frequency defaults to once per minute, but is configurable via a > command line option. > > It is useful for wireless clients that don't necessarily generate much > traffic themselves and need to announce their presence to > forgetful Access Points, etc. Can it react on an ARP conflict? If so, how does it handle it? Also, I think this daemon would go against the nature of RFC 3927, section 2.2 last paragraph. A host MUST NOT perform this check periodically as a matter of course. This would be a waste of network bandwidth, and is unnecessary due to the ability of hosts to passively discover conflicts, as described in Section 2.5. Thanks Roy From ramkumar.research at gmail.com Wed Jul 2 09:01:56 2008 From: ramkumar.research at gmail.com (Ram kumar) Date: Wed, 2 Jul 2008 09:01:56 -0700 Subject: busybox ping not able to reach public IP In-Reply-To: <486A5A1B.1126.363A04@mikes.kuentos.guam.net> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <486A5A1B.1126.363A04@mikes.kuentos.guam.net> Message-ID: <6306c640807020901g25bf2dd5j85bdb4048c43724e@mail.gmail.com> hi, Did you try pinging to the ip address of google.com? > It might be a named problem rather than a ping problem. > > I have tried pinging the google with the ip address too.But the ping just hangs......I have mentioned this in the previous mail.Any idea where could be the issue ? Regards, Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080702/4916dfe8/attachment.htm From farmatito at tiscali.it Wed Jul 2 09:18:43 2008 From: farmatito at tiscali.it (Tito) Date: Wed, 2 Jul 2008 18:18:43 +0200 Subject: busybox ping not able to reach public IP In-Reply-To: <6306c640807020901g25bf2dd5j85bdb4048c43724e@mail.gmail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <486A5A1B.1126.363A04@mikes.kuentos.guam.net> <6306c640807020901g25bf2dd5j85bdb4048c43724e@mail.gmail.com> Message-ID: <200807021818.43524.farmatito@tiscali.it> On Wednesday 02 July 2008 18:01:56 Ram kumar wrote: > hi, > > Did you try pinging to the ip address of google.com? > > It might be a named problem rather than a ping problem. > > > > I have tried pinging the google with the ip address too.But the ping just > hangs......I have mentioned this in the previous mail.Any idea where could > be the issue ? > > Regards, > Ram > Hi, have you all the needed libnss* libs on your system? For example: libnss_dns-2.7.so libnss_dns.so.2 libnss_files-2.7.so libnss_files.so.2 Is your /etc/nsswitch.conf correct? For example: ------------------------------------------------------------------------------------------------------------- # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: compat group: compat shadow: compat hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis ------------------------------------------------------------------------------------------------------------ Ciao, Tito From ramkumar.research at gmail.com Wed Jul 2 09:59:15 2008 From: ramkumar.research at gmail.com (Ram kumar) Date: Wed, 2 Jul 2008 09:59:15 -0700 Subject: busybox ping not able to reach public IP In-Reply-To: <200807021818.43524.farmatito@tiscali.it> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <486A5A1B.1126.363A04@mikes.kuentos.guam.net> <6306c640807020901g25bf2dd5j85bdb4048c43724e@mail.gmail.com> <200807021818.43524.farmatito@tiscali.it> Message-ID: <6306c640807020959y5502210ar57004ecb9f5df472@mail.gmail.com> hi, Hi, > have you all the needed libnss* libs on your system? > > For example: > > libnss_dns-2.7.so > libnss_dns.so.2 > libnss_files-2.7.so > libnss_files.so.2 > > Is your /etc/nsswitch.conf correct? > > Before i check the configuration,let me post my assumption................. I have a ethernet controller,in which the ping works fine................. ping 192.168.1.1(my default gateway)....................i get.............. 64 bytes from 192.168.1.1: seq=0 ttl=64 time=46.315 ms the same way when i ping google with the ip address............ # ping 64.233.167.99 (google's ip address) i get................... PING 64.233.167.99 (64.233.167.99) 56(84) bytes of data. 64 bytes from 64.233.167.99: icmp_seq=1 ttl=240 time=91.3 ms But when i use my wireless which is eth1 to ping my default gateway ping -I eth1 192.168.1.1 i get.................... 64 bytes from 192.168.1.1: seq=0 ttl=64 time=46.315 ms but when i ping google....... ping -I eth1 64.233.167.99 ping hangs after that........................ As you say,if the libnss_dns-2.7.so libnss_dns.so.2 libnss_files-2.7.so libnss_files.so.2 if they are not installed properly..........my ping command should fail for both ethernet as well as my wireless.......... Why the ping is failing only for my wireless device ? Regards, Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080702/83d989e9/attachment.htm From vda.linux at googlemail.com Wed Jul 2 11:52:28 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Jul 2008 20:52:28 +0200 Subject: busybox ping not able to reach public IP In-Reply-To: <6306c640807020959y5502210ar57004ecb9f5df472@mail.gmail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <200807021818.43524.farmatito@tiscali.it> <6306c640807020959y5502210ar57004ecb9f5df472@mail.gmail.com> Message-ID: <200807022052.28044.vda.linux@googlemail.com> On Wednesday 02 July 2008 18:59, Ram kumar wrote: > I have a ethernet controller,in which the ping works fine................. > > ping 192.168.1.1(my default gateway)....................i get.............. > > 64 bytes from 192.168.1.1: seq=0 ttl=64 time=46.315 ms > > the same way when i ping google with the ip address............ > > # ping 64.233.167.99 (google's ip address) > > i get................... > > PING 64.233.167.99 (64.233.167.99) 56(84) bytes of data. > 64 bytes from 64.233.167.99: icmp_seq=1 ttl=240 time=91.3 ms Ok. So routing works. > But when i use my wireless which is eth1 to ping my default gateway > > ping -I eth1 192.168.1.1 > > i get.................... > > 64 bytes from 192.168.1.1: seq=0 ttl=64 time=46.315 ms Wait a second. If you have two interfaces, typically only one of these interfaces is connected to the network which eventually is connected to Internet. That's the network where your default gateway machine is. Why are you trying to ping default gateway FROM ANOTHER network?! > but when i ping google....... > > ping -I eth1 64.233.167.99 > > ping hangs after that........................ Of course. - eth1[your box]eth0 - - 192.168.1.1[default gateway] - - []... - - [google] The google is on the "other side". I surprised that ping -I eth1 192.168.1.1 works... -- vda From ramkumar.research at gmail.com Wed Jul 2 12:43:53 2008 From: ramkumar.research at gmail.com (Ram kumar) Date: Wed, 2 Jul 2008 12:43:53 -0700 Subject: busybox ping not able to reach public IP In-Reply-To: <200807022052.28044.vda.linux@googlemail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <200807021818.43524.farmatito@tiscali.it> <6306c640807020959y5502210ar57004ecb9f5df472@mail.gmail.com> <200807022052.28044.vda.linux@googlemail.com> Message-ID: <6306c640807021243h2a6edc9ew6ff89b629ccb0511@mail.gmail.com> hi, Wait a second. If you have two interfaces, typically only one > of these interfaces is connected to the network which eventually > is connected to Internet. That's the network where your default > gateway machine is. > > Why are you trying to ping default gateway FROM ANOTHER network?! No both the interfaces are on the same eval board.........Imagine a laptop that has ethernet and wifi card connected to a router,that acts as an access point as well as a default gateway for ethernet.So a ethernet RJ45 cable connects the ethernet of the eval board to router and the wifi card gets connected to the access point(router) since the router is a wireless router. So what i am trying to do is ,i have both ethernet and wifi card on the eval board......both gets connected to the verizon router which acts as an access point as well as default gateway for ethernet. Now i want to check whether both my ethernet and wifi card were able to reach a web server...... so first time i ping google using ethernet.............. Then i change the interface to wifi using $ping -I eth1 64.233.167.99 where it hangs............... My ethernet is eth0....... My wifi is eth1.......... Regards, Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080702/4d02743d/attachment.htm From vda.linux at googlemail.com Wed Jul 2 13:18:07 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Jul 2008 22:18:07 +0200 Subject: busybox ping not able to reach public IP In-Reply-To: <6306c640807021243h2a6edc9ew6ff89b629ccb0511@mail.gmail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <200807022052.28044.vda.linux@googlemail.com> <6306c640807021243h2a6edc9ew6ff89b629ccb0511@mail.gmail.com> Message-ID: <200807022218.07803.vda.linux@googlemail.com> On Wednesday 02 July 2008 21:43, Ram kumar wrote: > hi, > > Wait a second. If you have two interfaces, typically only one > > of these interfaces is connected to the network which eventually > > is connected to Internet. That's the network where your default > > gateway machine is. > > > > Why are you trying to ping default gateway FROM ANOTHER network?! > > > No both the interfaces are on the same eval board.........Imagine a laptop > that has ethernet and wifi card connected to a router,that acts as an access > point as well as a default gateway for ethernet.So a ethernet RJ45 cable > connects the ethernet of the eval board to router and the wifi card gets > connected to the access point(router) since the router is a wireless router. > > So what i am trying to do is ,i have both ethernet and wifi card on the eval > board......both gets connected to the verizon router which acts as an access > point as well as default gateway for ethernet. > > Now i want to check whether both my ethernet and wifi card were able to > reach a web server...... > > so first time i ping google using ethernet.............. > > Then i change the interface to wifi using > > $ping -I eth1 64.233.167.99 where it hangs............... > > My ethernet is eth0....... > My wifi is eth1.......... Please show output of "ip a l" and "ip r l" commands. -- vda From ramkumar.research at gmail.com Wed Jul 2 14:14:27 2008 From: ramkumar.research at gmail.com (Ram kumar) Date: Wed, 2 Jul 2008 14:14:27 -0700 Subject: busybox ping not able to reach public IP In-Reply-To: <200807022218.07803.vda.linux@googlemail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <200807022052.28044.vda.linux@googlemail.com> <6306c640807021243h2a6edc9ew6ff89b629ccb0511@mail.gmail.com> <200807022218.07803.vda.linux@googlemail.com> Message-ID: <6306c640807021414l66f67ef3s1543e58272648ab1@mail.gmail.com> hi, > Please show output of "ip a l" and "ip r l" commands. > -- > vda Here is the output........... # ip a l 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:1c:23:f8:ec:80 brd ff:ff:ff:ff:ff:ff inet 192.168.1.41/24 brd 192.168.1.255 scope global eth0 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:19:88:05:10:17 brd ff:ff:ff:ff:ff:ff inet 192.168.1.23/24 brd 192.168.1.255 scope global eth1 # ip r l 192.168.1.0/24 dev eth0 src 192.168.1.41 192.168.1.0/24 dev eth1 src 192.168.1.23 127.0.0.0/8 dev lo default via 192.168.1.1 dev eth0 Please let me know how to solve it ????? Regards, Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080702/52e2cb42/attachment.htm From cristian.ionescu-idbohrn at axis.com Wed Jul 2 15:06:11 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 3 Jul 2008 00:06:11 +0200 (CEST) Subject: busybox ping not able to reach public IP In-Reply-To: <6306c640807021414l66f67ef3s1543e58272648ab1@mail.gmail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <200807022052.28044.vda.linux@googlemail.com> <6306c640807021243h2a6edc9ew6ff89b629ccb0511@mail.gmail.com> <200807022218.07803.vda.linux@googlemail.com> <6306c640807021414l66f67ef3s1543e58272648ab1@mail.gmail.com> Message-ID: <0807022346400.7341@somehost> On Wed, 2 Jul 2008, Ram kumar wrote: > > Please show output of "ip a l" and "ip r l" commands. > > -- > > vda > > Here is the output........... > > # ip a l > 1: lo: mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:1c:23:f8:ec:80 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.41/24 brd 192.168.1.255 scope global eth0 > 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:19:88:05:10:17 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.23/24 brd 192.168.1.255 scope global eth1 > > > # ip r l > 192.168.1.0/24 dev eth0 src 192.168.1.41 > 192.168.1.0/24 dev eth1 src 192.168.1.23 > 127.0.0.0/8 dev lo > default via 192.168.1.1 dev eth0 > > Please let me know how to solve it ????? This is _not_ a particular busybox thing, but general networking stuff. Help with doing that is best sought elsewhere. You have 2 interfaces in the same scope and one and the same gateway both use. Did you try putting different metrics on those routes? Like: $ ip r 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.41 metric 1 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.23 metric 10 default via 192.168.1.1 dev eth0 metric 1 default via 192.168.1.1 dev eth1 metric 10 Could you also please try to get control of your mailer and loose the much annoying html-crap? Cheers, -- Cristian From vda.linux at googlemail.com Wed Jul 2 15:12:01 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 3 Jul 2008 00:12:01 +0200 Subject: busybox ping not able to reach public IP In-Reply-To: <6306c640807021414l66f67ef3s1543e58272648ab1@mail.gmail.com> References: <6306c640807011615u36d7308fn47f99979b9ea366c@mail.gmail.com> <200807022218.07803.vda.linux@googlemail.com> <6306c640807021414l66f67ef3s1543e58272648ab1@mail.gmail.com> Message-ID: <200807030012.01704.vda.linux@googlemail.com> On Wednesday 02 July 2008 23:14, Ram kumar wrote: > > Please show output of "ip a l" and "ip r l" commands. > > Here is the output........... > > # ip a l > 1: lo: mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:1c:23:f8:ec:80 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.41/24 brd 192.168.1.255 scope global eth0 > 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:19:88:05:10:17 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.23/24 brd 192.168.1.255 scope global eth1 > > # ip r l > 192.168.1.0/24 dev eth0 src 192.168.1.41 > 192.168.1.0/24 dev eth1 src 192.168.1.23 > 127.0.0.0/8 dev lo > default via 192.168.1.1 dev eth0 You indeed have two networks with the same number. I am not sure it is even supposed to work. How kernel is supposed to know over which link it should reach default gw? I guess normally in such cases people just configure two devices as bridge (brctl) or trunk them (ifenslave). > Please let me know how to solve it ????? I guess 192.168.1.1 sends the answer for ping back by wired network, not wireless. That's why ping doesn see it. You may see it if you'll run tcpdump -nlieth0 -s0 icmp and tcpdump -nlieth1 -s0 icmp at the time you ping over wireless. -- vda From roberto.foglietta at gmail.com Thu Jul 3 07:40:45 2008 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Thu, 3 Jul 2008 16:40:45 +0200 Subject: -sh: can't access tty; job control turned off - busybox v1.6.0 In-Reply-To: References: <8B3BF7A02B910640AB146A919AB36594051849B7@exsvl03.hq.netapp.com> Message-ID: 2008/1/12 Roberto A. Foglietta : > 2008/1/12, Tallam, Sreenivas : >> Hi All, >> >> This has been discussed in the forum before but all of them were focused >> with a busybox version lower than what I am using >> So I am asking this question to the yet again, please bear with me >> > > I have the same problem with 1.2.2.1 but at this time I am ignoring > it because I can live with it. What is your problem apart the warning > message? > I have ported cttyhack into 1.2.2.1. It was a easy job but I would like the patch attached would be added here http://busybox.net/downloads/fixes-1.2.2.1-foglietta/ Thanks, -- /roberto -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.2.2.1_cttyhack_applet.patch Type: text/x-patch Size: 4697 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080703/e7956ef9/attachment-0001.bin From beck0778 at umn.edu Thu Jul 3 12:57:21 2008 From: beck0778 at umn.edu (beck0778 at umn.edu) Date: 03 Jul 2008 14:57:21 -0500 Subject: powerpc: question concerning insmod Message-ID: Hello, I am attempting to build busybox-1.11.0 for powerpc. I have unsuccessfully tried: 1) custom-built cross compiling toolchain built with crosstool (gcc 4.1.0, glibc 2.3.6) 2) vendor-provided cross compiling toolchain (gcc 3.4.3, glibc 2.3.3) 3) vendor-provided native powerpc toolchain (gcc 3.4.3, glibc 2.3.3) For the cross compilers, I'm trying to build with: $ make ARCH=powerpc CROSS_COMPILE=powerpc-405-linux-gnu- For the native compiler, I'm just using: $ make I am getting an error while compiling the file modutils/insmod.c using any of these toolchains: For all three toolchains, I get the following error messages: CC modutils/insmod.o modutils/insmod.c: In function 'arch_apply_relocation': modutils/insmod.c:864: error: 'ifile' undeclared (first use in this function) modutils/insmod.c:864: error: (Each undeclared identifier is reported only once modutils/insmod.c:864: error: for each function it appears in.) modutils/insmod.c:836: warning: unused parameter 'f' make[1]: *** [modutils/insmod.o] Error 1 make: *** [modutils] Error 2 I looked into the source file indicated, and it seems like the variable ifile is defined in this section, which does not include a " || defined(__powerpc__)" condition: #if defined(__arm__) || defined(__i386__) || defined(__mc68000__) \ || defined(__sh__) || defined(__s390__) || defined(__x86_64__) struct arch_file *ifile = (struct arch_file *) f; #endif The error line is 864: #if defined(USE_PLT_ENTRIES) ElfW(Addr) plt = ifile->plt ? ifile->plt->header.sh_addr : 0; unsigned long *ip; ... #endif If we look up near the top, we see: #elif defined(__powerpc__) #define MATCH_MACHINE(x) (x == EM_PPC) #define SHT_RELM SHT_RELA #define Elf32_RelM Elf32_Rela #define ELFCLASSM ELFCLASS32 #define USE_PLT_ENTRIES #define PLT_ENTRY_SIZE 16 #define USE_PLT_LIST #define LIST_ARCHTYPE ElfW(Addr) #define USE_LIST #define ARCHDATAM "__ftr_fixup" #endif Here it looks like USE_PLT_ENTRIES is defined for powerpc, but the ifile variable isn't defined for powerpc. I'm guessing that someone else has had success cross compiling busybox-1.11.0 for powerpc, and this is a problem with my setup. If anyone has run into this before, or has any suggestions, I would really appreciate any help. Thank you in advance, Matthew From vda.linux at googlemail.com Thu Jul 3 14:05:55 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 3 Jul 2008 23:05:55 +0200 Subject: powerpc: question concerning insmod In-Reply-To: References: Message-ID: <200807032305.55820.vda.linux@googlemail.com> On Thursday 03 July 2008 21:57, beck0778 at umn.edu wrote: > Hello, > > I am attempting to build busybox-1.11.0 for powerpc. I have unsuccessfully > tried: > > 1) custom-built cross compiling toolchain built with crosstool (gcc 4.1.0, > glibc 2.3.6) > > 2) vendor-provided cross compiling toolchain (gcc 3.4.3, glibc 2.3.3) > > 3) vendor-provided native powerpc toolchain (gcc 3.4.3, glibc 2.3.3) > > For the cross compilers, I'm trying to build with: > $ make ARCH=powerpc CROSS_COMPILE=powerpc-405-linux-gnu- > > For the native compiler, I'm just using: > $ make > > I am getting an error while compiling the file modutils/insmod.c using any > of these toolchains: > > For all three toolchains, I get the following error messages: > > CC modutils/insmod.o modutils/insmod.c: In function > 'arch_apply_relocation': modutils/insmod.c:864: error: 'ifile' undeclared > (first use in this function) modutils/insmod.c:864: error: (Each undeclared > identifier is reported only once modutils/insmod.c:864: error: for each > function it appears in.) modutils/insmod.c:836: warning: unused parameter > 'f' make[1]: *** [modutils/insmod.o] Error 1 make: *** [modutils] Error 2 > > I looked into the source file indicated, and it seems like the variable > ifile is defined in this section, which does not include a " || > defined(__powerpc__)" condition: > > #if defined(__arm__) || defined(__i386__) || defined(__mc68000__) \ > || defined(__sh__) || defined(__s390__) || defined(__x86_64__) > struct arch_file *ifile = (struct arch_file *) f; > #endif Does it work if you add || defined(__powerpc__) ? -- vda From vda.linux at googlemail.com Thu Jul 3 14:56:17 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 3 Jul 2008 23:56:17 +0200 Subject: -sh: can't access tty; job control turned off - busybox v1.6.0 In-Reply-To: References: <8B3BF7A02B910640AB146A919AB36594051849B7@exsvl03.hq.netapp.com> Message-ID: <200807032356.17999.vda.linux@googlemail.com> On Thursday 03 July 2008 16:40, Roberto A. Foglietta wrote: > 2008/1/12 Roberto A. Foglietta : > > 2008/1/12, Tallam, Sreenivas : > >> Hi All, > >> > >> This has been discussed in the forum before but all of them were focused > >> with a busybox version lower than what I am using > >> So I am asking this question to the yet again, please bear with me > >> > > > > I have the same problem with 1.2.2.1 but at this time I am ignoring > > it because I can live with it. What is your problem apart the warning > > message? > > > > I have ported cttyhack into 1.2.2.1. > It was a easy job but I would like the patch attached would be added here > > http://busybox.net/downloads/fixes-1.2.2.1-foglietta/ Done. Thanks. -- vda From Sreenivas.Tallam at netapp.com Thu Jul 3 15:21:36 2008 From: Sreenivas.Tallam at netapp.com (Tallam, Sreenivas) Date: Thu, 3 Jul 2008 15:21:36 -0700 Subject: powerpc: question concerning insmod In-Reply-To: References: Message-ID: Hi, Not sure if this matters, but I have taken the stock busybox-1.10.2 and built it using "make CROSS_COMPILE=ppc_405- " Do not use any other parameter at the end of ppc_405- I have compiled on a host system # cat /etc/redhat-release Red Hat Enterprise Linux WS release 4 (Nahant Update 3) Hope this helps!! Thanks, Sreen -----Original Message----- From: beck0778 at umn.edu [mailto:beck0778 at umn.edu] Sent: Thursday, July 03, 2008 12:57 PM To: busybox at busybox.net Subject: powerpc: question concerning insmod Hello, I am attempting to build busybox-1.11.0 for powerpc. I have unsuccessfully tried: 1) custom-built cross compiling toolchain built with crosstool (gcc 4.1.0, glibc 2.3.6) 2) vendor-provided cross compiling toolchain (gcc 3.4.3, glibc 2.3.3) 3) vendor-provided native powerpc toolchain (gcc 3.4.3, glibc 2.3.3) For the cross compilers, I'm trying to build with: $ make ARCH=powerpc CROSS_COMPILE=powerpc-405-linux-gnu- For the native compiler, I'm just using: $ make I am getting an error while compiling the file modutils/insmod.c using any of these toolchains: For all three toolchains, I get the following error messages: CC modutils/insmod.o modutils/insmod.c: In function 'arch_apply_relocation': modutils/insmod.c:864: error: 'ifile' undeclared (first use in this function) modutils/insmod.c:864: error: (Each undeclared identifier is reported only once modutils/insmod.c:864: error: for each function it appears in.) modutils/insmod.c:836: warning: unused parameter 'f' make[1]: *** [modutils/insmod.o] Error 1 make: *** [modutils] Error 2 I looked into the source file indicated, and it seems like the variable ifile is defined in this section, which does not include a " || defined(__powerpc__)" condition: #if defined(__arm__) || defined(__i386__) || defined(__mc68000__) \ || defined(__sh__) || defined(__s390__) || defined(__x86_64__) struct arch_file *ifile = (struct arch_file *) f; #endif The error line is 864: #if defined(USE_PLT_ENTRIES) ElfW(Addr) plt = ifile->plt ? ifile->plt->header.sh_addr : 0; unsigned long *ip; ... #endif If we look up near the top, we see: #elif defined(__powerpc__) #define MATCH_MACHINE(x) (x == EM_PPC) #define SHT_RELM SHT_RELA #define Elf32_RelM Elf32_Rela #define ELFCLASSM ELFCLASS32 #define USE_PLT_ENTRIES #define PLT_ENTRY_SIZE 16 #define USE_PLT_LIST #define LIST_ARCHTYPE ElfW(Addr) #define USE_LIST #define ARCHDATAM "__ftr_fixup" #endif Here it looks like USE_PLT_ENTRIES is defined for powerpc, but the ifile variable isn't defined for powerpc. I'm guessing that someone else has had success cross compiling busybox-1.11.0 for powerpc, and this is a problem with my setup. If anyone has run into this before, or has any suggestions, I would really appreciate any help. Thank you in advance, Matthew _______________________________________________ busybox mailing list busybox at busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox From jcurlnews at arcor.de Fri Jul 4 00:55:48 2008 From: jcurlnews at arcor.de (Jason Curl) Date: Fri, 4 Jul 2008 09:55:48 +0200 (CEST) Subject: BusyBox 1.11.0 man patch for "cat" Message-ID: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> Hello, I'd like to welcome comments on my first bb patch (it's the first I've needed to do since I've started using 1.0.0). I like the new "man" applet, but it needs nroff and gtbl. Unfortunately, I didn't prepare the c++ compiler and the gnu tools won't compile. No worry though, I've updated busybox to support "cat" pages also. This requires less space than installing all the GNU tools. The diff is applied, generated with "diff -au source modified". So, I have /share/man/cat1 /share/man/man1 It searches first in the "cat" pages and if it isn't found, then searches in the "man" pages. I'm sure there could be some optimisations made.... Thanks, Jason. Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmf?hrer mit Movie Star Bewertungen von TV Movie. Au?erdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv -------------- next part -------------- A non-text attachment was scrubbed... Name: busyboxman.patch Type: text/x-diff Size: 3420 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080704/7c46eff5/attachment.patch From vda.linux at googlemail.com Fri Jul 4 03:08:25 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Jul 2008 12:08:25 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> Message-ID: <200807041208.25148.vda.linux@googlemail.com> On Friday 04 July 2008 09:55, Jason Curl wrote: > Hello, > > I'd like to welcome comments on my first bb patch It's using spaces for indentation. Otherwise looks ok. > (it's the first I've needed to do since I've started > using 1.0.0). I like the new "man" applet, but it > needs nroff and gtbl. Unfortunately, I didn't prepare > the c++ compiler and the gnu tools won't compile. > No worry though, I've updated busybox to support > "cat" pages also. This requires less space than > installing all the GNU tools. Ideally, some simplified replacement for nroff+gtbl would be cool. -- vda From John.Holland at cellent-fs.de Fri Jul 4 04:39:12 2008 From: John.Holland at cellent-fs.de (Holland, John) Date: Fri, 4 Jul 2008 13:39:12 +0200 Subject: mdev scan Message-ID: Hi, I'm having problems scanning usb_endpoint '/dev's on older kernels, 2.6.13 in particular. The usb_endpoints are beyond the constant MAX_SYSFS_DEPTH somewhere under /sys. Is there any particular reason for scanning /sys/block and /sys/class separately other than to ascertain a nodes type? Assuming a particular /dev combination is unambiguous, one could scan the entire /sys tree without missing any '/dev's. I see three prerequisites. The first is to ignore links while traversing , the second is to drop the maximal search depth and last determine a nodes type by searching for '/block/' in the first len('/class/block/') characters in the resulting search path. A solution may however, result in longer scan times, but reduces executable size and code complexity. John Holland ___________________________________________ Cellent Finance Solutions AG Firmensitz: Calwer Stra?e 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080704/45cb4d0b/attachment-0001.htm From rep.dot.nop at gmail.com Fri Jul 4 07:36:04 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 4 Jul 2008 16:36:04 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> Message-ID: <20080704143604.GA2623@mx.loc> On Fri, Jul 04, 2008 at 09:55:48AM +0200, Jason Curl wrote: >Hello, > >I'd like to welcome comments on my first bb patch (it's the first I've needed to do since I've started using 1.0.0). I like the new "man" applet, but it needs nroff and gtbl. Unfortunately, I didn't prepare the c++ compiler and the gnu tools won't compile. No worry though, I've updated busybox to support "cat" pages also. This requires less space than installing all the GNU tools. > >The diff is applied, generated with "diff -au source modified". > >So, I have >/share/man/cat1 >/share/man/man1 > >It searches first in the "cat" pages and if it isn't found, then searches in the "man" pages. I'm sure there could be some optimisations made.... > >Thanks, >Jason. > >Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmf?hrer mit Movie Star Bewertungen von TV Movie. Au?erdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv >--- busybox-1.11.0/miscutils/man.c 2008-06-25 14:51:35.000000000 +0200 >+++ busybox-1.11.0_manpatch/miscutils/man.c 2008-07-04 09:47:58.000000000 +0200 >@@ -23,7 +23,7 @@ > > */ > >-static int run_pipe(const char *unpacker, const char *pager, char *man_filename) >+static int run_pipe(const char *unpacker, const char *pager, char *man_filename, int cat) > { > char *cmd; > >@@ -35,30 +35,34 @@ > return 1; > } > >- cmd = xasprintf("%s '%s' | gtbl | nroff -Tlatin1 -mandoc | %s", >- unpacker, man_filename, pager); >+ if (!cat) { >+ cmd = xasprintf("%s '%s' | gtbl | nroff -Tlatin1 -mandoc | %s", >+ unpacker, man_filename, pager); >+ } else { >+ cmd = xasprintf("%s '%s' | %s", unpacker, man_filename, pager); >+ } the parameter cat should probably be a smalluint (or bool). Perhaps try something like (pseudo-code): static const char const man_converter[]= "| gtbl | nroff -Tlatin1 -mandoc | %s"; cmd = xasprintf("%s '%s' | %s", unp,man_f,cat?man_converter:man_converter+32); > system(cmd); > free(cmd); > return 1; > } > > /* man_filename is of the form "/dir/dir/dir/name.s.bz2" */ >-static int show_manpage(const char *pager, char *man_filename) >+static int show_manpage(const char *pager, char *man_filename, int cat) > { > int len; > >- if (run_pipe("bunzip2 -c", pager, man_filename)) >+ if (run_pipe("bunzip2 -c", pager, man_filename, cat)) > return 1; > > len = strlen(man_filename) - 1; > > man_filename[len] = '\0'; /* ".bz2" -> ".gz" */ > man_filename[len - 2] = 'g'; >- if (run_pipe("gunzip -c", pager, man_filename)) >+ if (run_pipe("gunzip -c", pager, man_filename, cat)) > return 1; > > man_filename[len - 3] = '\0'; /* ".gz" -> "" */ >- if (run_pipe("cat", pager, man_filename)) >+ if (run_pipe("cat", pager, man_filename, cat)) > return 1; > > return 0; >@@ -134,14 +138,27 @@ > do { /* for each section */ > char *next_sect = strchrnul(cur_sect, ':'); > int sect_len = next_sect - cur_sect; >+ char *man_filename; >+ int found; > >- char *man_filename = xasprintf("%.*s/man%.*s/%s.%.*s" ".bz2", >- path_len, cur_path, >- sect_len, cur_sect, >- *argv, >- sect_len, cur_sect); >- int found = show_manpage(pager, man_filename); >+ /* Search for CAT page first */ >+ man_filename = xasprintf("%.*s/cat%.*s/%s.%.*s" ".bz2", It could be smaller to pass "cat" and "man" in here, since we could use the same fmt-string for both then. And you really need to fix the indentation :) Please resend (and include figures for size(1) with and without your patch, eventually ./scripts/bloat-o-meter output too). TIA >+ path_len, cur_path, >+ sect_len, cur_sect, >+ *argv, >+ sect_len, cur_sect); >+ found = show_manpage(pager, man_filename, 1); > free(man_filename); >+ >+ if (!found) { >+ man_filename = xasprintf("%.*s/man%.*s/%s.%.*s" ".bz2", >+ path_len, cur_path, >+ sect_len, cur_sect, >+ *argv, >+ sect_len, cur_sect); >+ found = show_manpage(pager, man_filename, 0); >+ free(man_filename); >+ } > if (found && !(opt & OPT_a)) > goto next_arg; > cur_sect = next_sect; >_______________________________________________ >busybox mailing list >busybox at busybox.net >http://busybox.net/cgi-bin/mailman/listinfo/busybox From jcurlnews at arcor.de Fri Jul 4 13:36:57 2008 From: jcurlnews at arcor.de (Jason Curl) Date: Fri, 04 Jul 2008 22:36:57 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <200807041208.25148.vda.linux@googlemail.com> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> <200807041208.25148.vda.linux@googlemail.com> Message-ID: <486E89E9.4090509@arcor.de> Denys Vlasenko wrote: > On Friday 04 July 2008 09:55, Jason Curl wrote: > >> Hello, >> >> I'd like to welcome comments on my first bb patch >> > > It's using spaces for indentation. Otherwise looks ok. > OK, I'll fix this. > >> (it's the first I've needed to do since I've started >> using 1.0.0). I like the new "man" applet, but it >> needs nroff and gtbl. Unfortunately, I didn't prepare >> the c++ compiler and the gnu tools won't compile. >> No worry though, I've updated busybox to support >> "cat" pages also. This requires less space than >> installing all the GNU tools. >> > > Ideally, some simplified replacement for nroff+gtbl > would be cool. > I've seem to found a bug while testing man in a bit more detail. It looks like the line alloc_mp = 10; /* this doesn't appear to initialise the array to NULL pointers */ man_path_list = xmalloc(10 * sizeof(man_path_list[0])); count_mp = 0; man_path_list[0] = xstrdup(getenv("MANPATH")); doesn't initialise the array to zero in my case (indicating NULL pointers). So as this array gets built up while parsing "/etc/man.conf" it assumes that it was previously NULL. if (strcmp("MANPATH", line) == 0) { man_path_list[count_mp] = xstrdup(value); count_mp++; if (alloc_mp == count_mp) { alloc_mp += 10; man_path_list = xrealloc(man_path_list, alloc_mp * sizeof(man_path_list[0])); } /* thus man_path_list is always NULL terminated */ That last comment doesn't seem to hold true. Then the final while loop checks while ((cur_path = man_path_list[cur_mp++]) != NULL) { and it turns out that uninitialised data is compared against NULL which fails, enters the loop again and dies with a segfault. So the solution appears to be if (cf) { .. } man_path_list[count_mp] = NULL; This fixes my segfault. > -- > vda > > From jcurlnews at arcor.de Fri Jul 4 14:00:22 2008 From: jcurlnews at arcor.de (Jason Curl) Date: Fri, 04 Jul 2008 23:00:22 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <20080704143604.GA2623@mx.loc> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> <20080704143604.GA2623@mx.loc> Message-ID: <486E8F66.1090309@arcor.de> Hello BB, New patch attached. There was a bug that I reported in a previous email that's also included in this patch (a one-liner so I didn't bother generating a patch for that only). Cheers, Jason. Bernhard Fischer wrote: > On Fri, Jul 04, 2008 at 09:55:48AM +0200, Jason Curl wrote: > >> Hello, >> >> I'd like to welcome comments on my first bb patch (it's the first I've needed to do since I've started using 1.0.0). I like the new "man" applet, but it needs nroff and gtbl. Unfortunately, I didn't prepare the c++ compiler and the gnu tools won't compile. No worry though, I've updated busybox to support "cat" pages also. This requires less space than installing all the GNU tools. >> >> The diff is applied, generated with "diff -au source modified". >> >> So, I have >> /share/man/cat1 >> /share/man/man1 >> >> It searches first in the "cat" pages and if it isn't found, then searches in the "man" pages. I'm sure there could be some optimisations made.... >> >> Thanks, >> Jason. >> >> --- busybox-1.11.0/miscutils/man.c 2008-06-25 14:51:35.000000000 +0200 >> +++ busybox-1.11.0_manpatch/miscutils/man.c 2008-07-04 09:47:58.000000000 +0200 >> @@ -23,7 +23,7 @@ >> >> */ >> >> -static int run_pipe(const char *unpacker, const char *pager, char *man_filename) >> +static int run_pipe(const char *unpacker, const char *pager, char *man_filename, int cat) >> { >> char *cmd; >> >> @@ -35,30 +35,34 @@ >> return 1; >> } >> >> - cmd = xasprintf("%s '%s' | gtbl | nroff -Tlatin1 -mandoc | %s", >> - unpacker, man_filename, pager); >> + if (!cat) { >> + cmd = xasprintf("%s '%s' | gtbl | nroff -Tlatin1 -mandoc | %s", >> + unpacker, man_filename, pager); >> + } else { >> + cmd = xasprintf("%s '%s' | %s", unpacker, man_filename, pager); >> + } >> > > the parameter cat should probably be a smalluint (or bool). > Perhaps try something like (pseudo-code): > static const char const man_converter[]= > "| gtbl | nroff -Tlatin1 -mandoc | %s"; > cmd = xasprintf("%s '%s' | %s", > unp,man_f,cat?man_converter:man_converter+32); > I've changed it to a smalluint and removed some of the spacing due to format strings. > >> system(cmd); >> free(cmd); >> return 1; >> } >> >> /* man_filename is of the form "/dir/dir/dir/name.s.bz2" */ >> -static int show_manpage(const char *pager, char *man_filename) >> +static int show_manpage(const char *pager, char *man_filename, int cat) >> { >> int len; >> >> - if (run_pipe("bunzip2 -c", pager, man_filename)) >> + if (run_pipe("bunzip2 -c", pager, man_filename, cat)) >> return 1; >> >> len = strlen(man_filename) - 1; >> >> man_filename[len] = '\0'; /* ".bz2" -> ".gz" */ >> man_filename[len - 2] = 'g'; >> - if (run_pipe("gunzip -c", pager, man_filename)) >> + if (run_pipe("gunzip -c", pager, man_filename, cat)) >> return 1; >> >> man_filename[len - 3] = '\0'; /* ".gz" -> "" */ >> - if (run_pipe("cat", pager, man_filename)) >> + if (run_pipe("cat", pager, man_filename, cat)) >> return 1; >> >> return 0; >> @@ -134,14 +138,27 @@ >> do { /* for each section */ >> char *next_sect = strchrnul(cur_sect, ':'); >> int sect_len = next_sect - cur_sect; >> + char *man_filename; >> + int found; >> >> - char *man_filename = xasprintf("%.*s/man%.*s/%s.%.*s" ".bz2", >> - path_len, cur_path, >> - sect_len, cur_sect, >> - *argv, >> - sect_len, cur_sect); >> - int found = show_manpage(pager, man_filename); >> + /* Search for CAT page first */ >> + man_filename = xasprintf("%.*s/cat%.*s/%s.%.*s" ".bz2", >> > > It could be smaller to pass "cat" and "man" in here, since we could use > the same fmt-string for both then. > Now in a loop. > And you really need to fix the indentation :) > I hope I caught all of them. > Please resend (and include figures for size(1) with and without your > patch, eventually ./scripts/bloat-o-meter output too). > I didn't have luck with the bloat-o-meter. It gave me weird results with differences where nothing was changed. So I'll have to look into it further.... > TIA > -------------- next part -------------- A non-text attachment was scrubbed... Name: mancat.patch Type: text/x-diff Size: 2463 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080704/cfa4d5f3/attachment.patch From vda.linux at googlemail.com Fri Jul 4 14:17:43 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Jul 2008 23:17:43 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <486E89E9.4090509@arcor.de> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> <200807041208.25148.vda.linux@googlemail.com> <486E89E9.4090509@arcor.de> Message-ID: <200807042317.43163.vda.linux@googlemail.com> On Friday 04 July 2008 22:36, Jason Curl wrote: > Denys Vlasenko wrote: > > On Friday 04 July 2008 09:55, Jason Curl wrote: > > > >> Hello, > >> > >> I'd like to welcome comments on my first bb patch > >> > > > > It's using spaces for indentation. Otherwise looks ok. > > > OK, I'll fix this. > > > >> (it's the first I've needed to do since I've started > >> using 1.0.0). I like the new "man" applet, but it > >> needs nroff and gtbl. Unfortunately, I didn't prepare > >> the c++ compiler and the gnu tools won't compile. > >> No worry though, I've updated busybox to support > >> "cat" pages also. This requires less space than > >> installing all the GNU tools. > >> > > > > Ideally, some simplified replacement for nroff+gtbl > > would be cool. > > > > I've seem to found a bug while testing man in a bit more detail. It > looks like the line > alloc_mp = 10; > /* this doesn't appear to initialise the array to NULL pointers */ > man_path_list = xmalloc(10 * sizeof(man_path_list[0])); > count_mp = 0; > man_path_list[0] = xstrdup(getenv("MANPATH")); > > doesn't initialise the array to zero in my case (indicating NULL > pointers). So as this array gets built up while parsing "/etc/man.conf" > it assumes that it was previously NULL. > if (strcmp("MANPATH", line) == 0) { > man_path_list[count_mp] = xstrdup(value); > count_mp++; > if (alloc_mp == count_mp) { > alloc_mp += 10; > man_path_list = xrealloc(man_path_list, alloc_mp > * sizeof(man_path_list[0])); > } > /* thus man_path_list is always NULL terminated */ > > That last comment doesn't seem to hold true. > > Then the final while loop checks > while ((cur_path = man_path_list[cur_mp++]) != NULL) { > > and it turns out that uninitialised data is compared against NULL which > fails, enters the loop again and dies with a segfault. > > So the solution appears to be > if (cf) { > .. > } > man_path_list[count_mp] = NULL; > > This fixes my segfault. Plase try this patch. It has an advantage of also making code smaller. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 6.patch Type: text/x-diff Size: 1608 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080704/779d6c49/attachment.patch From vda.linux at googlemail.com Fri Jul 4 14:55:10 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Jul 2008 23:55:10 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> Message-ID: <200807042355.10143.vda.linux@googlemail.com> On Friday 04 July 2008 09:55, Jason Curl wrote: > Hello, > > I'd like to welcome comments on my first bb patch (it's the first I've needed to do since I've started using 1.0.0). I like the new "man" applet, but it needs nroff and gtbl. Unfortunately, I didn't prepare the c++ compiler and the gnu tools won't compile. No worry though, I've updated busybox to support "cat" pages also. This requires less space than installing all the GNU tools. > > The diff is applied, generated with "diff -au source modified". > > So, I have > /share/man/cat1 > /share/man/man1 > > It searches first in the "cat" pages and if it isn't found, then searches in the "man" pages. I'm sure there could be some optimisations made.... I am applying your patch after fixing whitespace. I also discovered that it is not against current svn. Next time, please make a diff against svn, ok? -- vda From vda.linux at googlemail.com Fri Jul 4 15:07:20 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 5 Jul 2008 00:07:20 +0200 Subject: mdev scan In-Reply-To: References: Message-ID: <200807050007.20655.vda.linux@googlemail.com> On Friday 04 July 2008 13:39, Holland, John wrote: > Hi, > > I'm having problems scanning usb_endpoint '/dev's on older kernels, 2.6.13 in particular. > The usb_endpoints are beyond the constant MAX_SYSFS_DEPTH somewhere under /sys. How much is ok on those kernels? 4? 5? > Is there any particular reason for scanning /sys/block and /sys/class separately other than > to ascertain a nodes type? I guess scanning whole /sys will go into e.g. /sys/module too and it can be rather deep. > Assuming a particular /dev combination is unambiguous, one could scan the entire /sys tree > without missing any '/dev's. I see three prerequisites. Can you re-formulate your thoughts is a simpler way? By now, I don't understand what is the problem you are trying to solve. > The first is to ignore links while traversing, Yeah, pity mdev author forgot to document why ACTION_FOLLOWLINKS is necessary (example would be most useful). Now we need to guess whether it's real necessity or just an oversight... > the second is to drop the maximal search depth and last determine a nodes type by searching > for '/block/' in the first len('/class/block/') characters in the resulting search path. > > A solution may however, result in longer scan times, but reduces executable size and code complexity. Solution for what problem? -- vda From vda.linux at googlemail.com Fri Jul 4 15:36:25 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 5 Jul 2008 00:36:25 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <486E8F66.1090309@arcor.de> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> <20080704143604.GA2623@mx.loc> <486E8F66.1090309@arcor.de> Message-ID: <200807050036.25995.vda.linux@googlemail.com> On Friday 04 July 2008 23:00, Jason Curl wrote: > Hello BB, > > New patch attached. There was a bug that I reported in a previous email > that's also included in this patch (a one-liner so I didn't bother > generating a patch for that only). Applied, thanks. -- vda From jcurlnews at arcor.de Sat Jul 5 02:02:40 2008 From: jcurlnews at arcor.de (Jason Curl) Date: Sat, 05 Jul 2008 11:02:40 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <200807042355.10143.vda.linux@googlemail.com> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> <200807042355.10143.vda.linux@googlemail.com> Message-ID: <486F38B0.8020609@arcor.de> Denys Vlasenko wrote: > On Friday 04 July 2008 09:55, Jason Curl wrote: >> The diff is applied, generated with "diff -au source modified". >> >> So, I have >> /share/man/cat1 >> /share/man/man1 >> >> It searches first in the "cat" pages and if it isn't found, then searches in the "man" pages. I'm sure there could be some optimisations made.... >> > > I am applying your patch after fixing whitespace. > I also discovered that it is not against current svn. > Next time, please make a diff against svn, ok? > -- > vda > > I've checked your fix Denys and it also works (I don't get segfaults anymore). I've taken the code from my second patch, checked it against the latest snapshot and found I can reduce the size of man a bit more by removing the two instances of the format string when generating the man filename. I think the code is much more cryptic, but it's a small piece. function old new delta man_main 732 802 +70 show_manpage 111 - -111 ------------------------------------------------------------------------------ (add/remove: 0/1 grow/shrink: 1/0 up/down: 70/-111) Total: -41 bytes text data bss dec hex filename 1369158 2493 19292 1390943 15395f busybox_old 1369117 2493 19292 1390902 153936 busybox_unstripped Thanks, Jason. -------------- next part -------------- A non-text attachment was scrubbed... Name: man.patch Type: text/x-diff Size: 1296 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080705/795ebbd6/attachment-0001.patch From vda.linux at googlemail.com Sat Jul 5 02:25:37 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 5 Jul 2008 11:25:37 +0200 Subject: BusyBox 1.11.0 man patch for "cat" In-Reply-To: <486F38B0.8020609@arcor.de> References: <5873706.1215158148018.JavaMail.ngmail@webmail18.arcor-so.net> <200807042355.10143.vda.linux@googlemail.com> <486F38B0.8020609@arcor.de> Message-ID: <200807051125.37760.vda.linux@googlemail.com> On Saturday 05 July 2008 11:02, Jason Curl wrote: > I've checked your fix Denys and it also works (I don't get segfaults > anymore). I've taken the code from my second patch, checked it against > the latest snapshot and found I can reduce the size of man a bit more by > removing the two instances of the format string when generating the man > filename. I think the code is much more cryptic, but it's a small piece. + int mode = 0; - /* Search for cat page first */ - man_filename = xasprintf("%.*s/%s%.*s/%s.%.*s" ".bz2", Interesting patch format. char *man_filename; - int found_here; + int mode = 0; - /* Search for cat page first */ - man_filename = xasprintf("%.*s/%s%.*s/%s.%.*s" ".bz2", - path_len, cur_path, - "cat", - sect_len, cur_sect, - *argv, - sect_len, cur_sect); - found_here = show_manpage(pager, man_filename, 1); - free(man_filename); - if (!found_here) { + /* We search first for a cat page, then for a man page */ + while (mode < 2) { man_filename = xasprintf("%.*s/%s%.*s/%s.%.*s" ".bz2", - path_len, cur_path, - "man", - sect_len, cur_sect, - *argv, - sect_len, cur_sect); - found_here = show_manpage(pager, man_filename, 0); + path_len, cur_path, + mode?"man":"cat", + sect_len, cur_sect, + *argv, + sect_len, cur_sect); + found = show_manpage(pager, man_filename, 1-mode); free(man_filename); + mode += found + 1; } - found |= found_here; if (found && !(opt & OPT_a)) goto next_arg; "found |= found_here;" was there for a reason: If no man page is found, we need to report that. With "man -a", we are getting false negative (found == 0) - man thinks that page is not found, whereas it's "page is not found _in last man directory_". But overall idea is good and I incorporated it in man.c now. Thanks. -- vda From Ralf.Friedl at online.de Sat Jul 5 05:34:57 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Sat, 05 Jul 2008 14:34:57 +0200 Subject: [PATCH] Write pid-file in httpd Message-ID: <486F6A71.6050204@online.de> This is a patch to create a pid-file when httpd is started. A pid-file is useful to stop httpd or to send SIGHUP to reload the config. The filename is passed as a parameter so that multiple instances can run at the same time, with different pid-files. It would also be possible to make this configurable. Regards Ralf Friedl --- networking/httpd.c +++ networking/httpd.c @@ -2270,6 +2270,7 @@ USE_FEATURE_HTTPD_BASIC_AUTH( r_opt_realm ,) USE_FEATURE_HTTPD_AUTH_MD5( m_opt_md5 ,) USE_FEATURE_HTTPD_SETUID( u_opt_setuid ,) + p_opt_pidfile , p_opt_port , p_opt_inetd , p_opt_foreground, @@ -2281,6 +2282,7 @@ OPT_REALM = USE_FEATURE_HTTPD_BASIC_AUTH( (1 << r_opt_realm )) + 0, OPT_MD5 = USE_FEATURE_HTTPD_AUTH_MD5( (1 << m_opt_md5 )) + 0, OPT_SETUID = USE_FEATURE_HTTPD_SETUID( (1 << u_opt_setuid )) + 0, + OPT_PIDFILE = 1 << p_opt_pidfile, OPT_PORT = 1 << p_opt_port, OPT_INETD = 1 << p_opt_inetd, OPT_FOREGROUND = 1 << p_opt_foreground, @@ -2294,6 +2296,7 @@ int server_socket = server_socket; /* for gcc */ unsigned opt; char *url_for_decode; + char *pidfilename; USE_FEATURE_HTTPD_ENCODE_URL_STR(const char *url_for_encode;) USE_FEATURE_HTTPD_SETUID(const char *s_ugid = NULL;) USE_FEATURE_HTTPD_SETUID(struct bb_uidgid_t ugid;) @@ -2317,12 +2320,14 @@ USE_FEATURE_HTTPD_BASIC_AUTH("r:") USE_FEATURE_HTTPD_AUTH_MD5("m:") USE_FEATURE_HTTPD_SETUID("u:") + "P:" "p:ifv", &configFile, &url_for_decode, &home_httpd USE_FEATURE_HTTPD_ENCODE_URL_STR(, &url_for_encode) USE_FEATURE_HTTPD_BASIC_AUTH(, &g_realm) USE_FEATURE_HTTPD_AUTH_MD5(, &pass) USE_FEATURE_HTTPD_SETUID(, &s_ugid) + , &pidfilename , &bind_addr_or_port , &verbose ); @@ -2403,6 +2408,8 @@ #if BB_MMU if (!(opt & OPT_FOREGROUND)) bb_daemonize(0); /* don't change current directory */ + if (opt & OPT_PIDFILE) + write_pidfile(pidfilename); mini_httpd(server_socket); /* never returns */ #else mini_httpd_nommu(server_socket, argc, argv); /* never returns */ From rob at landley.net Sat Jul 5 13:40:54 2008 From: rob at landley.net (Rob Landley) Date: Sat, 5 Jul 2008 15:40:54 -0500 Subject: Patch going "boing" in 1.11.0. Message-ID: <200807051540.54886.rob@landley.net> The attached patch applies to the linux-2.6.25 kernel source with Kubuntu's "patch" (and the one in toybox), but busybox patch fails. Just FYI. I'm finally getting around to trying a current busybox in my FWL build system thingy, and figuring out what's breaks... (I also needed svn 22578 to fix "awk -f -f" for the gcc build, but that's already in svn...) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-2.6.13-cmdline.patch Type: text/x-diff Size: 478 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080705/fd510a42/attachment.patch From rob at landley.net Sat Jul 5 13:48:42 2008 From: rob at landley.net (Rob Landley) Date: Sat, 5 Jul 2008 15:48:42 -0500 Subject: =?utf-8?b?0J7RgtCy0LXRgjo=?= SENDMAIL In-Reply-To: <200806301720.06165.vda.linux@googlemail.com> References: <48661114.12054e0a.66f5.ffffa499@mx.google.com> <6784529b0806290231v5c4c4d77g32376aae22eba9d3@mail.gmail.com> <200806301720.06165.vda.linux@googlemail.com> Message-ID: <200807051548.44138.rob@landley.net> On Monday 30 June 2008 10:20:06 Denys Vlasenko wrote: > On Sunday 29 June 2008 11:31, Vladimir Dronnikov wrote: > > Q: I'm getting crazy of what people meant when they invented sendmail > > interface: where sender address is supposed to be obtained from? From > > OPTIONAL -f parameter? From 'From: ' header? From $USER being appended > > by ?$HOSTNAME? From [user:pass@]host[:port]?! Mail servers require > > ADDRESS not username to be passed with EHLO/HELO. > > Hehe. sendmail was a disaster. Harrowing tales > of sendmail.cf format which resulted in lines consisting > mostly of punctuation chars are still being told. > > IIRC it also had tons of security holes. > > The most sad part, I was reading an interview with the guy > who wrote it. Neither interviewer asked "How on earth you decided > to make such config format" etc nor the auther had guts > to tone down interviewer and admit "well, actually take note that > sendmail was written many years ago. I was not as experienced > back then as I am today and sendmail's original design and code > are not exactly too good. Today I'd do it much differently > and better..." > > In reality, interview was all rosy and sendmail was obviously > a cornerstone of Unix and a gem of programming art... Sendmail is a relic that's finally going the way of the original Netscape browser. The number of sites running sendmail has declined significantly over the past few years, last year sendmail use had fallen to about 12%: http://www.oreillynet.com/pub/a/sysadmin/2007/01/05/fingerprinting-mail-servers.html Postfix is #2, followed by Google's Postini, then Exchange... I wouldn't look at how sendmail does anything for a model, I'd look how _postfix_ does it. :) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From rob at landley.net Sat Jul 5 13:56:59 2008 From: rob at landley.net (Rob Landley) Date: Sat, 5 Jul 2008 15:56:59 -0500 Subject: [PATCH] start-stop-daemon: close extra fds on --background In-Reply-To: <200807011521.51229.vda.linux@googlemail.com> References: <4869EA6A.8060901@bridgeco.net> <200807011155.21382.roy@marples.name> <200807011521.51229.vda.linux@googlemail.com> Message-ID: <200807051557.00273.rob@landley.net> On Tuesday 01 July 2008 08:21:51 Denys Vlasenko wrote: > On Tuesday 01 July 2008 12:55, Roy Marples wrote: > > On Tuesday 01 July 2008 13:44:52 Denys Vlasenko wrote: > > > On Tuesday 01 July 2008 12:25, Roy Marples wrote: > > > > On Tuesday 01 July 2008 13:01:56 Denys Vlasenko wrote: > > > > > ssd: do not stat -x EXECUTABLE, it is not needed anymore > > > > > > > > Then userland won't catch an error with ssd --background when the > > > > file does not exit :/ > > > > > > > > Please re-consider this. > > > > > > With that stat(), even "start-stop-daemon -S -x true" does not work. > > > > ssd has historically required the full path when starting daemons. > > As I see it: > > Historically, surprising percentage of Unix admins > have no clue why $PATH is useful. Whenever they meet > a configuration problem causing PATH search to not find their > utility, they "fix" it by using full path. > Whereas correct fix is to fix $PATH or copy/move/symplink > executable to one of the directories which are in $PATH! > > That cluelessness is the prime cause why so many scripts > are littered with e.g. "/usr/sbin/sendmail" instead > of just "sendmail". Or, in the linux kernel's scripts/mkcompile.h: > if [ -x /bin/dnsdomainname ]; then > echo \#define LINUX_COMPILE_DOMAIN \"`dnsdomainname | $UTS_TRUNCATE`\" > elif [ -x /bin/domainname ]; then > echo \#define LINUX_COMPILE_DOMAIN \"`domainname | $UTS_TRUNCATE`\" > else > echo \#define LINUX_COMPILE_DOMAIN > fi I hit that earlier today: /bin/dnsdomainname is there but it's not in $PATH... > It is not a matter of aestetics. It is a matter of making your scripts > independent of where executables are stored on this particular machine. To me, it's a matter of doing the right thing... Rob P.S. Last time I saw a patch to compile the linux kernel under MacOS X, it was quite large... -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From rob at landley.net Sat Jul 5 14:03:14 2008 From: rob at landley.net (Rob Landley) Date: Sat, 5 Jul 2008 16:03:14 -0500 Subject: [PATCH] really close all extra fds in bb_daemonize_or_rexec In-Reply-To: <4869EA37.7020807@bridgeco.net> References: <4869EA37.7020807@bridgeco.net> Message-ID: <200807051603.15213.rob@landley.net> On Tuesday 01 July 2008 03:26:31 Andreas Wetzel wrote: > hi, > > the current implementation seems not to reliably close all open file > descriptors if the flag DAEMON_CLOSE_EXTRA_FDS is set. it is assumed, > that the fd returned by opening a file (bb_dev_null) is the top-most fd, > but this is not true. open returns the first free fd. so, potentially, > some fds remain open. > > the attached patch fixes this by calling close() on every possible file > descriptor (diffed against the busybox_1_9_stable branch). I wonder how that interacts with the non-sequential file descriptor stuff? (I never did follow to see if it was merged, but http://lwn.net/Articles/237722/ is a starting point.) Personally, I'd probably just iterate through /proc/$PID/fd and use the actual list of the process's open file descriptors to know what to close. But I can see the potential downsides of that probably being larger and depending on /proc. (Not that getdtablesize is the most portable call out there either, considering that even when it exists it can return INT_MAX...) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From rob at landley.net Sat Jul 5 16:13:28 2008 From: rob at landley.net (Rob Landley) Date: Sat, 5 Jul 2008 18:13:28 -0500 Subject: mdev scan In-Reply-To: <200807050007.20655.vda.linux@googlemail.com> References: <200807050007.20655.vda.linux@googlemail.com> Message-ID: <200807051813.29873.rob@landley.net> On Friday 04 July 2008 17:07:20 Denys Vlasenko wrote: > On Friday 04 July 2008 13:39, Holland, John wrote: > > Hi, > > > > I'm having problems scanning usb_endpoint '/dev's on older kernels, > > 2.6.13 in particular. The usb_endpoints are beyond the constant > > MAX_SYSFS_DEPTH somewhere under /sys. > > How much is ok on those kernels? 4? 5? Why is there a MAX_SYSFS_DEPTH? PATH_MAX is 1 page (4096 bytes) and that's the size of the buffer I originally allocated... > > Is there any particular reason for scanning /sys/block and /sys/class > > separately other than to ascertain a nodes type? > > I guess scanning whole /sys will go into e.g. /sys/module too > and it can be rather deep. Looking at arbitrary parts of sysfs has no defined semantics. There's nothing to say you won't find a "dev" node that isn't. > > The first is to ignore links while traversing, > > Yeah, pity mdev author forgot to document why ACTION_FOLLOWLINKS > is necessary (example would be most useful). What's ACTION_FOLLOWLINKS? I don't see it in the 1.10.0 util-linux/mdev.c... > Now we need to guess whether it's real necessity or just an oversight... I'm not quite sure what the question was here, or whether or not I'm the author you're referring to or somebody who's modified it since, but in general, recursing arbitrarily deep while following symlinks in sysfs will lead to endless loops on certain kernel versions. (Specifically following the "device" symlink can lead to an infinite recursion on some kernels. On other kernels, _everything_ under "block" and "class" is a symlink to a directory under devices.) The sysfs authors consider the /sys directory to exist for udev and for no other purpose, and they think it's ok to force you to upgrade udev when you upgrade a kernel. This is an export to userspace _without_ a documented or stable API. I made it work with a big hammer, and the toybox version of mdev has the semantics right for the 2.6.25 kernel, last I checked. > > the second is to drop the maximal search depth and last determine a nodes > > type by searching for '/block/' in the first len('/class/block/') > > characters in the resulting search path. > > > > A solution may however, result in longer scan times, but reduces > > executable size and code complexity. > > Solution for what problem? I'm kind of curious about that part myself... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From vda.linux at googlemail.com Sat Jul 5 23:00:19 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jul 2008 08:00:19 +0200 Subject: Patch going "boing" in 1.11.0. In-Reply-To: <200807051540.54886.rob@landley.net> References: <200807051540.54886.rob@landley.net> Message-ID: <200807060800.19723.vda.linux@googlemail.com> On Saturday 05 July 2008 22:40, Rob Landley wrote: > The attached patch applies to the linux-2.6.25 kernel source with > Kubuntu's "patch" (and the one in toybox), but busybox patch fails. With patch 2.5.4: # patch -p1 References: <200807050007.20655.vda.linux@googlemail.com> <200807051813.29873.rob@landley.net> Message-ID: <200807060842.23644.vda.linux@googlemail.com> On Sunday 06 July 2008 01:13, Rob Landley wrote: > On Friday 04 July 2008 17:07:20 Denys Vlasenko wrote: > > On Friday 04 July 2008 13:39, Holland, John wrote: > > > Hi, > > > > > > I'm having problems scanning usb_endpoint '/dev's on older kernels, > > > 2.6.13 in particular. The usb_endpoints are beyond the constant > > > MAX_SYSFS_DEPTH somewhere under /sys. > > > > How much is ok on those kernels? 4? 5? > > Why is there a MAX_SYSFS_DEPTH? PATH_MAX is 1 page (4096 bytes) and that's > the size of the buffer I originally allocated... It's a max depth to recurse, not a buffer size. > > > The first is to ignore links while traversing, > > > > Yeah, pity mdev author forgot to document why ACTION_FOLLOWLINKS > > is necessary (example would be most useful). > > What's ACTION_FOLLOWLINKS? I don't see it in the 1.10.0 util-linux/mdev.c... Here: int mdev_main(int argc, char **argv) { ... if (argc == 2 && !strcmp(argv[1],"-s")) { ... recursive_action("/sys/block", ACTION_RECURSE | ACTION_FOLLOWLINKS, fileAction, dirAction, temp, 0); recursive_action("/sys/class", ACTION_RECURSE | ACTION_FOLLOWLINKS, fileAction, dirAction, temp, 0); ... ACTION_FOLLOWLINKS was invented in 1.6.x in order to replace three bool params of recursive_action() with one bitmask. > > Now we need to guess whether it's real necessity or just an oversight... > > I'm not quite sure what the question was here, or whether or not I'm the > author you're referring to or somebody who's modified it since, but in No, the author is vapier: http://busybox.net/cgi-bin/viewcvs.cgi?rev=18811&view=rev Looking at it, it seems ACTION_FOLLOWLINKS is a mistake, because revision 18810 used lstat, not stat. -- vda From vda.linux at googlemail.com Sun Jul 6 00:08:54 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jul 2008 09:08:54 +0200 Subject: MODPROBE: next generation In-Reply-To: <6784529b0807052327i14acfa9bl3e551137380d3a9e@mail.gmail.com> References: <486d2e99.17044e0a.440a.612a@mx.google.com> <200807041226.43477.vda.linux@googlemail.com> <6784529b0807052327i14acfa9bl3e551137380d3a9e@mail.gmail.com> Message-ID: <200807060908.54951.vda.linux@googlemail.com> [CC: busybox at busybox.net] On Sunday 06 July 2008 08:27, Vladimir Dronnikov wrote: > Hello, Denys! > > Looked through modutils-small.c. Could you explain the changes you > made? I see the code became >500 bytes larger... I made the following changes: * directory scannig is done just once * if we find module to modprobe during dirscan, we immediately try to load it. If it succeeds, we exit. This makes modprobe MUCH faster in some quite coomon cases. * otherwise, we remember all module pathnames, so that we do not need to scan directory again. * If module was found but failed to load, we read ONLY that module's body, determine deps, scan in-memory list of modules, and try to load deps (recursively doing the same "read body, find deps" for each of them). * ONLY if module was not found by name, we read ALL module bodies and find alias names. Very time consuming. Still, as soon as alias is found, the module body reading stops (cuts time down by 50% on average). Then we try to load found module as above. I decided to get the above logic working correctly so that modprobe wouldn't scan whole module directory, and read each and every module in it on every call; and turn my attention to shrinking it later. -- vda From dronnikov at gmail.com Sun Jul 6 00:38:26 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Sun, 6 Jul 2008 07:38:26 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_MODPROBE:_next_generation?= In-Reply-To: <200807060908.54951.vda.linux@googlemail.com> References: <486d2e99.17044e0a.440a.612a@mx.google.com> <200807041226.43477.vda.linux@googlemail.com> <6784529b0807052327i14acfa9bl3e551137380d3a9e@mail.gmail.com> <200807060908.54951.vda.linux@googlemail.com> Message-ID: <6784529b0807060038u6335023bp478a52c785bf457e@mail.gmail.com> Understood. Well done! The only spiky edge I see in the following. At system startup when udevtrigger is called (or another technique of populating /dev is used) a lot of modprobes is called in parallel and they all have no plain module name specified. So they all need to go the most time-consuming branch of code: to read and parse on average the half of all modules. And the gain can be microscopic considering the growth in size. The ordinary use of modprobe after system has started up is not so time critical IMO. Is it? I propose to use intermediate dependencies storage (see the last patch). That way the very first modprobe will cache all dependencies once, so others will work very fast. The only problem is to block concurrent modprobes until the first is done (semaphores?). The fallback (say, when filesystem is RO) may result in just skipping of storage creating. -- Vladimir 2008/7/6, Denys Vlasenko : > [CC: busybox at busybox.net] > > On Sunday 06 July 2008 08:27, Vladimir Dronnikov wrote: >> Hello, Denys! >> >> Looked through modutils-small.c. Could you explain the changes you >> made? I see the code became >500 bytes larger... > > I made the following changes: > > * directory scannig is done just once > * if we find module to modprobe during dirscan, we immediately > try to load it. If it succeeds, we exit. This makes modprobe > MUCH faster in some quite coomon cases. > * otherwise, we remember all module pathnames, so that we > do not need to scan directory again. > * If module was found but failed to load, we read ONLY that > module's body, determine deps, scan in-memory list of modules, > and try to load deps (recursively doing the same > "read body, find deps" for each of them). > * ONLY if module was not found by name, we read ALL module > bodies and find alias names. Very time consuming. > Still, as soon as alias is found, the module body reading > stops (cuts time down by 50% on average). > Then we try to load found module as above. > > I decided to get the above logic working correctly so that > modprobe wouldn't scan whole module directory, and read > each and every module in it on every call; and turn > my attention to shrinking it later. > -- > vda > From vda.linux at googlemail.com Sun Jul 6 01:11:22 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jul 2008 10:11:22 +0200 Subject: =?koi8-r?q?=EF=D4=D7=C5=D4=3A_MODPROBE=3A_next?= generation In-Reply-To: <6784529b0807060038u6335023bp478a52c785bf457e@mail.gmail.com> References: <486d2e99.17044e0a.440a.612a@mx.google.com> <200807060908.54951.vda.linux@googlemail.com> <6784529b0807060038u6335023bp478a52c785bf457e@mail.gmail.com> Message-ID: <200807061011.22830.vda.linux@googlemail.com> On Sunday 06 July 2008 09:38, Vladimir Dronnikov wrote: > Understood. Well done! > > The only spiky edge I see in the following. At system startup when > udevtrigger is called (or another technique of populating /dev is > used) a lot of modprobes is called in parallel and they all have no > plain module name specified. So they all need to go the most > time-consuming branch of code: to read and parse on average the half > of all modules. And the gain can be microscopic considering the growth > in size. Are you saying they are called with module specified by alias? -- vda From dronnikov at gmail.com Sun Jul 6 04:31:59 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Sun, 6 Jul 2008 11:31:59 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_=EF=D4=D7=C5=D4:_MODPROBE:_next_generation?= In-Reply-To: <200807061011.22830.vda.linux@googlemail.com> References: <486d2e99.17044e0a.440a.612a@mx.google.com> <200807060908.54951.vda.linux@googlemail.com> <6784529b0807060038u6335023bp478a52c785bf457e@mail.gmail.com> <200807061011.22830.vda.linux@googlemail.com> Message-ID: <6784529b0807060431m15c883a3ubeb56be33a89162a@mail.gmail.com> Exactly. And the use of fnmatch() is definitely required, or we loose many modules, particularly PCI. -- Vladimir 2008/7/6, Denys Vlasenko : > On Sunday 06 July 2008 09:38, Vladimir Dronnikov wrote: >> Understood. Well done! >> >> The only spiky edge I see in the following. At system startup when >> udevtrigger is called (or another technique of populating /dev is >> used) a lot of modprobes is called in parallel and they all have no >> plain module name specified. So they all need to go the most >> time-consuming branch of code: to read and parse on average the half >> of all modules. And the gain can be microscopic considering the growth >> in size. > > Are you saying they are called with module specified by alias? > -- > vda > From vda.linux at googlemail.com Sun Jul 6 04:48:41 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jul 2008 13:48:41 +0200 Subject: =?koi8-r?b?79TXxdQ6IO/U18XUOiBNT0RQUk9CRTogbmV4dA==?= generation In-Reply-To: <6784529b0807060431m15c883a3ubeb56be33a89162a@mail.gmail.com> References: <486d2e99.17044e0a.440a.612a@mx.google.com> <200807061011.22830.vda.linux@googlemail.com> <6784529b0807060431m15c883a3ubeb56be33a89162a@mail.gmail.com> Message-ID: <200807061348.41948.vda.linux@googlemail.com> On Sunday 06 July 2008 13:31, Vladimir Dronnikov wrote: > Exactly. And the use of fnmatch() is definitely required, or we loose > many modules, particularly PCI. Like this? /* "modname alias1 symbol:sym1 alias2 symbol:sym2 " */ desc = xstrdup(modinfo[i].desc); /* Does matching substring exist? */ replace(desc, ' ', '\0'); for (s = desc; *s; s += strlen(s) + 1) { /* aliases in module bodies can be defined with * shell patterns. Example: * "pci:v000010DEd000000D9sv*sd*bc*sc*i*". * Plain strcmp() won't catch that */ if (fnmatch(s, alias, 0) == 0) { free(desc); dbg1_error_msg("found alias '%s' in module '%s'", alias, modinfo[i].pathname); return &modinfo[i]; } } -- vda From dronnikov at gmail.com Sun Jul 6 04:58:18 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Sun, 6 Jul 2008 11:58:18 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_=EF=D4=D7=C5=D4:_=EF=D4=D7=C5=D4:_MO?= =?KOI8-R?Q?DPROBE:_next_generation?= In-Reply-To: <200807061348.41948.vda.linux@googlemail.com> References: <486d2e99.17044e0a.440a.612a@mx.google.com> <200807061011.22830.vda.linux@googlemail.com> <6784529b0807060431m15c883a3ubeb56be33a89162a@mail.gmail.com> <200807061348.41948.vda.linux@googlemail.com> Message-ID: <6784529b0807060458m7f9a5aafn368945de159a5592@mail.gmail.com> Yes. You see some kind of grepping of all modules is needed at startup, so why not to perform it explicitly? On my system it is about 20 modprobe calls with pci: aliases. The time to resolve them currently is an order of magnitude longer than just to cache the definitions once and then use the cache. -- Vladimir 2008/7/6, Denys Vlasenko : > On Sunday 06 July 2008 13:31, Vladimir Dronnikov wrote: >> Exactly. And the use of fnmatch() is definitely required, or we loose >> many modules, particularly PCI. > > Like this? > > /* "modname alias1 symbol:sym1 alias2 symbol:sym2 " */ > desc = xstrdup(modinfo[i].desc); > /* Does matching substring exist? */ > replace(desc, ' ', '\0'); > for (s = desc; *s; s += strlen(s) + 1) { > /* aliases in module bodies can be defined with > * shell patterns. Example: > * "pci:v000010DEd000000D9sv*sd*bc*sc*i*". > * Plain strcmp() won't catch that */ > if (fnmatch(s, alias, 0) == 0) { > free(desc); > dbg1_error_msg("found alias '%s' in module > '%s'", > alias, modinfo[i].pathname); > return &modinfo[i]; > } > } > -- > vda > From dronnikov at gmail.com Sun Jul 6 07:06:53 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Sun, 6 Jul 2008 14:06:53 +0000 Subject: "mdev -s" fails to create /dev entries Message-ID: <6784529b0807060706r7a619362gf3d2f24a3fc24622@mail.gmail.com> In particular /sys/block/loop* are the symlinks and mdev -s ceased to mknod /dev/loop*. -- Vladimir From vda.linux at googlemail.com Sun Jul 6 09:12:33 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jul 2008 18:12:33 +0200 Subject: "mdev -s" fails to create /dev entries In-Reply-To: <6784529b0807060706r7a619362gf3d2f24a3fc24622@mail.gmail.com> References: <6784529b0807060706r7a619362gf3d2f24a3fc24622@mail.gmail.com> Message-ID: <200807061812.33688.vda.linux@googlemail.com> On Sunday 06 July 2008 16:06, Vladimir Dronnikov wrote: > In particular /sys/block/loop* are the symlinks and mdev -s ceased to > mknod /dev/loop*. Are you sure? # ls -l /sys/block/ drwxr-xr-x 5 root root 0 Jul 6 15:27 hdb drwxr-xr-x 4 root root 0 Jul 6 15:27 loop0 drwxr-xr-x 4 root root 0 Jul 6 15:27 loop1 drwxr-xr-x 4 root root 0 Jul 6 15:27 loop2 drwxr-xr-x 4 root root 0 Jul 6 15:27 loop3 drwxr-xr-x 4 root root 0 Jul 6 15:27 loop4 drwxr-xr-x 4 root root 0 Jul 6 15:27 loop5 drwxr-xr-x 4 root root 0 Jul 6 15:27 loop6 drwxr-xr-x 4 root root 0 Jul 6 15:27 loop7 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram0 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram1 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram10 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram11 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram12 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram13 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram14 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram15 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram2 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram3 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram4 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram5 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram6 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram7 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram8 drwxr-xr-x 4 root root 0 Jul 6 15:27 ram9 drwxr-xr-x 11 root root 0 Jul 6 15:27 sda # uname -a Linux shadow 2.6.26-rc8 #4 SMP PREEMPT Sat Jul 5 16:24:08 CEST 2008 x86_64 unknown Kernel .config is attached. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: .config.bz2 Type: application/x-bzip2 Size: 13157 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080706/68a805da/attachment-0001.bin From rob at landley.net Sun Jul 6 17:23:47 2008 From: rob at landley.net (Rob Landley) Date: Sun, 6 Jul 2008 19:23:47 -0500 Subject: mdev scan In-Reply-To: <200807060842.23644.vda.linux@googlemail.com> References: <200807051813.29873.rob@landley.net> <200807060842.23644.vda.linux@googlemail.com> Message-ID: <200807061923.48395.rob@landley.net> On Sunday 06 July 2008 01:42:23 Denys Vlasenko wrote: > > > > The first is to ignore links while traversing, > > > > > > Yeah, pity mdev author forgot to document why ACTION_FOLLOWLINKS > > > is necessary (example would be most useful). > > > > What's ACTION_FOLLOWLINKS? I don't see it in the 1.10.0 > > util-linux/mdev.c... > > Here: ... > recursive_action("/sys/block", > ACTION_RECURSE | ACTION_FOLLOWLINKS, > fileAction, dirAction, temp, 0); Ah, busybox has grown an equivalent of toybox's dirtree stuff since 1.2.2. I hadn't know that... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From rob at landley.net Sun Jul 6 17:35:45 2008 From: rob at landley.net (Rob Landley) Date: Sun, 6 Jul 2008 19:35:45 -0500 Subject: "mdev -s" fails to create /dev entries In-Reply-To: <6784529b0807060706r7a619362gf3d2f24a3fc24622@mail.gmail.com> References: <6784529b0807060706r7a619362gf3d2f24a3fc24622@mail.gmail.com> Message-ID: <200807061935.45353.rob@landley.net> On Sunday 06 July 2008 09:06:53 Vladimir Dronnikov wrote: > In particular /sys/block/loop* are the symlinks and mdev -s ceased to > mknod /dev/loop*. Keep in mind that sysfs keeps changing. It has no stable API. In toybox, my callback from dirtree_read() is doing: http://landley.net/hg/toybox/file/292/toys/mdev.c static int callback(char *path, struct dirtree *node) { // Entries in /sys/class/block aren't char devices, so skip 'em. (We'll // get block devices out of /sys/block.) if(!strcmp(node->name, "block")) return 1; // Does this directory have a "dev" entry in it? if (S_ISDIR(node->st.st_mode) || S_ISLNK(node->st.st_mode)) { char *dest = path+strlen(path); strcpy(dest, "/dev"); if (!access(path, R_OK)) make_device(path); *dest = 0; } // Circa 2.6.25 the entries more than 2 deep are all either redundant // (mouse#, event#) or unnamed (every usb_* entry is called "device"). return node->depth>1; } So essentially it recurses into /sys/class/*/* (but no deeper), skips any nodes named "block" (because /sys/class/block didn't used to exist, so we can't rely on it being there and have to check /sys/block to find block devices, but now it's a symlink to the same place as /sys/block so if we _do_ find it it does not contain char devices). I don't _think_ Greg KH and Kay Sievers are intentionally trying to break every other user of sysfs. It's probably just callous disregard rather than intentional malice... The "symlink vs non-symlink" thing used to be a reliable and simple indicator of what was interesting. And then they changed the kernel again. They've broken mdev something like 5 times since the first shell script version, by changing sysfs to have a different (still undocumented) API... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From pyrophobicman at gmail.com Sun Jul 6 19:52:03 2008 From: pyrophobicman at gmail.com (Poly-p man) Date: Sun, 6 Jul 2008 22:52:03 -0400 Subject: cttyhack question Message-ID: <20080707025203.GA14873@penguin.lan> I'm working on (almost done with) an init rewrite for my distro... I started getting the "no controlling tty" message as soon as I "fixed" my terminal opening code (close all fd's, open() the correct one, dup() twice)... The help message for cttyhack says that I can't open /dev/console... I didn't. In the case of the getty's I call, I open /dev/tty1 and /dev/tty2... Is there another fd I need to make? Is there any other fix I can do in my code to avoid this? I will post any of my code that you want to see... Thanks, poly-p man From natanael.copa at gmail.com Mon Jul 7 07:40:56 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Mon, 07 Jul 2008 16:40:56 +0200 Subject: [PATCH] indent comments in /etc/network/interfaces Message-ID: <1215441656.30926.35.camel@nc.nor.wtbts.org> Hi, Angry user reported that after upgrade (of my busybox/uclibc based distro Alpine) the ifup and ifdown utilites choked on his /etc/network/interfaces whenever comments where not on first comlumn. The comment in the code says: /* Let's try to be compatible. * * "man 5 interfaces" says: * Lines starting with "#" are ignored. Note that end-of-line * comments are NOT supported, comments must be on a line of their own. * A line may be extended across multiple lines by making * the last character a backslash. * * Seen elsewhere in example config file: * A "#" character in the very first column makes the rest of the line * be ignored. Blank lines are ignored. Lines may be indented freely. * A "\" character at the very end of the line indicates the next line * should be treated as a continuation of the current one. */ User claims that debian's ifup/ifdown have supported indent comments for ever. "Lines may be indented freely" seems to support that statement. Attatched patch fixes the issue and should not increase the size. Please commit to trunk and add to fixes-1.11.0. Thanks! -nc -------------- next part -------------- Index: networking/ifupdown.c =================================================================== --- networking/ifupdown.c (revision 22672) +++ networking/ifupdown.c (working copy) @@ -711,7 +711,7 @@ #endif rest_of_line = buf; first_word = next_word(&rest_of_line); - if (!first_word || *buf == '#') { + if (!first_word || *first_word == '#' ) { free(buf); continue; /* blank/comment line */ } From dronnikov at gmail.com Mon Jul 7 08:36:57 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Mon, 7 Jul 2008 15:36:57 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_[PATCH]_indent_commen?= =?KOI8-R?Q?ts_in_/etc/network/interfaces?= In-Reply-To: <1215441656.30926.35.camel@nc.nor.wtbts.org> References: <1215441656.30926.35.camel@nc.nor.wtbts.org> Message-ID: <6784529b0807070836t331596adw1126bfbcba81652@mail.gmail.com> I think we should at last invent a libbb function for dealing with parsing of config files. The zillions of config files are based on #-commented and \-continued lines. Almost all of them require then line-by-line processing of whitespaces delimited tokens. We already have got some examples (getopt32, recursiveAction, ...) which have clearly shown the fruitfullness of such an approach. Comments? -- Vladimir 2008/7/7, Natanael Copa : > Hi, > > Angry user reported that after upgrade (of my busybox/uclibc based > distro Alpine) the ifup and ifdown utilites choked on > his /etc/network/interfaces whenever comments where not on first > comlumn. > > The comment in the code says: > /* Let's try to be compatible. > * > * "man 5 interfaces" says: > * Lines starting with "#" are ignored. Note that end-of-line > * comments are NOT supported, comments must be on a line of their > own. > * A line may be extended across multiple lines by making > * the last character a backslash. > * > * Seen elsewhere in example config file: > * A "#" character in the very first column makes the rest of the > line > * be ignored. Blank lines are ignored. Lines may be indented > freely. > * A "\" character at the very end of the line indicates the next > line > * should be treated as a continuation of the current one. > */ > > > User claims that debian's ifup/ifdown have supported indent comments for > ever. > "Lines may be indented freely" seems to support that statement. > > Attatched patch fixes the issue and should not increase the size. > > Please commit to trunk and add to fixes-1.11.0. > > Thanks! > > -nc > From dronnikov at gmail.com Mon Jul 7 12:31:29 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Mon, 07 Jul 2008 12:31:29 -0700 (PDT) Subject: =?utf-8?B?TElCQkI6IHBhcnNlX2NvbmZpZygp?= Message-ID: <48726f11.21054e0a.2cea.26fa@mx.google.com> A helper function for parsing vanilla config files is added. I see mdev, crond and others can use it to uniformly process their configs. Typical usage: ----- CUT ----- void *data; char **token = parse_config(filename, 128, &data); // 128 tokens at most while (*token) { bb_error_msg("LINE---------"); while (*token) { bb_error_msg("TOKEN [%s]", *token); token++; } token++; } free(token); free(data); ----- CUT ----- Please, comment and consider applying. TIA, -- Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: parse.patch Type: application/octet-stream Size: 3790 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080707/d086d983/attachment.obj From rep.dot.nop at gmail.com Mon Jul 7 13:17:28 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 7 Jul 2008 22:17:28 +0200 Subject: LIBBB: parse_config() In-Reply-To: <48726f11.21054e0a.2cea.26fa@mx.google.com> References: <48726f11.21054e0a.2cea.26fa@mx.google.com> Message-ID: <20080707201728.GC17569@mx.loc> On Mon, Jul 07, 2008 at 12:31:29PM -0700, dronnikov at gmail.com wrote: >A helper function for parsing vanilla config files is added. >I see mdev, crond and others can use it to uniformly process their configs. It would be better if you would convert a few users to this new parse_config() and show the size-savings. The more you save, the more we all will like it :) Please don't forget to check that you don't accidentally introduce bugs in the course. cheers, From dronnikov at gmail.com Mon Jul 7 13:29:38 2008 From: dronnikov at gmail.com (Vladimir Dronnikov) Date: Mon, 7 Jul 2008 20:29:38 +0000 Subject: =?KOI8-R?Q?=EF=D4=D7=C5=D4:_LIBBB:_parse=5Fconfig()?= In-Reply-To: <20080707201728.GC17569@mx.loc> References: <48726f11.21054e0a.2cea.26fa@mx.google.com> <20080707201728.GC17569@mx.loc> Message-ID: <6784529b0807071329r680b4763le7cf97f2235ec4e5@mail.gmail.com> Sure :) But some help is needed. I am trying to convert inotifyd. mdev is "saint animal". Natanael mentioned ifup/down. There is crond that uses plain config. There gotta be savings en gros if we cope this together. -- Vladimir 2008/7/7, Bernhard Fischer : > On Mon, Jul 07, 2008 at 12:31:29PM -0700, dronnikov at gmail.com wrote: >>A helper function for parsing vanilla config files is added. >>I see mdev, crond and others can use it to uniformly process their configs. > > It would be better if you would convert a few users to this new > parse_config() and show the size-savings. The more you save, the more we > all will like it :) > > Please don't forget to check that you don't accidentally introduce bugs > in the course. > > cheers, > From John.Holland at cellent-fs.de Mon Jul 7 14:25:38 2008 From: John.Holland at cellent-fs.de (Holland, John) Date: Mon, 7 Jul 2008 23:25:38 +0200 Subject: mdev scan References: <200807050007.20655.vda.linux@googlemail.com> Message-ID: >> I'm having problems scanning usb_endpoint '/dev's on older kernels, 2.6.13 in particular. >> The usb_endpoints are beyond the constant MAX_SYSFS_DEPTH somewhere under /sys. > >How much is ok on those kernels? 4? 5? 5 would be good, but then I have problems with circular recursion. >> Is there any particular reason for scanning /sys/block and /sys/class separately other than >> to ascertain a nodes type? > >I guess scanning whole /sys will go into e.g. /sys/module too >and it can be rather deep. It would prolong scan times. I think it doesn't matter if a scan is little longer. >> Assuming a particular /dev combination is unambiguous, one could scan the entire /sys tree >> without missing any '/dev's. I see three prerequisites. > >Can you re-formulate your thoughts is a simpler way? By now, I don't >understand what is the problem you are trying to solve. ... >Solution for what problem? I can try... My problem is that some dev files are too deep in the /sys tree to be caught by the default mdev definition. When I increase the maximum depth to say 5, I have problems with circular recursion. Being that the dev files can be found elsewhere in the /sys tree albeit deeper and without following links, I wanted to solve the problem as previously stated. John ___________________________________________ Cellent Finance Solutions AG Firmensitz: Calwer Stra?e 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080707/2aa1ed9d/attachment.htm From John.Holland at cellent-fs.de Mon Jul 7 15:49:09 2008 From: John.Holland at cellent-fs.de (Holland, John) Date: Tue, 8 Jul 2008 00:49:09 +0200 Subject: mdev scan References: <200807050007.20655.vda.linux@googlemail.com> Message-ID: Because a picture is worth a thousand words... --- util-linux/mdev.c 2008-07-01 17:34:50.000000000 +0200 +++ util-linux/mdev.c.new 2008-07-08 00:16:36.000000000 +0200 @@ -21,8 +21,6 @@ #define root_major (G.root_major) #define root_minor (G.root_minor) -#define MAX_SYSFS_DEPTH 3 /* prevent infinite loops in /sys symlinks */ - /* We use additional 64+ bytes in make_device() */ #define SCRATCH_SIZE 80 @@ -76,11 +74,10 @@ * "/sys/block/..." is for block devices. "/sys/bus" etc is not! * Since kernel 2.6.25 block devices are also in /sys/class/block. */ /* TODO: would it be acceptable to just use strstr(path, "/block/")? */ - if (strncmp(&path[5], "class/block/"+6, 6) != 0 - && strncmp(&path[5], "class/block/", 12) != 0) - type = S_IFCHR; + if (NULL == strstr(&path[5], "/block/")) + type = S_IFCHR; else - type = S_IFBLK; + type = S_IFBLK; if (ENABLE_FEATURE_MDEV_CONF) { FILE *fp; @@ -315,15 +312,6 @@ return TRUE; } -/* Directory callback for /sys/ traversal */ -static int dirAction(const char *fileName ATTRIBUTE_UNUSED, - struct stat *statbuf ATTRIBUTE_UNUSED, - void *userData ATTRIBUTE_UNUSED, - int depth) -{ - return (depth >= MAX_SYSFS_DEPTH ? SKIP : TRUE); -} - /* For the full gory details, see linux/Documentation/firmware_class/README * * Firmware loading works like this: @@ -401,13 +389,8 @@ root_major = major(st.st_dev); root_minor = minor(st.st_dev); - recursive_action("/sys/block", - ACTION_RECURSE | ACTION_FOLLOWLINKS, - fileAction, dirAction, temp, 0); - - recursive_action("/sys/class", - ACTION_RECURSE | ACTION_FOLLOWLINKS, - fileAction, dirAction, temp, 0); + recursive_action("/sys", ACTION_RECURSE, + fileAction, NULL, temp, 0); } else { /* Hotplug: The patch has been tested on 2.6.19.2 kernel. I hope to get it tested on 2.6.13 in the coming week. John ___________________________________________ Cellent Finance Solutions AG Firmensitz: Calwer Stra?e 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080708/e1a1addd/attachment-0001.htm From John.Holland at cellent-fs.de Mon Jul 7 16:06:20 2008 From: John.Holland at cellent-fs.de (Holland, John) Date: Tue, 8 Jul 2008 01:06:20 +0200 Subject: mdev scan References: <200807050007.20655.vda.linux@googlemail.com> Message-ID: oops... + if (NULL == strstr(&path[5], "/block/")) should be + if (NULL == strstr(&path[4], "/block/")) John ___________________________________________ Cellent Finance Solutions AG Firmensitz: Calwer Stra?e 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080708/3930dfd1/attachment.htm From vda.linux at googlemail.com Mon Jul 7 20:26:52 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 8 Jul 2008 05:26:52 +0200 Subject: [PATCH] indent comments in /etc/network/interfaces In-Reply-To: <1215441656.30926.35.camel@nc.nor.wtbts.org> References: <1215441656.30926.35.camel@nc.nor.wtbts.org> Message-ID: <200807080526.52038.vda.linux@googlemail.com> On Monday 07 July 2008 16:40, Natanael Copa wrote: > Hi, > > Angry user reported that after upgrade (of my busybox/uclibc based > distro Alpine) the ifup and ifdown utilites choked on > his /etc/network/interfaces whenever comments where not on first > comlumn. > > The comment in the code says: > /* Let's try to be compatible. > * > * "man 5 interfaces" says: > * Lines starting with "#" are ignored. Note that end-of-line > * comments are NOT supported, comments must be on a line of their own. > * A line may be extended across multiple lines by making > * the last character a backslash. > * > * Seen elsewhere in example config file: > * A "#" character in the very first column makes the rest of the line > * be ignored. Blank lines are ignored. Lines may be indented freely. > * A "\" character at the very end of the line indicates the next line > * should be treated as a continuation of the current one. > */ > > > User claims that debian's ifup/ifdown have supported indent comments for ever. > "Lines may be indented freely" seems to support that statement. > > Attatched patch fixes the issue and should not increase the size. Pity it did not fix the comment ;) > Please commit to trunk and add to fixes-1.11.0. Applied, thanks! -- vda From vda.linux at googlemail.com Mon Jul 7 20:47:53 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 8 Jul 2008 05:47:53 +0200 Subject: LIBBB: parse_config() In-Reply-To: <48726f11.21054e0a.2cea.26fa@mx.google.com> References: <48726f11.21054e0a.2cea.26fa@mx.google.com> Message-ID: <200807080547.54009.vda.linux@googlemail.com> [CC: busybox at busybox.net] On Monday 07 July 2008 21:31, dronnikov at gmail.com wrote: > Please, comment and consider applying. +static void FAST_FUNC replace(char *s, char what, char with) You do not need FAST_FUNCs on static functions. gcc does it itself. At least I try to believe gcc will pick the most optimal ABI for them without help... +char FAST_FUNC **parse_config( + const char *filename, // name of config file to parse + int ntokens, // required amount of tokens, remainder to be returned verbatim + // just set to big number ... + char **tokens = xzalloc(128 * sizeof(char *) * + (ntokens /* required tokens */ + 1 /* end-of-tokens-on-this-line marker*/)); Guess what "big number" users will put there? INT_MAX. + line = strtok(s, "\n"); // N.B. s != NULL only the first time + if (!line) + break; strtok uses static storage. I want to get rid of it eventually. Maybe strsep? + replace(line, '#', '\0'); *strchrnul(line, '#') = '\0'. replace will do useless work after first '#'. + // skip comments and empty lines + line = skip_whitespace(line); + if (!line) + continue; I think it had to be if (!*line). + // pin token + // FIXME: realloc!!! + *token++ = s; realloc indeed. I find this to be a useful idiom: if (!(idx & 0xfff)) { vector = xrealloc(vector, sizeof(vector[0]) * (idx + 0x1001)); Another libbb candidate? + token++; // xzmalloc guarantees NULL it's "xzalloc" :) -- vda From vda.linux at googlemail.com Mon Jul 7 20:56:49 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 8 Jul 2008 05:56:49 +0200 Subject: LIBBB: parse_config() In-Reply-To: <200807080547.54009.vda.linux@googlemail.com> References: <48726f11.21054e0a.2cea.26fa@mx.google.com> <200807080547.54009.vda.linux@googlemail.com> Message-ID: <200807080556.49128.vda.linux@googlemail.com> On Tuesday 08 July 2008 05:47, Denys Vlasenko wrote: > [CC: busybox at busybox.net] > > On Monday 07 July 2008 21:31, dronnikov at gmail.com wrote: > > Please, comment and consider applying. Another comment: the return va