From mwigge at marcant.net  Thu Feb  1 00:04:16 2007
From: mwigge at marcant.net (Markus Wigge)
Date: Thu, 01 Feb 2007 09:04:16 +0100
Subject: version 1.4.1
Message-ID: <45C19F00.4060903@marcant.net>

Hi,

I'm a little bit confused, I recently read about busybox 1.4.1 and found 
an archive I could download but there is no tag for it in subversion and 
it is not announced on the web?

Is this an official version or what?

bye,
   Markus


From vapier at gentoo.org  Thu Feb  1 00:12:33 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Feb 2007 03:12:33 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200701300108.09929.vda.linux@googlemail.com>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
Message-ID: <200702010312.34740.vapier@gentoo.org>

On Monday 29 January 2007, Denis Vlasenko wrote:
> I propose to simply never define anything "modular"
>
> If people run "make modules",  well, that's their problems.

there are a bunch of env config settings which can cause problems ... what i'm 
looking at is busybox gets integrated into a larger build system which 
includes a kernel and next thing i know, busybox is failing because it's 
trying to generate depmod and build modules
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/33de39e9/attachment.pgp 

From aurel at gnuage.org  Thu Feb  1 05:03:23 2007
From: aurel at gnuage.org (Aurelien Jacobs)
Date: Thu, 1 Feb 2007 14:03:23 +0100
Subject: busybox 1.4.1 build failure
Message-ID: <20070201140323.4dc138fa.aurel@gnuage.org>

Hi,

When upgrading from bb-1.4.0 to bb-1.4.1 I got the following error
(gcc-4.1.1, uClibc for i386 target):

  CC      networking/interface.o
cc1: warnings being treated as errors
networking/interface.c: In function 'in_ether':
networking/interface.c:853: warning: pointer targets in assignment differ in signedness
make[1]: *** [networking/interface.o] Error 1
make: *** [networking] Error 2

The attached patch fixes it.

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 90_build_fix.diff
Type: text/x-diff
Size: 413 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/94b338fe/attachment.bin 

From yuwend at gmail.com  Thu Feb  1 05:23:42 2007
From: yuwend at gmail.com (Yuwen Dai)
Date: Thu, 1 Feb 2007 21:23:42 +0800
Subject: ash test suite
In-Reply-To: <45BF6F79.4020601@bfs.de>
References: <45B719C7.8010503@bfs.de>
	<f7e548110701240121ga2c4b1ej288f660ce7c6e6c6@mail.gmail.com>
	<45B75AF8.8050304@bfs.de>
	<f7e548110701290138w4e6b600g50263bbcd0d6f04f@mail.gmail.com>
	<45BDE4E6.200@bfs.de>
	<f7e548110701290553n206d528dt276a1764fa70d53b@mail.gmail.com>
	<45BDFDAA.8040508@bfs.de>
	<f7e548110701292155n4d52575ex5fb6d52d7fa6beea@mail.gmail.com>
	<45BF6F79.4020601@bfs.de>
Message-ID: <f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>

On 1/31/07, walter harms <wharms at bfs.de> wrote:
>
> your are right,
> note:  have removed the original diff for a 'diff -y | less' to see more
> clearly the differences.
> take also a look at the readme inside the ash* tests.


I see ash-* directories as well as test files in the same directory. While
in Bash testsuite, all test files are in same level, no subdirectories.  Did
you intend to put all all the test files into subdirectories?

Best regards,
Yuwen


re,
> wh
>
> inside the ash*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070201/c9b57984/attachment.html 

From wangbj at lzu.edu.cn  Thu Feb  1 05:56:04 2007
From: wangbj at lzu.edu.cn (Wang, Baojun)
Date: Thu, 1 Feb 2007 21:56:04 +0800
Subject: busybox 1.4.0(with patches) crosscompile failed:
Message-ID: <370399254.25716@eyou.net>

hi,


the cross compiler are being built using the clfs embedded way which can be 
found at: http://cross-lfs.org/view/clfs-embedded/x86/

after patching all patches, 

# make defconfig
# make menuconfig # select ash as default shell
# make CROSS_COMPILE=i686-pc-linux-uclibc- V=1

encounter the fellowing error:

  
i686-pc-linux-uclibc-gcc -Wp,-MD,miscutils/.taskset.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include 
include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(taskset)"  -D"KBUILD_MODNAME=KBUILD_STR(taskset)" -c -o 
miscutils/taskset.o miscutils/taskset.c
miscutils/taskset.c: In function '__from_cpuset':
miscutils/taskset.c:22: error: 'CPU_SETSIZE' undeclared (first use in this 
function)
miscutils/taskset.c:22: error: (Each undeclared identifier is reported only 
once
miscutils/taskset.c:22: error: for each function it appears in.)
cc1: warnings being treated as errors
miscutils/taskset.c:26: warning: implicit declaration of function 'CPU_ISSET'
miscutils/taskset.c: In function 'taskset_main':
miscutils/taskset.c:67: warning: implicit declaration of function 'CPU_ZERO'
miscutils/taskset.c:68: error: 'CPU_SETSIZE' undeclared (first use in this 
function)
miscutils/taskset.c:70: warning: implicit declaration of function 'CPU_SET'
miscutils/taskset.c:77: warning: implicit declaration of 
function 'sched_getaffinity'
miscutils/taskset.c:85: warning: implicit declaration of 
function 'sched_setaffinity'
make[1]: *** [miscutils/taskset.o] Error 1
make: *** [miscutils] Error 2

-- 
Wang, Baojun                                        Lanzhou University
Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
School of Information Science and Engeneering        wangbj at lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000                     .P.R.China
Tel:+86-931-8912025                                Fax:+86-931-8912022
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/0eb146e7/attachment.pgp 

From strange at nsk.no-ip.org  Thu Feb  1 07:03:29 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Thu, 1 Feb 2007 15:03:29 +0000
Subject: Busybox build problem
In-Reply-To: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
Message-ID: <20070201150329.GB8446@nsk.no-ip.org>

On Thu, Feb 01, 2007 at 12:26:20AM -0600, Brion Finlay wrote:
> Here are the compile problems that I get:
<snip>

Could you show the lines giving the errors?

> I'm sure it is something wrong with my environment, but I do not know what.
> Does anyone have any hints?

You could have hardware problems.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/7ec746b7/attachment.pgp 

From wangbj at lzu.edu.cn  Thu Feb  1 07:12:06 2007
From: wangbj at lzu.edu.cn (Wang, Baojun)
Date: Thu, 1 Feb 2007 23:12:06 +0800
Subject: busybox 1.4.0(with patches) crosscompile failed:
In-Reply-To: <370338889.00965@lzu.edu.cn>
References: <370338889.00965@lzu.edu.cn>
Message-ID: <370403821.29556@eyou.net>

:t???k-5??????M;?^zY???#?|+?????^r?,??&?)^???m?????????x-??%~??m?]y??br??????j?m???r?,?W?????'???_???y?^w?|??????j?!?x?ZZ??^?f?y??r???	??????(?????^r????y????!zYfjG?D??? ?
From rep.dot.nop at gmail.com  Thu Feb  1 07:18:28 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 1 Feb 2007 16:18:28 +0100
Subject: no sched_setaffinity in uClibc [was: Re: busybox 1.4.0(with patches)
	crosscompile failed:]
In-Reply-To: <200702012156.07524.wangbj@lzu.edu.cn>
References: <200702012156.07524.wangbj@lzu.edu.cn>
Message-ID: <20070201151828.GA24370@aon.at>

On Thu, Feb 01, 2007 at 09:56:04PM +0800, Wang, Baojun wrote:
>hi,
>
>
>the cross compiler are being built using the clfs embedded way which can be 
>found at: http://cross-lfs.org/view/clfs-embedded/x86/
>
>after patching all patches, 
>
># make defconfig
># make menuconfig # select ash as default shell
># make CROSS_COMPILE=i686-pc-linux-uclibc- V=1
>
>encounter the fellowing error:
>
>  
>i686-pc-linux-uclibc-gcc -Wp,-MD,miscutils/.taskset.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include 


uClibc trunk has no support for sched_[sg]etaffinity.

Turn that applet off.
-- 
>include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(taskset)"  -D"KBUILD_MODNAME=KBUILD_STR(taskset)" -c -o 
>miscutils/taskset.o miscutils/taskset.c
>miscutils/taskset.c: In function '__from_cpuset':
>miscutils/taskset.c:22: error: 'CPU_SETSIZE' undeclared (first use in this 
>function)
>miscutils/taskset.c:22: error: (Each undeclared identifier is reported only 
>once
>miscutils/taskset.c:22: error: for each function it appears in.)
>cc1: warnings being treated as errors
>miscutils/taskset.c:26: warning: implicit declaration of function 'CPU_ISSET'
>miscutils/taskset.c: In function 'taskset_main':
>miscutils/taskset.c:67: warning: implicit declaration of function 'CPU_ZERO'
>miscutils/taskset.c:68: error: 'CPU_SETSIZE' undeclared (first use in this 
>function)
>miscutils/taskset.c:70: warning: implicit declaration of function 'CPU_SET'
>miscutils/taskset.c:77: warning: implicit declaration of 
>function 'sched_getaffinity'
>miscutils/taskset.c:85: warning: implicit declaration of 
>function 'sched_setaffinity'
>make[1]: *** [miscutils/taskset.o] Error 1
>make: *** [miscutils] Error 2
>
>-- 
>Wang, Baojun                                        Lanzhou University
>Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
>School of Information Science and Engeneering        wangbj at lzu.edu.cn
>Tianshui South Road 222. Lanzhou 730000                     .P.R.China
>Tel:+86-931-8912025                                Fax:+86-931-8912022



>_______________________________________________
>busybox mailing list
>busybox at busybox.net
>http://busybox.net/cgi-bin/mailman/listinfo/busybox

From somlo at cmu.edu  Thu Feb  1 13:07:00 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 16:07:00 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <78a54e1b0701301258k5e2446fdi90a4c69bb7e4d0e7@mail.gmail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<78a54e1b0701291906i58239c8at93fe71bab40b1da2@mail.gmail.com>
	<20070130195006.GD21905@hedwig.net.cmu.edu>
	<78a54e1b0701301258k5e2446fdi90a4c69bb7e4d0e7@mail.gmail.com>
Message-ID: <20070201210700.GA20549@hedwig.net.cmu.edu>

On Tue, Jan 30, 2007 at 02:58:50PM -0600, Jason Schoon wrote:
> On 1/30/07, Gabriel L. Somlo <somlo at cmu.edu> wrote:
> >And what to do about all the (pre isc 3.1.0) clients that just dump the
> >content of option 15 into the search string ? :)
> 
> They still will.  Or they will disregard the option entirely.

So, the way I see it, 3.1.0 and later clients will first look for the
domain-search option to add to resolv.conf, and default to domain-name
if the former isn't being sent by the server. As far as pre-3.1.0
clients:

> They will not
> have your patch, so they will not be expecting to receive multiple strings
> in a single field.  They will be expecting this field to contain a single
> domain value.

no, they'll expect a single string :) which may contain spaces. Which
is the way this is being done today, via the domain-name option.
Here's a quote from the dhcp-options man page that comes with 3.1.0a3:

	The domain-search option specifies a 'search list' of
	Domain Names to be used by the client to locate
	not-fully-qualified domain names. The difference between
	this option and historic use of the domain-name option
	                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	for the same ends is that this option is encoded in
	^^^^^^^^^^^^^^^^^^
	RFC1035 compressed labels on the wire.

The problem with udhcpd is that it won't allow quoted strings to be
parsed from the udhcpd.conf file (which would allow passing single
strings that contain spaces).

So, we either complicate parsing of strings from the config file, or
we make certain string-type options listable, and insert single spaces
between members of the "list", ending up with longer strings that
contain spaces.

We'd have to do one or the other of these anyway, even for RFC3397, as
we'll try to pass multiple strings (or one space-separated line of
them) to the domain-search option.

My patch did this in one of the two possible ways. Do you think it
should be done the other way (i.e., by adding support for parsing
quoted strings from the config file) ?

Speaking of RFC3397, I've written a compact function that expands
RFC1035-compressed strings, and it's included at the bottom of this
email, if anyone wants to poke at it. I'm working on a compression
function, at which time I'll whip up a patch to add 3397 to udhcpd.

Either way, adding 3397 support won't fix my original problem, which
is to support passing space-separated strings via the domain-name
option, which is something lots of people do, today, with isc dhcpd...

Cheers.
Gabriel


#define NS_CMPRSFLGS 0xc0	/* name compression pointer flag */

/* expand a RFC1035-compressed list of domain names "src", of length "slen";
 * returns a newly allocated string containing the space-separated domains,
 * or NULL if an error occurs.
 */
char *ns_name_expand(const unsigned char *src, unsigned slen) {
	const unsigned char *c;
	unsigned crtpos, retpos, len = 0;
	char *dst = NULL;

	if (!src || !slen)
		return NULL;

	/* We make two passes over the src string. First, we compute
	 * how long the resulting string would be. Then we allocate a
	 * new buffer of the required length, and fill it in with the
	 * expanded content. The advantage of this approach is not
	 * having to deal with requiring callers to supply their own
	 * buffer, then having to check if it's sufficiently large, etc.
	 */

	while (!dst) {

		if (len > 0)	/* second pass? allocate dst buffer */
			dst = xmalloc(len);

		len = crtpos = retpos = 0;

		while (crtpos < slen) {
			c = src + crtpos;

			if (*c & NS_CMPRSFLGS) { /* pointer */
				if (retpos == 0) /* toplevel? save ret. spot */
					retpos = crtpos + 2;
				crtpos = *(c + 1);/* jump to pointed location */
			} else if (*c) { /* label */
				if (dst)
					memcpy(dst + len, c + 1, *c);
				len += (*c + 1);
				crtpos += (*c + 1);
				if (dst)
					*(dst + len - 1) = '.';
			} else {  /* null -- end of current domain name */
				if (retpos == 0) { /* toplevel? keep going */
					crtpos++;
				} else {   /* go back to toplevel saved spot */
					crtpos = retpos;
					retpos = 0;
				}
				if (dst)
					*(dst + len - 1) = ' ';
			}
		}

		if (dst)
			*(dst + len - 1) = '\0';
	}

	return dst;
}

From vda.linux at googlemail.com  Thu Feb  1 14:08:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:08:20 +0100
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <20070126170058.GA31444@hedwig.net.cmu.edu>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
Message-ID: <200702012308.20367.vda.linux@googlemail.com>

On Friday 26 January 2007 18:00, Gabriel L. Somlo wrote:
> Denis & All,
> 
> Whatever I specify as the value for "option domain" in udhcpd.conf
> ends up being on the "search" line in my client's /etc/resolv.conf
> 
> As such, I discovered that specifying multiple values for
> "option domain" doesn't work with udhcpd.
> 
> The following patch fixes that by making "domain" accept a list of
> options, and by insuring that STRING type options with multiple values
> end up being separated by spaces (instead of being cat-ed together).
> 
> Let me know what you think.
> 
> Thanks,
> Gabriel 
> 
> 
> diff -NarU5 busybox-svn-17463.orig/networking/udhcp/files.c busybox-svn-17463/networking/udhcp/files.c
> --- busybox-svn-17463.orig/networking/udhcp/files.c	2007-01-22 11:17:58.000000000 -0500
> +++ busybox-svn-17463/networking/udhcp/files.c	2007-01-26 11:52:26.000000000 -0500
> @@ -106,11 +106,16 @@
>  	if (existing) {
>  		DEBUG("Attaching option %s to existing member of list", option->name);
>  		if (option->flags & OPTION_LIST) {
>  			if (existing->data[OPT_LEN] + length <= 255) {
>  				existing->data = realloc(existing->data,

realloc? why not xrealloc?

> -						existing->data[OPT_LEN] + length + 2);
> +						existing->data[OPT_LEN] + length + 3);
> +				if ((option->flags & TYPE_MASK) == OPTION_STRING) {
> +					/* add space separator between STRING options in a list */
> +					*(existing->data + existing->data[OPT_LEN] + 2) = ' ';
> +					existing->data[OPT_LEN]++;
> +				}
>  				memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
>  				existing->data[OPT_LEN] += length;

You can overflow existing->data[OPT_LEN].

The below version should fix that (and even mostly fit
into 80 column displays). Can you try it?

static void attach_option(struct option_set **opt_list,
                const struct dhcp_option *option, char *buffer, int length)
{
        struct option_set *existing, *new, **curr;

        existing = find_option(*opt_list, option->code);
        if (!existing) {
                DEBUG("Attaching option %s to list", option->name);

                /* make a new option */
                new = xmalloc(sizeof(struct option_set));
                new->data = xmalloc(length + 2);
                new->data[OPT_CODE] = option->code;
                new->data[OPT_LEN] = length;
                memcpy(new->data + 2, buffer, length);

                curr = opt_list;
                while (*curr && (*curr)->data[OPT_CODE] < option->code)
                        curr = &(*curr)->next;

                new->next = *curr;
                *curr = new;
                return;
        }

        /* add it to an existing option */
        DEBUG("Attaching option %s to existing member of list", option->name);
        if (option->flags & OPTION_LIST) {
                if (existing->data[OPT_LEN] + length <= 255) {
                        existing->data = xrealloc(existing->data,
                                        existing->data[OPT_LEN] + length + 3);
                        if ((option->flags & TYPE_MASK) == OPTION_STRING) {
                                if (existing->data[OPT_LEN] + length >= 255)
                                        return;
                                /* add space separator between STRING options in a list */
                                existing->data[existing->data[OPT_LEN] + 2] = ' ';
                                existing->data[OPT_LEN]++;
                        }
                        memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
                        existing->data[OPT_LEN] += length;
                } /* else, ignore the data, we could put this in a second option in the future */
        } /* else, ignore the new data */
}

--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:15:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:15:51 +0100
Subject: version 1.4.1
In-Reply-To: <45C19F00.4060903@marcant.net>
References: <45C19F00.4060903@marcant.net>
Message-ID: <200702012315.51620.vda.linux@googlemail.com>

On Thursday 01 February 2007 09:04, Markus Wigge wrote:
> Hi,
> 
> I'm a little bit confused, I recently read about busybox 1.4.1 and found 
> an archive I could download but there is no tag for it in subversion and 
> it is not announced on the web?
> 
> Is this an official version or what?

I added relevant text in news.html in busybox cvs and expected it
to appear at busybox.net after a day or so, but it didn't.
(I planned to announce it after it is there)

I was a bit busy and didn't ask people why it is so.

Anyway, 1.4.1 is 1.4.0 plus these:

http://busybox.net/downloads/fixes-1.4.0/

--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:21:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:21:40 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
Message-ID: <200702012321.40884.vda.linux@googlemail.com>

On Thursday 01 February 2007 07:26, Brion Finlay wrote:
> This seems like it should be a simple question that other people have had
> problems with, but I cannot get Busybox to build.  I have tried google-ing
> for similar problems, searching the mail archives, and reading the FAQs and
> all of the documentation, but I cannot figure out what is going on.
> 
> I am using a fairly fresh install of Ubuntu 6.1, and I have installed enough
> of the development packages to build a custom kernel.  (I mention this
> because Ubuntu does not preinstall many development packages, so it is
> possible I am still missing some, but I have installed quite a few.)
> 
> The GCC version is 4.1.2.
> sed is GNU Sed version 4.1.5
>
> Here are the compile problems that I get:
> 
> Busybox 1.4.1
> # make defconfig; make
> 
> ...
> include/bbconfigopts.h:1088: error: missing terminating " character
> (repeated for each line)
> include/bbconfigopts.h:1089: error: expected expression before ';' token
> make[1]: *** [miscutils/bbconfig.o] Error 1
> make: *** [miscutils] Error 2

gcc 4.1.1, glibc 2.4, gnu sed 4.1.5, bbox 1.4.1: 

# make defconfig; make
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/split-include
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  HOSTCC  scripts/kconfig/mconf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf -d Config.in
/.local/tmp/busybox-1.4.1/scripts/defconfig:351:warning: trying to assign nonexistent symbol E2FSCK
/.local/tmp/busybox-1.4.1/scripts/defconfig:354:warning: trying to assign nonexistent symbol MKE2FS
/.local/tmp/busybox-1.4.1/scripts/defconfig:355:warning: trying to assign nonexistent symbol TUNE2FS
/.local/tmp/busybox-1.4.1/scripts/defconfig:356:warning: trying to assign nonexistent symbol E2LABEL
/.local/tmp/busybox-1.4.1/scripts/defconfig:357:warning: trying to assign nonexistent symbol FINDFS
/.local/tmp/busybox-1.4.1/scripts/defconfig:635:warning: symbol value '' invalid for FEATURE_COMMAND_HISTORY
*
* Busybox Configuration
*
*
* Busybox Settings
*
*
* General Configuration
*
See lots more (probably unnecessary) configuration options. (NITPICK) [N/y/?] n
Enable options for full-blown desktop systems (DESKTOP) [N/y/?] n
...
envdir (ENVDIR) [Y/n/?] y
softlimit (SOFTLIMIT) [Y/n/?] y
  SPLIT   include/autoconf.h -> include/config/*
  GEN     include/bbconfigopts.h
  HOSTCC  applets/usage
  GEN     include/usage_compressed.h
  CC      applets/applets.o
  CC      applets/busybox.o
...
  CC      util-linux/switch_root.o
  CC      util-linux/umount.o
  AR      util-linux/lib.a
  LINK    busybox_unstripped

include/bbconfigopts.h from build tree is attached.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bbconfigopts.h
Type: text/x-chdr
Size: 16270 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/6425a36c/attachment.h 

From vda.linux at googlemail.com  Thu Feb  1 14:22:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:22:56 +0100
Subject: Busybox build problem
In-Reply-To: <20070201002140.bfc52cea95091b0fffcb409eab6296ba.9cd207e1ee.wbe@email.secureserver.net>
References: <20070201002140.bfc52cea95091b0fffcb409eab6296ba.9cd207e1ee.wbe@email.secureserver.net>
Message-ID: <200702012322.56287.vda.linux@googlemail.com>

On Thursday 01 February 2007 08:21, akennedy at techmoninc.com wrote:
> 
> > I'm sure it is something wrong with my environment, but I do not know what.  Does anyone have any hints?
> Attempt the build with BuildRoot.  This will install uclibc and a gcc
> that will work with it to build BusyBox.  I've found it VERY difficult
> to build BusyBox with GLibC.

Really?! I do it all the time...

Please report what are the problems.
Provide gcc, glibc version, .config...
--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:36:52 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:36:52 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <1170276931.18296.5.camel@studio>
References: <1170276931.18296.5.camel@studio>
Message-ID: <200702012336.52095.vda.linux@googlemail.com>

On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> The attatched patch adds support for option -user. The arg to -user can
> be either username or uid.
>
> Would be nice if it could be committed.
> Thanks!

+???????????????????????ap->uid = bb_strtoul(arg1, (char **)NULL, 10);

Why you use *strtoul* and then assign it to unsigned *int*?
Why cast?

Otherwise looks ok, applying...
--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:57:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:57:03 +0100
Subject: CGI script and Content-type change in 1.4.0
In-Reply-To: <45C0533A.5000309@lkh-vil.or.at>
References: <45C0533A.5000309@lkh-vil.or.at>
Message-ID: <200702012357.03564.vda.linux@googlemail.com>

On Wednesday 31 January 2007 09:28, Alexander Griesser wrote:
> Hi folks!
> 
> Another thing that broke when upgrading to 1.4.0 is the management
> interface for my thinclients.
> 
> Previously, I used the following command to output a valid HTML header:
> 
> echo 'Content-type: text/html
> 
> 
> <html>
> <head>
> ...'
> 
> Now, with busybox 1.4.0, this doesn't work anymore.
> I get exactly the same output as written above in firefox (IE7 works
> fine).
> 
> I had a look at the changelog and found the following entry:
> 
> || httpd: stop adding our own "Content-type:" to CGI output
> 
> Additionally, I found a cgi-example (httpd_index_cgi_example) inside
> the busybox distribution that suggests do pipe all output generated
> through "dd bs=4k" with the following comment:
> 
> # Pipe thru dd (need to write header as single write(),
> # or else httpd doesn't see "Content-type: text/html"
> # in first read() and decides that it is not html)
> 
> Why is this needed with the current busybox release or are there any
> ways to work around this?

This piping not needed anymore, it has been fixed
after indexer example was addded.

Regarding your script: I must admit I am not a CGI expert,
but maybe you need to echo "HTTP/1.0 200 OK\r\n" first.

I just tested and cgi indexer works (also without piping thru dd),
so at least this cgi example is working.

If you definitely know that CGI should not print "200 OK"
(IOW: that https server process should add that instead),
please give me the URL so that I can educate myself too.

Thanks.
--
vda

From vapier at gentoo.org  Thu Feb  1 15:16:23 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Feb 2007 18:16:23 -0500
Subject: version 1.4.1
In-Reply-To: <200702012315.51620.vda.linux@googlemail.com>
References: <45C19F00.4060903@marcant.net>
	<200702012315.51620.vda.linux@googlemail.com>
Message-ID: <200702011816.24169.vapier@gentoo.org>

On Thursday 01 February 2007, Denis Vlasenko wrote:
> I was a bit busy and didn't ask people why it is so.

looks like svn locks got screwed up ... i cleared them and it should be OK now
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/66ae121a/attachment.pgp 

From vda.linux at googlemail.com  Thu Feb  1 15:14:21 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 00:14:21 +0100
Subject: extra targets in busybox Makefile
In-Reply-To: <200702010312.34740.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
	<200702010312.34740.vapier@gentoo.org>
Message-ID: <200702020014.21335.vda.linux@googlemail.com>

On Thursday 01 February 2007 09:12, Mike Frysinger wrote:
> On Monday 29 January 2007, Denis Vlasenko wrote:
> > I propose to simply never define anything "modular"
> >
> > If people run "make modules",  well, that's their problems.
> 
> there are a bunch of env config settings which can cause problems ... what i'm 
> looking at is busybox gets integrated into a larger build system which 
> includes a kernel and next thing i know, busybox is failing because it's 
> trying to generate depmod and build modules

Huh, if this is really getting problematic,
then feel free to chainsaw "modular" support off.

Or just rename makefile targets ('modules' -> 'dont_use_me__modules')
if you don't want to spend too much time on things which
do not materially improve generated code.
--
vda

From strange at nsk.no-ip.org  Thu Feb  1 15:44:35 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Thu, 1 Feb 2007 23:44:35 +0000
Subject: CGI script and Content-type change in 1.4.0
In-Reply-To: <200702012357.03564.vda.linux@googlemail.com>
References: <45C0533A.5000309@lkh-vil.or.at>
	<200702012357.03564.vda.linux@googlemail.com>
Message-ID: <20070201234435.GA6908@nsk.no-ip.org>

On Thu, Feb 01, 2007 at 11:57:03PM +0100, Denis Vlasenko wrote:
> If you definitely know that CGI should not print "200 OK"
> (IOW: that https server process should add that instead),
> please give me the URL so that I can educate myself too.

Links with specs:
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html#7.0

Basically, there are two different types of CGI scripts (the method to
distinguish between the two types is implementation defined; the first
link defines cgi prefix of nph-):
1. non-parsed header (NPH) output (support not required)
  - all output is sent as is to the client (full HTTP response is
    created by the script)

2. parsed header output (support required)
  - one of the following headers must be present, and will be parsed by
    the server (not limited to one, but no repetitions are allowed):
    * Content-type: the Internet Media Type of the entity body,
       which is to be sent unmodified to the client.
    * Location: specify to the server that the script is
       returning a reference to a document rather than an actual
       document:
      - absolute uri: Location: http://.... -> 302 redirect (unless
        Status also defined);
      - or path: Location: /path/... -> server internally processes the
        redirect and the output is as if the new location was directly
        called (POST and other requests may lose the request body).
    * Status: indicates to the server what status code the server MUST
      use in the response message: Status: [0-9]{3} reason-phrase

  - output consists of header plus body (body may be null):
    * if body, Content-type is mandatory
    * else one of Location or Status is mandatory

  - headers are specified on a single line
  
Also, #8.1 on the second link, Requirements for Servers, should be of
interest.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/48863634/attachment.pgp 

From vda.linux at googlemail.com  Thu Feb  1 17:14:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 02:14:33 +0100
Subject: busybox 1.4.1 build failure
In-Reply-To: <20070201140323.4dc138fa.aurel@gnuage.org>
References: <20070201140323.4dc138fa.aurel@gnuage.org>
Message-ID: <200702020214.33849.vda.linux@googlemail.com>

On Thursday 01 February 2007 14:03, Aurelien Jacobs wrote:
> Hi,
> 
> When upgrading from bb-1.4.0 to bb-1.4.1 I got the following error
> (gcc-4.1.1, uClibc for i386 target):
> 
>   CC      networking/interface.o
> cc1: warnings being treated as errors
> networking/interface.c: In function 'in_ether':
> networking/interface.c:853: warning: pointer targets in assignment differ in signedness
> make[1]: *** [networking/interface.o] Error 1
> make: *** [networking] Error 2
> 
> The attached patch fixes it.

thanks, applied
--
vda

From somlo at cmu.edu  Thu Feb  1 17:23:04 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 20:23:04 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702012308.20367.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
Message-ID: <20070202012303.GA23689@hedwig.net.cmu.edu>

On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> You can overflow existing->data[OPT_LEN].

Yes, by exactly 1 :)

>         /* add it to an existing option */

...

>                 if (existing->data[OPT_LEN] + length <= 255) {
>                         existing->data = xrealloc(existing->data,
>                                         existing->data[OPT_LEN] + length + 3);
>                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {
>                                 if (existing->data[OPT_LEN] + length >= 255)
>                                         return;

You already know that's never going to be more than 255 (see the if
statement at the beginning of the quote :) What you don't know is
whether the extra space I want to add will make it 256 instead of 255.
So, maybe do this:

>                               if (existing->data[OPT_LEN] + length + 1>= 255)
                                                                     ^^^^^
>                                         return;

The other choice would be to do this:

>                 if (existing->data[OPT_LEN] + length <= 254) {
                                                        ^^^^^^^
>                         existing->data = xrealloc(existing->data,
>                                         existing->data[OPT_LEN] + length + 3);
>                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {

and drop the second check entirely. I'd almost vote for this, but then
we'd be depriving non-string options of one potential byte. Makes the
code cleaner, though... I guess you're the decider :)

Otherwise, it compiles cleanly, and looks ok to me. Won't be able to
test it until some 15 hours from now, though, since I'll have to
physically hook up a dhcp client to the box which is in my office...

Cheers,
Gabriel

From vda.linux at googlemail.com  Thu Feb  1 17:55:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 02:55:13 +0100
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <20070202012303.GA23689@hedwig.net.cmu.edu>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
	<20070202012303.GA23689@hedwig.net.cmu.edu>
Message-ID: <200702020255.13687.vda.linux@googlemail.com>

On Friday 02 February 2007 02:23, Gabriel L. Somlo wrote:
> On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> > You can overflow existing->data[OPT_LEN].
> 
> Yes, by exactly 1 :)
> 
> >         /* add it to an existing option */
> 
> ...
> 
> >                 if (existing->data[OPT_LEN] + length <= 255) {
> >                         existing->data = xrealloc(existing->data,
> >                                         existing->data[OPT_LEN] + length + 3);
> >                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {
> >                                 if (existing->data[OPT_LEN] + length >= 255)
> >                                         return;
> 
> You already know that's never going to be more than 255 (see the if
> statement at the beginning of the quote :) What you don't know is
> whether the extra space I want to add will make it 256 instead of 255.
> So, maybe do this:
> 
> >                               if (existing->data[OPT_LEN] + length + 1>= 255)
>                                                                      ^^^^^
> >                                         return;

No. My check is really

		if (existing->data[OPT_LEN] + length == 255)

that is, "is it exactly 255? that wont fit because of +1!"
but I use >= because of sheer paranoia. ;)

--
vda

From somlo at cmu.edu  Thu Feb  1 19:21:42 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 22:21:42 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702020255.13687.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
	<20070202012303.GA23689@hedwig.net.cmu.edu>
	<200702020255.13687.vda.linux@googlemail.com>
Message-ID: <20070202032142.GA24474@hedwig.net.cmu.edu>

On Fri, Feb 02, 2007 at 02:55:13AM +0100, Denis Vlasenko wrote:
> 
> No. My check is really
> 
> 		if (existing->data[OPT_LEN] + length == 255)
> 
> that is, "is it exactly 255? that wont fit because of +1!"
> but I use >= because of sheer paranoia. ;)

Heh... You're right, of course...

That's why I like using computers -- you only have to get this
crap right once, and won't keep having to worry about spotting
that equal sign after the > sign... Or something... :) :)

Cheers,
Gabriel

From natanael.copa at gmail.com  Thu Feb  1 23:09:50 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 02 Feb 2007 08:09:50 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <200702012336.52095.vda.linux@googlemail.com>
References: <1170276931.18296.5.camel@studio>
	<200702012336.52095.vda.linux@googlemail.com>
Message-ID: <1170400190.28276.11.camel@localhost>

On Thu, 2007-02-01 at 23:36 +0100, Denis Vlasenko wrote:
> On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> > The attatched patch adds support for option -user. The arg to -user can
> > be either username or uid.
> >
> > Would be nice if it could be committed.
> > Thanks!
> 
> +                       ap->uid = bb_strtoul(arg1, (char **)NULL, 10);
> 
> Why you use *strtoul* and then assign it to unsigned *int*?

You are right. The uid type should ofcourse be uid_t and not int.

The xuname2uid() returns a long (why not uid_t?) so i think I could use
strtol() instead of bb_strtou().

> Why cast?

When I was looking for a atoi with error detection in libbb I found that
the atoi man-page states that the atoi behaviour is the same as

              strtol(nptr, (char **)NULL, 10);

The cast comes from there.

Sorry for the type confusion. New patch is attatched.

> Otherwise looks ok, applying...

Thanks!

> --
> vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-uid_t.patch
Type: text/x-patch
Size: 886 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/bddb1e2f/attachment.bin 

From somlo at cmu.edu  Fri Feb  2 06:25:53 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Fri, 2 Feb 2007 09:25:53 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702012308.20367.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
Message-ID: <20070202142553.GA8714@hedwig.net.cmu.edu>

On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> The below version should fix that (and even mostly fit
> into 80 column displays). Can you try it?

Tried it, and it looks like it's working fine.

Thanks,
Gabriel

From natanael.copa at gmail.com  Fri Feb  2 07:01:30 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 02 Feb 2007 16:01:30 +0100
Subject: [PATCH] find ! ... (operator -not)
Message-ID: <1170428490.28276.35.camel@localhost>

Hi,

Attatched is a patch for support of the '!' operator for find.

I created another macro ALLOC_TEST for actions that can be inverted with
'!'. They are not really actions (like -print) but tests (like -name).

It should not touch anything unless you have enabled the
FEATURE_FIND_NOT config option.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-operator-not.patch
Type: text/x-patch
Size: 5665 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/a13eb967/attachment-0001.bin 

From mcross at irobot.com  Fri Feb  2 09:24:21 2007
From: mcross at irobot.com (Cross, Matthew)
Date: Fri, 2 Feb 2007 12:24:21 -0500
Subject: Revisiting an old losetup bug (bug 609)
Message-ID: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>

I have run into this old bug.  I'm using an old version of busybox
(1.1.3) on an i.MX21 embedded system (it's ARM based).  I understand
what's going on and how it could be fixed but I'm not sure if it's a
busybox bug or a problem with the toolchain.  Looking at the code, the
problem is still in the latest source.  Let me explain:
 
In my case, I'm using a "BSP" provided by Freescale for this chip.  They
provide a pre-built toolchain (binutils, gcc, glibc).  When the
toolchain was built, kernel headers from a 2.6.11 kernel were used by
glibc.  The kernel that is running on the board is a heavily patched
2.4.20 kernel.  Therefore, when libbb/loop.c is compiled it sees a 2.6
kernel, and so uses LOOP_GET_STATUS64 for BB_LOOP_GET_STATUS - note that
this is ioctl 0x4c05 (if you look in the strace output in the log of bug
609 you see this ioctl there, so it looks like the original submitter
had a similar problem).  However, the loop driver in 2.4 kernels does
not support the 64 bit variants of these ioctl's, only the 32 bit
LOOP_GET_STATUS (which is 0x4c03).  When I hack loop.c to use the 2.4
version of the code, it works on my system properly, so clearly the 2.4
kernel supports the loop device fine.
 
Busybox could be modified to work in this scenario by trying the 32 bit
version of the ioctl if the 64 bit version fails, but I don't know if
that goes against the low-bloat philosophy of busybox.  Does the busybox
dev team feel that this is a problem with the build system, or should a
busybox built with headers from a 2.6 kernel work with a 2.4 kernel?
The vendor I am working from has argued that userland applications
should not depend on kernel headers and that this toolchain has been
working for several years with this processor and kernel.
 
    -Matt
 
--
Matt Cross
Senior Lead Software Engineer
iRobot Corporation
63 South Avenue, Burlington, MA 01803
781-418-3373 (ph)
781-345-0201 (fax)
mcross at irobot.com
www.irobot.com <http://www.irobot.com/> 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070202/6186fc96/attachment.htm 

From rob at landley.net  Fri Feb  2 11:58:58 2007
From: rob at landley.net (Rob Landley)
Date: Fri, 2 Feb 2007 14:58:58 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702010312.34740.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
	<200702010312.34740.vapier@gentoo.org>
Message-ID: <200702021458.59394.rob@landley.net>

On Thursday 01 February 2007 3:12 am, Mike Frysinger wrote:
> On Monday 29 January 2007, Denis Vlasenko wrote:
> > I propose to simply never define anything "modular"
> >
> > If people run "make modules",  well, that's their problems.
> 
> there are a bunch of env config settings which can cause problems ... what 
i'm 
> looking at is busybox gets integrated into a larger build system which 
> includes a kernel and next thing i know,

What do you mean by "integrated into a larger build system"?  Busybox's 
menuconfig is not the same as the kernel's (version skew among other things).  
If you write your own Config and use your own menuconfig infrastructure, you 
have to debug your new code as well, correct?

> busybox is failing because it's  
> trying to generate depmod and build modules

Because your "larger build system" (which we didn't write) is calling make 
modules on busybox?

What exactly is going on here?

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From vda.linux at googlemail.com  Fri Feb  2 12:17:30 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 21:17:30 +0100
Subject: Revisiting an old losetup bug (bug 609)
In-Reply-To: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>
References: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>
Message-ID: <200702022117.30601.vda.linux@googlemail.com>

On Friday 02 February 2007 18:24, Cross, Matthew wrote:
> In my case, I'm using a "BSP" provided by Freescale for this chip.  They
> provide a pre-built toolchain (binutils, gcc, glibc).  When the
> toolchain was built, kernel headers from a 2.6.11 kernel were used by
> glibc.  The kernel that is running on the board is a heavily patched
> 2.4.20 kernel.  Therefore, when libbb/loop.c is compiled it sees a 2.6
> kernel, and so uses LOOP_GET_STATUS64 for BB_LOOP_GET_STATUS - note that
> this is ioctl 0x4c05 (if you look in the strace output in the log of bug
> 609 you see this ioctl there, so it looks like the original submitter
> had a similar problem).  However, the loop driver in 2.4 kernels does
> not support the 64 bit variants of these ioctl's, only the 32 bit
> LOOP_GET_STATUS (which is 0x4c03).  When I hack loop.c to use the 2.4
> version of the code, it works on my system properly, so clearly the 2.4
> kernel supports the loop device fine.
>  
> Busybox could be modified to work in this scenario by trying the 32 bit
> version of the ioctl if the 64 bit version fails, but I don't know if
> that goes against the low-bloat philosophy of busybox.

It depents on the amount of bloat. If it is something like 32 bytes
it's ok. If significantly bigger, maybe create a CONFIG_xxx for it,
or sweep it under CONFIG_DESKTOP if you are lazy.

Please, by all means, send your patch to list. Thanks.
--
vda

From vda.linux at googlemail.com  Fri Feb  2 13:19:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 22:19:11 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <1170400190.28276.11.camel@localhost>
References: <1170276931.18296.5.camel@studio>
	<200702012336.52095.vda.linux@googlemail.com>
	<1170400190.28276.11.camel@localhost>
Message-ID: <200702022219.11973.vda.linux@googlemail.com>

On Friday 02 February 2007 08:09, Natanael Copa wrote:
> On Thu, 2007-02-01 at 23:36 +0100, Denis Vlasenko wrote:
> > On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> > > The attatched patch adds support for option -user. The arg to -user can
> > > be either username or uid.
> > >
> > > Would be nice if it could be committed.
> > > Thanks!
> > 
> > +                       ap->uid = bb_strtoul(arg1, (char **)NULL, 10);
> > 
> > Why you use *strtoul* and then assign it to unsigned *int*?
> 
> You are right. The uid type should ofcourse be uid_t and not int.

Ideally, yes.

> The xuname2uid() returns a long (why not uid_t?) so i think I could use
> strtol() instead of bb_strtou().

strtol treats really bizarre things like "      -" as 'numbers'.
That's why we have bb_strtoXXX.
--
vda

From vda.linux at googlemail.com  Fri Feb  2 13:43:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 22:43:56 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <1170428490.28276.35.camel@localhost>
References: <1170428490.28276.35.camel@localhost>
Message-ID: <200702022243.56100.vda.linux@googlemail.com>

On Friday 02 February 2007 16:01, Natanael Copa wrote:
> Hi,
> 
> Attatched is a patch for support of the '!' operator for find.
> 
> I created another macro ALLOC_TEST for actions that can be inverted with
> '!'. They are not really actions (like -print) but tests (like -name).
> 
> It should not touch anything unless you have enabled the
> FEATURE_FIND_NOT config option.

parse_params():
invert_flag is never reset to 0. This must be a bug -
"not" shouldn't be applied to the second -name here, I think
(did not check it versus GNU find, tho...):
find ! -name '*.a' -o -name '*.b'


Now, to more cosmetic matters:


+#define LOGIC_XOR(a, b) ( (!(a)) != (!(b)) )
                         ACTS(print)
                         ACTS(name,  const char *pattern;)
 USE_FEATURE_FIND_PRINT0(ACTS(print0))
@@ -120,7 +124,13 @@
                cur_action = -1;
                do {
                        ap = app[++cur_action];
-               } while (ap && (rc = ap->f(fileName, statbuf, ap)));
+               } while (ap &&
+#if ENABLE_FEATURE_FIND_NOT
+                       (rc = LOGIC_XOR(ap->f(fileName, statbuf, ap), ap->invert))
+#else
+                       (rc = ap->f(fileName, statbuf, ap))
+#endif
+               );


This is obscure. I propose to do this instead - much easier to read:


        while ((app = appp[++cur_group])) {
                cur_action = -1;
-               do {
+               while (1) {
                        ap = app[++cur_action];
-               } while (ap && (rc = ap->f(fileName, statbuf, ap)));
-               if (!ap) {
-                       /* all actions in group were successful */
-                       break;
+                       if (!ap) {
+                               /* all actions in group were successful */
+                               return rc;
+                       }
+                       rc = ap->f(fileName, statbuf, ap);
+#if ENABLE_FEATURE_FIND_NOT
+                       if (ap->invert) rc = !rc;
+#endif
+                       if (!rc) return rc;
                }
        }
        return rc;



+#if ENABLE_FEATURE_FIND_NOT
+               else if (strcmp(arg, "!") == 0
+                       USE_DESKTOP(|| strcmp(arg, "-not") == 0)
+               ) invert_flag = 1;
+#endif

Don't torture code reader please :) How about this?

+#if ENABLE_FEATURE_FIND_NOT
+               else if (strcmp(arg, "!") == 0
+                       USE_DESKTOP(|| strcmp(arg, "-not") == 0)
+               ) {
+                       invert_flag = 1;
+               }
+#endif



        action* alloc_action(int sizeof_struct, action_fp f
                USE_FEATURE_FIND_NOT(, int invert)
        )
        {
                action *ap;
                appp[cur_group] = xrealloc(appp[cur_group], (cur_action+2) * sizeof(*appp));
                appp[cur_group][cur_action++] = ap = xmalloc(sizeof_struct);
                appp[cur_group][cur_action] = NULL;
                ap->f = f;
                USE_FEATURE_FIND_NOT( ap->invert = invert; )
                return ap;
        }
#define ALLOC_ACTION(name) (action_##name*)alloc_action(sizeof(action_##name), (action_fp) func_##name USE_FEATURE_FIND_NOT(, 0))

#define ALLOC_TEST(name) (action_##name*)alloc_action(sizeof(action_##name), (action_fp) func_##name USE_FEATURE_FIND_NOT(, invert_flag))


You do not need to pass "int invert" to alloc_action. Just use invert_flag
in alloc_action body, and forcefully reset invert_flag = 0 whenever
you are about to do ALLOC_ACTION, like when you handle -print.
(GNU find doesn't error out on "find ! -print", it simply ignores "!").

Care to produce updated patch?
--
vda

From etzvetanov at xceedium.com  Fri Feb  2 15:05:08 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 18:05:08 -0500
Subject: "ls -l" Segmentation fault
Message-ID: <45C3C3A4.9050405@xceedium.com>

Hi all,

I have compiled version 1.4.1 of BusyBox and I have put it on a little 
system for testing.
It is running Linux kernel 2.6.18.1.

If I call "ls -l" in a directory with lots of files (say /dev or even 
/usr/bin) it is pulling Segmentation Fault.
What could be wrong or I am probably not on the same page with you guys...

I tried to search in the mailing list, but I could not find (or I was 
not able to find) any recent complains
-- 
*ET

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070202/1ad4838b/attachment.html 

From ddaney at avtrex.com  Fri Feb  2 15:18:40 2007
From: ddaney at avtrex.com (David Daney)
Date: Fri, 02 Feb 2007 15:18:40 -0800
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C3A4.9050405@xceedium.com>
References: <45C3C3A4.9050405@xceedium.com>
Message-ID: <45C3C6D0.8020209@avtrex.com>

Evgueni Tzvetanov wrote:
> Hi all,
> 
> I have compiled version 1.4.1 of BusyBox and I have put it on a little 
> system for testing.
> It is running Linux kernel 2.6.18.1.
> 
> If I call "ls -l" in a directory with lots of files (say /dev or even 
> /usr/bin) it is pulling Segmentation Fault.
> What could be wrong or I am probably not on the same page with you guys...
> 

What happens when you run it under gdb?

From etzvetanov at xceedium.com  Fri Feb  2 16:02:21 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 19:02:21 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C6D0.8020209@avtrex.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
Message-ID: <45C3D10D.8010006@xceedium.com>

David Daney wrote:
> Evgueni Tzvetanov wrote:
>> Hi all,
>>
>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>> little system for testing.
>> It is running Linux kernel 2.6.18.1.
>>
>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>> /usr/bin) it is pulling Segmentation Fault.
>> What could be wrong or I am probably not on the same page with you 
>> guys...
>>
>
> What happens when you run it under gdb?
It is a very small environment and I don't have a lot of stuff in the 
system.
But I think it must be a string boundary issue or something really 
small, because when I do "ls" or ls -1, it is not bombing.

I don't have ti time to look at the applet right now, but I may try next 
week. Though I think the owner should take a look at it...
Cheers.






From etzvetanov at xceedium.com  Fri Feb  2 16:49:17 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 19:49:17 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C6D0.8020209@avtrex.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
Message-ID: <45C3DC0D.900@xceedium.com>

David Daney wrote:
> Evgueni Tzvetanov wrote:
>> Hi all,
>>
>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>> little system for testing.
>> It is running Linux kernel 2.6.18.1.
>>
>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>> /usr/bin) it is pulling Segmentation Fault.
>> What could be wrong or I am probably not on the same page with you 
>> guys...
>>
>
> What happens when you run it under gdb?
Even stranger. When I call the command like (if this can help in anyway):
"busybox ls -l" it is not bombing. When I run it as "ls -l" it is bombing.


From questforhappiness at hotmail.com  Fri Feb  2 17:34:30 2007
From: questforhappiness at hotmail.com (none none)
Date: Fri, 02 Feb 2007 17:34:30 -0800
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
Message-ID: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>

Hi there,

My aventail appliances are using busybox as OS.  I checked and find that it 
is not using the new 2007 Daylight Saving Time schedule.  Does anyone know 
if there are patches or instructions to update busybox to accommodate the 
new 2007 Daylight Saving Time change?

Thank you,
Donald.

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline


From vda.linux at googlemail.com  Fri Feb  2 17:47:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 02:47:11 +0100
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>
References: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>
Message-ID: <200702030247.11080.vda.linux@googlemail.com>

On Saturday 03 February 2007 02:34, none none wrote:
> Hi there,
> 
> My aventail appliances are using busybox as OS.  I checked and find that it 
> is not using the new 2007 Daylight Saving Time schedule.  Does anyone know 
> if there are patches or instructions to update busybox to accommodate the 
> new 2007 Daylight Saving Time change?

This is done by libc routines. If it doesn't work for you,
you should update/fix your libc.
--
vda

From brion.finlay at gmail.com  Fri Feb  2 21:14:36 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Fri, 2 Feb 2007 23:14:36 -0600
Subject: Busybox build problem
In-Reply-To: <200702012321.40884.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
Message-ID: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>

Thanks for the responses.  It helped knowing that my gnu compiler/c library
configuration was correct.  It also helped knowing what the
bbconfigopts.hwas supposed to look like.

I did some digging into the problem and found the following.  The immediate
cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
/bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
construction for generating bbconfigopts.h.  This construction contains a
"\n" sequence, which the dash echo command interprets literally.  (See the
attached bbconfigopts.h production to see what happens.)

Linking /bin/sh to /bin/bash resolved this problem and allowed the build to
complete successfully.

The fix that could be made to scripts/mkconfigs in order to work more
generally, be less indirect, and avoid some of the backslash quoting would
be to eliminate the echo "`...`" construction and just execute the command
directly.  That is, change this:

echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
"\\"" $0 "\\\\n\\"";}'`"

to this:

sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
"\\n\"";}'

I tested this change under bash and dash and it works in both shells.


Alternatively, since awk is being invoked anyway, this line could be changed
to just a single line awk invocation to do away with the sed, the grep, and
the echo:

awk '/^#? ?CONFIG_/ {gsub(/\"/,"\\\\\"",$0); print "\"" $0 "\\n\"";}'
$config

I tested this change under bash and dash and it also works in both shells.

I have also attached a patch file to mkconfigs for the single line awk
version.


On 2/1/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Thursday 01 February 2007 07:26, Brion Finlay wrote:
> > This seems like it should be a simple question that other people have
> had
> > problems with, but I cannot get Busybox to build.  I have tried
> google-ing
> > for similar problems, searching the mail archives, and reading the FAQs
> and
> > all of the documentation, but I cannot figure out what is going on.
> >
> > I am using a fairly fresh install of Ubuntu 6.1, and I have installed
> enough
> > of the development packages to build a custom kernel.  (I mention this
> > because Ubuntu does not preinstall many development packages, so it is
> > possible I am still missing some, but I have installed quite a few.)
> >
> > The GCC version is 4.1.2.
> > sed is GNU Sed version 4.1.5
> >
> > Here are the compile problems that I get:
> >
> > Busybox 1.4.1
> > # make defconfig; make
> >
> > ...
> > include/bbconfigopts.h:1088: error: missing terminating " character
> > (repeated for each line)
> > include/bbconfigopts.h:1089: error: expected expression before ';' token
> > make[1]: *** [miscutils/bbconfig.o] Error 1
> > make: *** [miscutils] Error 2
>
> gcc 4.1.1, glibc 2.4, gnu sed 4.1.5, bbox 1.4.1:
>
> # make defconfig; make
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/basic/split-include
>   HOSTCC  scripts/basic/docproc
>   HOSTCC  scripts/kconfig/conf.o
>   HOSTCC  scripts/kconfig/kxgettext.o
>   HOSTCC  scripts/kconfig/mconf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/lex.zconf.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf -d Config.in
> /.local/tmp/busybox-1.4.1/scripts/defconfig:351:warning: trying to assign
> nonexistent symbol E2FSCK
> /.local/tmp/busybox-1.4.1/scripts/defconfig:354:warning: trying to assign
> nonexistent symbol MKE2FS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:355:warning: trying to assign
> nonexistent symbol TUNE2FS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:356:warning: trying to assign
> nonexistent symbol E2LABEL
> /.local/tmp/busybox-1.4.1/scripts/defconfig:357:warning: trying to assign
> nonexistent symbol FINDFS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:635:warning: symbol value ''
> invalid for FEATURE_COMMAND_HISTORY
> *
> * Busybox Configuration
> *
> *
> * Busybox Settings
> *
> *
> * General Configuration
> *
> See lots more (probably unnecessary) configuration options. (NITPICK)
> [N/y/?] n
> Enable options for full-blown desktop systems (DESKTOP) [N/y/?] n
> ...
> envdir (ENVDIR) [Y/n/?] y
> softlimit (SOFTLIMIT) [Y/n/?] y
>   SPLIT   include/autoconf.h -> include/config/*
>   GEN     include/bbconfigopts.h
>   HOSTCC  applets/usage
>   GEN     include/usage_compressed.h
>   CC      applets/applets.o
>   CC      applets/busybox.o
> ...
>   CC      util-linux/switch_root.o
>   CC      util-linux/umount.o
>   AR      util-linux/lib.a
>   LINK    busybox_unstripped
>
> include/bbconfigopts.h from build tree is attached.
> --
> vda
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070202/802bfa3b/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bbconfigopts.h
Type: text/x-chdr
Size: 20606 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/802bfa3b/attachment-0001.h 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkconfigs.patch
Type: text/x-patch
Size: 429 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/802bfa3b/attachment-0001.bin 

From vapier at gentoo.org  Fri Feb  2 23:41:38 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 3 Feb 2007 02:41:38 -0500
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702030241.41425.vapier@gentoo.org>

On Saturday 03 February 2007, Brion Finlay wrote:
> The fix that could be made to scripts/mkconfigs in order to work more
> generally

another fix would be to use a POSIX compliant shell ... then there wouldnt be 
problem
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/af9e409d/attachment.pgp 

From vapier at gentoo.org  Fri Feb  2 23:44:07 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 3 Feb 2007 02:44:07 -0500
Subject: build system doesnt properly detect applet rebuild requirement
Message-ID: <200702030244.08150.vapier@gentoo.org>

$ make distclean
$ make allnoconfig
$ make menuconfig
-> enable dmesg, syslog, klogd, logger
$ make
$ nano .config
-> disable syslog, klogd, logger
$ make oldconfig
$ make
<link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/97fef1e6/attachment.pgp 

From rep.dot.nop at gmail.com  Sat Feb  3 04:09:49 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:09:49 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702030244.08150.vapier@gentoo.org>
References: <200702030244.08150.vapier@gentoo.org>
Message-ID: <20070203120949.GB12488@aon.at>

On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
>$ make distclean
>$ make allnoconfig
>$ make menuconfig
>-> enable dmesg, syslog, klogd, logger
>$ make
>$ nano .config
>-> disable syslog, klogd, logger
>$ make oldconfig
>$ make
><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>-mike

Confirmed. See also vda's note that it's disfunctional:
http://busybox.net/lists/busybox/2007-January/025966.html

In the old buildsys we had a dependency like
applets.o: .config

Nowadays applets.o depends on usage_compressed.h alone.
Iff the problem turns out to be passing -include autoconf.h directly
(so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
#include "autoconf.h" into libbb.h would perhaps change that
misbehaviour. Any takers?

From vda.linux at googlemail.com  Sat Feb  3 04:07:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:07:45 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702030244.08150.vapier@gentoo.org>
References: <200702030244.08150.vapier@gentoo.org>
Message-ID: <200702031307.45497.vda.linux@googlemail.com>

On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> $ make distclean
> $ make allnoconfig
> $ make menuconfig
> -> enable dmesg, syslog, klogd, logger
> $ make
> $ nano .config
> -> disable syslog, klogd, logger
> $ make oldconfig
> $ make
> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> -mike

Does this patch help?
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 1914 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/2ad8d42b/attachment.bin 

From rep.dot.nop at gmail.com  Sat Feb  3 04:21:31 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:21:31 +0100
Subject: sigset_t [was: Re: svn commit: trunk/busybox/runit]
In-Reply-To: <20070203014756.DD8AE48641@busybox.net>
References: <20070203014756.DD8AE48641@busybox.net>
Message-ID: <20070203122131.GD12488@aon.at>

On Fri, Feb 02, 2007 at 05:47:56PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-02 17:47:56 -0800 (Fri, 02 Feb 2007)
>New Revision: 17732
>
>Log:
>sigset_t blocked_sigset is too big for static (128 bytes)

and what about
$ svngrep -rl sigset_t * 
init/init.c
loginutils/vlock.c
mk.check.log
networking/inetd.c
networking/arping.c
runit/runit_lib.c
runit/svlogd.c


From rep.dot.nop at gmail.com  Sat Feb  3 04:41:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:41:21 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702031307.45497.vda.linux@googlemail.com>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
Message-ID: <20070203124121.GF12488@aon.at>

On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
>On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
>> $ make distclean
>> $ make allnoconfig
>> $ make menuconfig
>> -> enable dmesg, syslog, klogd, logger
>> $ make
>> $ nano .config
>> -> disable syslog, klogd, logger
>> $ make oldconfig
>> $ make
>> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>> -mike
>
>Does this patch help?

An IMHO cleaner approach would be the attached.

Comments?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.fix-autoconf-dep.00.diff
Type: text/x-diff
Size: 1564 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/74944a0c/attachment.bin 

From vda.linux at googlemail.com  Sat Feb  3 04:39:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:39:51 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203120949.GB12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<20070203120949.GB12488@aon.at>
Message-ID: <200702031339.51374.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:09, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
> >$ make distclean
> >$ make allnoconfig
> >$ make menuconfig
> >-> enable dmesg, syslog, klogd, logger
> >$ make
> >$ nano .config
> >-> disable syslog, klogd, logger
> >$ make oldconfig
> >$ make
> ><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >-mike
> 
> Confirmed. See also vda's note that it's disfunctional:
> http://busybox.net/lists/busybox/2007-January/025966.html
> 
> In the old buildsys we had a dependency like
> applets.o: .config
> 
> Nowadays applets.o depends on usage_compressed.h alone.
> Iff the problem turns out to be passing -include autoconf.h directly
> (so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
> #include "autoconf.h" into libbb.h would perhaps change that
> misbehaviour. Any takers?

Attached patch should fix it. Works for me.
Can someone else confirm?

Will need big dumb patch with lots of

+int ar_main(int argc, char **argv);
 int ar_main(int argc, char **argv)

in order to suppress warnings.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 1914 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/aeffe6ef/attachment.bin 

From rep.dot.nop at gmail.com  Sat Feb  3 04:43:59 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:43:59 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702031339.51374.vda.linux@googlemail.com>
References: <200702030244.08150.vapier@gentoo.org>
	<20070203120949.GB12488@aon.at>
	<200702031339.51374.vda.linux@googlemail.com>
Message-ID: <20070203124359.GG12488@aon.at>

On Sat, Feb 03, 2007 at 01:39:51PM +0100, Denis Vlasenko wrote:
>On Saturday 03 February 2007 13:09, Bernhard Fischer wrote:
>> On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
>> >$ make distclean
>> >$ make allnoconfig
>> >$ make menuconfig
>> >-> enable dmesg, syslog, klogd, logger
>> >$ make
>> >$ nano .config
>> >-> disable syslog, klogd, logger
>> >$ make oldconfig
>> >$ make
>> ><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>> >-mike
>> 
>> Confirmed. See also vda's note that it's disfunctional:
>> http://busybox.net/lists/busybox/2007-January/025966.html
>> 
>> In the old buildsys we had a dependency like
>> applets.o: .config
>> 
>> Nowadays applets.o depends on usage_compressed.h alone.
>> Iff the problem turns out to be passing -include autoconf.h directly
>> (so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
>> #include "autoconf.h" into libbb.h would perhaps change that
>> misbehaviour. Any takers?
>
>Attached patch should fix it. Works for me.
>Can someone else confirm?
>
>Will need big dumb patch with lots of
>
>+int ar_main(int argc, char **argv);
> int ar_main(int argc, char **argv)
>
>in order to suppress warnings.

I don't like that approach, personally.
Seen my counter-proposal that i sent a minute ago?

From vda.linux at googlemail.com  Sat Feb  3 04:49:47 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:49:47 +0100
Subject: sigset_t [was: Re: svn commit: trunk/busybox/runit]
In-Reply-To: <20070203122131.GD12488@aon.at>
References: <20070203014756.DD8AE48641@busybox.net>
	<20070203122131.GD12488@aon.at>
Message-ID: <200702031349.47336.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:21, Bernhard Fischer wrote:
> On Fri, Feb 02, 2007 at 05:47:56PM -0800, vda at busybox.net wrote:
> >Author: vda
> >Date: 2007-02-02 17:47:56 -0800 (Fri, 02 Feb 2007)
> >New Revision: 17732
> >
> >Log:
> >sigset_t blocked_sigset is too big for static (128 bytes)
> 
> and what about
> $ svngrep -rl sigset_t * 
> init/init.c
> loginutils/vlock.c
> mk.check.log
> networking/inetd.c
> networking/arping.c
> runit/runit_lib.c
> runit/svlogd.c

None of them is static (all are auto variables)
--
vda

From vda.linux at googlemail.com  Sat Feb  3 04:51:44 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:51:44 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702031351.44512.vda.linux@googlemail.com>

On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> Thanks for the responses.  It helped knowing that my gnu compiler/c library
> configuration was correct.  It also helped knowing what the
> bbconfigopts.hwas supposed to look like.
> 
> I did some digging into the problem and found the following.  The immediate
> cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
> /bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
> construction for generating bbconfigopts.h.  This construction contains a
> "\n" sequence, which the dash echo command interprets literally.  (See the
> attached bbconfigopts.h production to see what happens.)
> 
> Linking /bin/sh to /bin/bash resolved this problem and allowed the build to
> complete successfully.
> 
> The fix that could be made to scripts/mkconfigs in order to work more
> generally, be less indirect, and avoid some of the backslash quoting would
> be to eliminate the echo "`...`" construction and just execute the command
> directly.  That is, change this:
> 
> echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> "\\"" $0 "\\\\n\\"";}'`"
> 
> to this:
> 
> sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
> "\\n\"";}'
> 
> I tested this change under bash and dash and it works in both shells.

There is presumably a reason why it is done that way. Is bbconfig.h different?

Another question, does it (unmodified version, that is) work with bbox ash?
--
vda

From vda.linux at googlemail.com  Sat Feb  3 04:57:17 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:57:17 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203124121.GF12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
	<20070203124121.GF12488@aon.at>
Message-ID: <200702031357.17715.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:41, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
> >On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> >> $ make distclean
> >> $ make allnoconfig
> >> $ make menuconfig
> >> -> enable dmesg, syslog, klogd, logger
> >> $ make
> >> $ nano .config
> >> -> disable syslog, klogd, logger
> >> $ make oldconfig
> >> $ make
> >> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >> -mike
> >
> >Does this patch help?
> 
> An IMHO cleaner approach would be the attached.
> 
> Comments?

--- busybox_trunk/include/libbb.h???????(revision 17735)
+++ busybox_trunk/include/libbb.h???????(working copy)

+#include "autoconf.h"
?#include "platform.h"

This will make every .c file depend on .config. Change just one
CONFIG_xxx and watch make rebuild everything.

-include/usage_compressed.h: $(srctree)/include/usage.h applets/usage
+include/usage_compressed.h: include/autoconf.h $(srctree)/include/usage.h applets/usage

Maybe this is needed. Or just .config instead of include/autoconf.h?
I admit I'm not good in Makefile hacking...

--
vda

From vda.linux at googlemail.com  Sat Feb  3 05:19:10 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 14:19:10 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203124121.GF12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
	<20070203124121.GF12488@aon.at>
Message-ID: <200702031419.10898.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:41, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
> >On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> >> $ make distclean
> >> $ make allnoconfig
> >> $ make menuconfig
> >> -> enable dmesg, syslog, klogd, logger
> >> $ make
> >> $ nano .config
> >> -> disable syslog, klogd, logger
> >> $ make oldconfig
> >> $ make
> >> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >> -mike
> >
> >Does this patch help?
> 
> An IMHO cleaner approach would be the attached.

Why is it 'cleaner'? I checked my change: it muchly
reduces false dependencies. Isn't it nice?
--
vda

From pgf at brightstareng.com  Sat Feb  3 05:41:00 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Sat, 03 Feb 2007 08:41:00 -0500
Subject: Busybox build problem 
In-Reply-To: vapier's message of Sat, 03 Feb 2007 02:41:38 -0500.
	<200702030241.41425.vapier@gentoo.org> 
Message-ID: <28616.1170510060@brightstareng.com>

vapier wrote:
 > On Saturday 03 February 2007, Brion Finlay wrote:
 > > The fix that could be made to scripts/mkconfigs in order to work more
 > > generally
 > 
 > another fix would be to use a POSIX compliant shell ... then there wouldnt
 > be problem
 > -mike
 > 

we had the same problem with a different build system when we
moved it to ubuntu.  i did some googling at the time, but
couldn't find a definitive answer -- i expected to find a lot of
discussion on it somewhere in ubuntu-land, since it's a pretty
big change, but i didn't.  it's not clear to me that dash isn't
posix compliant, at least with regard to echo's expanding '\n'. 
but it might not be.  is there a "dash is/isn't POSIX" discussion
page out there anywhere?

in our case it was expedient (and safe) to simply replace
"#!/bin/sh" with "#!/bin/bash", but that's probably not
appropriate for busybox.

paul
=---------------------
 paul fox, pgf at brightstareng.com

From brion.finlay at gmail.com  Sat Feb  3 11:15:22 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 13:15:22 -0600
Subject: Busybox build problem
In-Reply-To: <200702031351.44512.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
	<200702031351.44512.vda.linux@googlemail.com>
Message-ID: <aa1451e00702031115l292e2079seb2d37257c051ec2@mail.gmail.com>

bbconfig.h: Yes, it seems to be a different file that is not generated by
scripts/mkconfigs.  include/config/bbconfig.h looks to be only a single
line, and it does not have quotes or "\n" in the file like
include/bbconfigopts.h.  Whether built with dash or bash using the
unmodified mkconfigs, both include/config/bbconfig.h files look like this:

#define CONFIG_BBCONFIG 1

I don't think scripts/mkconfigs generates include/config/bbconfig.h, I think
it only generates bbconfigopts.h, despite the comment in the header.  The
main evidence for this is that the include define for the .h file it
generates is always "_BBCONFIGOPTS_H", and is always generated.
include/config/bbconfig.h does not contain any of the text that is always
generated.

To be honest, though, I am not sure what IS generating the
include/config/bbconfig.h file.  Some quick greps through the source tree do
not turn anything up, but I know that this file gets replaced with a #undef
CONFIG_BBCONFIG when that option is turned off.

I could also clean up the comments and submit another patch if you are
interested.  There is another error in the comments where it refers to
scripts/config/mkconfigs instead of scripts/mkconfigs, which is propogated
to the generated bbconfigopts.h.

ash:  I just tested with ash.  The unmodified version does work with the
bbox ash.  The unmodified version also works with bash, in case that wasn't
clear from my other email.  The modified version also works with ash, bash,
and dash.

I agree, presumably there was a reason.  Maybe someone can shed some light.
I will share some of my thoughts.

It might be that the reason for using the echo "` ... `" construction is
simply to make the script look nicer, since the other lines in the script
are all echo statements.

The only difference that I see using an echo "` ... `" versus direct
execution of the command is that the echo statement could process escape
characters from the output of the backquote command.   If it isn't the
intent to process escape characters, then it seems like it might as well
execute the command directly.  In this case, the echo command of "dash" IS
processing the escape characters, and this causes a problem, so it
certainly doesn't seem like the intent is to use echo to process escape
characters (which seems like a dubious intent, anyway.)

The mkconfigs script appears to be simple.  As the comments state, it is
pulling lines from .config which start with "CONFIG_" or "# CONFIG_",
replacing " with \", and prints each line as "<string>\n".


On 2/3/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> > Thanks for the responses.  It helped knowing that my gnu compiler/c
> library
> > configuration was correct.  It also helped knowing what the
> > bbconfigopts.hwas supposed to look like.
> >
> > I did some digging into the problem and found the following.  The
> immediate
> > cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
> > /bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
> > construction for generating bbconfigopts.h.  This construction contains
> a
> > "\n" sequence, which the dash echo command interprets literally.  (See
> the
> > attached bbconfigopts.h production to see what happens.)
> >
> > Linking /bin/sh to /bin/bash resolved this problem and allowed the build
> to
> > complete successfully.
> >
> > The fix that could be made to scripts/mkconfigs in order to work more
> > generally, be less indirect, and avoid some of the backslash quoting
> would
> > be to eliminate the echo "`...`" construction and just execute the
> command
> > directly.  That is, change this:
> >
> > echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
>
> > "\\"" $0 "\\\\n\\"";}'`"
> >
> > to this:
> >
> > sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\""
> $0
> > "\\n\"";}'
> >
> > I tested this change under bash and dash and it works in both shells.
>
> There is presumably a reason why it is done that way. Is bbconfig.hdifferent?
>
> Another question, does it (unmodified version, that is) work with bbox
> ash?
> --
> vda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070203/2f8b8a35/attachment.html 

From brion.finlay at gmail.com  Sat Feb  3 12:02:41 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 14:02:41 -0600
Subject: Busybox build problem
In-Reply-To: <28616.1170510060@brightstareng.com>
References: <200702030241.41425.vapier@gentoo.org>
	<28616.1170510060@brightstareng.com>
Message-ID: <aa1451e00702031202l2e85adffuf8c45864b272bf74@mail.gmail.com>

I agree Paul, I wasn't sure that dash was/wasn't compliant.  It is the
default with the latest Ubuntu for /bin/sh, which means busybox builds don't
work on Ubuntu by default.

Since the question was raised about posix compliance, I decided to go look
it up.  Here is what I found:

Here are the posix specs:
(free registration required)

Here is the main link:
http://www.unix.org/single_unix_specification/

here are some direct links:
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_02
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_03
http://www.opengroup.org/onlinepubs/000095399/utilities/echo.html

Here are some excerpts for consideration:

2.6.3 Command Substitution
"Within the backquoted style of command substitution, backslash shall retain
its literal meaning, except when followed by: '$', '`', or '\' (dollar sign,
backquote, backslash).
...
A single-quoted or double-quoted string that begins, but does not end,
within the "`...`" sequence produces undefined results."

so a single " or ' is undefined behavior within a backquote command
substitution and cannot be escaped with a backslash.

echo:
"It is not possible to use *echo* portably across all POSIX systems unless
both *-n* (as the first argument) and escape sequences are omitted."

"The following operands shall be supported:
*string*A string to be written to standard output. If the first operand is *
-n*, or if any of the operands contain a backslash ( '\' ) character, the
results are implementation-defined....
    \nWrite a <newline>....
"

So in the POSIX specs, the echo operand is not necessarily quoted, and a
"\n" is SUPPOSED to be printed as a newline, unless the "-n" option is used
(in which case backslash escapes are implementation specific), so according
to the spec technically bash and bbox ash are non-compliant because they
print the \n instead of the newline.

"New applications are encouraged to use
*printf*<http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html>instead
of
*echo*."
"

The *echo* utility has not been made obsolescent because of its extremely
widespread use in historical applications. Conforming applications that wish
to do prompting without <newline>s or that could possibly be expecting to
echo a *-n*, should use the
*printf*<http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html>utility
derived from the Ninth Edition system.

As specified, *echo* writes its arguments in the simplest of ways. The two
different historical versions of *echo* vary in fatally incompatible ways.

The BSD *echo* checks the first argument for the string *-n* which causes it
to suppress the <newline> that would otherwise follow the final argument in
the output.

The System V *echo* does not support any options, but allows escape
sequences within its operands, as described for XSI implementations in the
OPERANDS section.

The *echo* utility does not support Utility Syntax Guideline 10 because
historical applications depend on *echo* to echo *all* of its arguments,
except for the *-n* option in the BSD version.

"
Regardless of all of this (or perhaps this is a good demonstration) -
quoting is complicated and it is probably a good idea to avoid it when
possible.  An echo "`...`" command substitution seems a little like calling
"a 

On 2/3/07, Paul Fox <pgf at brightstareng.com> wrote:
>
> vapier wrote:
> > On Saturday 03 February 2007, Brion Finlay wrote:
> > > The fix that could be made to scripts/mkconfigs in order to work more
> > > generally
> >
> > another fix would be to use a POSIX compliant shell ... then there
> wouldn't
> > be problem
> > -mike
> >
>
> we had the same problem with a different build system when we
> moved it to ubuntu.  i did some googling at the time, but
> couldn't find a definitive answer -- i expected to find a lot of
> discussion on it somewhere in ubuntu-land, since it's a pretty
> big change, but i didn't.  it's not clear to me that dash isn't
> posix compliant, at least with regard to echo's expanding '\n'.
> but it might not be.  is there a "dash is/isn't POSIX" discussion
> page out there anywhere?
>
> in our case it was expedient (and safe) to simply replace
> "#!/bin/sh" with "#!/bin/bash", but that's probably not
> appropriate for busybox.
>
> paul
> =---------------------
> paul fox, pgf at brightstareng.com
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070203/e179b110/attachment.htm 

From vda.linux at googlemail.com  Sat Feb  3 15:34:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 00:34:32 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702040034.32257.vda.linux@googlemail.com>

On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> The fix that could be made to scripts/mkconfigs in order to work more
> generally, be less indirect, and avoid some of the backslash quoting would
> be to eliminate the echo "`...`" construction and just execute the command
> directly.  That is, change this:
> 
> echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> "\\"" $0 "\\\\n\\"";}'`"
> 
> to this:
> 
> sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
> "\\n\"";}'
> 
> I tested this change under bash and dash and it works in both shells.

But it doesn't work for me. ;) Your sed should have three \\\ instead of five.

Can you try the attached patch? Will apply if it also works for you.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 1349 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070204/3103bfbe/attachment.bin 

From somlo at cmu.edu  Sat Feb  3 15:58:43 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sat, 3 Feb 2007 18:58:43 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
Message-ID: <20070203235843.GA4059@hedwig.net.cmu.edu>

Denis & All,

The first part of this patch fixes BB_EXECLP in libbb.h, (it
accidentally calls execvp instead of execlp).

The rest replaces execlp and execvp calls with BB_EXECLP and
BB_EXECVP, respectively (except in the shells, where we use
STANDALONE_SHELL to accomplish this).

Once this is in, we should be able to remove hardcoded paths from
anywhere else they might still be used.

Cheers,
Gabriel

diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
--- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
@@ -559,11 +559,11 @@
 	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
 #define BB_EXECLP(prog,cmd,...) \
 	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
 #else
 #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
-#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
+#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
 #endif
 
 USE_DESKTOP(long long) int uncompress(int fd_in, int fd_out);
 int inflate(int in, int out);
 
diff -NarU5 busybox-svn-17746.orig/archival/tar.c busybox-svn-17746/archival/tar.c
--- busybox-svn-17746.orig/archival/tar.c	2007-02-03 18:17:52.000000000 -0500
+++ busybox-svn-17746/archival/tar.c	2007-02-03 18:48:50.000000000 -0500
@@ -527,11 +527,11 @@
 			dup2(tbInfo.tarFd, 1);
 
 			close(gzipStatusPipe[0]);
 			fcntl(gzipStatusPipe[1], F_SETFD, FD_CLOEXEC);	/* close on exec shows success */
 
-			execlp(zip_exec, zip_exec, "-f", NULL);
+			BB_EXECLP(zip_exec, zip_exec, "-f", NULL);
 			vfork_exec_errno = errno;
 
 			close(gzipStatusPipe[1]);
 			exit(-1);
 		} else if (gzipPid > 0) {
diff -NarU5 busybox-svn-17746.orig/console-tools/openvt.c busybox-svn-17746/console-tools/openvt.c
--- busybox-svn-17746.orig/console-tools/openvt.c	2007-02-03 18:17:52.000000000 -0500
+++ busybox-svn-17746/console-tools/openvt.c	2007-02-03 18:31:02.000000000 -0500
@@ -34,10 +34,10 @@
 		dup2(fd, STDIN_FILENO);
 		dup2(fd, STDOUT_FILENO);
 		dup2(fd, STDERR_FILENO);
 		while (fd > 2) close(fd--);
 
-		execvp(argv[2], &argv[2]);
+		BB_EXECVP(argv[2], &argv[2]);
 		_exit(1);
 	}
 	return EXIT_SUCCESS;
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/chroot.c busybox-svn-17746/coreutils/chroot.c
--- busybox-svn-17746.orig/coreutils/chroot.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/chroot.c	2007-02-03 18:32:55.000000000 -0500
@@ -31,8 +31,8 @@
 			*argv = (char *) DEFAULT_SHELL;
 		}
 		argv[1] = (char *) "-i";
 	}
 
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("cannot execute %s", *argv);
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/env.c busybox-svn-17746/coreutils/env.c
--- busybox-svn-17746.orig/coreutils/env.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/env.c	2007-02-03 18:33:53.000000000 -0500
@@ -79,11 +79,11 @@
 		}
 		++argv;
 	}
 
 	if (*argv) {
-		execvp(*argv, argv);
+		BB_EXECVP(*argv, argv);
 		/* SUSv3-mandated exit codes. */
 		xfunc_error_retval = (errno == ENOENT) ? 127 : 126;
 		bb_perror_msg_and_die("%s", *argv);
 	}
 
diff -NarU5 busybox-svn-17746.orig/coreutils/install.c busybox-svn-17746/coreutils/install.c
--- busybox-svn-17746.orig/coreutils/install.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/install.c	2007-02-03 18:49:11.000000000 -0500
@@ -124,11 +124,11 @@
 		) {
 			bb_perror_msg("cannot change ownership of %s", dest);
 			ret = EXIT_FAILURE;
 		}
 		if (flags & OPT_STRIP) {
-			if (execlp("strip", "strip", dest, NULL) == -1) {
+			if (BB_EXECLP("strip", "strip", dest, NULL) == -1) {
 				bb_perror_msg("strip");
 				ret = EXIT_FAILURE;
 			}
 		}
 		if (ENABLE_FEATURE_CLEAN_UP && isdir) free(dest);
diff -NarU5 busybox-svn-17746.orig/coreutils/nice.c busybox-svn-17746/coreutils/nice.c
--- busybox-svn-17746.orig/coreutils/nice.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/nice.c	2007-02-03 18:34:17.000000000 -0500
@@ -45,11 +45,11 @@
 		if (setpriority(PRIO_PROCESS, 0, prio) < 0) {
 			bb_perror_msg_and_die("setpriority(%d)", prio);
 		}
 	}
 
-	execvp(*argv, argv);		/* Now exec the desired program. */
+	BB_EXECVP(*argv, argv);		/* Now exec the desired program. */
 
 	/* The exec failed... */
 	xfunc_error_retval = (errno == ENOENT) ? 127 : 126; /* SUSv3 */
 	bb_perror_msg_and_die("%s", *argv);
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/nohup.c busybox-svn-17746/coreutils/nohup.c
--- busybox-svn-17746.orig/coreutils/nohup.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/nohup.c	2007-02-03 18:34:07.000000000 -0500
@@ -51,10 +51,10 @@
 
 	if (nullfd > 2)
 		close(nullfd);
 	signal(SIGHUP, SIG_IGN);
 
-	execvp(argv[1], argv+1);
+	BB_EXECVP(argv[1], argv+1);
 	if (ENABLE_FEATURE_CLEAN_UP && home)
 		free((char*)nohupout);
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17746.orig/e2fsprogs/fsck.c busybox-svn-17746/e2fsprogs/fsck.c
--- busybox-svn-17746.orig/e2fsprogs/fsck.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/e2fsprogs/fsck.c	2007-02-03 18:34:40.000000000 -0500
@@ -675,11 +675,11 @@
 			if (!interactive) {
 				/* NB: e2fsck will complain because of this!
 				 * Use "fsck -s" to avoid... */
 				close(0);
 			}
-			execvp(argv[0], argv);
+			BB_EXECVP(argv[0], argv);
 			bb_perror_msg_and_die("%s", argv[0]);
 		}
 	}
 
 	for (i = num_args+1; i < argc; i++)
diff -NarU5 busybox-svn-17746.orig/findutils/xargs.c busybox-svn-17746/findutils/xargs.c
--- busybox-svn-17746.orig/findutils/xargs.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/findutils/xargs.c	2007-02-03 18:35:23.000000000 -0500
@@ -58,11 +58,11 @@
 	if (p < 0)
 		bb_perror_msg_and_die("vfork");
 
 	if (p == 0) {
 		/* vfork -- child */
-		execvp(args[0], args);
+		BB_EXECVP(args[0], args);
 		exec_errno = errno;     /* set error to shared stack */
 		_exit(1);
 	}
 
 	/* vfork -- parent */
diff -NarU5 busybox-svn-17746.orig/loginutils/adduser.c busybox-svn-17746/loginutils/adduser.c
--- busybox-svn-17746.orig/loginutils/adduser.c	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/loginutils/adduser.c	2007-02-03 18:49:30.000000000 -0500
@@ -78,11 +78,11 @@
 static void passwd_wrapper(const char *login) ATTRIBUTE_NORETURN;
 
 static void passwd_wrapper(const char *login)
 {
 	static const char prog[] = "passwd";
-	execlp(prog, prog, login, NULL);
+	BB_EXECLP(prog, prog, login, NULL);
 	bb_error_msg_and_die("failed to execute '%s', you must set the password for '%s' manually", prog, login);
 }
 
 /* putpwent(3) remix */
 static int adduser(struct passwd *p, unsigned long flags)
diff -NarU5 busybox-svn-17746.orig/loginutils/login.c busybox-svn-17746/loginutils/login.c
--- busybox-svn-17746.orig/loginutils/login.c	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/loginutils/login.c	2007-02-03 18:36:35.000000000 -0500
@@ -355,11 +355,11 @@
 				setenv("LOGIN_TTY", full_tty, 1);
 				setenv("LOGIN_USER", pw->pw_name, 1);
 				setenv("LOGIN_UID", utoa(pw->pw_uid), 1);
 				setenv("LOGIN_GID", utoa(pw->pw_gid), 1);
 				setenv("LOGIN_SHELL", pw->pw_shell, 1);
-				execvp(script, t_argv);
+				BB_EXECVP(script, t_argv);
 				exit(1);
 			default: /* parent */
 				wait(NULL);
 			}
 		}
diff -NarU5 busybox-svn-17746.orig/miscutils/devfsd.c busybox-svn-17746/miscutils/devfsd.c
--- busybox-svn-17746.orig/miscutils/devfsd.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/devfsd.c	2007-02-03 18:38:06.000000000 -0500
@@ -376,11 +376,11 @@
 		exit (EXIT_SUCCESS);
 	}
 	 /* Child : if arg0 != NULL do execvp */
 	if(arg0 != NULL )
 	{
-		execvp (arg0, arg);
+		BB_EXECVP(arg0, arg);
 		msg_logger_and_die(LOG_ERR, "execvp");
 	}
 }
 
 static void safe_memcpy( char *dest, const char *src, int len)
diff -NarU5 busybox-svn-17746.orig/miscutils/setsid.c busybox-svn-17746/miscutils/setsid.c
--- busybox-svn-17746.orig/miscutils/setsid.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/setsid.c	2007-02-03 18:39:23.000000000 -0500
@@ -34,9 +34,9 @@
 	}
 	/* child */
 
 	setsid();  /* no error possible */
 
-	execvp(argv[1], argv + 1);
+	BB_EXECVP(argv[1], argv + 1);
 
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17746.orig/miscutils/taskset.c busybox-svn-17746/miscutils/taskset.c
--- busybox-svn-17746.orig/miscutils/taskset.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/taskset.c	2007-02-03 18:39:02.000000000 -0500
@@ -89,11 +89,11 @@
 		state += 8;
 		++argv;
 		goto print_aff;
 	}
 	++argv;
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("%s", *argv);
 }
 #undef OPT_p
 #undef TASKSET_PRINTF_MASK
 #undef from_cpuset
diff -NarU5 busybox-svn-17746.orig/miscutils/time.c busybox-svn-17746/miscutils/time.c
--- busybox-svn-17746.orig/miscutils/time.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/time.c	2007-02-03 18:38:33.000000000 -0500
@@ -408,11 +408,11 @@
 	if (pid < 0)
 		bb_error_msg_and_die("cannot fork");
 	else if (pid == 0) {	/* If child.  */
 		/* Don't cast execvp arguments; that causes errors on some systems,
 		   versus merely warnings if the cast is left off.  */
-		execvp(cmd[0], cmd);
+		BB_EXECVP(cmd[0], cmd);
 		bb_error_msg("cannot run %s", cmd[0]);
 		_exit(errno == ENOENT ? 127 : 126);
 	}
 
 	/* Have signals kill the child but not self (if possible).  */
diff -NarU5 busybox-svn-17746.orig/networking/ifupdown.c busybox-svn-17746/networking/ifupdown.c
--- busybox-svn-17746.orig/networking/ifupdown.c	2007-02-03 18:17:50.000000000 -0500
+++ busybox-svn-17746/networking/ifupdown.c	2007-02-03 18:40:21.000000000 -0500
@@ -1002,11 +1002,11 @@
 		dup2(outfd[1], 1);
 		close(infd[0]);
 		close(infd[1]);
 		close(outfd[0]);
 		close(outfd[1]);
-		execvp(command, argv);
+		BB_EXECVP(command, argv);
 		exit(127);
 	default:			/* parent */
 		*in = fdopen(infd[1], "w");
 		*out = fdopen(outfd[0], "r");
 		close(infd[0]);
diff -NarU5 busybox-svn-17746.orig/networking/nc.c busybox-svn-17746/networking/nc.c
--- busybox-svn-17746.orig/networking/nc.c	2007-02-03 18:17:50.000000000 -0500
+++ busybox-svn-17746/networking/nc.c	2007-02-03 18:42:22.000000000 -0500
@@ -147,11 +147,11 @@
 			dup2(cfd, 0);
 			close(cfd);
 		}
 		dup2(0, 1);
 		dup2(0, 2);
-		USE_NC_EXTRA(execvp(execparam[0], execparam);)
+		USE_NC_EXTRA(BB_EXECVP(execparam[0], execparam);)
 		/* Don't print stuff or it will go over the wire.... */
 		_exit(127);
 	}
 
 	// Select loop copying stdin to cfd, and cfd to stdout.
diff -NarU5 busybox-svn-17746.orig/runit/chpst.c busybox-svn-17746/runit/chpst.c
--- busybox-svn-17746.orig/runit/chpst.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/runit/chpst.c	2007-02-03 18:42:47.000000000 -0500
@@ -308,11 +308,11 @@
 	if (env_user) euidgid(env_user);
 	if (set_user) suidgid(set_user);
 	if (OPT_nostdin) close(0);
 	if (OPT_nostdout) close(1);
 	if (OPT_nostderr) close(2);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void setuidgid(int argc, char **argv)
 {
@@ -320,11 +320,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	suidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envuidgid(int argc, char **argv)
 {
@@ -332,11 +332,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	euidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envdir(int argc, char **argv)
 {
@@ -344,11 +344,11 @@
 
 	dir = *++argv;
 	if (!dir) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	edir(dir);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void softlimit(int argc, char **argv)
 {
@@ -367,8 +367,8 @@
 	if (option_mask32 & 0x200) limits = xatoul(s); // -s
 	if (option_mask32 & 0x400) limitt = xatoul(t); // -t
 	argv += optind;
 	if (!argv[0]) bb_show_usage();
 	slimit();
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
diff -NarU5 busybox-svn-17746.orig/runit/runsvdir.c busybox-svn-17746/runit/runsvdir.c
--- busybox-svn-17746.orig/runit/runsvdir.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/runit/runsvdir.c	2007-02-03 18:43:10.000000000 -0500
@@ -71,11 +71,11 @@
 		prog[1] = (char*)name;
 		prog[2] = NULL;
 		sig_uncatch(SIGHUP);
 		sig_uncatch(SIGTERM);
 		if (pgrp) setsid();
-		execvp(prog[0], prog);
+		BB_EXECVP(prog[0], prog);
 		//pathexec_run(*prog, prog, (char* const*)environ);
 		fatal2_cannot("start runsv ", name);
 	}
 	sv[no].pid = pid;
 }
diff -NarU5 busybox-svn-17746.orig/util-linux/setarch.c busybox-svn-17746/util-linux/setarch.c
--- busybox-svn-17746.orig/util-linux/setarch.c	2007-02-03 18:17:59.000000000 -0500
+++ busybox-svn-17746/util-linux/setarch.c	2007-02-03 18:45:38.000000000 -0500
@@ -44,10 +44,10 @@
 
 	/* Try to set personality */
 	if (personality(pers) >= 0) {
 
 		/* Try to execute the program */
-		execvp(argv[0], argv);
+		BB_EXECVP(argv[0], argv);
 	}
 
 	bb_perror_msg_and_die("%s", argv[0]);
 }

From vda.linux at googlemail.com  Sat Feb  3 16:08:05 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 01:08:05 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070203235843.GA4059@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
Message-ID: <200702040108.05723.vda.linux@googlemail.com>

On Sunday 04 February 2007 00:58, Gabriel L. Somlo wrote:
> Denis & All,
> 
> The first part of this patch fixes BB_EXECLP in libbb.h, (it
> accidentally calls execvp instead of execlp).

Thanks! Consider this already fixed.

> The rest replaces execlp and execvp calls with BB_EXECLP and
> BB_EXECVP, respectively (except in the shells, where we use
> STANDALONE_SHELL to accomplish this).
> 
> Once this is in, we should be able to remove hardcoded paths from
> anywhere else they might still be used.
> 
> Cheers,
> Gabriel
> 
> diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
> --- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
> +++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
> @@ -559,11 +559,11 @@
>  	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
>  #define BB_EXECLP(prog,cmd,...) \
>  	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
>  #else

Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
(which should be a function) to save space?

>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 

It's probably too messy to make BB_EXECLP a function because of varargs...

Otherwise looks ok.
--
vda

From brion.finlay at gmail.com  Sat Feb  3 19:54:33 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 21:54:33 -0600
Subject: Busybox build problem
In-Reply-To: <200702040034.32257.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
	<200702040034.32257.vda.linux@googlemail.com>
Message-ID: <aa1451e00702031954m171e377fw55fdedbbba6360aa@mail.gmail.com>

Whoops, you are absolutely right.  I did not do the ash testing correctly,
but I figured out why and retested.  The patch I gave you did not work under
ash, and that was because of the extra back slash quotes, just like you say.

I tested this new patch you sent under ash and I also tested it with dash -
it works there too.

I have one more change for your patch - the comment about
"scripts/config/mkconfigs" should be "scripts/mkconfigs".  This comment gets
put into bbconfigopts.h.  I regenerated the diff with this additional change
and attached it as "4.sed.patch".  I also fixed the awk-only version and
retested it under ash.  I attached it as "4.awk.patch".   I personally like
the awk-only version a little better because it is only one invocation vs.
three invocations and two pipes for the sed | grep  | awk version, and maybe
more because it is a slick awk one-liner - but its trivial, really.  It's
just a shell script that is part of the build process.  They both work to
get the job done so they both work for me.

Thanks

Brion

On 2/3/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> > The fix that could be made to scripts/mkconfigs in order to work more
> > generally, be less indirect, and avoid some of the backslash quoting
> would
> > be to eliminate the echo "`...`" construction and just execute the
> command
> > directly.  That is, change this:
> >
> > echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> > "\\"" $0 "\\\\n\\"";}'`"
> >
> > to this:
> >
> > sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\""
> $0
> > "\\n\"";}'
> >
> > I tested this change under bash and dash and it works in both shells.
>
> But it doesn't work for me. ;) Your sed should have three \\\ instead of
> five.
>
> Can you try the attached patch? Will apply if it also works for you.
> --
> vda
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070203/1a4813d7/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.sed.patch
Type: text/x-patch
Size: 1290 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/1a4813d7/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.awk.patch
Type: text/x-patch
Size: 1287 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/1a4813d7/attachment-0001.bin 

From Alexander at Kriegisch.name  Sat Feb  3 21:25:29 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 06:25:29 +0100
Subject: httpd and form-based upload
Message-ID: <45C56E49.9030907@Kriegisch.name>

Hi!

I would like to know if httpd supports form-based uploads and how they
can be handled in plain shell scripts (/bin/sh). I would be glad to see
one or more sample script(s).

Kind regards
-- 
Alexander Kriegisch

From rep.dot.nop at gmail.com  Sun Feb  4 02:28:53 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 11:28:53 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702040108.05723.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
Message-ID: <20070204102853.GJ12488@aon.at>

On Sun, Feb 04, 2007 at 01:08:05AM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 00:58, Gabriel L. Somlo wrote:
>> Denis & All,
>> 
>> The first part of this patch fixes BB_EXECLP in libbb.h, (it
>> accidentally calls execvp instead of execlp).
>
>Thanks! Consider this already fixed.
>
>> The rest replaces execlp and execvp calls with BB_EXECLP and
>> BB_EXECVP, respectively (except in the shells, where we use
>> STANDALONE_SHELL to accomplish this).
>> 
>> Once this is in, we should be able to remove hardcoded paths from
>> anywhere else they might still be used.
>> 
>> Cheers,
>> Gabriel
>> 
>> diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
>> --- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
>> +++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
>> @@ -559,11 +559,11 @@
>>  	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
>>  #define BB_EXECLP(prog,cmd,...) \
>>  	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
>>  #else
>
>Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
>(which should be a function) to save space?

Yes, please put it into an bb_execvp
>
>>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
>> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
>> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
>
>It's probably too messy to make BB_EXECLP a function because of varargs...

Why so? We already have several functions with varargs (our print
helpers), so this is fine. I'll note that several uncommon compilers had
problems with __VA_ARGS__ in the preprocessor but work fine for varargs
for the compiler. I'd prefer to have bb_execlp as a function, too.

From rep.dot.nop at gmail.com  Sun Feb  4 02:32:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 11:32:21 +0100
Subject: svn commit: trunk/busybox: include libbb networking sysklogd
In-Reply-To: <20070204023908.12D5548601@busybox.net>
References: <20070204023908.12D5548601@busybox.net>
Message-ID: <20070204103221.GK12488@aon.at>

On Sat, Feb 03, 2007 at 06:39:08PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-03 18:39:08 -0800 (Sat, 03 Feb 2007)
>New Revision: 17749

>Modified: trunk/busybox/include/libbb.h
>===================================================================
>--- trunk/busybox/include/libbb.h	2007-02-04 02:38:21 UTC (rev 17748)
>+++ trunk/busybox/include/libbb.h	2007-02-04 02:39:08 UTC (rev 17749)
>@@ -317,13 +317,13 @@
>  * Currently will return IPv4 or IPv6 sockaddrs only
>  * (depending on host), but in theory nothing prevents e.g.
>  * UNIX socket address being returned, IPX sockaddr etc... */
>-len_and_sockaddr* host2sockaddr(const char *host, int port);
>+len_and_sockaddr* xhost2sockaddr(const char *host, int port);
> #if ENABLE_FEATURE_IPV6
> /* Same, useful if you want to force family (e.g. IPv6) */
>-len_and_sockaddr* host_and_af2sockaddr(const char *host, int port, sa_family_t af);
>+len_and_sockaddr* xhost_and_af2sockaddr(const char *host, int port, sa_family_t af);

Why don't you mark those extern, btw?
> #else


From vda.linux at googlemail.com  Sun Feb  4 02:50:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 11:50:51 +0100
Subject: svn commit: trunk/busybox: include libbb networking sysklogd
In-Reply-To: <20070204103221.GK12488@aon.at>
References: <20070204023908.12D5548601@busybox.net>
	<20070204103221.GK12488@aon.at>
Message-ID: <200702041150.51385.vda.linux@googlemail.com>

On Sunday 04 February 2007 11:32, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 06:39:08PM -0800, vda at busybox.net wrote:
> >Author: vda
> >Date: 2007-02-03 18:39:08 -0800 (Sat, 03 Feb 2007)
> >New Revision: 17749
> 
> >Modified: trunk/busybox/include/libbb.h
> >===================================================================
> >--- trunk/busybox/include/libbb.h	2007-02-04 02:38:21 UTC (rev 17748)
> >+++ trunk/busybox/include/libbb.h	2007-02-04 02:39:08 UTC (rev 17749)
> >@@ -317,13 +317,13 @@
> >  * Currently will return IPv4 or IPv6 sockaddrs only
> >  * (depending on host), but in theory nothing prevents e.g.
> >  * UNIX socket address being returned, IPX sockaddr etc... */
> >-len_and_sockaddr* host2sockaddr(const char *host, int port);
> >+len_and_sockaddr* xhost2sockaddr(const char *host, int port);
> > #if ENABLE_FEATURE_IPV6
> > /* Same, useful if you want to force family (e.g. IPv6) */
> >-len_and_sockaddr* host_and_af2sockaddr(const char *host, int port, sa_family_t af);
> >+len_and_sockaddr* xhost_and_af2sockaddr(const char *host, int port, sa_family_t af);
> 
> Why don't you mark those extern, btw?

Function declarations are externs even if you don't put
extern keyword there, I think. extern is a must only for
variable declarations.

If you know a reason why extern should be there, please let me know.
--
vda

From vda.linux at googlemail.com  Sun Feb  4 03:03:28 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 12:03:28 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204102853.GJ12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
Message-ID: <200702041203.28506.vda.linux@googlemail.com>

On Sunday 04 February 2007 11:28, Bernhard Fischer wrote:
> >>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
> >> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
> >> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
> >
> >It's probably too messy to make BB_EXECLP a function because of varargs...
> 
> Why so? We already have several functions with varargs (our print
> helpers), so this is fine. I'll note that several uncommon compilers had
> problems with __VA_ARGS__ in the preprocessor but work fine for varargs
> for the compiler. I'd prefer to have bb_execlp as a function, too.

I have difficulty imagining how to _implement_ it.

int bb_execlp(char *prog, ...)
{
        va_list p;
	int n;
        va_start(p, prog);
        n = vexec(prog, p); ???? libc doesn't have vexec! ???
        va_end(p);
	return n;
}

Maybe it is doable with dirty tricks like calling execvp
with address of a parameter and hope that on your architecture
it will work.

But it doesn't worth the effort/complexity.
We have only four callsites of execlp.
--
vda

From rep.dot.nop at gmail.com  Sun Feb  4 03:51:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 12:51:21 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041203.28506.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
	<200702041203.28506.vda.linux@googlemail.com>
Message-ID: <20070204115117.GM12488@aon.at>

On Sun, Feb 04, 2007 at 12:03:28PM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 11:28, Bernhard Fischer wrote:
>> >>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
>> >> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
>> >> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
>> >
>> >It's probably too messy to make BB_EXECLP a function because of varargs...
>> 
>> Why so? We already have several functions with varargs (our print
>> helpers), so this is fine. I'll note that several uncommon compilers had
>> problems with __VA_ARGS__ in the preprocessor but work fine for varargs
>> for the compiler. I'd prefer to have bb_execlp as a function, too.
>
>I have difficulty imagining how to _implement_ it.

>But it doesn't worth the effort/complexity.
>We have only four callsites of execlp.

I see. Well if it's only four callsite, then a define is fine.

cheers,

From Alexander at Kriegisch.name  Sun Feb  4 05:44:40 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 14:44:40 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5E348.2050602@Kriegisch.name>

I wrote earlier:
>> I would like to know if httpd supports form-based uploads and how
>> they can be handled in plain shell scripts (/bin/sh). I would be glad
>> to see one or more sample script(s).

Some more background info: An HTML page for form-based upload could look like this:

<html>
<body>
  <form action="/cgi-bin/do_upload.cgi" method=post enctype="multipart/form-data">
    <input type=file size=50 maxlength=100000 name="File"><br>
    <input type=submit value="Submit">
  </form>
</body>
</html>

A server-side script receiving the upload could look like this:

#!/bin/sh
echo -n -e 'HTTP/1.0 200 OK\r\n'
echo -n -e 'Content-type: text/html\r\n\r\n'

cat > /var/tmp/upload.bin
cat << EOF
<html>
<body>
  <h2>Upload finished</h2>
</body>
</html>
EOF

And this would be the content of upload.bin:

-----------------------------7d72033ac0372
Content-Disposition: form-data; name="File"; filename="I:\install\sample_upload.tar.gz"
Content-Type: application/x-gzip

(...) unencoded binary stuff (...)
-----------------------------7d72033ac0372--

So, basically, I would need a shell script which could
cut away the MIME header and footer, so as to only save 
the "unencoded binary stuff" section to disk. This may 
not be a very busybox-specific question, but anyway, 
probably I should use the limited means provided by 
busybox's shell (ash) and toolset (sed, awk, maybe others) 
to achieve. I was also hoping for an httpd  configuration
option to help me achieve my goal without having to code
a CGI upload handler in C. BTW: My busybox is running on
a DSL router.
--
Alexander Kriegisch


From somlo at cmu.edu  Sun Feb  4 05:47:37 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sun, 4 Feb 2007 08:47:37 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204102853.GJ12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
Message-ID: <20070204134737.GA10874@hedwig.net.cmu.edu>

On Sun, Feb 04, 2007 at 11:28:53AM +0100, Bernhard Fischer wrote:
> >Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
> >(which should be a function) to save space?
> 
> Yes, please put it into an bb_execvp

OK, will do that. Now, about the specifics: I could simply do what the
macro now does, i.e., check for the existance of a busybox applet and
then call execvp. Or, I could "unwind" execvp, and check for the
presence of a '/' in the program name first, then for the presence of
an applet, and last search PATH the way the real execvp does, and end
up by calling execve(), the way the real execvp does.

Do we want to keep it simple more than we care about speed (avoiding
work when the progname contains a '/') ?

Cheers,
Gabriel

From wharms at bfs.de  Sun Feb  4 06:12:02 2007
From: wharms at bfs.de (walter harms)
Date: Sun, 04 Feb 2007 15:12:02 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5E9B2.70800@bfs.de>

hi Alexander
you would like to use httpd for uploading files ? (rfc1867)
the problem is already solved and called 'ftp'. there are several
examples how to script ftp. http has a totally different target
and misuse are mostly to be punished with serve problems.

Why do you need this ?

re,
 wh


Alexander Kriegisch wrote:
> Hi!
> 
> I would like to know if httpd supports form-based uploads and how they
> can be handled in plain shell scripts (/bin/sh). I would be glad to see
> one or more sample script(s).
> 
> Kind regards

From Alexander at Kriegisch.name  Sun Feb  4 06:21:22 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 15:21:22 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C5E9B2.70800@bfs.de>
References: <45C56E49.9030907@Kriegisch.name> <45C5E9B2.70800@bfs.de>
Message-ID: <45C5EBE2.1050203@Kriegisch.name>

> you would like to use httpd for uploading files ? (rfc1867) the
> problem is already solved and called 'ftp'. there are several 
> examples how to script ftp. http has a totally different target and
> misuse are mostly to be punished with serve problems.
> 
> Why do you need this ?

Dear Walter,

I want to extend my router's web configuration interface, so it would be
natural to use form based upload and not open a second data transmission
channel. As you wrote, there is an RFC for form-based upload, and MIME
multiparts are known much longer than that anyway. So this should nort
be regarded a misuse, it is a standard.
--
Alexander

> Alexander Kriegisch wrote:
>> I would like to know if httpd supports form-based uploads and how
>> they can be handled in plain shell scripts (/bin/sh). I would be
>> glad to see one or more sample script(s).


From rep.dot.nop at gmail.com  Sun Feb  4 07:01:57 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 16:01:57 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204134737.GA10874@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
Message-ID: <20070204150157.GN12488@aon.at>

On Sun, Feb 04, 2007 at 08:47:37AM -0500, Gabriel L. Somlo wrote:
>On Sun, Feb 04, 2007 at 11:28:53AM +0100, Bernhard Fischer wrote:
>> >Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
>> >(which should be a function) to save space?
>> 
>> Yes, please put it into an bb_execvp
>
>OK, will do that. Now, about the specifics: I could simply do what the
>macro now does, i.e., check for the existance of a busybox applet and
>then call execvp. Or, I could "unwind" execvp, and check for the
>presence of a '/' in the program name first, then for the presence of
>an applet, and last search PATH the way the real execvp does, and end
>up by calling execve(), the way the real execvp does.
>
>Do we want to keep it simple more than we care about speed (avoiding
>work when the progname contains a '/') ?

I don't think that spawning a subprogram is _that_ performance critical,
so i'd go for the simple case of looking if we've got an applet (like
the macro did) only. Also, i'd expect this to me smaller, which is the
ultimate reason there.

From nangel at nothome.org  Sun Feb  4 06:32:50 2007
From: nangel at nothome.org (Nathan Anglacos)
Date: Sun, 04 Feb 2007 09:32:50 -0500
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5EE92.80307@nothome.org>

[reposting to the busybox list]


Alexander Kriegisch wrote:
> Hi!
> 
> I would like to know if httpd supports form-based uploads and how they
> can be handled in plain shell scripts (/bin/sh). I would be glad to see
> one or more sample script(s).
> 
> Kind regards

Hi Alexander,

haserl (haserl.sourceforge.net) does what you are asking for.    haserl 
is a C cgi script, and works with busybox httpd.


From vda.linux at googlemail.com  Sun Feb  4 08:07:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 17:07:33 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204150157.GN12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
Message-ID: <200702041707.33774.vda.linux@googlemail.com>

On Sunday 04 February 2007 16:01, Bernhard Fischer wrote:
> >OK, will do that. Now, about the specifics: I could simply do what the
> >macro now does, i.e., check for the existance of a busybox applet and
> >then call execvp. Or, I could "unwind" execvp, and check for the
> >presence of a '/' in the program name first, then for the presence of
> >an applet, and last search PATH the way the real execvp does, and end
> >up by calling execve(), the way the real execvp does.
> >
> >Do we want to keep it simple more than we care about speed (avoiding
> >work when the progname contains a '/') ?
> 
> I don't think that spawning a subprogram is _that_ performance critical,

Yes. PATH search is completely dwarfed by fork+exec time anyway
(on current x86 processors and kernels, fork+exec flushes entire
L1 data cache (too many pages copied/zeroed out)).
--
vda

From vda.linux at googlemail.com  Sun Feb  4 09:10:57 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 18:10:57 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <200702022243.56100.vda.linux@googlemail.com>
References: <1170428490.28276.35.camel@localhost>
	<200702022243.56100.vda.linux@googlemail.com>
Message-ID: <200702041810.57851.vda.linux@googlemail.com>

On Friday 02 February 2007 22:43, Denis Vlasenko wrote:
> On Friday 02 February 2007 16:01, Natanael Copa wrote:
> > Hi,
> > 
> > Attatched is a patch for support of the '!' operator for find.
> > 
> > I created another macro ALLOC_TEST for actions that can be inverted with
> > '!'. They are not really actions (like -print) but tests (like -name).
> > 
> > It should not touch anything unless you have enabled the
> > FEATURE_FIND_NOT config option.
> 
> parse_params():
> invert_flag is never reset to 0. This must be a bug -
> "not" shouldn't be applied to the second -name here, I think
> (did not check it versus GNU find, tho...):
> find ! -name '*.a' -o -name '*.b'

I did it myself. find ! support is in svn. Please test.
--
vda

From wharms at bfs.de  Sun Feb  4 09:44:14 2007
From: wharms at bfs.de (walter harms)
Date: Sun, 04 Feb 2007 18:44:14 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C5EE92.80307@nothome.org>
References: <45C56E49.9030907@Kriegisch.name> <45C5EE92.80307@nothome.org>
Message-ID: <45C61B6E.4010705@bfs.de>



hi nathan,
i could not find any security stuff (like preventing an rm -r /).
did you try check it out ?

maybe this is something that should go to the webpage.

re,
 wh


Nathan Anglacos wrote:
> [reposting to the busybox list]
> 
> 
> Alexander Kriegisch wrote:
>> Hi!
>>
>> I would like to know if httpd supports form-based uploads and how they
>> can be handled in plain shell scripts (/bin/sh). I would be glad to see
>> one or more sample script(s).
>>
>> Kind regards
> 
> Hi Alexander,
> 
> haserl (haserl.sourceforge.net) does what you are asking for.    haserl 
> is a C cgi script, and works with busybox httpd.
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
> 
> 

From pgf at brightstareng.com  Sun Feb  4 09:51:04 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Sun, 04 Feb 2007 12:51:04 -0500
Subject: Busybox build problem 
In-Reply-To: brion.finlay's message of Sat, 03 Feb 2007 14:02:41 -0600.
	<aa1451e00702031202l2e85adffuf8c45864b272bf74@mail.gmail.com> 
Message-ID: <10826.1170611464@brightstareng.com>

 > 
 > "New applications are encouraged to use
 > *printf* ... instead of *echo*."

perhaps busybox should start moving in this direction in its
build scripts?  (i've never tried this sort of conversion myself,
and don't know whether other portability issues would emerge
as a result...)

paul
=---------------------
 paul fox, pgf at brightstareng.com

From vda.linux at googlemail.com  Sun Feb  4 13:17:09 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 22:17:09 +0100
Subject: svn commit: trunk/busybox/libbb
In-Reply-To: <20070204203239.23E9B48657@busybox.net>
References: <20070204203239.23E9B48657@busybox.net>
Message-ID: <200702042217.09589.vda.linux@googlemail.com>

On Sunday 04 February 2007 21:32, aldot at busybox.net wrote:
> -void llist_add_to(llist_t **old_head, void *data)
> +void llist_add_to(llist_t ** old_head, void *data)

Why different style for llist_t* and void*?

I think than this particular aspect of style should
be left unspecified.
--
vda

From rep.dot.nop at gmail.com  Sun Feb  4 13:50:40 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 22:50:40 +0100
Subject: svn commit: trunk/busybox/libbb
In-Reply-To: <200702042217.09589.vda.linux@googlemail.com>
References: <20070204203239.23E9B48657@busybox.net>
	<200702042217.09589.vda.linux@googlemail.com>
Message-ID: <20070204215040.GQ12488@aon.at>

On Sun, Feb 04, 2007 at 10:17:09PM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 21:32, aldot at busybox.net wrote:
>> -void llist_add_to(llist_t **old_head, void *data)
>> +void llist_add_to(llist_t ** old_head, void *data)
>
>Why different style for llist_t* and void*?
>
>I think than this particular aspect of style should
>be left unspecified.

I remember that i once looked to make indent not treat them differently,
but didn't find how to specify that. If you -- or anybody else for that
matter -- spot which setting this is, then please adjust it or send a
patch.

TIA,

From somlo at cmu.edu  Sun Feb  4 15:22:17 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sun, 4 Feb 2007 18:22:17 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041707.33774.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
	<200702041707.33774.vda.linux@googlemail.com>
Message-ID: <20070204232217.GA16952@hedwig.net.cmu.edu>

Denis, Bernhard,

Here's the patch that adds bb_execvp(). I compiled it
with static and dynamic linking (against glibc, I know static there is
buggy, but I just wanted to see how the binary size was affected :) ).
Here's the results (I'm building all but maybe two of the applets that
call execvp()):

arch.   linking         standalone      macro calls     bytes   
                        macro           bb_execvp()     saved


        static          1257820         1257820         0 
i386
        dynamic          512136          512136         0 


        static          1677276         1676860         416 
ppc
        dynamic          659600          659600         0 

No clue how much (if anything) we'd save on other architectures. Also,
not clear why dynamically linked binaries aren't affected (maybe
there's some padding/alignment thing, but I'm not an expert on the ELF
format :)

Also, if you *want* a bb_execlp(), we could do the following,
(shamelessly ripped from glibc):

int bb_execlp (const char *file, const char *arg, ...)
{
#define INITIAL_ARGV_MAX 1024
  size_t argv_max = INITIAL_ARGV_MAX;
  const char *initial_argv[INITIAL_ARGV_MAX];
  const char **argv = initial_argv;
  va_list args;

  argv[0] = arg;

  va_start (args, arg);
  unsigned int i = 0;
  while (argv[i++] != NULL)
    {
      if (i == argv_max)
        {
          argv_max *= 2;
          const char **nptr = xrealloc (argv == initial_argv ? NULL : argv,
                                       argv_max * sizeof (const char *));
          if (nptr == NULL)
            {
              if (argv != initial_argv)
                free (argv);
              return -1;
            }
          if (argv == initial_argv)
            /* We have to copy the already filled-in data ourselves.  */
            memcpy (nptr, argv, i * sizeof (const char *));

          argv = nptr;
        }

      argv[i] = va_arg (args, const char *);
    }
  va_end (args);

  int ret = bb_execvp (file, (char *const *) argv);
  if (argv != initial_argv)
    free (argv);

  return ret;
}

But given how few the places it's being called from, we'd end up maybe
increasing the size slightly instead of saving a few bytes.

(now, I don't know how many places call execl() with hardcoded paths
that should really be calling BB_EXECLP(), but that's something I'll
be looking into next :) )

OK, so given the meager space savings, do you guys still want this, or
should we stick with standalone macros ?

Here goes the patch.
Cheers,
--Gabriel

diff -NarU5 busybox-svn-17770.orig/libbb/execable.c busybox-svn-17770/libbb/execable.c
--- busybox-svn-17770.orig/libbb/execable.c	2007-02-04 16:25:51.000000000 -0500
+++ busybox-svn-17770/libbb/execable.c	2007-02-04 17:43:13.000000000 -0500
@@ -57,5 +57,15 @@
 		free(ret);
 		return 1;
 	}
 	return 0;
 }
+
+#ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
+/* just like the real execvp, but try to launch an applet named 'file' first
+ */
+int bb_execvp(const char *file, char *const argv[])
+{
+	return execvp(find_applet_by_name(file) ? CONFIG_BUSYBOX_EXEC_PATH : file,
+					argv);
+}
+#endif
diff -NarU5 busybox-svn-17770.orig/include/libbb.h busybox-svn-17770/include/libbb.h
--- busybox-svn-17770.orig/include/libbb.h	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/include/libbb.h	2007-02-04 17:42:54.000000000 -0500
@@ -560,12 +560,12 @@
 int execable_file(const char *name);
 char *find_execable(const char *filename);
 int exists_execable(const char *filename);
 
 #ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
-#define BB_EXECVP(prog,cmd) \
-	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
+int bb_execvp(const char *file, char *const argv[]);
+#define BB_EXECVP(prog,cmd) bb_execvp(prog,cmd)
 #define BB_EXECLP(prog,cmd,...) \
 	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
 #else
 #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
 #define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 

From somlo at cmu.edu  Sun Feb  4 15:23:55 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sun, 4 Feb 2007 18:23:55 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041707.33774.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
	<200702041707.33774.vda.linux@googlemail.com>
Message-ID: <20070204232355.GB16952@hedwig.net.cmu.edu>

... And here's the rest of it again -- converting exec*p to BB_EXEC*P.

Either way you decide to go with bb_exec*p(), this should be applied
regardless... :)

Thanks,
Gabriel


diff -NarU5 busybox-svn-17770.orig/archival/tar.c busybox-svn-17770/archival/tar.c
--- busybox-svn-17770.orig/archival/tar.c	2007-02-04 16:25:47.000000000 -0500
+++ busybox-svn-17770/archival/tar.c	2007-02-04 16:30:04.000000000 -0500
@@ -527,11 +527,11 @@
 			dup2(tbInfo.tarFd, 1);
 
 			close(gzipStatusPipe[0]);
 			fcntl(gzipStatusPipe[1], F_SETFD, FD_CLOEXEC);	/* close on exec shows success */
 
-			execlp(zip_exec, zip_exec, "-f", NULL);
+			BB_EXECLP(zip_exec, zip_exec, "-f", NULL);
 			vfork_exec_errno = errno;
 
 			close(gzipStatusPipe[1]);
 			exit(-1);
 		} else if (gzipPid > 0) {
diff -NarU5 busybox-svn-17770.orig/console-tools/openvt.c busybox-svn-17770/console-tools/openvt.c
--- busybox-svn-17770.orig/console-tools/openvt.c	2007-02-04 16:25:47.000000000 -0500
+++ busybox-svn-17770/console-tools/openvt.c	2007-02-04 16:30:04.000000000 -0500
@@ -34,10 +34,10 @@
 		dup2(fd, STDIN_FILENO);
 		dup2(fd, STDOUT_FILENO);
 		dup2(fd, STDERR_FILENO);
 		while (fd > 2) close(fd--);
 
-		execvp(argv[2], &argv[2]);
+		BB_EXECVP(argv[2], &argv[2]);
 		_exit(1);
 	}
 	return EXIT_SUCCESS;
 }
diff -NarU5 busybox-svn-17770.orig/coreutils/chroot.c busybox-svn-17770/coreutils/chroot.c
--- busybox-svn-17770.orig/coreutils/chroot.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/chroot.c	2007-02-04 16:30:04.000000000 -0500
@@ -31,8 +31,8 @@
 			*argv = (char *) DEFAULT_SHELL;
 		}
 		argv[1] = (char *) "-i";
 	}
 
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("cannot execute %s", *argv);
 }
diff -NarU5 busybox-svn-17770.orig/coreutils/env.c busybox-svn-17770/coreutils/env.c
--- busybox-svn-17770.orig/coreutils/env.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/env.c	2007-02-04 16:30:04.000000000 -0500
@@ -79,11 +79,11 @@
 		}
 		++argv;
 	}
 
 	if (*argv) {
-		execvp(*argv, argv);
+		BB_EXECVP(*argv, argv);
 		/* SUSv3-mandated exit codes. */
 		xfunc_error_retval = (errno == ENOENT) ? 127 : 126;
 		bb_perror_msg_and_die("%s", *argv);
 	}
 
diff -NarU5 busybox-svn-17770.orig/coreutils/install.c busybox-svn-17770/coreutils/install.c
--- busybox-svn-17770.orig/coreutils/install.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/install.c	2007-02-04 16:30:04.000000000 -0500
@@ -124,11 +124,11 @@
 		) {
 			bb_perror_msg("cannot change ownership of %s", dest);
 			ret = EXIT_FAILURE;
 		}
 		if (flags & OPT_STRIP) {
-			if (execlp("strip", "strip", dest, NULL) == -1) {
+			if (BB_EXECLP("strip", "strip", dest, NULL) == -1) {
 				bb_perror_msg("strip");
 				ret = EXIT_FAILURE;
 			}
 		}
 		if (ENABLE_FEATURE_CLEAN_UP && isdir) free(dest);
diff -NarU5 busybox-svn-17770.orig/coreutils/nice.c busybox-svn-17770/coreutils/nice.c
--- busybox-svn-17770.orig/coreutils/nice.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/nice.c	2007-02-04 16:30:04.000000000 -0500
@@ -45,11 +45,11 @@
 		if (setpriority(PRIO_PROCESS, 0, prio) < 0) {
 			bb_perror_msg_and_die("setpriority(%d)", prio);
 		}
 	}
 
-	execvp(*argv, argv);		/* Now exec the desired program. */
+	BB_EXECVP(*argv, argv);		/* Now exec the desired program. */
 
 	/* The exec failed... */
 	xfunc_error_retval = (errno == ENOENT) ? 127 : 126; /* SUSv3 */
 	bb_perror_msg_and_die("%s", *argv);
 }
diff -NarU5 busybox-svn-17770.orig/coreutils/nohup.c busybox-svn-17770/coreutils/nohup.c
--- busybox-svn-17770.orig/coreutils/nohup.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/nohup.c	2007-02-04 16:30:04.000000000 -0500
@@ -51,10 +51,10 @@
 
 	if (nullfd > 2)
 		close(nullfd);
 	signal(SIGHUP, SIG_IGN);
 
-	execvp(argv[1], argv+1);
+	BB_EXECVP(argv[1], argv+1);
 	if (ENABLE_FEATURE_CLEAN_UP && home)
 		free((char*)nohupout);
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17770.orig/e2fsprogs/fsck.c busybox-svn-17770/e2fsprogs/fsck.c
--- busybox-svn-17770.orig/e2fsprogs/fsck.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/e2fsprogs/fsck.c	2007-02-04 16:30:04.000000000 -0500
@@ -675,11 +675,11 @@
 			if (!interactive) {
 				/* NB: e2fsck will complain because of this!
 				 * Use "fsck -s" to avoid... */
 				close(0);
 			}
-			execvp(argv[0], argv);
+			BB_EXECVP(argv[0], argv);
 			bb_perror_msg_and_die("%s", argv[0]);
 		}
 	}
 
 	for (i = num_args+1; i < argc; i++)
diff -NarU5 busybox-svn-17770.orig/findutils/xargs.c busybox-svn-17770/findutils/xargs.c
--- busybox-svn-17770.orig/findutils/xargs.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/findutils/xargs.c	2007-02-04 16:30:04.000000000 -0500
@@ -58,11 +58,11 @@
 	if (p < 0)
 		bb_perror_msg_and_die("vfork");
 
 	if (p == 0) {
 		/* vfork -- child */
-		execvp(args[0], args);
+		BB_EXECVP(args[0], args);
 		exec_errno = errno;     /* set error to shared stack */
 		_exit(1);
 	}
 
 	/* vfork -- parent */
diff -NarU5 busybox-svn-17770.orig/loginutils/adduser.c busybox-svn-17770/loginutils/adduser.c
--- busybox-svn-17770.orig/loginutils/adduser.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/loginutils/adduser.c	2007-02-04 16:30:04.000000000 -0500
@@ -78,11 +78,11 @@
 static void passwd_wrapper(const char *login) ATTRIBUTE_NORETURN;
 
 static void passwd_wrapper(const char *login)
 {
 	static const char prog[] = "passwd";
-	execlp(prog, prog, login, NULL);
+	BB_EXECLP(prog, prog, login, NULL);
 	bb_error_msg_and_die("failed to execute '%s', you must set the password for '%s' manually", prog, login);
 }
 
 /* putpwent(3) remix */
 static int adduser(struct passwd *p, unsigned long flags)
diff -NarU5 busybox-svn-17770.orig/loginutils/login.c busybox-svn-17770/loginutils/login.c
--- busybox-svn-17770.orig/loginutils/login.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/loginutils/login.c	2007-02-04 16:30:04.000000000 -0500
@@ -355,11 +355,11 @@
 				setenv("LOGIN_TTY", full_tty, 1);
 				setenv("LOGIN_USER", pw->pw_name, 1);
 				setenv("LOGIN_UID", utoa(pw->pw_uid), 1);
 				setenv("LOGIN_GID", utoa(pw->pw_gid), 1);
 				setenv("LOGIN_SHELL", pw->pw_shell, 1);
-				execvp(script, t_argv);
+				BB_EXECVP(script, t_argv);
 				exit(1);
 			default: /* parent */
 				wait(NULL);
 			}
 		}
diff -NarU5 busybox-svn-17770.orig/miscutils/devfsd.c busybox-svn-17770/miscutils/devfsd.c
--- busybox-svn-17770.orig/miscutils/devfsd.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/devfsd.c	2007-02-04 16:30:04.000000000 -0500
@@ -376,11 +376,11 @@
 		exit (EXIT_SUCCESS);
 	}
 	 /* Child : if arg0 != NULL do execvp */
 	if(arg0 != NULL )
 	{
-		execvp (arg0, arg);
+		BB_EXECVP(arg0, arg);
 		msg_logger_and_die(LOG_ERR, "execvp");
 	}
 }
 
 static void safe_memcpy( char *dest, const char *src, int len)
diff -NarU5 busybox-svn-17770.orig/miscutils/setsid.c busybox-svn-17770/miscutils/setsid.c
--- busybox-svn-17770.orig/miscutils/setsid.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/setsid.c	2007-02-04 16:30:04.000000000 -0500
@@ -34,9 +34,9 @@
 	}
 	/* child */
 
 	setsid();  /* no error possible */
 
-	execvp(argv[1], argv + 1);
+	BB_EXECVP(argv[1], argv + 1);
 
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17770.orig/miscutils/taskset.c busybox-svn-17770/miscutils/taskset.c
--- busybox-svn-17770.orig/miscutils/taskset.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/taskset.c	2007-02-04 16:30:04.000000000 -0500
@@ -89,11 +89,11 @@
 		state += 8;
 		++argv;
 		goto print_aff;
 	}
 	++argv;
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("%s", *argv);
 }
 #undef OPT_p
 #undef TASKSET_PRINTF_MASK
 #undef from_cpuset
diff -NarU5 busybox-svn-17770.orig/miscutils/time.c busybox-svn-17770/miscutils/time.c
--- busybox-svn-17770.orig/miscutils/time.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/time.c	2007-02-04 16:30:04.000000000 -0500
@@ -408,11 +408,11 @@
 	if (pid < 0)
 		bb_error_msg_and_die("cannot fork");
 	else if (pid == 0) {	/* If child.  */
 		/* Don't cast execvp arguments; that causes errors on some systems,
 		   versus merely warnings if the cast is left off.  */
-		execvp(cmd[0], cmd);
+		BB_EXECVP(cmd[0], cmd);
 		bb_error_msg("cannot run %s", cmd[0]);
 		_exit(errno == ENOENT ? 127 : 126);
 	}
 
 	/* Have signals kill the child but not self (if possible).  */
diff -NarU5 busybox-svn-17770.orig/networking/ifupdown.c busybox-svn-17770/networking/ifupdown.c
--- busybox-svn-17770.orig/networking/ifupdown.c	2007-02-04 16:25:44.000000000 -0500
+++ busybox-svn-17770/networking/ifupdown.c	2007-02-04 16:30:04.000000000 -0500
@@ -1002,11 +1002,11 @@
 		dup2(outfd[1], 1);
 		close(infd[0]);
 		close(infd[1]);
 		close(outfd[0]);
 		close(outfd[1]);
-		execvp(command, argv);
+		BB_EXECVP(command, argv);
 		exit(127);
 	default:			/* parent */
 		*in = fdopen(infd[1], "w");
 		*out = fdopen(outfd[0], "r");
 		close(infd[0]);
diff -NarU5 busybox-svn-17770.orig/networking/nc.c busybox-svn-17770/networking/nc.c
--- busybox-svn-17770.orig/networking/nc.c	2007-02-04 16:25:44.000000000 -0500
+++ busybox-svn-17770/networking/nc.c	2007-02-04 16:30:04.000000000 -0500
@@ -147,11 +147,11 @@
 			dup2(cfd, 0);
 			close(cfd);
 		}
 		dup2(0, 1);
 		dup2(0, 2);
-		USE_NC_EXTRA(execvp(execparam[0], execparam);)
+		USE_NC_EXTRA(BB_EXECVP(execparam[0], execparam);)
 		/* Don't print stuff or it will go over the wire.... */
 		_exit(127);
 	}
 
 	// Select loop copying stdin to cfd, and cfd to stdout.
diff -NarU5 busybox-svn-17770.orig/runit/chpst.c busybox-svn-17770/runit/chpst.c
--- busybox-svn-17770.orig/runit/chpst.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/runit/chpst.c	2007-02-04 16:30:04.000000000 -0500
@@ -308,11 +308,11 @@
 	if (env_user) euidgid(env_user);
 	if (set_user) suidgid(set_user);
 	if (OPT_nostdin) close(0);
 	if (OPT_nostdout) close(1);
 	if (OPT_nostderr) close(2);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void setuidgid(int argc, char **argv)
 {
@@ -320,11 +320,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	suidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envuidgid(int argc, char **argv)
 {
@@ -332,11 +332,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	euidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envdir(int argc, char **argv)
 {
@@ -344,11 +344,11 @@
 
 	dir = *++argv;
 	if (!dir) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	edir(dir);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void softlimit(int argc, char **argv)
 {
@@ -367,8 +367,8 @@
 	if (option_mask32 & 0x200) limits = xatoul(s); // -s
 	if (option_mask32 & 0x400) limitt = xatoul(t); // -t
 	argv += optind;
 	if (!argv[0]) bb_show_usage();
 	slimit();
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
diff -NarU5 busybox-svn-17770.orig/runit/runsvdir.c busybox-svn-17770/runit/runsvdir.c
--- busybox-svn-17770.orig/runit/runsvdir.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/runit/runsvdir.c	2007-02-04 16:30:04.000000000 -0500
@@ -71,11 +71,11 @@
 		prog[1] = (char*)name;
 		prog[2] = NULL;
 		sig_uncatch(SIGHUP);
 		sig_uncatch(SIGTERM);
 		if (pgrp) setsid();
-		execvp(prog[0], prog);
+		BB_EXECVP(prog[0], prog);
 		//pathexec_run(*prog, prog, (char* const*)environ);
 		fatal2_cannot("start runsv ", name);
 	}
 	sv[no].pid = pid;
 }
diff -NarU5 busybox-svn-17770.orig/util-linux/setarch.c busybox-svn-17770/util-linux/setarch.c
--- busybox-svn-17770.orig/util-linux/setarch.c	2007-02-04 16:25:54.000000000 -0500
+++ busybox-svn-17770/util-linux/setarch.c	2007-02-04 16:30:04.000000000 -0500
@@ -44,10 +44,10 @@
 
 	/* Try to set personality */
 	if (personality(pers) >= 0) {
 
 		/* Try to execute the program */
-		execvp(argv[0], argv);
+		BB_EXECVP(argv[0], argv);
 	}
 
 	bb_perror_msg_and_die("%s", argv[0]);
 }

From nangel at nothome.org  Sun Feb  4 17:00:22 2007
From: nangel at nothome.org (Nathan Angelacos)
Date: Mon, 05 Feb 2007 01:00:22 +0000
Subject: httpd and form-based upload
In-Reply-To: <45C61B6E.4010705@bfs.de>
References: <45C56E49.9030907@Kriegisch.name> <45C5EE92.80307@nothome.org>
	<45C61B6E.4010705@bfs.de>
Message-ID: <45C681A6.1090409@nothome.org>

walter harms wrote:
> 
> hi nathan,
> i could not find any security stuff (like preventing an rm -r /).
> did you try check it out ?
> 
> maybe this is something that should go to the webpage.
> 
> re,
>  wh
> 
Hi walter,

I'm not sure I understand your question.

haserl does the parsing of http GET/POST and mime-encoded http requests.
 That's what Alexander was asking about.  Its is a tool, like busybox or
netcat is a tool.

If someone really wants to make a web page that does "rm -rf /" - I
guess its a self-limiting problem. ;-)



From Alexander at Kriegisch.name  Sun Feb  4 17:33:04 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Mon, 05 Feb 2007 02:33:04 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C681A6.1090409@nothome.org>
References: <45C56E49.9030907@Kriegisch.name>
	<45C5EE92.80307@nothome.org>	<45C61B6E.4010705@bfs.de>
	<45C681A6.1090409@nothome.org>
Message-ID: <45C68950.20007@Kriegisch.name>

@Walter: I agree with Nathan. Besides, in my special case the router's
config web interface is not accessible from "outside" anyway. Haserl is
a tool facilitating what I want.

@Nathan: Maybe Walter speaks of code injection. Anyway, Haserl's man
page even mentions an example showing how to filter the content of HTML
form fields. That should be a starter for those who need or want to
provide their web pages with more security.

For me it works brilliantly, thank you. I guess Haserl will make its way
into our standard firmware mod for the AVM Fritz!Box router series.

Regards
--
Alexander Kriegisch



Nathan Angelacos wrote:
> walter harms wrote:
>> hi nathan,
>> i could not find any security stuff (like preventing an rm -r /).
>> did you try check it out ?
>
> Hi walter,
> 
> I'm not sure I understand your question.
> 
> haserl does the parsing of http GET/POST and mime-encoded http
> requests. That's what Alexander was asking about. Its is a tool, like
> busybox or netcat is a tool.
> 
> If someone really wants to make a web page that does "rm -rf /" - I 
> guess its a self-limiting problem. ;-)>


From farmatito at tiscali.it  Sun Feb  4 22:20:54 2007
From: farmatito at tiscali.it (Tito)
Date: Mon, 5 Feb 2007 07:20:54 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204232355.GB16952@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
Message-ID: <200702050720.54286.farmatito@tiscali.it>

On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> +???????BB_EXECVP(*argv, argv);
> ????????bb_perror_msg_and_die("cannot execute %s", *argv);

Hi,
shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
be moved inside  BB_EXECVP(*argv, argv); ?
This would probably save some space.

Ciao,
Tito 

From rep.dot.nop at gmail.com  Mon Feb  5 00:49:00 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Mon, 5 Feb 2007 09:49:00 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702050720.54286.farmatito@tiscali.it>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
	<200702050720.54286.farmatito@tiscali.it>
Message-ID: <20070205084900.GB5399@aon.at>

On Mon, Feb 05, 2007 at 07:20:54AM +0100, Tito wrote:
>On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
>> +???????BB_EXECVP(*argv, argv);
>> ????????bb_perror_msg_and_die("cannot execute %s", *argv);
>
>Hi,
>shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
>be moved inside  BB_EXECVP(*argv, argv); ?
>This would probably save some space.

seconded :)

Also, i'd add a bb_msg_exec_failed
and fixup svngrep -ri "exec.*%s" *  to use that msg instead of growing
a dozend of separate messages for this very same error, but maybe that's
just me :P

From rupesh_gujare at rediffmail.com  Mon Feb  5 01:21:13 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 5 Feb 2007 09:21:13 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070205092113.603.qmail@webmail8.rediffmail.com>

  
Hello all,
 I am a newbie to busybox.. Dont know whether it is right place to ask..
  I am building embedded linux.. and using initrd image to boot linux at the start. I am booting from USB pen drive.
  But problem is after booting from pen drive, i am unable to remove initrd image. and mount my real filesystem.
  My initrd image includes busybox links and rcS script. I am using busybox 1.3.1

My /etc/init.d/rcS file is as follow:-
 
#!/bin/sh
# Remount the root filesystem in read-write (requires /etc/fstab)
mount -n -o remount,rw /
# Mount /proc filesystem
mount /proc

/etc/inittab:----

::sysinit:/etc/init.d/rcS
::restart:/sbin/init
::shutdown:/bin/umount -a -r
::respawn:/bin/sh 

fstab:----
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/sda1 / ext2 defaults,errors=remount-ro 0 1

After booting system still i gets initrd image as a root file system.
Can anyone tell me what i am doing wrong?
 Thanks in advance 
 Rupesh..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070205/e3a9336e/attachment.html 

From vapier at gentoo.org  Mon Feb  5 01:38:54 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 5 Feb 2007 04:38:54 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702021458.59394.rob@landley.net>
References: <200701282116.46840.vapier@gentoo.org>
	<200702010312.34740.vapier@gentoo.org>
	<200702021458.59394.rob@landley.net>
Message-ID: <200702050438.55998.vapier@gentoo.org>

On Friday 02 February 2007, Rob Landley wrote:
> On Thursday 01 February 2007 3:12 am, Mike Frysinger wrote:
> > busybox is failing because it's
> > trying to generate depmod and build modules
>
> Because your "larger build system" (which we didn't write) is calling make
> modules on busybox?

incorrect ... the busybox system changes the default all dependencies based 
upon the environment it is run in

so if the host env has the same defines that the kernel uses, then busybox 
will incorrectly try and generate modules (since it is really just using the 
kernel build)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070205/532c53e6/attachment.pgp 

From vapier at gentoo.org  Mon Feb  5 01:41:55 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 5 Feb 2007 04:41:55 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702020014.21335.vda.linux@googlemail.com>
References: <200701282116.46840.vapier@gentoo.org>
	<200702010312.34740.vapier@gentoo.org>
	<200702020014.21335.vda.linux@googlemail.com>
Message-ID: <200702050441.56413.vapier@gentoo.org>

:t???
k-5??????M;
???YZ????
?????'??+"????\?z?b?
k??^??br?^??????z?
?????&???j?.??+???:??????????
~)^???z?&???z?h???zg????z??????????-?????^rH???Z???)??X?z?"}???E c
B?K??u??8?H??P?D???8D?951?J?Z??v?????~??????^n??v??????.??!??????'%y????-?Z?+????Z????!j?!??]m??u?^v'???h????h???v?(??!?)??{a?x,????'??????jYr?jk???zw?j??r?^????'h??'?!j?????y???)???^????????Z??'?{^?????!?????,r??m?Mjg????j)ZnW??????bq?b????"?v?????7??????z?'???j)ZnW??Xm???n?2n?gz????l?????1??mi?fz{l?m4?M???8sM?y??????g???)

From somlo at cmu.edu  Mon Feb  5 05:13:48 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Mon, 5 Feb 2007 08:13:48 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070205084900.GB5399@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
	<200702050720.54286.farmatito@tiscali.it>
	<20070205084900.GB5399@aon.at>
Message-ID: <20070205131348.GA22190@hedwig.net.cmu.edu>

On Mon, Feb 05, 2007 at 09:49:00AM +0100, Bernhard Fischer wrote:
> On Mon, Feb 05, 2007 at 07:20:54AM +0100, Tito wrote:
> >On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> >> +???????BB_EXECVP(*argv, argv);
> >> ????????bb_perror_msg_and_die("cannot execute %s", *argv);
> >
> >Hi,
> >shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
> >be moved inside  BB_EXECVP(*argv, argv); ?
> >This would probably save some space.
> 
> seconded :)

I too noticed that a lot of the code surrounding execvp/BB_EXECVP
looks similar in a lot of the places it happens. However, BB_EXECVP
was meant as strictly a drop-in replacement for the execvp function
call. Maybe what we want to do is find a way to replace a lot of the
boilerplate code with a call to spawn() (in libbb/xfuncs.c) instead...

Cheers,
Gabriel

> 
> Also, i'd add a bb_msg_exec_failed
> and fixup svngrep -ri "exec.*%s" *  to use that msg instead of growing
> a dozend of separate messages for this very same error, but maybe that's
> just me :P
> 

From floydpink at gmail.com  Mon Feb  5 05:40:15 2007
From: floydpink at gmail.com (Jason Schoon)
Date: Mon, 5 Feb 2007 07:40:15 -0600
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070205092113.603.qmail@webmail8.rediffmail.com>
References: <20070205092113.603.qmail@webmail8.rediffmail.com>
Message-ID: <78a54e1b0702050540t13dee290jc0e9b542b27843c9@mail.gmail.com>

On 5 Feb 2007 09:21:13 -0000, Rupesh Gujare <rupesh_gujare at rediffmail.com>
wrote:
>
>
> After booting system still i gets initrd image as a root file system.
> Can anyone tell me what i am doing wrong?
> Thanks in advance
> Rupesh..
>

man pivot_root

If you are on a 2.6 kernel though, you should do some google searching on
initramfs and switch_root (provided by Busybox).  There is a good starting
point regarding initramfs in the Linux kernel Documentation directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070205/9c1775c5/attachment.htm 

From rupesh_gujare at rediffmail.com  Mon Feb  5 06:11:36 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 5 Feb 2007 14:11:36 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070205141136.5944.qmail@webmail81.rediffmail.com>

  
I had tried with pivot_root:
 I entered 
/bin/sh  in /etc/rcS
and after mounting /proc tried to do pivot_root
 it gives me 
pivot_root:pivot_root: Device or resource busy.
 any clue why it is like this?

 Regarding initramfs.. i am not aware of it by too much.. i will try to find out more about it.. Is it more easier than ramdisk image?

 Your suggestions are greatly appreciated
 Thanks in advance 
Rupesh
 


On Mon, 05 Feb 2007 Jason Schoon wrote :
>On 5 Feb 2007 09:21:13 -0000, Rupesh Gujare <rupesh_gujare at rediffmail.com>
>wrote:
>>
>>
>>After booting system still i gets initrd image as a root file system.
>>Can anyone tell me what i am doing wrong?
>>Thanks in advance
>>Rupesh..
>>
>
>man pivot_root
>
>If you are on a 2.6 kernel though, you should do some google searching on
>initramfs and switch_root (provided by Busybox).  There is a good starting
>point regarding initramfs in the Linux kernel Documentation directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070205/5d3d2ba7/attachment.html 

From rupesh_gujare at rediffmail.com  Mon Feb  5 06:11:53 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 5 Feb 2007 14:11:53 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070205141153.21424.qmail@webmail100.rediffmail.com>

  
I had tried with pivot_root:
 I entered 
/bin/sh  in /etc/rcS
and after mounting /proc tried to do pivot_root
 it gives me 
pivot_root:pivot_root: Device or resource busy.
 any clue why it is like this?

 Regarding initramfs.. i am not aware of it by too much.. i will try to find out more about it.. Is it more easier than ramdisk image?

 Your suggestions are greatly appreciated
 Thanks in advance 
Rupesh
 


On Mon, 05 Feb 2007 Jason Schoon wrote :
>On 5 Feb 2007 09:21:13 -0000, Rupesh Gujare <rupesh_gujare at rediffmail.com>
>wrote:
>>
>>
>>After booting system still i gets initrd image as a root file system.
>>Can anyone tell me what i am doing wrong?
>>Thanks in advance
>>Rupesh..
>>
>
>man pivot_root
>
>If you are on a 2.6 kernel though, you should do some google searching on
>initramfs and switch_root (provided by Busybox).  There is a good starting
>point regarding initramfs in the Linux kernel Documentation directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070205/f15223e1/attachment-0001.htm 

From rob at landley.net  Mon Feb  5 08:10:59 2007
From: rob at landley.net (Rob Landley)
Date: Mon, 5 Feb 2007 11:10:59 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702050438.55998.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200702021458.59394.rob@landley.net>
	<200702050438.55998.vapier@gentoo.org>
Message-ID: <200702051111.00383.rob@landley.net>

On Monday 05 February 2007 4:38 am, Mike Frysinger wrote:
> On Friday 02 February 2007, Rob Landley wrote:
> > On Thursday 01 February 2007 3:12 am, Mike Frysinger wrote:
> > > busybox is failing because it's
> > > trying to generate depmod and build modules
> >
> > Because your "larger build system" (which we didn't write) is calling make
> > modules on busybox?
> 
> incorrect ... the busybox system changes the default all dependencies based 
> upon the environment it is run in

What's the "default all dependencies"?  You mean the default behavior of "make 
all"?  (I don't think you mean "make depend" because that's not there 
anymore...)

> so if the host env has the same defines that the kernel uses, then busybox  
> will incorrectly try and generate modules (since it is really just using the 
> kernel build)

Ok, once again guessing at your meaning, I take it this isn't "#defines" but 
environment variables you're talking about?

Changing behavior based on random environment variables is bad, but the Linux 
From Scratch project goes out of its way to tell you to blank certain 
environment variables because they've been known to screw things up if you 
don't.  That's a known problem and a "don't do that".

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From somlo at cmu.edu  Mon Feb  5 08:40:26 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Mon, 5 Feb 2007 11:40:26 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041707.33774.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
	<200702041707.33774.vda.linux@googlemail.com>
Message-ID: <20070205164026.GB23779@hedwig.net.cmu.edu>


Denis, Bernhard,

Here's a version that provides both a bb_execvp() and a bb_execlp()
function. The latter is a simplified version of the glibc one, but
returns E2BIG when more than 16 arguments are passed into it, and does
have the code that would grow the argv array dynamically while reading
its varargs. That should not be a problem, as all execlp calls I've
seen so far in busybox have maybe four arguments max...

Cheers,
Gabriel



diff -NarU5 busybox-svn-17770.orig/include/libbb.h busybox-svn-17770/include/libbb.h
--- busybox-svn-17770.orig/include/libbb.h	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/include/libbb.h	2007-02-05 11:33:12.000000000 -0500
@@ -560,14 +560,14 @@
 int execable_file(const char *name);
 char *find_execable(const char *filename);
 int exists_execable(const char *filename);
 
 #ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
-#define BB_EXECVP(prog,cmd) \
-	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
-#define BB_EXECLP(prog,cmd,...) \
-	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
+int bb_execvp(const char *file, char *const argv[]);
+int bb_execlp(const char *file, const char *arg, ...);
+#define BB_EXECVP(prog,cmd) bb_execvp(prog,cmd)
+#define BB_EXECLP(prog,cmd,...) bb_execlp(prog,cmd, __VA_ARGS__) 
 #else
 #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
 #define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
 #endif
 
diff -NarU5 busybox-svn-17770.orig/libbb/execable.c busybox-svn-17770/libbb/execable.c
--- busybox-svn-17770.orig/libbb/execable.c	2007-02-04 16:25:51.000000000 -0500
+++ busybox-svn-17770/libbb/execable.c	2007-02-05 11:30:55.000000000 -0500
@@ -57,5 +57,42 @@
 		free(ret);
 		return 1;
 	}
 	return 0;
 }
+
+#ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
+/* just like the real execvp, but try to launch an applet named 'file' first
+ */
+int bb_execvp(const char *file, char *const argv[])
+{
+	return execvp(find_applet_by_name(file) ? CONFIG_BUSYBOX_EXEC_PATH : file,
+					argv);
+}
+
+/* just like the real execlp, but try to launch an applet named 'file' first
+ * (since there's no good way to handle varargs here, we unroll execlp and
+ *  replace the execvp call with a bb_execvp call :)
+ */
+int bb_execlp (const char *file, const char *arg, ...)
+{
+	#define ARGV_MAX 16
+	const char *argv[ARGV_MAX];
+	unsigned int i = 0;
+	va_list args;
+
+	argv[0] = arg;
+
+	va_start(args, arg);
+	while (argv[i++] != NULL && i < ARGV_MAX) {
+		argv[i] = va_arg(args, const char *);
+	}
+	va_end(args);
+
+	if (i >= ARGV_MAX) {
+		errno = E2BIG;
+		return -1;
+	}
+
+	return bb_execvp(file, (char *const *)argv);
+}
+#endif

From sortiz at olivetti-engineering.com  Mon Feb  5 08:33:06 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Mon, 05 Feb 2007 17:33:06 +0100
Subject: [PATCH] udhcp: infinite retries
Message-ID: <45C75C42.8040302@olivetti-engineering.com>

Hi All,

It may be useful (at least it is for us) to keep on sending DHCP request 
and renewals for ever until we actually get an answer. For that purpose 
udhcpc -t 0 could do the job.
Attached you will find the corresponding patch, please let me know if 
you'd consider it for inclusion.

Cheers,
Samuel.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_udhcpc_retries
Url: http://busybox.net/lists/busybox/attachments/20070205/6dc82d9e/attachment.asc 

From akennedy at techmoninc.com  Mon Feb  5 10:25:49 2007
From: akennedy at techmoninc.com (Andy Kennedy)
Date: Mon, 05 Feb 2007 12:25:49 -0600
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <20070201005758.GA19486@nsk.no-ip.org>
References: <45C0EA70.4080508@techmoninc.com> <45C0EBB2.1090604@seiner.com>
	<45C0F180.4000904@techmoninc.com> <45C11D80.20906@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
Message-ID: <45C776AD.5090602@techmoninc.com>

Luciano Miguel Ferreira Rocha wrote:
> On Wed, Jan 31, 2007 at 04:51:44PM -0600, Andy Kennedy wrote:
>   
>> Anyone have ANY idea about this???  Anyone else have a buildroot/busybox 
>> setup that uses a serial console?
>>     
> 3. boot scripts set serial speed:
> for d in /dev/ttyS* /dev/ttyAM* /dev/ttyUSB*; do
>     [ -e "$d" ] && stty -F $d ospeed 57600
> done
Attempted this.  Didn't help.  To restate my problem (in case some kind 
developer decides to help me):

When I have the kernel command line parameter "console=ttyS0,115200n8" I 
get nice neat output on the serial line up until the init runs.  As soon 
as init runs, I get missing chars.  So, I replace the BusyBox init with 
minit, compiled from source and using the uCLibC gcc that I let 
buildroot make for me.  Same problem.  For some reason, when the system 
initializes -- after the kernel has reported all of its output, my 
serial console goes splat.  When I initialize the console using BusyBox 
(/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is {'i', 'g', 
's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  One of these 
letters will appear each time I send enter.

I have tried everything I can think of.  There is no script setting any 
of the line speeds -- in fact, I have even attempted to remove the 
scripts and still get the same thing.  Removing the 
console=ttyS0,115200n8 (or attempting any variant of it) has no affect, 
except without the consolething I haven't attempted yet is to replace the getty with an equivalent 
to see if that makes a difference.  I have also tried 9600, 38400, 
19200, with E8, O8, 2 stop bits, and 1 stop bit in just about every 
combination, but I still cannot get a serial console.

Can anyone offer a suggestion as to how I might fix this -- or some 
other place to start?

Thanks in advance for any help you can offer,
Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: akennedy.vcf
Type: text/x-vcard
Size: 256 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070205/43f16d7e/attachment.vcf 

From vda.linux at googlemail.com  Mon Feb  5 16:48:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 01:48:45 +0100
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070205141136.5944.qmail@webmail81.rediffmail.com>
References: <20070205141136.5944.qmail@webmail81.rediffmail.com>
Message-ID: <200702060148.45448.vda.linux@googlemail.com>

On Monday 05 February 2007 15:11, Rupesh Gujare wrote:
> 
> I had tried with pivot_root:
>  I entered 
> /bin/sh  in /etc/rcS
> and after mounting /proc tried to do pivot_root
>  it gives me 
> pivot_root:pivot_root: Device or resource busy.
>  any clue why it is like this?

Oh, wonderful problem report. No solid info on what exactly
you did (params to pivot_root etc...).

Anyway, a part of my homemade initrd whcu does pivot_root
(bu this time "new" rootfs is mounted on /new_root):


# Clean up
#umount /sys
umount /proc

echo "# Chrooting into root fs"
# we expect that /dev/console and /dev/null exist in /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc || {
    echo "pivot_root failed. Fatal, cannot continue booting"
    while true; do sleep 32000; done
}

exec \
chroot . \
sh -c '\
umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
exec /bin/env - /sbin/init
'

echo "chroot . sh failed. Fatal, cannot continue booting"
while true; do sleep 32000; done


Hope this helps
--
vda

From vda.linux at googlemail.com  Mon Feb  5 16:58:21 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 01:58:21 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070205131348.GA22190@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070205084900.GB5399@aon.at>
	<20070205131348.GA22190@hedwig.net.cmu.edu>
Message-ID: <200702060158.21461.vda.linux@googlemail.com>

On Monday 05 February 2007 14:13, Gabriel L. Somlo wrote:
> On Mon, Feb 05, 2007 at 09:49:00AM +0100, Bernhard Fischer wrote:
> > On Mon, Feb 05, 2007 at 07:20:54AM +0100, Tito wrote:
> > >On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> > >> +???????BB_EXECVP(*argv, argv);
> > >> ????????bb_perror_msg_and_die("cannot execute %s", *argv);
> > >
> > >Hi,
> > >shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
> > >be moved inside  BB_EXECVP(*argv, argv); ?
> > >This would probably save some space.
> > 
> > seconded :)
> 
> I too noticed that a lot of the code surrounding execvp/BB_EXECVP
> looks similar in a lot of the places it happens. However, BB_EXECVP
> was meant as strictly a drop-in replacement for the execvp function
> call.

I prefer it to stay that way. Dying variety should be called
xexecvp() according to our usual conventions.
--
vda

From vda.linux at googlemail.com  Mon Feb  5 17:20:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 02:20:11 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C75C42.8040302@olivetti-engineering.com>
References: <45C75C42.8040302@olivetti-engineering.com>
Message-ID: <200702060220.11391.vda.linux@googlemail.com>

On Monday 05 February 2007 17:33, Samuel Ortiz wrote:
> Hi All,
> 
> It may be useful (at least it is for us) to keep on sending DHCP request 
> and renewals for ever until we actually get an answer. For that purpose 
> udhcpc -t 0 could do the job.

I guess udhcpc -t 999999999 will be the same in practice.

> Attached you will find the corresponding patch, please let me know if 
> you'd consider it for inclusion.

Well, and if for some obscure reason someone wants zero retries?
--
vda

From vda.linux at googlemail.com  Mon Feb  5 17:40:35 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 02:40:35 +0100
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45C776AD.5090602@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com>
Message-ID: <200702060240.35806.vda.linux@googlemail.com>

On Monday 05 February 2007 19:25, Andy Kennedy wrote:
> Luciano Miguel Ferreira Rocha wrote:
> > On Wed, Jan 31, 2007 at 04:51:44PM -0600, Andy Kennedy wrote:
> >   
> >> Anyone have ANY idea about this???  Anyone else have a buildroot/busybox 
> >> setup that uses a serial console?
> >>     
> > 3. boot scripts set serial speed:
> > for d in /dev/ttyS* /dev/ttyAM* /dev/ttyUSB*; do
> >     [ -e "$d" ] && stty -F $d ospeed 57600
> > done
>
> Attempted this.  Didn't help.  To restate my problem (in case some kind 
> developer decides to help me):
> 
> When I have the kernel command line parameter "console=ttyS0,115200n8" I 
> get nice neat output on the serial line up until the init runs.  As soon 
> as init runs, I get missing chars.  So, I replace the BusyBox init with 
> minit, compiled from source and using the uCLibC gcc that I let 
> buildroot make for me.  Same problem.  For some reason, when the system 
> initializes -- after the kernel has reported all of its output, my 
> serial console goes splat.  When I initialize the console using BusyBox 
> (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is {'i', 'g', 
> 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  One of these 
> letters will appear each time I send enter.
> 
> I have tried everything I can think of.  There is no script setting any 
> of the line speeds -- in fact, I have even attempted to remove the 
> scripts and still get the same thing.  Removing the 
> console=ttyS0,115200n8 (or attempting any variant of it) has no affect, 
> except without the console= I get no good output on the line.  The only 
> thing I haven't attempted yet is to replace the getty with an equivalent 
> to see if that makes a difference.  I have also tried 9600, 38400, 
> 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about every 
> combination, but I still cannot get a serial console.
> 
> Can anyone offer a suggestion as to how I might fix this -- or some 
> other place to start?

Does booting with init=/bin/sh work? If yes, then try to run with
init=/a/shell/script, where script is:

#!/bin/sh
# ...stty, setserial, whatever else you want to experiment with...
getty -L ttyS0 115200
echo "Getty exited..."
# So that we can continue experimenting...
sh

or even

#!/bin/sh
# This is the "debug shell"
sh </dev/tty12 >/dev/tty12 2>&1 &
exec /sbin/init

then debug stuff using that shell on vt #12 (strace, kernel logs, etc)

Also, using console=ttyS0 is not very commot, so you may want to tap
much wider userbase by posting to lkml.
--
vda

From larry.brigman at gmail.com  Mon Feb  5 17:40:26 2007
From: larry.brigman at gmail.com (Larry Brigman)
Date: Mon, 5 Feb 2007 17:40:26 -0800
Subject: troubleshooting mklibs
Message-ID: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>

This might be a little off topic but it is a problem I am having with busybox
and glibc.
I know, too many problems linking to glibc but right now I have to fix
the problem.

The problem,  running mklibs to produce a small sub-set of libraries that are
needed on the target system, doesn't always include all the functions that
are needed.

Other applications change and the mix of functions that are needed changes and
the ones that are necessary for busybox to run are missed.

The other day it missed __r_debug from GLIBC_2.0.  Today it is missing
crypt in GLIBC_2.0 for busybox login.

My question:  How do I go about troubleshooting this problem?
If someone could hit me with a clue stick it would be much appreciated.

From vda.linux at googlemail.com  Mon Feb  5 17:21:15 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 02:21:15 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204232355.GB16952@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
Message-ID: <200702060221.15515.vda.linux@googlemail.com>

On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> ... And here's the rest of it again -- converting exec*p to BB_EXEC*P.

Applied both (sans bb_execlp), Thanks!
--
vda

From vda.linux at googlemail.com  Mon Feb  5 18:36:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 03:36:20 +0100
Subject: troubleshooting mklibs
In-Reply-To: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>
References: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>
Message-ID: <200702060336.20899.vda.linux@googlemail.com>

On Tuesday 06 February 2007 02:40, Larry Brigman wrote:
> This might be a little off topic but it is a problem I am having with busybox
> and glibc.
> I know, too many problems linking to glibc but right now I have to fix
> the problem.
> 
> The problem,  running mklibs to produce a small sub-set of libraries that are
> needed on the target system, doesn't always include all the functions that
> are needed.

What is mklibs?
--
vda

From ddaney at avtrex.com  Mon Feb  5 20:46:32 2007
From: ddaney at avtrex.com (David Daney)
Date: Mon, 05 Feb 2007 20:46:32 -0800
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45C776AD.5090602@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com>
	<45C0EBB2.1090604@seiner.com>	<45C0F180.4000904@techmoninc.com>
	<45C11D80.20906@techmoninc.com>	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com>
Message-ID: <45C80828.6050507@avtrex.com>

Andy Kennedy wrote:
> Luciano Miguel Ferreira Rocha wrote:
>> On Wed, Jan 31, 2007 at 04:51:44PM -0600, Andy Kennedy wrote:
>>  
>>> Anyone have ANY idea about this???  Anyone else have a 
>>> buildroot/busybox setup that uses a serial console?
>>>     
>> 3. boot scripts set serial speed:
>> for d in /dev/ttyS* /dev/ttyAM* /dev/ttyUSB*; do
>>     [ -e "$d" ] && stty -F $d ospeed 57600
>> done
> Attempted this.  Didn't help.  To restate my problem (in case some 
> kind developer decides to help me):
>
> When I have the kernel command line parameter "console=ttyS0,115200n8" 
> I get nice neat output on the serial line up

I think I always use "console=ttyS0,115200,n,8,1"

Try it with commas between the all the comm parameters and see what happens.

Setting init=/bin/sh might help track it down also.

> until the init runs.  As soon as init runs, I get missing chars.  So, 
> I replace the BusyBox init with minit, compiled from source and using 
> the uCLibC gcc that I let buildroot make for me.  Same problem.  For 
> some reason, when the system initializes -- after the kernel has 
> reported all of its output, my serial console goes splat.  When I 
> initialize the console using BusyBox (/sbin/getty -L ttyS0 115200 
> vt100) I get "X n", where X is {'i', 'g', 's', 'o', 'l', 'm'}, but I 
> cannot find a pattern in it.  One of these letters will appear each 
> time I send enter.
>
> I have tried everything I can think of.  There is no script setting 
> any of the line speeds -- in fact, I have even attempted to remove the 
> scripts and still get the same thing.  Removing the 
> console=ttyS0,115200n8 (or attempting any variant of it) has no 
> affect, except without the console= I get no good output on the line.  
> The only thing I haven't attempted yet is to replace the getty with an 
> equivalent to see if that makes a difference.  I have also tried 9600, 
> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
> every combination, but I still cannot get a serial console.
>
> Can anyone offer a suggestion as to how I might fix this -- or some 
> other place to start?
>
> Thanks in advance for any help you can offer,
> Andy
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox



From larry.brigman at gmail.com  Mon Feb  5 22:08:34 2007
From: larry.brigman at gmail.com (Larry Brigman)
Date: Mon, 5 Feb 2007 22:08:34 -0800
Subject: troubleshooting mklibs
In-Reply-To: <200702060336.20899.vda.linux@googlemail.com>
References: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>
	<200702060336.20899.vda.linux@googlemail.com>
Message-ID: <ca5165530702052208k2308e7eibac2fce7bc95863c@mail.gmail.com>

On 2/5/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Tuesday 06 February 2007 02:40, Larry Brigman wrote:
> > This might be a little off topic but it is a problem I am having with busybox
> > and glibc.
> > I know, too many problems linking to glibc but right now I have to fix
> > the problem.
> >
> > The problem,  running mklibs to produce a small sub-set of libraries that are
> > needed on the target system, doesn't always include all the functions that
> > are needed.
>
> What is mklibs?

It is a shell or python script that takes a list of executable to make
small(er) optimized
shared libraries using only the info that the libraries and executables provide.
The python version is a debian package, is used in buildroot and other
systems to
make boot floppies.  I have used it before on other projects and know
that it misses
libnss_files and libnss_dns because of the privated internal link
between glibc and
these libraries but I haven't seen this behavior before.

From sortiz at olivetti-engineering.com  Tue Feb  6 01:36:12 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Tue, 06 Feb 2007 10:36:12 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <200702060220.11391.vda.linux@googlemail.com>
References: <45C75C42.8040302@olivetti-engineering.com>
	<200702060220.11391.vda.linux@googlemail.com>
Message-ID: <45C84C0C.5040703@olivetti-engineering.com>

Hi Denis,

Denis Vlasenko wrote:
> On Monday 05 February 2007 17:33, Samuel Ortiz wrote:
>> Hi All,
>>
>> It may be useful (at least it is for us) to keep on sending DHCP request 
>> and renewals for ever until we actually get an answer. For that purpose 
>> udhcpc -t 0 could do the job.
> 
> I guess udhcpc -t 999999999 will be the same in practice.

Almost, but not exactly.
We have machines that can be powered up without being connected to any 
network for weeks. However, we need them to fetch an IP if they ever get 
plugged to some network.


>> Attached you will find the corresponding patch, please let me know if 
>> you'd consider it for inclusion.
> 
> Well, and if for some obscure reason someone wants zero retries?

0 retries would be one try, and that would be -t 1.
With the current code, running udhcpc with -t 0 is quite useless since 
it will not send _any_ DHCP frame since packet_num will never be lower
than client_config.retries. I don't see the point of doing that unless 
you're expecting a DHCP offer or ACK without having sent a discovery or 
request previously.
That's why I assumed -t 0 was semantically available, and proposed to 
use it for infinite retries.

Cheers,
Samuel.

From rep.dot.nop at gmail.com  Tue Feb  6 01:55:54 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Tue, 6 Feb 2007 10:55:54 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C84C0C.5040703@olivetti-engineering.com>
References: <45C75C42.8040302@olivetti-engineering.com>
	<200702060220.11391.vda.linux@googlemail.com>
	<45C84C0C.5040703@olivetti-engineering.com>
Message-ID: <20070206095554.GA17279@aon.at>

On Tue, Feb 06, 2007 at 10:36:12AM +0100, Samuel Ortiz wrote:
>Hi Denis,
>
>Denis Vlasenko wrote:
>> On Monday 05 February 2007 17:33, Samuel Ortiz wrote:
>>> Hi All,
>>>
>>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>> and renewals for ever until we actually get an answer. For that purpose 
>>> udhcpc -t 0 could do the job.
>> 
>> I guess udhcpc -t 999999999 will be the same in practice.
>
>Almost, but not exactly.
>We have machines that can be powered up without being connected to any 
>network for weeks. However, we need them to fetch an IP if they ever get 
>plugged to some network.
>
>
>>> Attached you will find the corresponding patch, please let me know if 
>>> you'd consider it for inclusion.
>> 
>> Well, and if for some obscure reason someone wants zero retries?
>
>0 retries would be one try, and that would be -t 1.
>With the current code, running udhcpc with -t 0 is quite useless since 
>it will not send _any_ DHCP frame since packet_num will never be lower
>than client_config.retries. I don't see the point of doing that unless 
>you're expecting a DHCP offer or ACK without having sent a discovery or 
>request previously.
>That's why I assumed -t 0 was semantically available, and proposed to 
>use it for infinite retries.

I think that the proposal to provide means to infinitely query makes
sense. Can zcip take care of this even now, perhaps?

From rupesh_gujare at rediffmail.com  Tue Feb  6 05:02:16 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 6 Feb 2007 13:02:16 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070206130216.14246.qmail@webmail72.rediffmail.com>

hello all,
 thanks for help..  and sorry for not stating my problem clearly
so finally i was able to change rootfs.. Here is what i did at interactive shell by adding /bin/sh at start in /etc/init.d/rcS:--

 mount -t proc none /proc
 mount -t ext2 /dev/sda1 /tmp
 cd /tmp
 umount /proc
 pivot_root . tmp   #tmp exist on new-root
 mount -t proc none /proc
 exec chroot . /bin/ash <dev/console > dev/console 2>&1
 exec chroot . /sbin/init <dev/console > dev/console 2>&1
 umount /tmp
 
BUT HERE I GET ERROR AS:--
Device or resource busy
 
 Where I am going wrong?
I am compiling busybox with shared library as a dynamically linked.
 Is it problem with /dev/sda1? ie. i am referencing to /dev/sda1 on old   root FS(if it's like that, then how to overcome it?). or with shared libraries on old FS?
 your help is greatly appreciated..
 Thanks in advance..

Rupesh Gujare.




On Tue, 06 Feb 2007 Denis Vlasenko wrote :
>On Monday 05 February 2007 15:11, Rupesh Gujare wrote:
> >
> > I had tried with pivot_root:
> >  I entered
> > /bin/sh  in /etc/rcS
> > and after mounting /proc tried to do pivot_root
> >  it gives me
> > pivot_root:pivot_root: Device or resource busy.
> >  any clue why it is like this?
>
>Oh, wonderful problem report. No solid info on what exactly
>you did (params to pivot_root etc...).
>
>Anyway, a part of my homemade initrd whcu does pivot_root
>(bu this time "new" rootfs is mounted on /new_root):
>
>
># Clean up
>#umount /sys
>umount /proc
>
>echo "# Chrooting into root fs"
># we expect that /dev/console and /dev/null exist in /new_root/dev
>cd /new_root
># making sure we dont keep /dev busy
>exec <dev/console >dev/console 2>&1
># proc/ in new root is used here as a temp mountpoint for old root
>pivot_root . proc || {
>     echo "pivot_root failed. Fatal, cannot continue booting"
>     while true; do sleep 32000; done
>}
>
>exec \
>chroot . \
>sh -c '\
>umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
>exec /bin/env - /sbin/init
>'
>
>echo "chroot . sh failed. Fatal, cannot continue booting"
>while true; do sleep 32000; done
>
>
>Hope this helps
>--
>vda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070206/b2767cc4/attachment.html 

From strange at nsk.no-ip.org  Tue Feb  6 06:07:17 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 6 Feb 2007 14:07:17 +0000
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070206130216.14246.qmail@webmail72.rediffmail.com>
References: <20070206130216.14246.qmail@webmail72.rediffmail.com>
Message-ID: <20070206140717.GA21057@nsk.no-ip.org>

On Tue, Feb 06, 2007 at 01:02:16PM -0000, Rupesh Gujare wrote:
> hello all,
>  thanks for help..  and sorry for not stating my problem clearly
> so finally i was able to change rootfs.. Here is what i did at interactive shell by adding /bin/sh at start in /etc/init.d/rcS:--
> 
>  mount -t proc none /proc
>  mount -t ext2 /dev/sda1 /tmp
>  cd /tmp
>  umount /proc
>  pivot_root . tmp   #tmp exist on new-root
>  mount -t proc none /proc
>  exec chroot . /bin/ash <dev/console > dev/console 2>&1
>  exec chroot . /sbin/init <dev/console > dev/console 2>&1
>  umount /tmp
>  
> BUT HERE I GET ERROR AS:--
> Device or resource busy
>  
>  Where I am going wrong?

That script *has* to be init, not run from init. Try booting with
init=/etc/init.d/rcS and if it works replace /sbin/init with that
script.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070206/a89eee6e/attachment.pgp 

From steven.scholz at imc-berlin.de  Tue Feb  6 05:44:47 2007
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 06 Feb 2007 14:44:47 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C84C0C.5040703@olivetti-engineering.com>
References: <45C75C42.8040302@olivetti-engineering.com>	<200702060220.11391.vda.linux@googlemail.com>
	<45C84C0C.5040703@olivetti-engineering.com>
Message-ID: <45C8864F.1020005@imc-berlin.de>

Samuel,

>>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>> and renewals for ever until we actually get an answer. For that purpose 
>>> udhcpc -t 0 could do the job.
>> I guess udhcpc -t 999999999 will be the same in practice.
> 
> Almost, but not exactly.
> We have machines that can be powered up without being connected to any 
> network for weeks. However, we need them to fetch an IP if they ever get 
> plugged to some network.

Then maybe you want to use something like netplugd ot ifplugd ...

--
Steven



From pgf at brightstareng.com  Tue Feb  6 06:17:44 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Tue, 06 Feb 2007 09:17:44 -0500
Subject: [PATCH] udhcp: infinite retries 
In-Reply-To: steven.scholz's message of Tue, 06 Feb 2007 14:44:47 +0100.
	<45C8864F.1020005@imc-berlin.de> 
Message-ID: <16105.1170771464@brightstareng.com>

 > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
 > >>> and renewals for ever until we actually get an answer. For that purpose 
 > >>> udhcpc -t 0 could do the job.
 > >> I guess udhcpc -t 999999999 will be the same in practice.
 > > 
 > > Almost, but not exactly.
 > > We have machines that can be powered up without being connected to any 
 > > network for weeks. However, we need them to fetch an IP if they ever get 
 > > plugged to some network.
 > 
 > Then maybe you want to use something like netplugd ot ifplugd ...

of course that takes care of the locally connected problem, but
not the "connected to a switch which is itself disconnected"
problem.  but i agree -- if it were me, i'd probably use a
combination of the mechanisms.

dhcp should be using netlink itself, to track interface connectivity.  (i.e.,
needing ifplugd is a bug, in my opinion.)

paul
=---------------------
 paul fox, pgf at brightstareng.com

From sortiz at olivetti-engineering.com  Tue Feb  6 06:54:52 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Tue, 06 Feb 2007 15:54:52 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <16105.1170771464@brightstareng.com>
References: <16105.1170771464@brightstareng.com>
Message-ID: <45C896BC.505@olivetti-engineering.com>

Paul Fox wrote:
>  > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
>  > >>> and renewals for ever until we actually get an answer. For that purpose 
>  > >>> udhcpc -t 0 could do the job.
>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>  > > 
>  > > Almost, but not exactly.
>  > > We have machines that can be powered up without being connected to any 
>  > > network for weeks. However, we need them to fetch an IP if they ever get 
>  > > plugged to some network.
>  > 
>  > Then maybe you want to use something like netplugd ot ifplugd ...
> 
> of course that takes care of the locally connected problem, but
> not the "connected to a switch which is itself disconnected"
> problem.  but i agree -- if it were me, i'd probably use a
> combination of the mechanisms.
well, with the infinite retries option, we can live without netplugd.
However, I agree that it would be nicer to have netplugd firing up 
udhcpc with infinite retries whenever we actually are plugged/associated 
(we do have machines with both ethernet and 802.11 interfaces).

Cheers,
Samuel.


> dhcp should be using netlink itself, to track interface connectivity.  (i.e.,
> needing ifplugd is a bug, in my opinion.)
> 
> paul
> =---------------------
>  paul fox, pgf at brightstareng.com
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 


From natanael.copa at gmail.com  Tue Feb  6 07:50:33 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Tue, 06 Feb 2007 16:50:33 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <200702041810.57851.vda.linux@googlemail.com>
References: <1170428490.28276.35.camel@localhost>
	<200702022243.56100.vda.linux@googlemail.com>
	<200702041810.57851.vda.linux@googlemail.com>
Message-ID: <1170777033.6604.13.camel@localhost>

vda,

Sorry for the delayed reply. I was sick since friday.

Thank for you comments. They were appreciated.

On Sun, 2007-02-04 at 18:10 +0100, Denis Vlasenko wrote:
> On Friday 02 February 2007 22:43, Denis Vlasenko wrote:
> > On Friday 02 February 2007 16:01, Natanael Copa wrote:
> > > Hi,
> > > 
> > > Attatched is a patch for support of the '!' operator for find.
> > > 
> > > I created another macro ALLOC_TEST for actions that can be inverted with
> > > '!'. They are not really actions (like -print) but tests (like -name).
> > > 
> > > It should not touch anything unless you have enabled the
> > > FEATURE_FIND_NOT config option.
> > 
> > parse_params():
> > invert_flag is never reset to 0. This must be a bug -
> > "not" shouldn't be applied to the second -name here, I think
> > (did not check it versus GNU find, tho...):
> > find ! -name '*.a' -o -name '*.b'

Correct. It was a bug.

> I did it myself. find ! support is in svn. Please test.

The bug is still there.

./busybox find ! -name '*.c' -name 'f*'

Should give you a lists of files starting with 'f' and with all .c files
excluded.

The attatched patch should fix it.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-not-fix.patch
Type: text/x-patch
Size: 1280 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070206/8442e1fc/attachment.bin 

From natanael.copa at gmail.com  Tue Feb  6 07:56:43 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Tue, 06 Feb 2007 16:56:43 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <1170777033.6604.13.camel@localhost>
References: <1170428490.28276.35.camel@localhost>
	<200702022243.56100.vda.linux@googlemail.com>
	<200702041810.57851.vda.linux@googlemail.com>
	<1170777033.6604.13.camel@localhost>
Message-ID: <1170777403.6604.18.camel@localhost>

On Tue, 2007-02-06 at 16:50 +0100, Natanael Copa wrote:

> > > parse_params():
> > > invert_flag is never reset to 0. This must be a bug -
> > > "not" shouldn't be applied to the second -name here, I think
> > > (did not check it versus GNU find, tho...):
> > > find ! -name '*.a' -o -name '*.b'
> 
> Correct. It was a bug.
> 
> > I did it myself. find ! support is in svn. Please test.
> 
> The bug is still there.
> 
> ./busybox find ! -name '*.c' -name 'f*'
> 
> Should give you a lists of files starting with 'f' and with all .c files
> excluded.
> 
> The attatched patch should fix it.

I'm sorry. I posted it a few seconds to early. The following chunk
should not be there:
@@ -342,7 +342,7 @@
 	action*** appp;
 	unsigned cur_group = 0;
 	unsigned cur_action = 0;
-	USE_FEATURE_FIND_NOT( smallint invert_flag = 0; )
+	USE_FEATURE_FIND_NOT( smallint invert_flag; )
 
 	action* alloc_action(int sizeof_struct, action_fp f)
 	{


The invert_flag should be initialized.



From steven.scholz at imc-berlin.de  Tue Feb  6 08:21:00 2007
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 06 Feb 2007 17:21:00 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <16105.1170771464@brightstareng.com>
References: <16105.1170771464@brightstareng.com>
Message-ID: <45C8AAEC.1090307@imc-berlin.de>

Paul Fox wrote:
>  > >>> It may be useful (at least it is for us) to keep on sending DHCP
request
>  > >>> and renewals for ever until we actually get an answer. For that
purpose
>  > >>> udhcpc -t 0 could do the job.
>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>  > >
>  > > Almost, but not exactly.
>  > > We have machines that can be powered up without being connected to any
>  > > network for weeks. However, we need them to fetch an IP if they ever get
>  > > plugged to some network.
>  >
>  > Then maybe you want to use something like netplugd ot ifplugd ...
>
> of course that takes care of the locally connected problem, but
> not the "connected to a switch which is itself disconnected"
> problem.

But udhcpc in background mode takes care of this situation by trying toi get
a lease every 5 minutes or so ... Right?

> dhcp should be using netlink itself, to track interface connectivity.  (i.e.,
> needing ifplugd is a bug, in my opinion.)
Not realy. We're using netplugd with static IP adresses as well. No need for
eth0 to be up and running if there's no network...

--
Steven

From steven.scholz at imc-berlin.de  Tue Feb  6 08:22:13 2007
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 06 Feb 2007 17:22:13 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C896BC.505@olivetti-engineering.com>
References: <16105.1170771464@brightstareng.com>
	<45C896BC.505@olivetti-engineering.com>
Message-ID: <45C8AB35.8050505@imc-berlin.de>

Samuel Ortiz wrote:
> Paul Fox wrote:
>>  > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>  > >>> and renewals for ever until we actually get an answer. For that purpose 
>>  > >>> udhcpc -t 0 could do the job.
>>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>>  > > 
>>  > > Almost, but not exactly.
>>  > > We have machines that can be powered up without being connected to any 
>>  > > network for weeks. However, we need them to fetch an IP if they ever get 
>>  > > plugged to some network.
>>  > 
>>  > Then maybe you want to use something like netplugd ot ifplugd ...
>>
>> of course that takes care of the locally connected problem, but
>> not the "connected to a switch which is itself disconnected"
>> problem.  but i agree -- if it were me, i'd probably use a
>> combination of the mechanisms.
> well, with the infinite retries option, we can live without netplugd.
How about using

-b,     --background
	Fork to background if lease cannot be immediately negotiated.

???

Steven

From sortiz at olivetti-engineering.com  Tue Feb  6 08:33:02 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Tue, 06 Feb 2007 17:33:02 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C8AB35.8050505@imc-berlin.de>
References: <16105.1170771464@brightstareng.com>
	<45C896BC.505@olivetti-engineering.com>
	<45C8AB35.8050505@imc-berlin.de>
Message-ID: <45C8ADBE.5060603@olivetti-engineering.com>

Steven Scholz wrote:
> Samuel Ortiz wrote:
>> Paul Fox wrote:
>>>  > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>>  > >>> and renewals for ever until we actually get an answer. For that purpose 
>>>  > >>> udhcpc -t 0 could do the job.
>>>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>>>  > > 
>>>  > > Almost, but not exactly.
>>>  > > We have machines that can be powered up without being connected to any 
>>>  > > network for weeks. However, we need them to fetch an IP if they ever get 
>>>  > > plugged to some network.
>>>  > 
>>>  > Then maybe you want to use something like netplugd ot ifplugd ...
>>>
>>> of course that takes care of the locally connected problem, but
>>> not the "connected to a switch which is itself disconnected"
>>> problem.  but i agree -- if it were me, i'd probably use a
>>> combination of the mechanisms.
>> well, with the infinite retries option, we can live without netplugd.
> How about using
> 
> -b,     --background
> 	Fork to background if lease cannot be immediately negotiated.
> 
> ???

I didn't check this option, but it seems that it will wakeup after 60
seconds, and try again, so this could be a solution, yes.

Cheers,
Samuel.


> Steven
> 


From vda.linux at googlemail.com  Tue Feb  6 09:14:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 18:14:20 +0100
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070206130216.14246.qmail@webmail72.rediffmail.com>
References: <20070206130216.14246.qmail@webmail72.rediffmail.com>
Message-ID: <200702061814.20154.vda.linux@googlemail.com>

On Tuesday 06 February 2007 14:02, Rupesh Gujare wrote:
> hello all,
>  thanks for help..  and sorry for not stating my problem clearly
> so finally i was able to change rootfs.. Here is what i did at interactive shell by adding /bin/sh at start in /etc/init.d/rcS:--
> 
>  mount -t proc none /proc
>  mount -t ext2 /dev/sda1 /tmp
>  cd /tmp
>  umount /proc
>  pivot_root . tmp   #tmp exist on new-root
>  mount -t proc none /proc
>  exec chroot . /bin/ash <dev/console > dev/console 2>&1
>  exec chroot . /sbin/init <dev/console > dev/console 2>&1
>  umount /tmp
>  
> BUT HERE I GET ERROR AS:--
> Device or resource busy

Because your current directory is still "old" /
(== "new" /tmp)

>  Where I am going wrong?

Example that I posted:

echo "# Chrooting into root fs"
# we expect that /dev/console and /dev/null exist in /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc

avoided that by changing to /new_root, detaching stdio from lod /dev
and doing pivot_root while sitting in /new_root.

Why you are not following the example?
--
vda

From vda.linux at googlemail.com  Tue Feb  6 09:36:29 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 18:36:29 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <1170777403.6604.18.camel@localhost>
References: <1170428490.28276.35.camel@localhost>
	<1170777033.6604.13.camel@localhost>
	<1170777403.6604.18.camel@localhost>
Message-ID: <200702061836.29931.vda.linux@googlemail.com>

On Tuesday 06 February 2007 16:56, Natanael Copa wrote:
> On Tue, 2007-02-06 at 16:50 +0100, Natanael Copa wrote:
> 
> > > > parse_params():
> > > > invert_flag is never reset to 0. This must be a bug -
> > > > "not" shouldn't be applied to the second -name here, I think
> > > > (did not check it versus GNU find, tho...):
> > > > find ! -name '*.a' -o -name '*.b'
> > 
> > Correct. It was a bug.
> > 
> > > I did it myself. find ! support is in svn. Please test.
> > 
> > The bug is still there.
> > 
> > ./busybox find ! -name '*.c' -name 'f*'
> > 
> > Should give you a lists of files starting with 'f' and with all .c files
> > excluded.
> > 
> > The attatched patch should fix it.
> 
> I'm sorry. I posted it a few seconds to early. The following chunk
> should not be there:
> @@ -342,7 +342,7 @@
>  	action*** appp;
>  	unsigned cur_group = 0;
>  	unsigned cur_action = 0;
> -	USE_FEATURE_FIND_NOT( smallint invert_flag = 0; )
> +	USE_FEATURE_FIND_NOT( smallint invert_flag; )
>  
>  	action* alloc_action(int sizeof_struct, action_fp f)
>  	{
> 
> 
> The invert_flag should be initialized.

Applied, thanks.
--
vda

From questforhappiness at hotmail.com  Tue Feb  6 11:34:25 2007
From: questforhappiness at hotmail.com (none none)
Date: Tue, 06 Feb 2007 11:34:25 -0800
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <200702030247.11080.vda.linux@googlemail.com>
Message-ID: <BAY123-F85F6D80EA409D2C95FC4BB99F0@phx.gbl>




>From: Denis Vlasenko <vda.linux at googlemail.com>
>To: busybox at busybox.net
>CC: "none none" <questforhappiness at hotmail.com>
>Subject: Re: Patch to accommodate 2007 Daylight Saving Time change 
>(busybox)
>Date: Sat, 3 Feb 2007 02:47:11 +0100
>
>On Saturday 03 February 2007 02:34, none none wrote:
> > Hi there,
> >
> > My aventail appliances are using busybox as OS.  I checked and find that 
>it
> > is not using the new 2007 Daylight Saving Time schedule.  Does anyone 
>know
> > if there are patches or instructions to update busybox to accommodate 
>the
> > new 2007 Daylight Saving Time change?
>
>This is done by libc routines. If it doesn't work for you,
>you should update/fix your libc.
>--
>vda


I am new to busybox although I have some background in linux.  How do you 
usually update packages like libc in busybox?  In Linux, we use either yum 
or up2date.  It is the same for busybox?  Is there a link where I can find 
the correct libc for 2007 Daylight Saving Time?

Thank you,
Donald.

_________________________________________________________________
Search for grocery stores. Find gratitude. Turn a simple search into 
something more. 
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_gratitude&FORM=WLMTAG


From vda.linux at googlemail.com  Tue Feb  6 11:29:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 20:29:32 +0100
Subject: libselinux utilities applets - please test
Message-ID: <200702062029.33013.vda.linux@googlemail.com>

int getsebool_main(int argc, char **argv)
{
...
        if (!len) {
                if (argc < 2)
                        bb_show_usage();
                len = argc - 1;
                names = xmalloc(sizeof(char *) * len);
                for (i = 0; i < len; i++)
                        names[i] = xstrdup(argv[i + 1]);
        }

Is it necessary to allocate names and xstrdup argv[i]?
Maybe just do "names = argv + 1"?


bb_perror_msg_and_die("error while processing %s: ", prefix);

bb_perror prints: "<applet>: message: <strerror>" - that thrailing
": " in your code is not needed.


+#define matchpathcon_trivial_usage \
+       "[-n] [-N] [-f file_contexts_file] [-p prefix] [-V]"
+#define matchpathcon_full_usage \
+       "\t-n\tDo not display path.\n" \
+       "\t-N\tDo not use translations.\n" \
+       "\t-f\tfile_context_file Use alternate file_context file\n" \
+       "\t-p\tprefix Use prefix to speed translations\n" \
+       "\t-V\tVerify file context on disk matches defaults"

Ehhh.... usage.h has such a nice comment at the top:

/*
 * This file suffers from chronically incorrect tabification
 * of messages. Before editing this file:
 * 1. Switch you editor to 8-space tab mode.
 * 2. Do not use \t in messages, use real tab character.
 * 3. Start each source line with message as follows:
 *    |<7 spaces>"text with tabs"....
 */


Okay. I applied your patch to svn and did some changes.
Please review & test - I can't run-test it at the moment
(my kernel and userspace is not selinux-enabled).

Patch is attached for easy review. Thanks.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sl.patch
Type: text/x-diff
Size: 12760 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070206/cee881f2/attachment-0001.bin 

From vda.linux at googlemail.com  Tue Feb  6 11:42:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 20:42:40 +0100
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <BAY123-F85F6D80EA409D2C95FC4BB99F0@phx.gbl>
References: <BAY123-F85F6D80EA409D2C95FC4BB99F0@phx.gbl>
Message-ID: <200702062042.40194.vda.linux@googlemail.com>

On Tuesday 06 February 2007 20:34, none none wrote:
> I am new to busybox although I have some background in linux.  How do you 
> usually update packages like libc in busybox?

You seem to confuse busybox with linux distributions.
It isn't a distro. It is just a collection of programs.

You question is similar to "how do you usually update
apache in samba?". My reaction is "what??!".

> In Linux, we use either yum  
> or up2date.  It is the same for busybox?

In "my" Linux, it's wget && read_docs_carefully && make. ;)

> Is there a link where I can find  
> the correct libc for 2007 Daylight Saving Time?

I doubt you need to update libc.

If you have problems with incorrect time zone setup,
on "desktop" (i.e., glibc-based) distro check your
/etc/localtime (should be a symlink, something like
/etc/localtime -> /usr/share/zoneinfo/Europe/Kiev).

On uclibc, check /etc/TZ and/or TZ environment variable.
Example: /etc/TZ contents for Eastern Europe is
just one line:

EET-2EEST-3

It says "Normal time is called 'EET' and is GMT + 2:00,
summer time is called 'EEST' and is GMT + 3".

More complex example specifies _when_ to do transition:

EET-2EEST-3,M3.5.0/03:00:00,M10.5.0/04:00:00

--
vda

From pgf at brightstareng.com  Tue Feb  6 12:21:11 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Tue, 06 Feb 2007 15:21:11 -0500
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox) 
In-Reply-To: vda.linux's message of Tue, 06 Feb 2007 20:42:40 +0100.
	<200702062042.40194.vda.linux@googlemail.com> 
Message-ID: <26843.1170793271@brightstareng.com>

 > On Tuesday 06 February 2007 20:34, none none wrote:
 > > I am new to busybox although I have some background in linux.  How do you 
 > > usually update packages like libc in busybox?
 > 
...
 > I doubt you need to update libc.
 > 
 > If you have problems with incorrect time zone setup,
 > on "desktop" (i.e., glibc-based) distro check your
 > /etc/localtime (should be a symlink, something like
 > /etc/localtime -> /usr/share/zoneinfo/Europe/Kiev).

i suspect the original poster is concerned with the USA's
change of daylight savings time start/end dates.  the law
requiring the change was passed in 2005, and takes effect
this year.  many vendors are only now scrambling to implement
the change, which is pretty late, since DST starts on march
11th this year.  :-)

so:  what needs to change is not just a symlink or a reference, but the
contents of the tz database.

but, to echo vda's comment:  this isn't a busybox issue.

paul
=---------------------
 paul fox, pgf at brightstareng.com

From questforhappiness at hotmail.com  Tue Feb  6 13:50:51 2007
From: questforhappiness at hotmail.com (none none)
Date: Tue, 06 Feb 2007 13:50:51 -0800
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <26843.1170793271@brightstareng.com>
Message-ID: <BAY123-F200BA655A818D835020FAEB99F0@phx.gbl>


>i suspect the original poster is concerned with the USA's
>change of daylight savings time start/end dates.  the law
>requiring the change was passed in 2005, and takes effect
>this year.  many vendors are only now scrambling to implement
>the change, which is pretty late, since DST starts on march
>11th this year.  :-)

Yes, that is exactly right.

>so:  what needs to change is not just a symlink or a reference, but the
>contents of the tz database.
>
>but, to echo vda's comment:  this isn't a busybox issue.

Yes, nothing is wrong with busybox.  I do need to change the content of the 
tz database.  I don't know how to do that in busybox.  Please help give some 
directions.

thank you,
Donald.

_________________________________________________________________
FREE online classifieds from Windows Live Expo ? buy and sell with people 
you know 
http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06


From psmith at netezza.com  Tue Feb  6 14:01:55 2007
From: psmith at netezza.com (Paul Smith)
Date: Tue, 06 Feb 2007 17:01:55 -0500
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <BAY123-F200BA655A818D835020FAEB99F0@phx.gbl>
References: <BAY123-F200BA655A818D835020FAEB99F0@phx.gbl>
Message-ID: <1170799315.32495.12.camel@psmithub>

On Tue, 2007-02-06 at 13:50 -0800, none none wrote:

> Yes, nothing is wrong with busybox.  I do need to change the content of the 
> tz database.  I don't know how to do that in busybox.  Please help give some 
> directions.

The tz database is not part of busybox: it (typically) is part of your C
runtime library.  You need to check with the folks who maintain whatever
C library you use: probably either GNU libc (glibc) or UClib.


Cheers!

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <psmith at netezza.com>                       http://netezza.com
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
-----------------------------------------------------------------------------
      These are my opinions--Netezza takes no responsibility for them.

From pgf at brightstareng.com  Tue Feb  6 14:04:34 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Tue, 06 Feb 2007 17:04:34 -0500
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox) 
In-Reply-To: questforhappiness's message of Tue, 06 Feb 2007 13:50:51 -0800.
	<BAY123-F200BA655A818D835020FAEB99F0@phx.gbl> 
Message-ID: <26244.1170799474@brightstareng.com>

 > Yes, nothing is wrong with busybox.  I do need to change the content of the 
 > tz database.  I don't know how to do that in busybox.  Please help give some 
 > directions.

download the latest tz database, and compile it:
    http://www.twinsun.com/tz/tz-link.htm

paul
=---------------------
 paul fox, pgf at brightstareng.com

From education.sina at gmail.com  Tue Feb  6 21:02:16 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Wed, 7 Feb 2007 14:02:16 +0900
Subject: Busybox compilation error
Message-ID: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>

Hi,
I am trying to compile busybox for ARM cpu...Am using arm bese toolchain...
I am getting this error at the end...
LINK    busybox_unstripped
applets/built-in.o:(.rodata.applets+0x664): undefined reference to
`readahead_main'
applets/built-in.o:(.rodata.applets+0x868): undefined reference to
`taskset_main'
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1

BTD I am keeping off two line  at /miscutils/Kbuild
#lib-$(CONFIG_READAHEAD)   +#lib-$(CONFIG_TASKSET)     +
as if i keeping this two line then i am also geting some errors...
Can anybody tell what should i do now..to solve this problem...

Thanks
Sina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070207/0ea51218/attachment.html 

From natanael.copa at gmail.com  Wed Feb  7 01:33:09 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Wed, 07 Feb 2007 10:33:09 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
Message-ID: <1170840789.6604.48.camel@localhost>

Hi,

I just discovered that busybox wget segfaults in my
gentoo/hardened/uclibc environment.

strace shows this:

open("/etc/services", O_RDONLY)         = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
(Inappropriate ioctl for device)
brk(0x10e57000)                         = 0x10e57000
read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
close(3)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 15366 detached

Does anybody know anything about it?



From kaigai at kaigai.gr.jp  Wed Feb  7 07:28:07 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Thu, 08 Feb 2007 00:28:07 +0900
Subject: libselinux utilities applets - please test
In-Reply-To: <200702062029.33013.vda.linux@googlemail.com>
References: <200702062029.33013.vda.linux@googlemail.com>
Message-ID: <45C9F007.40706@kaigai.gr.jp>

Denis, Thanks for merging the series of patches.

> Okay. I applied your patch to svn and did some changes.
> Please review & test - I can't run-test it at the moment
> (my kernel and userspace is not selinux-enabled).
> 
> Patch is attached for easy review. Thanks.
> --
> vda

I found some problems on building SELinux related applets.
The attached patch will fix them.

> diff -urpN busybox.5/selinux/matchpathcon.c busybox.6/selinux/matchpathcon.c
> --- busybox.5/selinux/matchpathcon.c	1970-01-01 01:00:00.000000000 +0100
> +++ busybox.6/selinux/matchpathcon.c	2007-02-06 20:23:46.000000000 +0100

- snip -

Compiler generated a warning message due to missing a prototype definition.
So, I put a prototype definition such as other applets.

> +int matchpathcon_main(int argc, char **argv)
> +{
> +	int error = 0;
> +	unsigned opts;
> +	char *fcontext, *prefix, *path;
> +
> +	opt_complementary = "-1:" /* at least one param reqd */
> +		"f--p:p--f"; /* mutually exclusive */
> +	opts = getopt32(argc, argv, "nNf:p:V", &fcontext, &prefix);
> +	argv += optind;
> +
> +	if (opts & OPT_NOT_TRANS) {
> +		set_matchpathcon_flags(NOTRANS);
                                       ^^^^^^^
It should be MATCHPATHCON_NOTRANS which is defined in selinux/selinux.h.
It's not a constant value to represent a command line option.

> +	}
> +	if (opts & OPT_FCONTEXT) {
> +		if (matchpathcon_init(fcontext))
> +			bb_perror_msg_and_die("error while processing %s", fcontext);
> +	}
> +	if (opts & OPT_PREFIX) {
> +		if (matchpathcon_init_prefix(NULL, prefix))
> +			bb_perror_msg_and_die("error while processing %s", prefix);
> +	}
> +
> +	while((path = *argv++) != NULL) {
> +		security_context_t con;
> +		int rc;
> +
> +		if (!(opts & OPT_VERIFY)) {
> +			error += print_matchpathcon(path, opt & OPT_NOT_PRINT);
It should be 'opts', not 'opt'.

> +			continue;
> +		}
> +
> +		if (selinux_file_context_verify(path, 0)) {
> +			printf("%s verified\n", path);
> +			continue;
> +		}
> +
> +		if (opts & OPT_NOT_TRANS)
> +			rc = lgetfilecon_raw(path, &con);
> +		else
> +			rc = lgetfilecon(path, &con);
> +
> +		if (rc >= 0) {
> +			printf("%s has context %s, should be ", path, con);
> +			error += print_matchpathcon(path, 1);
> +			freecon(con);
> +			continue;
> +		}
> +		printf("actual context unknown: %s, should be ", strerror(errno));
> +		error += print_matchpathcon(path, 1);
> +	}
> +	matchpathcon_fini();
> +	return error;
> +}

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-selinux-fix-build.patch
Type: text/x-patch
Size: 2191 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/1acdae87/attachment.bin 

From marc.leeman at gmail.com  Wed Feb  7 08:15:25 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Wed, 7 Feb 2007 17:15:25 +0100
Subject: syslogd +realpath
Message-ID: <20070207161525.GQ15523@scorpius.homelinux.org>

I seem to have stumbled on another problem with syslogd in 1.4.0/1.4.1.
I did not notice it at first since I was developing on an NFS system and
not yet on a squashfs system with a ro /

The problem occurs when syslogd unlinks /dev/log and creates a socket in
/dev/log; on a RO fs, it cannot do that and will segfault all the time.

On a virgin NFS system; the following happens:

[mleeman at gemini target.scu.jodw]$ ls -al dev/log
lrwxrwxrwx 1 root root 10 Feb  7 17:04 dev/log -> ../tmp/log
[mleeman at gemini target.scu.jodw]$ ls -al dev/log
lrwxrwxrwx 1 root root 10 Feb  7 17:04 dev/log -> ../tmp/log
[mleeman at gemini target.scu.jodw]$ ls -al dev/log
srw-rw-rw- 1 root root 0 Feb  7 17:05 dev/log

The link is replaced with a socket (/ fs is RW).

-- 
  greetz, marc
Come on out, Chiana. Look, I don't have time to play this game. Durka's
gone Hannibal Lector on us.
	Crichton - Durka Returns
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://busybox.net/lists/busybox/attachments/20070207/9351ae79/attachment.pgp 

From marc.leeman at gmail.com  Wed Feb  7 08:35:07 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Wed, 7 Feb 2007 17:35:07 +0100
Subject: [gmail] syslogd +realpath
In-Reply-To: <20070207161525.GQ15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
Message-ID: <20070207163507.GR15523@scorpius.homelinux.org>

> The link is replaced with a socket (/ fs is RW).

Forgot to mention that I am using uclibc on powerpc.:

-- 
  greetz, marc
I may be small but allow me to remind you that only serves to put me
at castration level.
	Rygel - Relativity
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://busybox.net/lists/busybox/attachments/20070207/7ce1cc6f/attachment-0001.pgp 

From marc.leeman at gmail.com  Wed Feb  7 08:58:34 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Wed, 7 Feb 2007 17:58:34 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070207163507.GR15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207163507.GR15523@scorpius.homelinux.org>
Message-ID: <20070207165834.GT15523@scorpius.homelinux.org>

On Wed, Feb 07, 2007 at 05:35:07PM +0100, Marc Leeman wrote:
> > The link is replaced with a socket (/ fs is RW).
> 
> Forgot to mention that I am using uclibc on powerpc.:


adding:

char *xmalloc_realpath(const char *path)
{
#if defined(__GLIBC__) && !defined(__UCLIBC__)
    /* glibc provides a non-standard extension */
    return realpath(path, NULL);
#else
    char buf[PATH_MAX+1];

    fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
    fprintf(stdout,"realpath buf is %s\n",buf);
    /* on error returns NULL (xstrdup(NULL) =NULL) */
    return xstrdup(realpath(path, buf));
#endif
}

results in:

$ /sbin/syslogd -n -m 0 -C16
realpath returns (null)
realpath buf is /tmp/log
syslogd: bind: Address already in use

oeps!

let's blatantly ignore the comment about "on error":

char *xmalloc_realpath(const char *path)
{
#if defined(__GLIBC__) && !defined(__UCLIBC__)
    /* glibc provides a non-standard extension */
    return realpath(path, NULL);
#else
    char buf[PATH_MAX+1];

    fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
    fprintf(stdout,"realpath buf is %s\n",buf);
    /* on error returns NULL (xstrdup(NULL) =NULL) */
    return xstrdup(buf);
#endif
}

$ ls -al /tmp/log
srw-rw-rw-    1 0        0               0 Jan  1 00:00 /tmp/log

this seems to give us what we expect :)

cf. att'd patch

-- 
  Marc Leeman
  R&D Firmware Engineer
  Security & Monitoring Division
  
  Barco N.V.
  Noordlaan 5, 
  B-8520 Kuurne
  Tel. +32 (0)56 368 428
  Tel. +32 (0)56 368 605
  mailto:marc.leeman at barco.com
  http://www.barco.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmalloc_realpath.diff
Type: text/x-diff
Size: 459 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070207/35980f6c/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://busybox.net/lists/busybox/attachments/20070207/35980f6c/attachment.pgp 

From vda.linux at googlemail.com  Wed Feb  7 12:25:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 21:25:43 +0100
Subject: Busybox compilation error
In-Reply-To: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
Message-ID: <200702072125.43257.vda.linux@googlemail.com>

On Wednesday 07 February 2007 06:02, Sina Mallick wrote:
> Hi,
> I am trying to compile busybox for ARM cpu...Am using arm bese toolchain...
> I am getting this error at the end...
> LINK    busybox_unstripped
> applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> `readahead_main'
> applets/built-in.o:(.rodata.applets+0x868): undefined reference to
> `taskset_main'
> collect2: ld returned 1 exit status
> make: *** [busybox_unstripped] Error 1
> 
> BTD I am keeping off two line  at /miscutils/Kbuild
> #lib-$(CONFIG_READAHEAD)   += readahead.o
> #lib-$(CONFIG_TASKSET)     += taskset.o
> 
> as if i keeping this two line then i am also geting some errors...
> Can anybody tell what should i do now..to solve this problem...

Please post your .comfig
--
vda

From vda.linux at googlemail.com  Wed Feb  7 13:26:49 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 22:26:49 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170840789.6604.48.camel@localhost>
References: <1170840789.6604.48.camel@localhost>
Message-ID: <200702072226.49159.vda.linux@googlemail.com>

On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> Hi,
> 
> I just discovered that busybox wget segfaults in my
> gentoo/hardened/uclibc environment.
> 
> strace shows this:
> 
> open("/etc/services", O_RDONLY)         = 3
> ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> (Inappropriate ioctl for device)
> brk(0x10e57000)                         = 0x10e57000
> read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> close(3)                                = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 15366 detached
> 
> Does anybody know anything about it?

What is your bbox version and .config? uclibc version and .config?
--
vda

From vda.linux at googlemail.com  Wed Feb  7 14:07:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:07:45 +0100
Subject: libselinux utilities applets - please test
In-Reply-To: <45C9F007.40706@kaigai.gr.jp>
References: <200702062029.33013.vda.linux@googlemail.com>
	<45C9F007.40706@kaigai.gr.jp>
Message-ID: <200702072307.45400.vda.linux@googlemail.com>

:u?vw?u???W?????m4?^??????????-x7????jy,~??z?"?az????(~??r?:F?!?i?'??????\??,?v?u?????r??????z????-z?Hq?????z?b??m???????)
?w?jwn?????
???????{?zv???Oj?!?????!y???????????????Z!?.??(??k??^??'n??v)?HB???kzV?y???W??8^j?Zr???\???????N???)?X?v?,?r??'???y?'z???Z)?)???b?t?z?^??\?*'?'^????)???????q?
"g???l?g??)????jw?????	??????mi?fz{pj?
???y?Z???j?!O*^??m?b}??????F???z?'???j)ZnW??Xm???n?2n?gz????l?????1??mi?fz{l?m4?M???8??
???????g????

From vda.linux at googlemail.com  Wed Feb  7 14:19:04 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:19:04 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070207165834.GT15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207163507.GR15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
Message-ID: <200702072319.04728.vda.linux@googlemail.com>

On Wednesday 07 February 2007 17:58, Marc Leeman wrote:
> On Wed, Feb 07, 2007 at 05:35:07PM +0100, Marc Leeman wrote:
> > > The link is replaced with a socket (/ fs is RW).
> > 
> > Forgot to mention that I am using uclibc on powerpc.:
> 
> 
> adding:
> 
> char *xmalloc_realpath(const char *path)
> {
> #if defined(__GLIBC__) && !defined(__UCLIBC__)
>     /* glibc provides a non-standard extension */
>     return realpath(path, NULL);
> #else
>     char buf[PATH_MAX+1];
> 
>     fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
>     fprintf(stdout,"realpath buf is %s\n",buf);
>     /* on error returns NULL (xstrdup(NULL) ==NULL) */
>     return xstrdup(realpath(path, buf));
> #endif
> }
> 
> results in:
> 
> $ /sbin/syslogd -n -m 0 -C16
> realpath returns (null)
> realpath buf is /tmp/log
> syslogd: bind: Address already in use
> 
> oeps!
> 
> let's blatantly ignore the comment about "on error":
> 
> char *xmalloc_realpath(const char *path)
> {
> #if defined(__GLIBC__) && !defined(__UCLIBC__)
>     /* glibc provides a non-standard extension */
>     return realpath(path, NULL);
> #else
>     char buf[PATH_MAX+1];
> 
>     fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
>     fprintf(stdout,"realpath buf is %s\n",buf);
>     /* on error returns NULL (xstrdup(NULL) ==NULL) */
>     return xstrdup(buf);
> #endif
> }
> 
> $ ls -al /tmp/log
> srw-rw-rw-    1 0        0               0 Jan  1 00:00 /tmp/log
> 
> this seems to give us what we expect :)

Yeah, strange... but think about what will happen when realpath REALLY
will fail. We will xstrdup and return... something bogus?

Maybe you should look into uclibc. Why it returned NULL?
My manpage says:

RETURN VALUE
       If there is no error, realpath() returns a pointer to the
       resolved_path.
       Otherwise  it  returns a NULL pointer, and the contents
       of the array resolved_path are undefined. The global
       variable errno is set to indicate the error.

Yet another question is why syslogd even bothers to do this
remove/recreate cycle? What will happen if it will just
bind to /dev/log? (the code will be smaller too)
--
vda

From vda.linux at googlemail.com  Wed Feb  7 14:25:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:25:20 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702072319.04728.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
Message-ID: <200702072325.20231.vda.linux@googlemail.com>

On Wednesday 07 February 2007 23:19, Denis Vlasenko wrote:
> Yet another question is why syslogd even bothers to do this
> remove/recreate cycle? What will happen if it will just
> bind to /dev/log? (the code will be smaller too)

This is what will happen:

./busybox syslogd -n -O zz_syslog
syslogd: bind: Address already in use

I like it. Do you? I mean, let's kill realpath'ing entirely!

But don't forget to file uclibc bug report regarding realpath
at http://bugs.uclibc.org/
--
vda

From vda.linux at googlemail.com  Wed Feb  7 14:29:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:29:20 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <200702072226.49159.vda.linux@googlemail.com>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
Message-ID: <200702072329.20826.vda.linux@googlemail.com>

On Wednesday 07 February 2007 22:26, Denis Vlasenko wrote:
> On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.
> > 
> > strace shows this:
> > 
> > open("/etc/services", O_RDONLY)         = 3
> > ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> > (Inappropriate ioctl for device)
> > brk(0x10e57000)                         = 0x10e57000
> > read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> > read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> > close(3)                                = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> > Process 15366 detached
> > 
> > Does anybody know anything about it?
> 
> What is your bbox version and .config? uclibc version and .config?

Oh, and of course, what is wget's commandline?
--
vda

From solar at gentoo.org  Wed Feb  7 14:39:14 2007
From: solar at gentoo.org (Ned Ludd)
Date: Wed, 07 Feb 2007 14:39:14 -0800
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170840789.6604.48.camel@localhost>
References: <1170840789.6604.48.camel@localhost>
Message-ID: <1170887954.14435.33.camel@onyx.private.gni.com>

On Wed, 2007-02-07 at 10:33 +0100, Natanael Copa wrote:
> Hi,
> 
> I just discovered that busybox wget segfaults in my
> gentoo/hardened/uclibc environment.

I more or less have a tinderbox setup with the same setup.

uClibc-0.9.28.1
busybox-1.4.1

gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2, HTB-3.4.4-1.00,
ssp-3.4.6-1.0, pie-8.7.9)

wget does not segfault here.

Unless your /etc/services matches the following checksum
bd6b457cdce64b7932a4db4d4a251265 can you post that also?

> 
> strace shows this:
> 
> open("/etc/services", O_RDONLY)         = 3
> ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> (Inappropriate ioctl for device)
> brk(0x10e57000)                         = 0x10e57000
> read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> close(3)                                = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 15366 detached
> 
> Does anybody know anything about it?
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
-- 
Ned Ludd <solar at gentoo.org>
Gentoo Linux


From education.sina at gmail.com  Wed Feb  7 16:47:30 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Thu, 8 Feb 2007 09:47:30 +0900
Subject: Busybox compilation error
In-Reply-To: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
Message-ID: <1ff320400702071647x1b64de12m10bef0c1c59fccd8@mail.gmail.com>

Hi,
> I am trying to compile busybox for ARM cpu...Am using arm bese
> toolchain...
> I am getting this error at the end...
> LINK    busybox_unstripped
> applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> `readahead_main'
> applets/built-in.o: (.rodata.applets+0x868): undefined reference to
> `taskset_main'
> collect2: ld returned 1 exit status
> make: *** [busybox_unstripped] Error 1
>
> BTD I am keeping off two line  at /miscutils/Kbuild
> #lib-$(CONFIG_READAHEAD)   +> #lib-$(CONFIG_TASKSET)     +>
> as if i keeping this two line then i am also geting some errors...
> Can anybody tell what should i do now..to solve this problem...
>
> Thanks
> Sina

I am attaching .config file at this mail...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070208/eecffe45/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busyconfig
Type: application/octet-stream
Size: 15741 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/eecffe45/attachment-0001.obj 

From education.sina at gmail.com  Wed Feb  7 16:41:17 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Thu, 8 Feb 2007 09:41:17 +0900
Subject: Busybox compilation error
In-Reply-To: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
Message-ID: <1ff320400702071641x362f2494j5b0604c435c4cea4@mail.gmail.com>

Hi,
> I am trying to compile busybox for ARM cpu...Am using arm bese
> toolchain...
> I am getting this error at the end...
> LINK    busybox_unstripped
> applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> `readahead_main'
> applets/built-in.o: (.rodata.applets+0x868): undefined reference to
> `taskset_main'
> collect2: ld returned 1 exit status
> make: *** [busybox_unstripped] Error 1
>
> BTD I am keeping off two line  at /miscutils/Kbuild
> #lib-$(CONFIG_READAHEAD)   +> #lib-$(CONFIG_TASKSET)     +>
> as if i keeping this two line then i am also geting some errors...
> Can anybody tell what should i do now..to solve this problem...
>
> Thanks
> Sina
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070208/45ba084c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Config.in
Type: application/octet-stream
Size: 15800 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/45ba084c/attachment.obj 

From natanael.copa at gmail.com  Thu Feb  8 00:14:45 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Thu, 08 Feb 2007 09:14:45 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170887954.14435.33.camel@onyx.private.gni.com>
References: <1170840789.6604.48.camel@localhost>
	<1170887954.14435.33.camel@onyx.private.gni.com>
Message-ID: <1170922485.14212.10.camel@localhost>

On Wed, 2007-02-07 at 14:39 -0800, Ned Ludd wrote:
> On Wed, 2007-02-07 at 10:33 +0100, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.
> 
> I more or less have a tinderbox setup with the same setup.
> 
> uClibc-0.9.28.1

same here.

> busybox-1.4.1

same here but with backported find from svn.

> gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2, HTB-3.4.4-1.00,
> ssp-3.4.6-1.0, pie-8.7.9)

gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)

> 
> wget does not segfault here.
> 
> Unless your /etc/services matches the following checksum
> bd6b457cdce64b7932a4db4d4a251265 can you post that also?

bd6b457cdce64b7932a4db4d4a251265  /etc/services
yup... same.


The config is attatched.

> > 
> > strace shows this:
> > 
> > open("/etc/services", O_RDONLY)         = 3
> > ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> > (Inappropriate ioctl for device)
> > brk(0x10e57000)                         = 0x10e57000
> > read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> > read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> > close(3)                                = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> > Process 15366 detached
> > 
> > Does anybody know anything about it?
> > 
> > 
> > _______________________________________________
> > busybox mailing list
> > busybox at busybox.net
> > http://busybox.net/cgi-bin/mailman/listinfo/busybox
> > 
-------------- next part --------------
#
# Automatically generated make config: don't edit
# Busybox version: 1.4.1
# Tue Feb  6 16:59:42 2007
#
CONFIG_HAVE_DOT_CONFIG=y

#
# Busybox Settings
#

#
# General Configuration
#
CONFIG_NITPICK=y
CONFIG_DESKTOP=y
CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
# CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set
# CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set
CONFIG_SHOW_USAGE=y
CONFIG_FEATURE_VERBOSE_USAGE=y
CONFIG_FEATURE_COMPRESS_USAGE=y
CONFIG_FEATURE_INSTALLER=y
# CONFIG_LOCALE_SUPPORT is not set
CONFIG_GETOPT_LONG=y
CONFIG_FEATURE_DEVPTS=y
# CONFIG_FEATURE_CLEAN_UP is not set
CONFIG_FEATURE_SUID=y
CONFIG_FEATURE_SYSLOG=y
# CONFIG_FEATURE_SUID_CONFIG is not set
# CONFIG_FEATURE_SUID_CONFIG_QUIET is not set
CONFIG_FEATURE_HAVE_RPC=y
# CONFIG_SELINUX is not set
CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe"

#
# Build Options
#
# CONFIG_STATIC is not set
# CONFIG_BUILD_LIBBUSYBOX is not set
# CONFIG_FEATURE_FULL_LIBBUSYBOX is not set
# CONFIG_FEATURE_SHARED_BUSYBOX is not set
CONFIG_LFS=y
# CONFIG_BUILD_AT_ONCE is not set

#
# Debugging Options
#
# CONFIG_DEBUG is not set
# CONFIG_DEBUG_PESSIMIZE is not set
# CONFIG_NO_DEBUG_LIB is not set
# CONFIG_DMALLOC is not set
# CONFIG_EFENCE is not set
# CONFIG_INCLUDE_SUSv2 is not set

#
# Installation Options
#
# CONFIG_INSTALL_NO_USR is not set
CONFIG_INSTALL_APPLET_SYMLINKS=y
# CONFIG_INSTALL_APPLET_HARDLINKS is not set
# CONFIG_INSTALL_APPLET_DONT is not set
CONFIG_PREFIX="./_install"

#
# Busybox Library Tuning
#
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SIZE_VS_SPEED=0

#
# Applets
#

#
# Archival Utilities
#
CONFIG_AR=y
CONFIG_FEATURE_AR_LONG_FILENAMES=y
CONFIG_BUNZIP2=y
CONFIG_CPIO=y
# CONFIG_DPKG is not set
# CONFIG_DPKG_DEB is not set
# CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set
CONFIG_GUNZIP=y
CONFIG_FEATURE_GUNZIP_UNCOMPRESS=y
CONFIG_GZIP=y
# CONFIG_RPM2CPIO is not set
# CONFIG_RPM is not set
CONFIG_TAR=y
CONFIG_FEATURE_TAR_CREATE=y
CONFIG_FEATURE_TAR_BZIP2=y
CONFIG_FEATURE_TAR_LZMA=y
CONFIG_FEATURE_TAR_FROM=y
CONFIG_FEATURE_TAR_GZIP=y
CONFIG_FEATURE_TAR_COMPRESS=y
CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y
# CONFIG_FEATURE_TAR_LONG_OPTIONS is not set
CONFIG_UNCOMPRESS=y
CONFIG_UNLZMA=y
CONFIG_FEATURE_LZMA_FAST=y
CONFIG_UNZIP=y

#
# Common options for cpio and tar
#
CONFIG_FEATURE_UNARCHIVE_TAPE=y
# CONFIG_FEATURE_DEB_TAR_GZ is not set
# CONFIG_FEATURE_DEB_TAR_BZ2 is not set
# CONFIG_FEATURE_DEB_TAR_LZMA is not set

#
# Coreutils
#
CONFIG_BASENAME=y
CONFIG_CAL=y
CONFIG_CAT=y
CONFIG_CATV=y
CONFIG_CHGRP=y
CONFIG_CHMOD=y
CONFIG_CHOWN=y
CONFIG_CHROOT=y
CONFIG_CKSUM=y
CONFIG_CMP=y
CONFIG_COMM=y
CONFIG_CP=y
CONFIG_CUT=y
CONFIG_DATE=y
CONFIG_FEATURE_DATE_ISOFMT=y
CONFIG_DD=y
CONFIG_FEATURE_DD_SIGNAL_HANDLING=y
CONFIG_FEATURE_DD_IBS_OBS=y
CONFIG_DF=y
CONFIG_DIFF=y
CONFIG_FEATURE_DIFF_BINARY=y
CONFIG_FEATURE_DIFF_DIR=y
CONFIG_FEATURE_DIFF_MINIMAL=y
CONFIG_DIRNAME=y
CONFIG_DOS2UNIX=y
CONFIG_UNIX2DOS=y
CONFIG_DU=y
CONFIG_FEATURE_DU_DEFAULT_BLOCKSIZE_1K=y
CONFIG_ECHO=y
CONFIG_FEATURE_FANCY_ECHO=y
CONFIG_ENV=y
# CONFIG_FEATURE_ENV_LONG_OPTIONS is not set
CONFIG_EXPR=y
CONFIG_EXPR_MATH_SUPPORT_64=y
CONFIG_FALSE=y
CONFIG_FOLD=y
CONFIG_HEAD=y
CONFIG_FEATURE_FANCY_HEAD=y
CONFIG_HOSTID=y
CONFIG_ID=y
CONFIG_INSTALL=y
# CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set
CONFIG_LENGTH=y
CONFIG_LN=y
# CONFIG_LOGNAME is not set
CONFIG_LS=y
CONFIG_FEATURE_LS_FILETYPES=y
CONFIG_FEATURE_LS_FOLLOWLINKS=y
CONFIG_FEATURE_LS_RECURSIVE=y
CONFIG_FEATURE_LS_SORTFILES=y
CONFIG_FEATURE_LS_TIMESTAMPS=y
CONFIG_FEATURE_LS_USERNAME=y
CONFIG_FEATURE_LS_COLOR=y
CONFIG_FEATURE_LS_COLOR_IS_DEFAULT=y
CONFIG_MD5SUM=y
CONFIG_MKDIR=y
# CONFIG_FEATURE_MKDIR_LONG_OPTIONS is not set
CONFIG_MKFIFO=y
CONFIG_MKNOD=y
CONFIG_MV=y
# CONFIG_FEATURE_MV_LONG_OPTIONS is not set
CONFIG_NICE=y
CONFIG_NOHUP=y
# CONFIG_OD is not set
CONFIG_PRINTENV=y
CONFIG_PRINTF=y
CONFIG_PWD=y
CONFIG_REALPATH=y
CONFIG_RM=y
CONFIG_RMDIR=y
CONFIG_SEQ=y
CONFIG_SHA1SUM=y
CONFIG_SLEEP=y
CONFIG_FEATURE_FANCY_SLEEP=y
CONFIG_SORT=y
CONFIG_FEATURE_SORT_BIG=y
CONFIG_STAT=y
CONFIG_FEATURE_STAT_FORMAT=y
CONFIG_STTY=y
CONFIG_SUM=y
CONFIG_SYNC=y
CONFIG_TAIL=y
CONFIG_FEATURE_FANCY_TAIL=y
CONFIG_TEE=y
CONFIG_FEATURE_TEE_USE_BLOCK_IO=y
CONFIG_TEST=y
CONFIG_FEATURE_TEST_64=y
CONFIG_TOUCH=y
CONFIG_TR=y
CONFIG_FEATURE_TR_CLASSES=y
CONFIG_FEATURE_TR_EQUIV=y
CONFIG_TRUE=y
CONFIG_TTY=y
CONFIG_UNAME=y
CONFIG_UNIQ=y
CONFIG_USLEEP=y
# CONFIG_UUDECODE is not set
CONFIG_UUENCODE=y
CONFIG_WATCH=y
CONFIG_WC=y
# CONFIG_FEATURE_WC_LARGE is not set
CONFIG_WHO=y
CONFIG_WHOAMI=y
CONFIG_YES=y

#
# Common options for cp and mv
#
CONFIG_FEATURE_PRESERVE_HARDLINKS=y

#
# Common options for ls, more and telnet
#
CONFIG_FEATURE_AUTOWIDTH=y

#
# Common options for df, du, ls
#
CONFIG_FEATURE_HUMAN_READABLE=y

#
# Common options for md5sum, sha1sum
#
CONFIG_FEATURE_MD5_SHA1_SUM_CHECK=y

#
# Console Utilities
#
CONFIG_CHVT=y
CONFIG_CLEAR=y
CONFIG_DEALLOCVT=y
CONFIG_DUMPKMAP=y
CONFIG_LOADFONT=y
CONFIG_LOADKMAP=y
CONFIG_OPENVT=y
CONFIG_RESET=y
CONFIG_RESIZE=y
CONFIG_FEATURE_RESIZE_PRINT=y
CONFIG_SETCONSOLE=y
# CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS is not set
CONFIG_SETKEYCODES=y
CONFIG_SETLOGCONS=y

#
# Debian Utilities
#
CONFIG_MKTEMP=y
CONFIG_PIPE_PROGRESS=y
CONFIG_READLINK=y
CONFIG_FEATURE_READLINK_FOLLOW=y
CONFIG_RUN_PARTS=y
CONFIG_FEATURE_RUN_PARTS_LONG_OPTIONS=y
CONFIG_START_STOP_DAEMON=y
CONFIG_FEATURE_START_STOP_DAEMON_FANCY=y
CONFIG_FEATURE_START_STOP_DAEMON_LONG_OPTIONS=y
CONFIG_WHICH=y

#
# Editors
#
CONFIG_AWK=y
CONFIG_FEATURE_AWK_MATH=y
# CONFIG_ED is not set
CONFIG_PATCH=y
CONFIG_SED=y
CONFIG_VI=y
CONFIG_FEATURE_VI_COLON=y
CONFIG_FEATURE_VI_YANKMARK=y
CONFIG_FEATURE_VI_SEARCH=y
CONFIG_FEATURE_VI_USE_SIGNALS=y
CONFIG_FEATURE_VI_DOT_CMD=y
CONFIG_FEATURE_VI_READONLY=y
CONFIG_FEATURE_VI_SETOPTS=y
CONFIG_FEATURE_VI_SET=y
CONFIG_FEATURE_VI_WIN_RESIZE=y
CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
CONFIG_FEATURE_ALLOW_EXEC=y

#
# Finding Utilities
#
CONFIG_FIND=y
CONFIG_FEATURE_FIND_PRINT0=y
CONFIG_FEATURE_FIND_MTIME=y
CONFIG_FEATURE_FIND_MMIN=y
CONFIG_FEATURE_FIND_PERM=y
CONFIG_FEATURE_FIND_TYPE=y
CONFIG_FEATURE_FIND_XDEV=y
CONFIG_FEATURE_FIND_NEWER=y
CONFIG_FEATURE_FIND_INUM=y
CONFIG_FEATURE_FIND_EXEC=y
CONFIG_FEATURE_FIND_USER=y
CONFIG_FEATURE_FIND_NOT=y
CONFIG_GREP=y
CONFIG_FEATURE_GREP_EGREP_ALIAS=y
CONFIG_FEATURE_GREP_FGREP_ALIAS=y
CONFIG_FEATURE_GREP_CONTEXT=y
CONFIG_XARGS=y
CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION=y
CONFIG_FEATURE_XARGS_SUPPORT_QUOTES=y
CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT=y
CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM=y

#
# Init Utilities
#
CONFIG_INIT=y
# CONFIG_DEBUG_INIT is not set
CONFIG_FEATURE_USE_INITTAB=y
CONFIG_FEATURE_INIT_SCTTY=y
CONFIG_FEATURE_EXTRA_QUIET=y
# CONFIG_FEATURE_INIT_COREDUMPS is not set
CONFIG_FEATURE_INITRD=y
CONFIG_HALT=y
CONFIG_MESG=y

#
# Login/Password Management Utilities
#
CONFIG_FEATURE_SHADOWPASSWDS=y
CONFIG_USE_BB_SHADOW=y
CONFIG_USE_BB_PWD_GRP=y
CONFIG_ADDGROUP=y
CONFIG_DELGROUP=y
CONFIG_ADDUSER=y
CONFIG_DELUSER=y
CONFIG_GETTY=y
CONFIG_FEATURE_UTMP=y
CONFIG_FEATURE_WTMP=y
CONFIG_LOGIN=y
CONFIG_LOGIN_SCRIPTS=y
CONFIG_FEATURE_SECURETTY=y
CONFIG_PASSWD=y
CONFIG_FEATURE_PASSWD_WEAK_CHECK=y
CONFIG_SU=y
CONFIG_FEATURE_SU_SYSLOG=y
CONFIG_FEATURE_SU_CHECKS_SHELLS=y
# CONFIG_SULOGIN is not set
CONFIG_VLOCK=y

#
# Linux Ext2 FS Progs
#
# CONFIG_CHATTR is not set
# CONFIG_FSCK is not set
# CONFIG_LSATTR is not set

#
# Linux Module Utilities
#
CONFIG_INSMOD=y
# CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set
# CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS is not set
# CONFIG_FEATURE_INSMOD_LOADINKMEM is not set
# CONFIG_FEATURE_INSMOD_LOAD_MAP is not set
# CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set
CONFIG_RMMOD=y
CONFIG_LSMOD=y
CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT=y
CONFIG_MODPROBE=y
CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS=y
CONFIG_FEATURE_MODPROBE_FANCY_ALIAS=y

#
# Options common to multiple modutils
#
CONFIG_FEATURE_CHECK_TAINTED_MODULE=y
# CONFIG_FEATURE_2_4_MODULES is not set
CONFIG_FEATURE_2_6_MODULES=y
# CONFIG_FEATURE_QUERY_MODULE_INTERFACE is not set

#
# Linux System Utilities
#
CONFIG_DMESG=y
CONFIG_FEATURE_DMESG_PRETTY=y
CONFIG_FBSET=y
CONFIG_FEATURE_FBSET_FANCY=y
CONFIG_FEATURE_FBSET_READMODE=y
CONFIG_FDFLUSH=y
CONFIG_FDFORMAT=y
CONFIG_FDISK=y
CONFIG_FDISK_SUPPORT_LARGE_DISKS=y
CONFIG_FEATURE_FDISK_WRITABLE=y
CONFIG_FEATURE_AIX_LABEL=y
CONFIG_FEATURE_SGI_LABEL=y
CONFIG_FEATURE_SUN_LABEL=y
CONFIG_FEATURE_OSF_LABEL=y
CONFIG_FEATURE_FDISK_ADVANCED=y
CONFIG_FREERAMDISK=y
# CONFIG_FSCK_MINIX is not set
# CONFIG_MKFS_MINIX is not set
# CONFIG_FEATURE_MINIX2 is not set
CONFIG_GETOPT=y
CONFIG_HEXDUMP=y
CONFIG_HWCLOCK=y
# CONFIG_FEATURE_HWCLOCK_LONG_OPTIONS is not set
CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y
CONFIG_IPCRM=y
CONFIG_IPCS=y
CONFIG_LOSETUP=y
CONFIG_MDEV=y
CONFIG_FEATURE_MDEV_CONF=y
CONFIG_FEATURE_MDEV_EXEC=y
CONFIG_MKSWAP=y
# CONFIG_FEATURE_MKSWAP_V0 is not set
CONFIG_MORE=y
CONFIG_FEATURE_USE_TERMIOS=y
CONFIG_MOUNT=y
CONFIG_FEATURE_MOUNT_NFS=y
CONFIG_FEATURE_MOUNT_CIFS=y
CONFIG_FEATURE_MOUNT_FLAGS=y
CONFIG_FEATURE_MOUNT_FSTAB=y
# CONFIG_PIVOT_ROOT is not set
CONFIG_RDATE=y
CONFIG_READPROFILE=y
# CONFIG_SETARCH is not set
CONFIG_SWAPONOFF=y
# CONFIG_SWITCH_ROOT is not set
CONFIG_UMOUNT=y
CONFIG_FEATURE_UMOUNT_ALL=y

#
# Common options for mount/umount
#
CONFIG_FEATURE_MOUNT_LOOP=y
# CONFIG_FEATURE_MTAB_SUPPORT is not set

#
# Miscellaneous Utilities
#
CONFIG_ADJTIMEX=y
CONFIG_BBCONFIG=y
CONFIG_CROND=y
# CONFIG_DEBUG_CROND_OPTION is not set
CONFIG_FEATURE_CROND_CALL_SENDMAIL=y
CONFIG_CRONTAB=y
CONFIG_DC=y
# CONFIG_DEVFSD is not set
# CONFIG_DEVFSD_MODLOAD is not set
# CONFIG_DEVFSD_FG_NP is not set
# CONFIG_DEVFSD_VERBOSE is not set
# CONFIG_FEATURE_DEVFS is not set
CONFIG_EJECT=y
CONFIG_LAST=y
CONFIG_LESS=y
CONFIG_FEATURE_LESS_MAXLINES=9999999
CONFIG_FEATURE_LESS_BRACKETS=y
CONFIG_FEATURE_LESS_FLAGS=y
CONFIG_FEATURE_LESS_FLAGCS=y
CONFIG_FEATURE_LESS_MARKS=y
CONFIG_FEATURE_LESS_REGEXP=y
# CONFIG_HDPARM is not set
# CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set
# CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set
# CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set
CONFIG_MAKEDEVS=y
# CONFIG_FEATURE_MAKEDEVS_LEAF is not set
CONFIG_FEATURE_MAKEDEVS_TABLE=y
CONFIG_MOUNTPOINT=y
CONFIG_MT=y
CONFIG_NMETER=y
CONFIG_RAIDAUTORUN=y
CONFIG_READAHEAD=y
CONFIG_RUNLEVEL=y
CONFIG_RX=y
CONFIG_STRINGS=y
CONFIG_SETSID=y
# CONFIG_TASKSET is not set
# CONFIG_FEATURE_TASKSET_FANCY is not set
CONFIG_TIME=y
CONFIG_WATCHDOG=y

#
# Networking Utilities
#
CONFIG_FEATURE_IPV6=y
CONFIG_ARP=y
CONFIG_ARPING=y
# CONFIG_DNSD is not set
CONFIG_ETHER_WAKE=y
CONFIG_FAKEIDENTD=y
# CONFIG_FTPGET is not set
# CONFIG_FTPPUT is not set
# CONFIG_FEATURE_FTPGETPUT_LONG_OPTIONS is not set
CONFIG_HOSTNAME=y
CONFIG_HTTPD=y
# CONFIG_FEATURE_HTTPD_RELOAD_CONFIG_SIGHUP is not set
CONFIG_FEATURE_HTTPD_SETUID=y
CONFIG_FEATURE_HTTPD_BASIC_AUTH=y
CONFIG_FEATURE_HTTPD_AUTH_MD5=y
CONFIG_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES=y
CONFIG_FEATURE_HTTPD_CGI=y
CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR=y
CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV=y
CONFIG_FEATURE_HTTPD_ENCODE_URL_STR=y
CONFIG_IFCONFIG=y
CONFIG_FEATURE_IFCONFIG_STATUS=y
CONFIG_FEATURE_IFCONFIG_SLIP=y
CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ=y
CONFIG_FEATURE_IFCONFIG_HW=y
CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS=y
CONFIG_IFUPDOWN=y
CONFIG_FEATURE_IFUPDOWN_IP=y
CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN=y
# CONFIG_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN is not set
CONFIG_FEATURE_IFUPDOWN_IPV4=y
CONFIG_FEATURE_IFUPDOWN_IPV6=y
# CONFIG_FEATURE_IFUPDOWN_IPX is not set
# CONFIG_FEATURE_IFUPDOWN_MAPPING is not set
CONFIG_INETD=y
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN is not set
# CONFIG_FEATURE_INETD_RPC is not set
CONFIG_IP=y
CONFIG_FEATURE_IP_ADDRESS=y
CONFIG_FEATURE_IP_LINK=y
CONFIG_FEATURE_IP_ROUTE=y
CONFIG_FEATURE_IP_TUNNEL=y
CONFIG_FEATURE_IP_RULE=y
CONFIG_FEATURE_IP_SHORT_FORMS=y
CONFIG_IPADDR=y
CONFIG_IPLINK=y
CONFIG_IPROUTE=y
CONFIG_IPTUNNEL=y
CONFIG_IPRULE=y
CONFIG_IPCALC=y
CONFIG_FEATURE_IPCALC_FANCY=y
# CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set
CONFIG_NAMEIF=y
CONFIG_NC=y
CONFIG_NC_SERVER=y
CONFIG_NC_EXTRA=y
CONFIG_NETSTAT=y
CONFIG_NSLOOKUP=y
CONFIG_PING=y
CONFIG_FEATURE_FANCY_PING=y
CONFIG_PING6=y
CONFIG_FEATURE_FANCY_PING6=y
CONFIG_ROUTE=y
CONFIG_TELNET=y
CONFIG_FEATURE_TELNET_TTYPE=y
CONFIG_FEATURE_TELNET_AUTOLOGIN=y
# CONFIG_TELNETD is not set
# CONFIG_FEATURE_TELNETD_STANDALONE is not set
# CONFIG_TFTP is not set
# CONFIG_FEATURE_TFTP_GET is not set
# CONFIG_FEATURE_TFTP_PUT is not set
# CONFIG_FEATURE_TFTP_BLOCKSIZE is not set
# CONFIG_DEBUG_TFTP is not set
CONFIG_TRACEROUTE=y
CONFIG_FEATURE_TRACEROUTE_VERBOSE=y
CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE=y
CONFIG_FEATURE_TRACEROUTE_USE_ICMP=y
CONFIG_APP_UDHCPD=y
CONFIG_APP_DHCPRELAY=y
CONFIG_APP_DUMPLEASES=y
CONFIG_APP_UDHCPC=y
CONFIG_FEATURE_UDHCP_SYSLOG=y
# CONFIG_FEATURE_UDHCP_DEBUG is not set
CONFIG_VCONFIG=y
CONFIG_WGET=y
CONFIG_FEATURE_WGET_STATUSBAR=y
CONFIG_FEATURE_WGET_AUTHENTICATION=y
CONFIG_FEATURE_WGET_IP6_LITERAL=y
# CONFIG_FEATURE_WGET_LONG_OPTIONS is not set
CONFIG_ZCIP=y

#
# Process Utilities
#
CONFIG_FREE=y
CONFIG_FUSER=y
CONFIG_KILL=y
CONFIG_KILLALL=y
CONFIG_KILLALL5=y
CONFIG_PIDOF=y
CONFIG_FEATURE_PIDOF_SINGLE=y
CONFIG_FEATURE_PIDOF_OMIT=y
CONFIG_PS=y
CONFIG_FEATURE_PS_WIDE=y
CONFIG_RENICE=y
CONFIG_BB_SYSCTL=y
CONFIG_TOP=y
CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE=y
CONFIG_UPTIME=y

#
# Shells
#
CONFIG_FEATURE_SH_IS_ASH=y
# CONFIG_FEATURE_SH_IS_HUSH is not set
# CONFIG_FEATURE_SH_IS_LASH is not set
# CONFIG_FEATURE_SH_IS_MSH is not set
# CONFIG_FEATURE_SH_IS_NONE is not set
CONFIG_ASH=y

#
# Ash Shell Options
#
CONFIG_ASH_JOB_CONTROL=y
CONFIG_ASH_READ_NCHARS=y
CONFIG_ASH_READ_TIMEOUT=y
CONFIG_ASH_ALIAS=y
CONFIG_ASH_MATH_SUPPORT=y
CONFIG_ASH_MATH_SUPPORT_64=y
CONFIG_ASH_GETOPTS=y
CONFIG_ASH_BUILTIN_ECHO=y
CONFIG_ASH_BUILTIN_TEST=y
CONFIG_ASH_CMDCMD=y
CONFIG_ASH_MAIL=y
CONFIG_ASH_OPTIMIZE_FOR_SIZE=y
CONFIG_ASH_RANDOM_SUPPORT=y
CONFIG_ASH_EXPAND_PRMT=y
# CONFIG_HUSH is not set
# CONFIG_LASH is not set
# CONFIG_MSH is not set

#
# Bourne Shell Options
#
CONFIG_FEATURE_SH_EXTRA_QUIET=y
# CONFIG_FEATURE_SH_STANDALONE_SHELL is not set
CONFIG_FEATURE_COMMAND_EDITING=y
CONFIG_FEATURE_COMMAND_EDITING_VI=y
CONFIG_FEATURE_COMMAND_HISTORY=31
CONFIG_FEATURE_COMMAND_SAVEHISTORY=y
CONFIG_FEATURE_COMMAND_TAB_COMPLETION=y
CONFIG_FEATURE_COMMAND_USERNAME_COMPLETION=y
CONFIG_FEATURE_SH_FANCY_PROMPT=y

#
# System Logging Utilities
#
CONFIG_SYSLOGD=y
CONFIG_FEATURE_ROTATE_LOGFILE=y
CONFIG_FEATURE_REMOTE_LOG=y
CONFIG_FEATURE_IPC_SYSLOG=y
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16
CONFIG_LOGREAD=y
CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
CONFIG_KLOGD=y
CONFIG_LOGGER=y

#
# Runit Utilities
#
# CONFIG_RUNSV is not set
# CONFIG_RUNSVDIR is not set
# CONFIG_SV is not set
# CONFIG_SVLOGD is not set
# CONFIG_CHPST is not set
# CONFIG_SETUIDGID is not set
# CONFIG_ENVUIDGID is not set
# CONFIG_ENVDIR is not set
# CONFIG_SOFTLIMIT is not set

From rep.dot.nop at gmail.com  Thu Feb  8 00:15:57 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 8 Feb 2007 09:15:57 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702072325.20231.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
	<200702072325.20231.vda.linux@googlemail.com>
Message-ID: <20070208081557.GA5301@aon.at>

On Wed, Feb 07, 2007 at 11:25:20PM +0100, Denis Vlasenko wrote:
>On Wednesday 07 February 2007 23:19, Denis Vlasenko wrote:
>> Yet another question is why syslogd even bothers to do this
>> remove/recreate cycle? What will happen if it will just
>> bind to /dev/log? (the code will be smaller too)
>
>This is what will happen:
>
>./busybox syslogd -n -O zz_syslog
>syslogd: bind: Address already in use
>
>I like it. Do you? I mean, let's kill realpath'ing entirely!
>
>But don't forget to file uclibc bug report regarding realpath
>at http://bugs.uclibc.org/

IIRC there is already a proposed fix for this. Yep:
http://busybox.net/lists/uclibc/2007-February/017284.html

From marc.leeman at gmail.com  Thu Feb  8 01:09:39 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Thu, 8 Feb 2007 10:09:39 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702072319.04728.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207163507.GR15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
Message-ID: <20070208090939.GW15523@scorpius.homelinux.org>

> Maybe you should look into uclibc. Why it returned NULL?

I was planning to do so, but I just isolated and fixed the problem
around 18h, I'm going to see of something like that is already reported
in uclibc today.

> My manpage says:
> 
> RETURN VALUE
>        If there is no error, realpath() returns a pointer to the
>        resolved_path.
>        Otherwise  it  returns a NULL pointer, and the contents
>        of the array resolved_path are undefined. The global
>        variable errno is set to indicate the error.

I could not agree with you more on this: it really is uclibc that is not
following the manpage and I also noticed that the "resolved_path are
undefined" is not really something to cherish.

But the issue is that the re-write of syslogd triggered an underlying
problem in uclibc, making the current busybox not compatible with 0.9.28
based toolchains.

So the real question is: should busybox include a workaround for a,
hopefully, temporary problem in uclibc or not.

> Yet another question is why syslogd even bothers to do this
> remove/recreate cycle? What will happen if it will just
> bind to /dev/log? (the code will be smaller too)

Probably there is some reason that they did it like this in the past. It
could be that changing this breaks several crosscompilation
(buildroot/uclibc) systems. But this is just guessing on my part.

-- 
  greetz, marc
If he should ask for it, what body part are you willing to offer for
it, your Eminence?
	Pilot - DNA Mad Scientist
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://busybox.net/lists/busybox/attachments/20070208/b04eed92/attachment.pgp 

From natanael.copa at gmail.com  Thu Feb  8 01:28:20 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Thu, 08 Feb 2007 10:28:20 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <200702072226.49159.vda.linux@googlemail.com>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
Message-ID: <1170926900.14212.23.camel@localhost>

On Wed, 2007-02-07 at 22:26 +0100, Denis Vlasenko wrote:
> On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.

more info, from gdb:

al-1.5 busybox-1.4.1 # gdb ./busybox_unstripped
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-gentoo-linux-uclibc"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set args wget http://
(gdb) run
Starting program: /var/tmp/portage/busybox-1.4.1-r1/work/busybox-1.4.1/busybox_unstripped wget http://
warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4

Program received signal SIGSEGV, Segmentation fault.
bb_get_last_path_component (path=0x811074d "")
    at libbb/get_last_path_component.c:29
29              last[1] = 0;
(gdb) bt
#0  bb_get_last_path_component (path=0x811074d "")
    at libbb/get_last_path_component.c:29
#1  0x08096d39 in wget_main (argc=2, argv=0x810649d) at networking/wget.c:193
#2  0x080484ad in run_applet_by_name (name=0x8116a28 "F\035\017\b?k\t\b\003", 
    argc=134514459, argv=0xffab2c98) at applets/applets.c:489
#3  0x0804871b in busybox_main (argc=3, argv=0xffab2c94)
    at applets/busybox.c:143
#4  0x08048415 in run_applet_by_name (name=0xffab3b49 "busybox_unstripped", 
    argc=134513955, argv=0xffab2c94) at applets/applets.c:480
#5  0x08048523 in main (argc=-5559148, argv=0xffab2c94) at applets/busybox.c:72
(gdb) 




From natanael.copa at gmail.com  Thu Feb  8 02:18:58 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Thu, 08 Feb 2007 11:18:58 +0100
Subject: [RESOLVED] Re: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <200702072226.49159.vda.linux@googlemail.com>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
Message-ID: <1170929938.14212.37.camel@localhost>

On Wed, 2007-02-07 at 22:26 +0100, Denis Vlasenko wrote:
> On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.

Here is the explanation:

When url is "http://a/b" evertyhing works. When url is "http://a" then
the following happens:

parse_url sets target.path = ""

later, when guessing the out file name

 fname_out = bb_get_last_path_component(target.path);

bb_get_last_path_component() will write to target.path.

Looks like its fixed in svn. Would be nice to have it fixed for 1.4.2.

Attached is a patch for 1.4.1.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bb-wget-path.patch
Type: text/x-patch
Size: 457 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/3fe517bc/attachment.bin 

From vda.linux at googlemail.com  Thu Feb  8 11:12:38 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 20:12:38 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070208090939.GW15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
	<20070208090939.GW15523@scorpius.homelinux.org>
Message-ID: <200702082012.38814.vda.linux@googlemail.com>

On Thursday 08 February 2007 10:09, Marc Leeman wrote:
> > Yet another question is why syslogd even bothers to do this
> > remove/recreate cycle? What will happen if it will just
> > bind to /dev/log? (the code will be smaller too)
> 
> Probably there is some reason that they did it like this in the past. It
> could be that changing this breaks several crosscompilation
> (buildroot/uclibc) systems. But this is just guessing on my part.

I tried. /dev/log is created by bind() of AF_UNIX.
If it exists, bind() will fail, even if no other process did bind().
That's why removing /dev/log is really needed.
--
vda

From ynakam at hitachisoft.jp  Wed Feb  7 22:54:48 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:48 +0900
Subject: [PATCH 5/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155448.961743fb.ynakam@hitachisoft.jp>


[5/6]  busybox-coreutils-05-ls.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-ls-05.patch
Type: application/octet-stream
Size: 592 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/f6149c3e/attachment-0001.obj 

From ynakam at hitachisoft.jp  Wed Feb  7 22:54:17 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:17 +0900
Subject: [PATCH 0/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155417.8d62937f.ynakam@hitachisoft.jp>

Hi.

The following patches provide SELinux options(like -Z) to coreutils 
We imported SELinux options from coreutils 5.97(included in Fedora Core6).
You have to enable CONFIG_SELINUX to use following feature.
Any of them are fundamental one to use SELinux.
We are welcoming any comment, and hope to merge it into busybox.


[1/6] busybox-coreutils-common-01.patch
 - usage.h for SELinux options

[2/6] busybox-coreutils-02-copy.patch
  - cp: -Z,-c option support. 
      -c option: security context is preserved during file copy.
      -Z option: security context can be set during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.

[3/6] busybox-coreutils-03-mk.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.

[4/6] busybox-coreutils-04-stat.patch
 - -Z option support for stat. Security context of file is shown by -Z option.

[5/6]  busybox-coreutils-05-ls.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.

[6/6] busybox-coreutils-06-id.patch
 - -Z option support for id. Security context of process is shown by -Z option.


This project is originated from some of JPSEUG(Japan SELinux User Group). 
Now, we are preparing to submit more patches to support SELinux commands/options.

Regards,

Yuichi Nakamura
Hitachi Software
SELinux Policy Editor: http://seedit.sourceforge.net/

From ynakam at hitachisoft.jp  Wed Feb  7 22:54:38 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:38 +0900
Subject: [PATCH 3/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>

[3/6] busybox-coreutils-03-mk.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.


Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-mk-03.patch
Type: application/octet-stream
Size: 2211 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/b4148715/attachment-0001.obj 

From ynakam at hitachisoft.jp  Wed Feb  7 22:54:56 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:56 +0900
Subject: [PATCH 6/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155456.2d016051.ynakam@hitachisoft.jp>

[6/6] busybox-coreutils-06-id.patch
 - -Z option support for id. Security context of process is shown by -Z option.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-id-06.patch
Type: application/octet-stream
Size: 2641 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/7813d8f6/attachment-0001.obj 

From ynakam at hitachisoft.jp  Wed Feb  7 22:54:26 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:26 +0900
Subject: [PATCH 1/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>


[1/6] busybox-coreutils-common-01.patch
 - usage.h for SELinux options

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.patch
Type: application/octet-stream
Size: 4206 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/282af443/attachment-0001.obj 

From ynakam at hitachisoft.jp  Wed Feb  7 22:54:32 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:32 +0900
Subject: [PATCH 2/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155432.e8234d84.ynakam@hitachisoft.jp>

[2/6] busybox-coreutils-02-copy.patch
  - cp: -Z,-c option support. 
      -c option: security context is preserved during file copy.
      -Z option: security context can be set during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.patch
Type: application/octet-stream
Size: 6414 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/96a1fb65/attachment-0001.obj 

From ynakam at hitachisoft.jp  Wed Feb  7 22:54:42 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:42 +0900
Subject: [PATCH 4/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155442.045b052b.ynakam@hitachisoft.jp>

[4/6] busybox-coreutils-04-stat.patch
 - -Z option support for stat. Security context of file is shown by -Z option.

Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-stat-04.patch
Type: application/octet-stream
Size: 10382 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/92c89f09/attachment-0001.obj 

From marc.leeman at gmail.com  Thu Feb  8 11:39:12 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Thu, 8 Feb 2007 20:39:12 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702082012.38814.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
	<20070208090939.GW15523@scorpius.homelinux.org>
	<200702082012.38814.vda.linux@googlemail.com>
Message-ID: <20070208193912.GC15523@scorpius.homelinux.org>

> I tried. /dev/log is created by bind() of AF_UNIX.

doh, on a RO fs?

> If it exists, bind() will fail, even if no other process did bind().
> That's why removing /dev/log is really needed.

No, /dev/ is not normally mounted on a rw filesystem (tmpfs). That's
probably why a symlink was used in the firsts place (to /tmp/log)


-- 
  greetz, marc
It's not Kansas, and you're way too homely to be Auntie Em, but... Come
here, Toto.
	Crichton - That Old Black Magic
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://busybox.net/lists/busybox/attachments/20070208/54949273/attachment.pgp 

From vda.linux at googlemail.com  Thu Feb  8 12:51:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 21:51:33 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070208193912.GC15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<200702082012.38814.vda.linux@googlemail.com>
	<20070208193912.GC15523@scorpius.homelinux.org>
Message-ID: <200702082151.33326.vda.linux@googlemail.com>

On Thursday 08 February 2007 20:39, Marc Leeman wrote:
> > I tried. /dev/log is created by bind() of AF_UNIX.
> 
> doh, on a RO fs?

It is indeed created with bind(), but on RO fs it fails.

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
int main(int argc, char **argv)
{
        struct sockaddr_un sunx;
        socklen_t addr_len;
        int sock_fd;
//      unlink(argv[1]);
        memset(&sunx, 0, sizeof(sunx));
        sunx.sun_family = AF_UNIX;
        strncpy(sunx.sun_path, argv[1], sizeof(sunx.sun_path));
        sock_fd = socket(AF_UNIX, SOCK_DGRAM, 0);
        if (sock_fd < 0) return 1;
        addr_len = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
        bind(sock_fd, (struct sockaddr *) &sunx, addr_len);
        return 0;
}

Testing by stracing "testprog /dev/log2"

...
socket(PF_FILE, SOCK_DGRAM, 0)          = 4
bind(4, {sa_family=AF_FILE, path="/dev/log2"}, 11) = 0
exit_group(0)

and also now I see /dev/log2 socket.

Running that again:

...
socket(PF_FILE, SOCK_DGRAM, 0)          = 4
bind(4, {sa_family=AF_FILE, path="/dev/log2"}, 11) = -1 EADDRINUSE (Address already in use)
exit_group(0)


On RO fs (my / in RO, so I just do "testprog /bin/log2")

socket(PF_FILE, SOCK_DGRAM, 0)          = 4
bind(4, {sa_family=AF_FILE, path="/bin/log2"}, 11) = -1 EROFS (Read-only file system)
exit_group(0)  


> > If it exists, bind() will fail, even if no other process did bind().
> > That's why removing /dev/log is really needed.
> 
> No, /dev/ is not normally mounted on a rw filesystem (tmpfs). That's
> probably why a symlink was used in the firsts place (to /tmp/log)

Of sourse you may want to symlink /dev/log, and that's exactly why syslogd
tries to resolve the symlink - it needs to remove the socket, or else
it won't be able to bind to it.
--
vda

From vda.linux at googlemail.com  Thu Feb  8 16:10:27 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 9 Feb 2007 01:10:27 +0100
Subject: file descriptors
In-Reply-To: <20061215233441.CD5014855E@busybox.net>
References: <20061215233441.CD5014855E@busybox.net>
Message-ID: <200702090110.27682.vda.linux@googlemail.com>

On Saturday 16 December 2006 00:26, Eric Perraud wrote:
> Hello,
> 
> My application, running on busy box, potentially needs more than 1024 file
> descriptors available to it.
> 
> I have tried "ulimit -n 2048" on the command line and also tried adding the
> same line to the end of /etc/profile.
> 
> Either way, doing a "ulimit -a" shows nofiles  2048, however my application
> is still no longer able to open a file descriptor once it reaches 1024
> (verified by doing a ls | wc -w in /proc/<pid>/fs).
> 
> Additionally, I have verifed that the entire system is not running out of
> fd's by examining the values in /proc/sys/fs/file-nr
> 
> Any ideas on how to raise the "per process " file descriptor limit would
> much appreciated.

Google said me that I maybe need:
echo 32768 > /proc/sys/fs/file-max
increases the system limit on open files, and
ulimit -n 32768
increases the current process' limit.

On yet another page I read about increasing
/proc/sys/fs/inode-nr
too

I suggest you use Google too.
--
vda

From carl at matrixstream.com  Thu Feb  8 13:42:05 2007
From: carl at matrixstream.com (Carl Stewart)
Date: Thu, 8 Feb 2007 13:42:05 -0800
Subject: busybox 1.4.1 and rules.mak
Message-ID: <FDEIKJLBDHGMFFMHEKPGIENPDPAA.carl@matrixstream.com>

In busybox 1.2.2.1 and earlier, it used the rules.mak file to compile it.
But the compiling process seems to have changed now and that makefile is no
longer their.  The reason I'm asking is because the embedded system's SDK,
which is uclinux based, references that rules.mak file when adding and
compiling busybox to the rootfs folder.  And I want to be able to use
busybox 1.4.1 instead of 1.2.2.1 because 1.4.1 has the ability to mount smb
shares.

Anyone know how to do this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070208/297755b0/attachment.html 

From vda.linux at googlemail.com  Thu Feb  8 14:29:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:29:37 +0100
Subject: [PATCH 1/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
References: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
Message-ID: <200702082329.37316.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> 
> [1/6] busybox-coreutils-common-01.patch
>  - usage.h for SELinux options
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>


@@ -1299,9 +1301,8 @@
 #define id_full_usage \
        "Print information for USERNAME or the current user" \
        "\n\nOptions:\n" \
-	USE_SELINUX( \
-       "	-c	Prints only the security context\n") \
-       "	-g	Prints only the group ID\n" \
+	   USAGE_SELINUX("	-Z	prints only the security context\n")	\
+	   "	-g	Prints only the group ID\n"						\

Well I can fix occasional problems but this is a bitt too much.
I would prefer more careful formatting, like:



        "	-u	Prints only the user ID\n" \
        "	-n	Print a name instead of a number\n" \
        "	-r	Prints the real user ID instead of the effective ID"
@@ -1519,7 +1520,9 @@
        "	-m	Set permission modes\n" \
        "	-o	Set ownership\n" \
        "	-p	Preserve date\n" \
-       "	-s	Strip symbol tables"
+       "    -s  Strip symbol tables\n" \
+	USAGE_SELINUX("	-P	preserve security context\n") \
+	USAGE_SELINUX("	Z	CONTEXT  set security context of copy to CONTEXT")
 
 #define ip_trivial_usage \
        "[OPTIONS] {address | link | route | tunnel | rule} {COMMAND}"
@@ -1829,7 +1832,9 @@
 	USE_SELINUX( \
        "\n	-k	Print security context") \
 	USE_SELINUX( \
-       "\n	-K	Print security context in long format")
+       "\n	-K	Print security context in long format") \
+	USE_SELINUX( \
+	"\n	-Z	Print security context and permission")
 
 #define lsattr_trivial_usage \
        "[-Radlv] [files...]"
@@ -1974,7 +1979,9 @@
        "Create the DIRECTORY(ies) if they do not already exist" \
        "\n\nOptions:\n" \
        "	-m	Set permission mode (as in chmod), not rwxrwxrwx - umask\n" \
-       "	-p	No error if existing, make parent directories as needed"
+       "	-p	No error if existing, make parent directories as needed\n"	\
+       USAGE_SELINUX("	-Z	set security context")
+
 #define mkdir_example_usage \
        "$ mkdir /tmp/foo\n" \
        "$ mkdir /tmp/foo\n" \
@@ -2019,7 +2026,8 @@
 #define mkfifo_full_usage \
        "Create a named pipe (identical to 'mknod name p')" \
        "\n\nOptions:\n" \
-       "	-m	Create the pipe using the specified mode (default a=rw)"
+       "	-m	Create the pipe using the specified mode (default a=rw)\n" \
+	USAGE_SELINUX("	-Z	set security context")
 
 #define mkfs_minix_trivial_usage \
        "[-c | -l filename] [-nXX] [-iXX] /dev/name [blocks]"
@@ -2041,7 +2049,9 @@
        "\n\nTYPEs include:\n" \
        "	b:	Make a block (buffered) device\n" \
        "	c or u:	Make a character (un-buffered) device\n" \
-       "	p:	Make a named pipe. MAJOR and MINOR are ignored for named pipes"
+       "	p:	Make a named pipe. MAJOR and MINOR are ignored for named pipes\n" \
+	USAGE_SELINUX("	-Z	set security context")
+
 #define mknod_example_usage \
        "$ mknod /dev/fd0 b 2 0\n" \
        "$ mknod -m 644 /tmp/pipe p\n"
@@ -2901,6 +2911,7 @@
        "	-f	Display filesystem status\n" \
        "	-L,-l	Dereference links\n" \
        "	-t	Display info in terse form" \
+	USAGE_SELINUX("	-Z	print security context\n") \
 	USE_FEATURE_STAT_FORMAT( \
        "\n\nValid format sequences for files:\n" \
        " %a	Access rights in octal\n" \
@@ -2935,6 +2946,7 @@
        " %c	Total file nodes in file system\n" \
        " %d	Free file nodes in file system\n" \
        " %f	Free blocks in file system\n" \
+	USAGE_SELINUX("	%C	Security context in SELinux\n")	\
        " %i	File System ID in hex\n" \
        " %l	Maximum length of filenames\n" \
        " %n	File name\n" \

From vda.linux at googlemail.com  Thu Feb  8 14:32:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:32:43 +0100
Subject: [PATCH 1/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
References: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
Message-ID: <200702082332.43175.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> 
> [1/6] busybox-coreutils-common-01.patch
>  - usage.h for SELinux options
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>


@@ -1299,9 +1301,8 @@
 #define id_full_usage \
        "Print information for USERNAME or the current user" \
        "\n\nOptions:\n" \
-	USE_SELINUX( \
-       "	-c	Prints only the security context\n") \
-       "	-g	Prints only the group ID\n" \
+	   USAGE_SELINUX("	-Z	prints only the security context\n")	\
+	   "	-g	Prints only the group ID\n"						\

Well I can fix occasional problems but this is a bitt too much.
I would prefer more careful formatting, like

	USAGE_SELINUX( \
       "	-Z	prints only the security context\n" \
	) \
       "	-g	Prints only the group ID\n" \

This helps to avoid misformatting in help texts.

The rest of this patch needs similar reformatting.
--
vda

From vda.linux at googlemail.com  Thu Feb  8 14:49:08 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:49:08 +0100
Subject: [PATCH 2/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155432.e8234d84.ynakam@hitachisoft.jp>
References: <20070208155432.e8234d84.ynakam@hitachisoft.jp>
Message-ID: <200702082349.08804.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> [2/6] busybox-coreutils-02-copy.patch
>   - cp: -Z,-c option support. 
>       -c option: security context is preserved during file copy.
>       -Z option: security context can be set during file copy.
>   - mv 
>     In SELinux, it is recommended to preserve security context 
>     when file is moved. By this patch, file context is preserved 
>     during file move.
>   - install
>     When file is copied by install, security context of installed file 
>     becomes different from value configured in file_contexts file.
>     By this patch, security context is set according to file_contexts file.
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>


Index: include/libbb.h
===================================================================
--- include/libbb.h	(revision 17803)
+++ include/libbb.h	(working copy)
@@ -743,9 +743,15 @@
 	FILEUTILS_INTERACTIVE = 0x10,
 	FILEUTILS_MAKE_HARDLINK = 0x20,
 	FILEUTILS_MAKE_SOFTLINK = 0x40,
+#if ENABLE_SELINUX
+	FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
+	FILEUTILS_SET_SECURITY_CONTEXT = 0x100
+#endif
+
 };

This empty line after #endif - why?

+#if ENABLE_SELINUX 
+	if (flags & FILEUTILS_SET_SECURITY_CONTEXT) {
+		if(is_selinux_enabled() == 0) {
+			fprintf( stderr, "Warning:  ignoring --context (-Z). "
+					 "It requires a SELinux enabled kernel.\n" );
+		}else{
+			if ( setfscreatecon(context_str) < 0 ) {
+				bb_error_msg_and_die("cannot set default security context %s\n", context_str);
+			}
+		}
+	}
+#endif

The style is not consistent. Should be "if ()", "} else {".
"Warning:  ignoring" has extra space for no reason.
fprintf(stderr) can be probably replaced by bb_error_msg:
bb_error_msg("warning: ignoring --context (-Z), it requires a SELinux enabled kernel");


+static int use_default_selinux_context = 1;

You never change it, it is always 1.  - ?!
--
vda

From vda.linux at googlemail.com  Thu Feb  8 14:53:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:53:43 +0100
Subject: [PATCH 3/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>
References: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>
Message-ID: <200702082353.43667.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> [3/6] busybox-coreutils-03-mk.patch
>  - -Z option support for mkdir, mkfifo, mknod. 
>     By -Z, security context for created file can be set.
> 
> Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>


+#if ENABLE_SELINUX
+	security_context_t scontext = NULL;
+#endif
 
 #if ENABLE_FEATURE_MKDIR_LONG_OPTIONS
 	applet_long_options = mkdir_long_options;
 #endif
-	opt = getopt32(argc, argv, "m:p", &smode);
+	opt = getopt32(argc, argv, "m:p" USE_SELINUX("Z:"), &smode USE_SELINUX(,&scontext));
 	if (opt & 1) {
 		mode = 0777;
 		if (!bb_parse_mode(smode, &mode)) {
@@ -50,6 +61,15 @@
 	}
 	if (opt & 2)
 		flags |= FILEUTILS_RECUR;
+#if ENABLE_SELINUX
+	if(opt & 4) {
+		selinux_or_die();
+		if (setfscreatecon(scontext)) {
+			bb_error_msg_and_die ("Sorry, cannot set default context "
+					      "to %s.\n", scontext);

Initializing scontext to NULL is useless code. bb_error_msg_and_die
has useless "Sorry" (with wrong capitalization: "mkdir: Sorry...")
and useless ".\n" at the end.

Sorry guys, I would be really happy if these patches get
a little bit prettier...
--
vda

From education.sina at gmail.com  Thu Feb  8 18:04:23 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Fri, 9 Feb 2007 11:04:23 +0900
Subject: Busybox compilation error(for ARM CPU)
Message-ID: <1ff320400702081804x750ce909na2f0ec26f3e85ea@mail.gmail.com>

Hello ,

I am trying to compile busy box for ARM CPU....
Busybox version is 1.4.0...
I am fecing this problem when i am trying to run this command
#make ARCH=arm CROSS_COMPILE=/cross/arm-unknown-linux-gnu-
I am geting this error at the end....
 LINK    busybox_unstripped
applets/built-in.o:(.rodata.applets+0x664): undefined reference to
`readahead_main'
applets/built-in.o:(.rodata.applets+0x868): undefined reference to
`taskset_main'
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1

I am attaching my config with this email...

If anybody knows about this problem please help  me out ....

Thanks
Sina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070209/b8cf9225/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busyconfig
Type: application/octet-stream
Size: 15741 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070209/b8cf9225/attachment-0001.obj 

From ddaney at avtrex.com  Thu Feb  8 18:04:31 2007
From: ddaney at avtrex.com (David Daney)
Date: Thu, 08 Feb 2007 18:04:31 -0800
Subject: Detecting link state in dhcpc...
Message-ID: <45CBD6AF.7060407@avtrex.com>

I recall reading on the list recently that someone was thinking about 
modifying dhcpc to do nice things when the link state changes.

Has this been done?

If not, I think I will be doing it very soon.

David Daney

From vapier at gentoo.org  Thu Feb  8 20:56:51 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 8 Feb 2007 23:56:51 -0500
Subject: busybox 1.4.1 and rules.mak
In-Reply-To: <FDEIKJLBDHGMFFMHEKPGIENPDPAA.carl@matrixstream.com>
References: <FDEIKJLBDHGMFFMHEKPGIENPDPAA.carl@matrixstream.com>
Message-ID: <200702082356.52557.vapier@gentoo.org>

On Thursday 08 February 2007, Carl Stewart wrote:
> In busybox 1.2.2.1 and earlier, it used the rules.mak file to compile it.
> But the compiling process seems to have changed now and that makefile is no
> longer their.  The reason I'm asking is because the embedded system's SDK,
> which is uclinux based, references that rules.mak file when adding and
> compiling busybox to the rootfs folder.  And I want to be able to use
> busybox 1.4.1 instead of 1.2.2.1 because 1.4.1 has the ability to mount smb
> shares.
>
> Anyone know how to do this?

what's wrong with `$(MAKE) -C busybox` ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070208/ba9a649f/attachment.pgp 

From marc.leeman at gmail.com  Fri Feb  9 00:36:05 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Fri, 9 Feb 2007 09:36:05 +0100
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702090021.35590.vapier@gentoo.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702081409.43111.vapier@gentoo.org>
	<20070208193704.GB15523@scorpius.homelinux.org>
	<200702090021.35590.vapier@gentoo.org>
Message-ID: <20070209083605.GF15523@scorpius.homelinux.org>

Cc to busybox ML.

> > > could you be more specific as to what is breaking ?  "syslogd breaks on
> > > read only filesystems" does not translate well into actual test cases for
> > > inclusion into uClibc testsuite ...
> >
> > cf. busybox discussion of yesterday:
> >
> > http://www.busybox.net/lists/busybox/2007-February/026252.html
> 
> ok, looking again and i see your setup is:
>  - /dev is mounted RO
>  - /tmp is mounted RW
>  - /dev/log is a symlink to ../tmp/log
> 
> busybox launches sysklogd which does:
>  - dev_log_name >  - unlink(dev_log_name)
> 
> on your system, dev_log_name should be resolving to /tmp/log but it seems to 
> return NULL ... on my system, it works:
> # ls -l /dev/log /tmp/log 
> lrwxrwxrwx 1 root root 10 2007-02-08 23:58 /dev/log -> ../tmp/log
> -rw-r--r-- 1 root root  0 2007-02-08 23:58 /tmp/log
> # ./busybox syslogd -n
> running xmalloc_realpath(/dev/log)
> got back /tmp/log
> dev_log_name is now /tmp/log
> unlinking(/tmp/log)
> exiting now
> # ./busybox syslogd -n
> running xmalloc_realpath(/dev/log)
> got back (null)
> dev_log_name is now /dev/log
> unlinking(/dev/log)
> exiting now
> 
> this behavior is correct ... since /tmp/log was removed in the first run, the 
> second run should actually return NULL ...

The system is using an empty /tmp fs (tmpfs), so the socket or any other
file is not present in /tmp when xmallok_realpath("/dev/log") is called.

The old syslogd implementation correctly de-referenced the pointer in
/dev/log to /tmp/log and created a /tmp/log socket. the new syslogd
implementation tries to delete /dev/log on the RO filesystem and tries
to create the log socket there, what obviously fails on a RO fs.

So since uclibc's implementation of realpath matches glibc's; we should
re-store the relevant parts of the older syslogd code again instead of
fixing it in xmalloc_realpath()?

-- 
  greetz, marc
My dear, I've kicked more ass than you've sat on.
	Zhaan - Through the Looking Glass
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://busybox.net/lists/busybox/attachments/20070209/e3e8d3ed/attachment.pgp 

From develop at cle-mens.de  Fri Feb  9 08:15:18 2007
From: develop at cle-mens.de (Dirk Clemens)
Date: Fri, 09 Feb 2007 17:15:18 +0100
Subject: Bug in bb 1.3.1, httpd with POST
Message-ID: <45CC9E16.9010407@cle-mens.de>

I thing I have found a post bug in busybosy 1.3.1/mips.

If I want to take the POST input from stdin,
I get the following error message:

.../cgi-bin/test: line 3: read: read error: 0: Bad file descriptor

I will get this message in all cgi scripts and also if I do simply:
cat >/tmp/out

The vars REQUEST_METHOD and CONTENT_LENGTH are correct.

Dirk

From parmarsatpal at gmail.com  Fri Feb  9 08:56:38 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Fri, 9 Feb 2007 22:26:38 +0530
Subject: udhcp client not working
Message-ID: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>

Hi all;

   I am trying to make udchpc (UDHCP clinet from busybox) work on my kernel
(linux 2.6.11.12, linux 2.6.18 and linux 2.6.19 ).
 poted on arm9 board.I am getting following output


/ # udhcpc
udhcpc (v1.2.0-svn) started
eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:37

Sending discover...
Sending discover...
Sending discover...
eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:37

NETDEV WATCHDOG: eth0: transmit timed out
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

I have a linux machine which works as dhcp server at ip adress
192.168.0.1and I am able to concet to another windows machine with
adress
192.168.0.20

Tcpdump on linux machine reflect no packet received from board.

my dmesg log:

 139too Fast Ethernet driver 0.9.28
PCI: enabling device 0000:00:0b.0 (0140 -> 0143)
eth0: RealTek RTL8139 at 0x44800000, 00:40:f4:39:6a:61, IRQ 37
eth0:  Identified 8139 chip type 'RTL-8139C'
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing init memory: 80K
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008003c. (queue head)
eth0:  Tx descriptor 1 is 0008003c.
eth0:  Tx descriptor 2 is 0008003c.
eth0:  Tx descriptor 3 is 0008003c.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008024e. (queue head)
eth0:  Tx descriptor 1 is 0008024e.
eth0:  Tx descriptor 2 is 0008024e.
eth0:  Tx descriptor 3 is 0008024e.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008024e. (queue head)
eth0:  Tx descriptor 1 is 0008024e.
eth0:  Tx descriptor 2 is 0008024e.
eth0:  Tx descriptor 3 is 0008024e.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008024e. (queue head)
eth0:  Tx descriptor 1 is 0008024e.
eth0:  Tx descriptor 2 is 0008024e.
eth0:  Tx descriptor 3 is 0008024e.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

I would also like to know what configuration in networking are MUST for dhcp
clinet to work.

Thanks in advance.

satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070209/8d88c43e/attachment.htm 

From rep.dot.nop at gmail.com  Fri Feb  9 09:18:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 18:18:21 +0100
Subject: udhcp client not working
In-Reply-To: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
References: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
Message-ID: <20070209171821.GS12488@aon.at>

On Fri, Feb 09, 2007 at 10:26:38PM +0530, satpal parmar wrote:
>Hi all;
>
>  I am trying to make udchpc (UDHCP clinet from busybox) work on my kernel

(1) Can you reproduce this with the current release? See
   http://busybox.net/
(2) Can you reproduce this with current trunk?
(3) does the HW and the driver work if you manually up the eth0 and ping
   some other host?

>(linux 2.6.11.12, linux 2.6.18 and linux 2.6.19 ).
>poted on arm9 board.I am getting following output
>
>
>/ # udhcpc
>udhcpc (v1.2.0-svn) started
>eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>         collisions:0 txqueuelen:1000
>         RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>         Interrupt:37
>
>Sending discover...
>Sending discover...
>Sending discover...
>eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>         collisions:0 txqueuelen:1000
>         RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>         Interrupt:37

grep eth /proc/interrupts if you happen to have /proc support in your
kernel. Short of that verify that your HW works as suggested in (3)

If no irq fires off, then drop the busybox list off.

HTH,
Bernhard

From ynakam at hitachisoft.jp  Thu Feb  8 23:44:09 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 16:44:09 +0900
Subject: [PATCH 0/6] busybox -- SELinux option support for coreutils
In-Reply-To: <1170941165.11912.208.camel@moss-spartans.epoch.ncsc.mil>
References: <20070208155417.8d62937f.ynakam@hitachisoft.jp>
	<1170941165.11912.208.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <20070209164409.3b302e35.ynakam@hitachisoft.jp>


On Thu, 08 Feb 2007 08:26:04 -0500
Stephen Smalley wrote:
> On Thu, 2007-02-08 at 15:54 +0900, Yuichi Nakamura wrote:
> > Hi.
> > 
> > The following patches provide SELinux options(like -Z) to coreutils 
> > We imported SELinux options from coreutils 5.97(included in Fedora Core6).
> > You have to enable CONFIG_SELINUX to use following feature.
> > Any of them are fundamental one to use SELinux.
> > We are welcoming any comment, and hope to merge it into busybox.
> 
> I'd suggest looking at the upstream coreutils selinux branch (see Jim
> Meyering's prior announcement of it on selinux list) and make sure you
> are consistent with it rather than Fedora Core 6, as I believe some
> aspects have changed (e.g. cp -a handling).
Thanks for information.
I've looked at upstream coreutils, and found some changes in cp and install.
I will fix them later.

> 
> > 
> > 
> > [1/6] busybox-coreutils-common-01.patch
> >  - usage.h for SELinux options
> > 
> > [2/6] busybox-coreutils-02-copy.patch
> >   - cp: -Z,-c option support. 
> >       -c option: security context is preserved during file copy.
> >       -Z option: security context can be set during file copy.
> >   - mv 
> >     In SELinux, it is recommended to preserve security context 
> >     when file is moved. By this patch, file context is preserved 
> >     during file move.
> >   - install
> >     When file is copied by install, security context of installed file 
> >     becomes different from value configured in file_contexts file.
> >     By this patch, security context is set according to file_contexts file.
> > 
> > [3/6] busybox-coreutils-03-mk.patch
> >  - -Z option support for mkdir, mkfifo, mknod. 
> >     By -Z, security context for created file can be set.
> > 
> > [4/6] busybox-coreutils-04-stat.patch
> >  - -Z option support for stat. Security context of file is shown by -Z option.
> > 
> > [5/6]  busybox-coreutils-05-ls.patch
> >  - -Z option support for ls. Security context of file is shown by -Z option.
> >    In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.
> > 
> > [6/6] busybox-coreutils-06-id.patch
> >  - -Z option support for id. Security context of process is shown by -Z option.
> > 
> > 
> > This project is originated from some of JPSEUG(Japan SELinux User Group). 
> > Now, we are preparing to submit more patches to support SELinux commands/options.
> > 
> > Regards,
> > 
> > Yuichi Nakamura
> > Hitachi Software
> > SELinux Policy Editor: http://seedit.sourceforge.net/
> > 
> > --
> > This message was distributed to subscribers of the selinux mailing list.
> > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with
> > the words "unsubscribe selinux" without quotes as the message.
> -- 
> Stephen Smalley
> National Security Agency
> 

From ynakam at hitachisoft.jp  Fri Feb  9 01:47:41 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 18:47:41 +0900
Subject: [busybox:00365] Re: [PATCH 1/6] busybox -- SELinux option
	support for coreutils
In-Reply-To: <200702082332.43175.vda.linux@googlemail.com>
References: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
	<200702082332.43175.vda.linux@googlemail.com>
Message-ID: <20070209184741.dcbef9a9.ynakam@hitachisoft.jp>

Thank you for comments.

On Thu, 8 Feb 2007 23:32:43 +0100
Denis Vlasenko  wrote:
> On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> > 
> > [1/6] busybox-coreutils-common-01.patch
> >  - usage.h for SELinux options
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> 
> @@ -1299,9 +1301,8 @@
>  #define id_full_usage \
>         "Print information for USERNAME or the current user" \
>         "\n\nOptions:\n" \
> -	USE_SELINUX( \
> -       "	-c	Prints only the security context\n") \
> -       "	-g	Prints only the group ID\n" \
> +	   USAGE_SELINUX("	-Z	prints only the security context\n")	\
> +	   "	-g	Prints only the group ID\n"						\
> 
> Well I can fix occasional problems but this is a bitt too much.
> I would prefer more careful formatting, like
> 
> 	USAGE_SELINUX( \
>        "	-Z	prints only the security context\n" \
> 	) \
>        "	-g	Prints only the group ID\n" \
> 
> This helps to avoid misformatting in help texts.
> 
> The rest of this patch needs similar reformatting.
Fixed.

> --
> vda
> 

We were porting SELinux option based on coreutils in Fedora Core6, 
but Stephen recommended to check upstream coreutils.
So I have checked upstream coreutils and found some SELinux option has been changed.
I have changed following:
* Removed -Z option from cp
* Added -Z and --preserve-context option to install

About cp,  -c option is dropped in upstream and "--preserve=context" is used instead.
However, cp in BusyBox does not have long options, so our patch still has -c option.

Yuichi Nakamura


-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v2.patch
Type: application/octet-stream
Size: 4171 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070209/89431eb2/attachment-0001.obj 

From ynakam at hitachisoft.jp  Fri Feb  9 01:48:17 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 18:48:17 +0900
Subject: [busybox:00366] Re: [PATCH 2/6] busybox -- SELinux option
	support for coreutils
In-Reply-To: <200702082349.08804.vda.linux@googlemail.com>
References: <20070208155432.e8234d84.ynakam@hitachisoft.jp>
	<200702082349.08804.vda.linux@googlemail.com>
Message-ID: <20070209184817.3384ed07.ynakam@hitachisoft.jp>

On Thu, 8 Feb 2007 23:49:08 +0100
Denis Vlasenko wrote:
> On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> > [2/6] busybox-coreutils-02-copy.patch
> >   - cp: -Z,-c option support. 
> >       -c option: security context is preserved during file copy.
> >       -Z option: security context can be set during file copy.
> >   - mv 
> >     In SELinux, it is recommended to preserve security context 
> >     when file is moved. By this patch, file context is preserved 
> >     during file move.
> >   - install
> >     When file is copied by install, security context of installed file 
> >     becomes different from value configured in file_contexts file.
> >     By this patch, security context is set according to file_contexts file.
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> 
> Index: include/libbb.h
> ===================================================================
> --- include/libbb.h	(revision 17803)
> +++ include/libbb.h	(working copy)
> @@ -743,9 +743,15 @@
>  	FILEUTILS_INTERACTIVE = 0x10,
>  	FILEUTILS_MAKE_HARDLINK = 0x20,
>  	FILEUTILS_MAKE_SOFTLINK = 0x40,
> +#if ENABLE_SELINUX
> +	FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
> +	FILEUTILS_SET_SECURITY_CONTEXT = 0x100
> +#endif
> +
>  };
> 
> This empty line after #endif - why?

removed this empty line.

> 
> +#if ENABLE_SELINUX 
> +	if (flags & FILEUTILS_SET_SECURITY_CONTEXT) {
> +		if(is_selinux_enabled() == 0) {
> +			fprintf( stderr, "Warning:  ignoring --context (-Z). "
> +					 "It requires a SELinux enabled kernel.\n" );
> +		}else{
> +			if ( setfscreatecon(context_str) < 0 ) {
> +				bb_error_msg_and_die("cannot set default security context %s\n", context_str);
> +			}
> +		}
> +	}
> +#endif
This part is removed because upstream coreutils does not have -Z option for cp.

> 
> The style is not consistent. Should be "if ()", "} else {".
> "Warning:  ignoring" has extra space for no reason.
> fprintf(stderr) can be probably replaced by bb_error_msg:
> bb_error_msg("warning: ignoring --context (-Z), it requires a SELinux enabled kernel");
fixed.

> 
> 
> +static int use_default_selinux_context = 1;
> 
> You never change it, it is always 1.  - ?!
It is used in current patch.

> --
> vda
> 

Other changes are following:
* Removed -Z option from cp
* Added --preserve-context, -Z options to install


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.v2.patch
Type: application/octet-stream
Size: 7808 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070209/205fedc0/attachment-0001.obj 

From ynakam at hitachisoft.jp  Fri Feb  9 01:48:53 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 18:48:53 +0900
Subject: [busybox:00367] Re: [PATCH 3/6] busybox -- SELinux option
	support for coreutils
In-Reply-To: <200702082353.43667.vda.linux@googlemail.com>
References: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>
	<200702082353.43667.vda.linux@googlemail.com>
Message-ID: <20070209184853.0671d4c9.ynakam@hitachisoft.jp>

On Thu, 8 Feb 2007 23:53:43 +0100
Denis Vlasenko wrote:
> On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> > [3/6] busybox-coreutils-03-mk.patch
> >  - -Z option support for mkdir, mkfifo, mknod. 
> >     By -Z, security context for created file can be set.
> > 
> > Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>
> 
> 
> +#if ENABLE_SELINUX
> +	security_context_t scontext = NULL;
> +#endif
>  
>  #if ENABLE_FEATURE_MKDIR_LONG_OPTIONS
>  	applet_long_options = mkdir_long_options;
>  #endif
> -	opt = getopt32(argc, argv, "m:p", &smode);
> +	opt = getopt32(argc, argv, "m:p" USE_SELINUX("Z:"), &smode USE_SELINUX(,&scontext));
>  	if (opt & 1) {
>  		mode = 0777;
>  		if (!bb_parse_mode(smode, &mode)) {
> @@ -50,6 +61,15 @@
>  	}
>  	if (opt & 2)
>  		flags |= FILEUTILS_RECUR;
> +#if ENABLE_SELINUX
> +	if(opt & 4) {
> +		selinux_or_die();
> +		if (setfscreatecon(scontext)) {
> +			bb_error_msg_and_die ("Sorry, cannot set default context "
> +					      "to %s.\n", scontext);
> 
> Initializing scontext to NULL is useless code. bb_error_msg_and_die
> has useless "Sorry" (with wrong capitalization: "mkdir: Sorry...")
> and useless ".\n" at the end.
Fixed.

> 
> Sorry guys, I would be really happy if these patches get
> a little bit prettier...
Thank you :-)

> --
> vda
> 


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-mk-03.v2.patch
Type: application/octet-stream
Size: 2213 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070209/292c4424/attachment-0001.obj 

From rep.dot.nop at gmail.com  Fri Feb  9 09:59:41 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 18:59:41 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CC9E16.9010407@cle-mens.de>
References: <45CC9E16.9010407@cle-mens.de>
Message-ID: <20070209175941.GT12488@aon.at>

On Fri, Feb 09, 2007 at 05:15:18PM +0100, Dirk Clemens wrote:
>I thing I have found a post bug in busybosy 1.3.1/mips.

Can you reproduce this with the current 1.4.1 (?) release or with trunk?
Please attach an strace for the cat > /tmp/out  case.
What toolchain did you use to build busybox?

From rep.dot.nop at gmail.com  Fri Feb  9 10:49:44 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 19:49:44 +0100
Subject: svn commit: trunk/busybox: include libbb networking
In-Reply-To: <20070209173217.8C217486DE@busybox.net>
References: <20070209173217.8C217486DE@busybox.net>
Message-ID: <20070209184944.GV12488@aon.at>

On Fri, Feb 09, 2007 at 09:32:17AM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-09 09:32:16 -0800 (Fri, 09 Feb 2007)
>New Revision: 17842
>
>Log:
>ping: support -I addr in family neutral manner; reuse a bit of common code

>Modified: trunk/busybox/include/usage.h
>===================================================================
>--- trunk/busybox/include/usage.h	2007-02-09 17:30:14 UTC (rev 17841)
>+++ trunk/busybox/include/usage.h	2007-02-09 17:32:16 UTC (rev 17842)
>@@ -2428,20 +2428,22 @@
> #define ping_full_usage \
>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>        "\n\nOptions:\n" \
>-       "	-c CNT	Send only CNT pings\n" \
>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>-       "	-I IP	Use IP as source address\n" \
>-       "	-q	Quiet mode, only displays output at start\n" \
>-       "		and when finished"
>+       "	-4, -6		Force IPv4 or IPv6 hostname resolution\n" \

s/resolution/resolving/g

btw (re: usage.h)
let me suggest the attached stripping of redundant information in
busybox_main.
Furthermore, That helptext should really be moved to usage.h to be able
to compress it, just as a sidenote ;)


>+       "	-c CNT		Send only CNT pings\n" \
>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>+       "	-I iface/IP	Use interface or IP address as source\n" \
>+       "	-q		Quiet mode, only displays output at start\n" \
>+       "			and when finished"
> #define ping6_trivial_usage \
>        "[OPTION]... host"
> #define ping6_full_usage \
>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>        "\n\nOptions:\n" \
>-       "	-c CNT	Send only CNT pings\n" \
>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>-       "	-q	Quiet mode, only displays output at start\n" \
>-       "		and when finished"

"Be quiet."
should suffice, really

>+       "	-c CNT		Send only CNT pings\n" \
>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>+       "	-I iface/IP	Use interface or IP address as source\n" \
>+       "	-q		Quiet mode, only displays output at start\n" \
>+       "			and when finished"

ditto

>Modified: trunk/busybox/networking/ping.c
>===================================================================
>--- trunk/busybox/networking/ping.c	2007-02-09 17:30:14 UTC (rev 17841)
>+++ trunk/busybox/networking/ping.c	2007-02-09 17:32:16 UTC (rev 17842)
>@@ -254,7 +254,7 @@
> 	struct sockaddr_in6 sin6;
> #endif
> } pingaddr;
>-static struct sockaddr_in sourceaddr;
>+static len_and_sockaddr *source_lsa;
> static int pingsock = -1;
> static unsigned datalen; /* intentionally uninitialized to work around gcc bug */
/* huh? what bug, exactly? */
 
>@@ -561,9 +561,8 @@
> 
> 	pingsock = create_icmp_socket();
> 	pingaddr.sin = lsa->sin;
>-	if (sourceaddr.sin_addr.s_addr) {
>-		xbind(pingsock, (struct sockaddr*)&sourceaddr, sizeof(sourceaddr));
>-	}
>+	if (source_lsa)
>+		xbind(pingsock, &lsa->sa, lsa->len);

Didn't look, but are there any users that can't rely on xbind using
#parm2->len so we could drop that explicit len parm?
 
> 	/* enable broadcast pings */
> 	setsockopt_broadcast(pingsock);

>@@ -695,25 +685,21 @@
> }
> #endif
> 
>-/* TODO: consolidate ether-wake.c, dnsd.c, ifupdown.c, nslookup.c
>- * versions of below thing. BTW we have far too many "%u.%u.%u.%u" too...
>-*/
>-static int parse_nipquad(const char *str, struct sockaddr_in* addr)
>+static void ping(len_and_sockaddr *lsa)

const len_and_sockaddr * const lsa , perhaps?

>@@ -732,9 +718,11 @@
> 	if (option_mask32 & OPT_s) datalen = xatou16(opt_s); // -s
> 	if (option_mask32 & OPT_I) { // -I
> 		if_index = if_nametoindex(opt_I);
>-		if (!if_index)
>-			if (parse_nipquad(opt_I, &sourceaddr))
>-				bb_show_usage();
>+		if (!if_index) {
>+			/* TODO: I'm not sure it takes IPv6 unless in [XX:XX..] format */

I'm unsure whether the decision to require that [XX:XX..] format was a
good idea since it sounds to be non-standard to me

cheers,

From etzvetanov at xceedium.com  Fri Feb  9 10:53:16 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 09 Feb 2007 13:53:16 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3DC0D.900@xceedium.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
	<45C3DC0D.900@xceedium.com>
Message-ID: <45CCC31C.1010300@xceedium.com>

I still can't make this work for me... When it comes to processing a lot 
of file listing information not only "ls -s" causes a segmentation 
fault, but also any attempt to use the file system functions does the 
same...
---
*ET*
**

Evgueni Tzvetanov wrote:
> David Daney wrote:
>   
>> Evgueni Tzvetanov wrote:
>>     
>>> Hi all,
>>>
>>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>>> little system for testing.
>>> It is running Linux kernel 2.6.18.1.
>>>
>>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>>> /usr/bin) it is pulling Segmentation Fault.
>>> What could be wrong or I am probably not on the same page with you 
>>> guys...
>>>
>>>       
>> What happens when you run it under gdb?
>>     
> Even stranger. When I call the command like (if this can help in anyway):
> "busybox ls -l" it is not bombing. When I run it as "ls -l" it is bombing.
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070209/9aa12b7e/attachment.htm 

From rep.dot.nop at gmail.com  Fri Feb  9 11:14:07 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 20:14:07 +0100
Subject: svn commit: trunk/busybox: include libbb networking
In-Reply-To: <20070209184944.GV12488@aon.at>
References: <20070209173217.8C217486DE@busybox.net>
	<20070209184944.GV12488@aon.at>
Message-ID: <20070209191407.GW12488@aon.at>

On Fri, Feb 09, 2007 at 07:49:44PM +0100, Bernhard Fischer wrote:
>On Fri, Feb 09, 2007 at 09:32:17AM -0800, vda at busybox.net wrote:
>>Author: vda
>>Date: 2007-02-09 09:32:16 -0800 (Fri, 09 Feb 2007)
>>New Revision: 17842
>>
>>Log:
>>ping: support -I addr in family neutral manner; reuse a bit of common code
>
>>Modified: trunk/busybox/include/usage.h
>>===================================================================
>>--- trunk/busybox/include/usage.h	2007-02-09 17:30:14 UTC (rev 17841)
>>+++ trunk/busybox/include/usage.h	2007-02-09 17:32:16 UTC (rev 17842)
>>@@ -2428,20 +2428,22 @@
>> #define ping_full_usage \
>>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>>        "\n\nOptions:\n" \
>>-       "	-c CNT	Send only CNT pings\n" \
>>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>>-       "	-I IP	Use IP as source address\n" \
>>-       "	-q	Quiet mode, only displays output at start\n" \
>>-       "		and when finished"
>>+       "	-4, -6		Force IPv4 or IPv6 hostname resolution\n" \
>
>s/resolution/resolving/g
>
>btw (re: usage.h)
>let me suggest the attached stripping of redundant information in
>busybox_main.

And embarassingly enough i forgot to attach said hunks..
Attached now, sorry for the noise. <skip rest>

>Furthermore, That helptext should really be moved to usage.h to be able
>to compress it, just as a sidenote ;)
>
>
>>+       "	-c CNT		Send only CNT pings\n" \
>>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>>+       "	-I iface/IP	Use interface or IP address as source\n" \
>>+       "	-q		Quiet mode, only displays output at start\n" \
>>+       "			and when finished"
>> #define ping6_trivial_usage \
>>        "[OPTION]... host"
>> #define ping6_full_usage \
>>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>>        "\n\nOptions:\n" \
>>-       "	-c CNT	Send only CNT pings\n" \
>>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>>-       "	-q	Quiet mode, only displays output at start\n" \
>>-       "		and when finished"
>
>"Be quiet."
>should suffice, really
>
>>+       "	-c CNT		Send only CNT pings\n" \
>>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>>+       "	-I iface/IP	Use interface or IP address as source\n" \
>>+       "	-q		Quiet mode, only displays output at start\n" \
>>+       "			and when finished"
>
>ditto
>
>>Modified: trunk/busybox/networking/ping.c
>>===================================================================
>>--- trunk/busybox/networking/ping.c	2007-02-09 17:30:14 UTC (rev 17841)
>>+++ trunk/busybox/networking/ping.c	2007-02-09 17:32:16 UTC (rev 17842)
>>@@ -254,7 +254,7 @@
>> 	struct sockaddr_in6 sin6;
>> #endif
>> } pingaddr;
>>-static struct sockaddr_in sourceaddr;
>>+static len_and_sockaddr *source_lsa;
>> static int pingsock = -1;
>> static unsigned datalen; /* intentionally uninitialized to work around gcc bug */
>/* huh? what bug, exactly? */
> 
>>@@ -561,9 +561,8 @@
>> 
>> 	pingsock = create_icmp_socket();
>> 	pingaddr.sin = lsa->sin;
>>-	if (sourceaddr.sin_addr.s_addr) {
>>-		xbind(pingsock, (struct sockaddr*)&sourceaddr, sizeof(sourceaddr));
>>-	}
>>+	if (source_lsa)
>>+		xbind(pingsock, &lsa->sa, lsa->len);
>
>Didn't look, but are there any users that can't rely on xbind using
>#parm2->len so we could drop that explicit len parm?
> 
>> 	/* enable broadcast pings */
>> 	setsockopt_broadcast(pingsock);
>
>>@@ -695,25 +685,21 @@
>> }
>> #endif
>> 
>>-/* TODO: consolidate ether-wake.c, dnsd.c, ifupdown.c, nslookup.c
>>- * versions of below thing. BTW we have far too many "%u.%u.%u.%u" too...
>>-*/
>>-static int parse_nipquad(const char *str, struct sockaddr_in* addr)
>>+static void ping(len_and_sockaddr *lsa)
>
>const len_and_sockaddr * const lsa , perhaps?
>
>>@@ -732,9 +718,11 @@
>> 	if (option_mask32 & OPT_s) datalen = xatou16(opt_s); // -s
>> 	if (option_mask32 & OPT_I) { // -I
>> 		if_index = if_nametoindex(opt_I);
>>-		if (!if_index)
>>-			if (parse_nipquad(opt_I, &sourceaddr))
>>-				bb_show_usage();
>>+		if (!if_index) {
>>+			/* TODO: I'm not sure it takes IPv6 unless in [XX:XX..] format */
>
>I'm unsure whether the decision to require that [XX:XX..] format was a
>good idea since it sounds to be non-standard to me
>
>cheers,
>_______________________________________________
>busybox mailing list
>busybox at busybox.net
>http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.shring-bare-helptext.00.diff
Type: text/x-diff
Size: 1002 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070209/785b565f/attachment.bin 

From akennedy at techmoninc.com  Fri Feb  9 11:45:33 2007
From: akennedy at techmoninc.com (Andy Kennedy)
Date: Fri, 09 Feb 2007 13:45:33 -0600
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45C776AD.5090602@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com>
	<45C0EBB2.1090604@seiner.com>	<45C0F180.4000904@techmoninc.com>
	<45C11D80.20906@techmoninc.com>	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com>
Message-ID: <45CCCF5D.6040203@techmoninc.com>

Andy Kennedy wrote:
> To restate my problem (in case some kind developer decides to help me):
>
> When I have the kernel command line parameter "console=ttyS0,115200n8" 
> I get nice neat output on the serial line up until the init runs.  As 
> soon as init runs, I get missing chars.  So, I replace the BusyBox 
> init with minit, compiled from source and using the uCLibC gcc that I 
> let buildroot make for me.  Same problem.  For some reason, when the 
> system initializes -- after the kernel has reported all of its output, 
> my serial console goes splat.  When I initialize the console using 
> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
> One of these letters will appear each time I send enter.
>
> I have tried everything I can think of.  There is no script setting 
> any of the line speeds -- in fact, I have even attempted to remove the 
> scripts and still get the same thing.  Removing the 
> console=ttyS0,115200n8 (or attempting any variant of it) has no 
> affect, except without the console= I get no good output on the line.  
> The only thing I haven't attempted yet is to replace the getty with an 
> equivalent to see if that makes a difference.  I have also tried 9600, 
> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
> every combination, but I still cannot get a serial console.
>
> Can anyone offer a suggestion as to how I might fix this -- or some 
> other place to start?
>
> Thanks in advance for any help you can offer,
> Andy
Okay, now I'm really confused.  Here is what I have done so far:
Made my laptop boot with a console on ttyS0 and put a login shell on it 
(to verify that I can do it -- I was beginning to think maybe I needed 
to remove Linux from my computer and get rid of all of  it being to 
stupid to own a computer, much less program an embedded system) and I 
had no problems.  So, I took my syslinux disk and booted from it (the 
SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
everything comes up as you would expect.

Given that this test worked there is one of about three possibilities:
1) Cable issue.  Tested my serial cable on another embedded system (an 
Arcom Viper), checks out.  Replaced the break-out cable from the 
embedded system -- failed.  Tried a known good cable -- failed.  Tested 
a different VersaLogic board -- failed.  Now, here is the part that 
really yanked me around:

The last time I booted the machine I didn't have the keyboard connected 
to the break-out cable.  The boot went as it normally does except the 
keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
BusyBox init takes over the console and prints all kind of whack.  I 
plug in the keyboard and the keyboard driver prints a perfect string 
onto the serial console.

I've looked through the code to see what type of initialization init is 
doing to the console, but it doesn't look like it is re-initializing the 
sucker at all.  The only thing that I can think is that BusyBox is doing 
something that Linux doesn't do to interact with the ttyS0 so I'm not 
getting what I expect.

Perhaps this will click something in your head and you can help me fix this.

Thanks again for any help you can provide,
Andy Kennedy

From rep.dot.nop at gmail.com  Fri Feb  9 13:11:42 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 22:11:42 +0100
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45CCCF5D.6040203@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com> <45C0EBB2.1090604@seiner.com>
	<45C0F180.4000904@techmoninc.com> <45C11D80.20906@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com> <45CCCF5D.6040203@techmoninc.com>
Message-ID: <20070209211142.GY12488@aon.at>

On Fri, Feb 09, 2007 at 01:45:33PM -0600, Andy Kennedy wrote:
>Andy Kennedy wrote:
>> To restate my problem (in case some kind developer decides to help me):
>>
>> When I have the kernel command line parameter "console=ttyS0,115200n8" 
>> I get nice neat output on the serial line up until the init runs.  As 
>> soon as init runs, I get missing chars.  So, I replace the BusyBox 
>> init with minit, compiled from source and using the uCLibC gcc that I 
>> let buildroot make for me.  Same problem.  For some reason, when the 
>> system initializes -- after the kernel has reported all of its output, 
>> my serial console goes splat.  When I initialize the console using 
>> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
>> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
>> One of these letters will appear each time I send enter.
>>
>> I have tried everything I can think of.  There is no script setting 
>> any of the line speeds -- in fact, I have even attempted to remove the 
>> scripts and still get the same thing.  Removing the 
>> console=ttyS0,115200n8 (or attempting any variant of it) has no 
>> affect, except without the console= I get no good output on the line.  
>> The only thing I haven't attempted yet is to replace the getty with an 
>> equivalent to see if that makes a difference.  I have also tried 9600, 
>> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
>> every combination, but I still cannot get a serial console.
>>
>> Can anyone offer a suggestion as to how I might fix this -- or some 
>> other place to start?
>>
>> Thanks in advance for any help you can offer,
>> Andy
>Okay, now I'm really confused.  Here is what I have done so far:
>Made my laptop boot with a console on ttyS0 and put a login shell on it 
>(to verify that I can do it -- I was beginning to think maybe I needed 
>to remove Linux from my computer and get rid of all of  it being to 
>stupid to own a computer, much less program an embedded system) and I 
>had no problems.  So, I took my syslinux disk and booted from it (the 
>SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
>everything comes up as you would expect.
>
>Given that this test worked there is one of about three possibilities:
>1) Cable issue.  Tested my serial cable on another embedded system (an 
>Arcom Viper), checks out.  Replaced the break-out cable from the 
>embedded system -- failed.  Tried a known good cable -- failed.  Tested 
>a different VersaLogic board -- failed.  Now, here is the part that 
>really yanked me around:
>
>The last time I booted the machine I didn't have the keyboard connected 
>to the break-out cable.  The boot went as it normally does except the 
>keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
>BusyBox init takes over the console and prints all kind of whack.  I 
>plug in the keyboard and the keyboard driver prints a perfect string 
>onto the serial console.
>
>I've looked through the code to see what type of initialization init is 
>doing to the console, but it doesn't look like it is re-initializing the 
>sucker at all.  The only thing that I can think is that BusyBox is doing 
>something that Linux doesn't do to interact with the ttyS0 so I'm not 
>getting what I expect.

IIRC busybox's init doesn't do anything special for serial lines.

As vda already suggested, better seek help on lkml or try to find
somebody to whom that <char><space><char>.. pattern sounds familiar.

From vapier at gentoo.org  Fri Feb  9 18:34:35 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 9 Feb 2007 21:34:35 -0500
Subject: realpath bug
In-Reply-To: <20070209083605.GF15523@scorpius.homelinux.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702090021.35590.vapier@gentoo.org>
	<20070209083605.GF15523@scorpius.homelinux.org>
Message-ID: <200702092134.35752.vapier@gentoo.org>

On Friday 09 February 2007, Marc Leeman wrote:
> The system is using an empty /tmp fs (tmpfs), so the socket or any other
> file is not present in /tmp when xmallok_realpath("/dev/log") is called.

then the behavior of realpath is correct ... it should return NULL on broken 
symlinks which is what it appears to be doing

> So since uclibc's implementation of realpath matches glibc's; we should
> re-store the relevant parts of the older syslogd code again instead of
> fixing it in xmalloc_realpath()?

that seems to be prudent i would think
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070209/d9d95fa7/attachment.pgp 

From vda.linux at googlemail.com  Sat Feb 10 10:17:04 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:17:04 +0100
Subject: Busybox compilation error
In-Reply-To: <1ff320400702071647x1b64de12m10bef0c1c59fccd8@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
	<1ff320400702071647x1b64de12m10bef0c1c59fccd8@mail.gmail.com>
Message-ID: <200702101917.04048.vda.linux@googlemail.com>

On Thursday 08 February 2007 01:47, Sina Mallick wrote:
> Hi,
> > I am trying to compile busybox for ARM cpu...Am using arm bese
> > toolchain...
> > I am getting this error at the end...
> > LINK    busybox_unstripped
> > applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> > `readahead_main'
> > applets/built-in.o: (.rodata.applets+0x868): undefined reference to
> > `taskset_main'
> > collect2: ld returned 1 exit status
> > make: *** [busybox_unstripped] Error 1

I think you are getting these because your libc
does not have functions needed for readahead and taskset.

Apparently you disabled these applets and reran make, but
due to a bug in build system it is still trying to link in
newly-disabled applets. This bug was recently fixed.

"make clean; make" will work around the problem.
--
vda

From vda.linux at googlemail.com  Sat Feb 10 10:20:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:20:56 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <45CBD6AF.7060407@avtrex.com>
References: <45CBD6AF.7060407@avtrex.com>
Message-ID: <200702101920.56047.vda.linux@googlemail.com>

On Friday 09 February 2007 03:04, David Daney wrote:
> I recall reading on the list recently that someone was thinking about 
> modifying dhcpc to do nice things when the link state changes.
> 
> Has this been done?
> 
> If not, I think I will be doing it very soon.

Why do you need this?

Windows have such a behavior (of severing all TCP connections
whenever I need to unplug my network cable for 5 seconds)
and it is _awful_.

I hope you plan to implement something less annoying then this.
--
vda

From floydpink at gmail.com  Sat Feb 10 10:35:13 2007
From: floydpink at gmail.com (Jason Schoon)
Date: Sat, 10 Feb 2007 12:35:13 -0600
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702101920.56047.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
Message-ID: <78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>

On 2/10/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Friday 09 February 2007 03:04, David Daney wrote:
> > I recall reading on the list recently that someone was thinking about
> > modifying dhcpc to do nice things when the link state changes.
> >
> > Has this been done?
> >
> > If not, I think I will be doing it very soon.
>
> Why do you need this?
>
> Windows have such a behavior (of severing all TCP connections
> whenever I need to unplug my network cable for 5 seconds)
> and it is _awful_.
>
> I hope you plan to implement something less annoying then this.


Perhaps he is talking more along the lines of doing an automatic renewal
when a link is upped.  For example, plugging into a new network.  You want
to get a new address on that net, not keep using an old one.  I have
implemented that several times in different DHCP clients.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070210/4093efe9/attachment.htm 

From vda.linux at googlemail.com  Sat Feb 10 10:35:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:35:37 +0100
Subject: [gmail] Re: realpath bug
In-Reply-To: <20070209083605.GF15523@scorpius.homelinux.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702090021.35590.vapier@gentoo.org>
	<20070209083605.GF15523@scorpius.homelinux.org>
Message-ID: <200702101935.37919.vda.linux@googlemail.com>

On Friday 09 February 2007 09:36, Marc Leeman wrote:
> Cc to busybox ML.
> 
> > > > could you be more specific as to what is breaking ?  "syslogd breaks on
> > > > read only filesystems" does not translate well into actual test cases for
> > > > inclusion into uClibc testsuite ...
> > >
> > > cf. busybox discussion of yesterday:
> > >
> > > http://www.busybox.net/lists/busybox/2007-February/026252.html
> > 
> > ok, looking again and i see your setup is:
> >  - /dev is mounted RO
> >  - /tmp is mounted RW
> >  - /dev/log is a symlink to ../tmp/log
> > 
> > busybox launches sysklogd which does:
> >  - dev_log_name = xmalloc_realpath(/dev/log)
> >  - unlink(dev_log_name)
> > 
> > on your system, dev_log_name should be resolving to /tmp/log but it seems to 
> > return NULL ... on my system, it works:
> > # ls -l /dev/log /tmp/log 
> > lrwxrwxrwx 1 root root 10 2007-02-08 23:58 /dev/log -> ../tmp/log
> > -rw-r--r-- 1 root root  0 2007-02-08 23:58 /tmp/log
> > # ./busybox syslogd -n
> > running xmalloc_realpath(/dev/log)
> > got back /tmp/log
> > dev_log_name is now /tmp/log
> > unlinking(/tmp/log)
> > exiting now
> > # ./busybox syslogd -n
> > running xmalloc_realpath(/dev/log)
> > got back (null)
> > dev_log_name is now /dev/log
> > unlinking(/dev/log)
> > exiting now
> > 
> > this behavior is correct ... since /tmp/log was removed in the first run, the 
> > second run should actually return NULL ...
> 
> The system is using an empty /tmp fs (tmpfs), so the socket or any other
> file is not present in /tmp when xmallok_realpath("/dev/log") is called.
> 
> The old syslogd implementation correctly de-referenced the pointer in
> /dev/log to /tmp/log and created a /tmp/log socket. the new syslogd
> implementation tries to delete /dev/log on the RO filesystem and tries
> to create the log socket there, what obviously fails on a RO fs.

rev 16000:

        /* Create the syslog file so realpath() can work. */
        if (realpath(_PATH_LOG, lfile) != NULL) {
                unlink(lfile);
        }

        memset(&sunx, 0, sizeof(sunx));
        sunx.sun_family = AF_UNIX;
        strncpy(sunx.sun_path, lfile, sizeof(sunx.sun_path));
        sock_fd = xsocket(AF_UNIX, SOCK_DGRAM, 0);
        addrLength = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
        if (bind(sock_fd, (struct sockaddr *) &sunx, addrLength) < 0) {
                bb_perror_msg_and_die("Could not connect to socket " _PATH_LOG);
        }

if realpath fails, lfile is undefined.
strncpy above will pass possibly bogus lfile as socket name to bind().
it happens so on glibc realpath() returns resolved link and
uclibc returns NULL but fills lfile with resolved link.

New code is:

        dev_log_name = xmalloc_realpath(_PATH_LOG);
        if (!dev_log_name)
                dev_log_name = _PATH_LOG;

        /* Unlink old /dev/log (or object it points to) */
        unlink(dev_log_name);

        memset(&sunx, 0, sizeof(sunx));
        sunx.sun_family = AF_UNIX;
        strncpy(sunx.sun_path, dev_log_name, sizeof(sunx.sun_path));
        sock_fd = xsocket(AF_UNIX, SOCK_DGRAM, 0);
        addr_len = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
        xbind(sock_fd, (struct sockaddr *) &sunx, addr_len);

which looks more sane to me.

Apparently the problem is that realpath may fail to resolve
dangling links (e.g. uclibc).

Patch which replaces realpath with readlink, anyone?
--
vda

From vda.linux at googlemail.com  Sat Feb 10 10:46:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:46:11 +0100
Subject: udhcp client not working
In-Reply-To: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
References: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
Message-ID: <200702101946.11939.vda.linux@googlemail.com>

On Friday 09 February 2007 17:56, satpal parmar wrote:
> Hi all;
> 
>    I am trying to make udchpc (UDHCP clinet from busybox) work on my kernel
> (linux 2.6.11.12, linux 2.6.18 and linux 2.6.19 ).
>  poted on arm9 board.I am getting following output
> 
> 
> / # udhcpc
> udhcpc (v1.2.0-svn) started
> eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>           Interrupt:37
> 
> Sending discover...
> Sending discover...
> Sending discover...
> eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>           Interrupt:37
> 
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

This is a kernel message. Your network card is failing to send
packets.

Try assigning static ip address and pinging some other
machine on the network - does that work?
--
vda

From vda.linux at googlemail.com  Sat Feb 10 18:09:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 03:09:32 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
Message-ID: <200702110309.32856.vda.linux@googlemail.com>

On Saturday 10 February 2007 19:35, Jason Schoon wrote:
> > > I recall reading on the list recently that someone was thinking about
> > > modifying dhcpc to do nice things when the link state changes.
> > >
> > > Has this been done?
> > >
> > > If not, I think I will be doing it very soon.
> >
> > Why do you need this?
> >
> > Windows have such a behavior (of severing all TCP connections
> > whenever I need to unplug my network cable for 5 seconds)
> > and it is _awful_.
> >
> > I hope you plan to implement something less annoying then this.
> 
> Perhaps he is talking more along the lines of doing an automatic renewal
> when a link is upped.  For example, plugging into a new network.  You want
> to get a new address on that net, not keep using an old one.  I have
> implemented that several times in different DHCP clients.

Why? If I unplug my machine from network, it does NOT
automatically mean I should renew DHCP address.

It is needed sometimes, but other times (e.g. "I need to unplug
my machine for 10 seconds...") it will be utterly inconvenient.

If you really want it, perhaps kernel sends a hotplug event
or something like it on link down/link up,
so you can hook onto it and kill/restart udhcpc?
--
vda

From rogelio.serrano at gmail.com  Sat Feb 10 18:23:12 2007
From: rogelio.serrano at gmail.com (Rogelio Serrano)
Date: Sun, 11 Feb 2007 02:23:12 +0000
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702110309.32856.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
	<200702110309.32856.vda.linux@googlemail.com>
Message-ID: <a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>

On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Saturday 10 February 2007 19:35, Jason Schoon wrote:
> > > > I recall reading on the list recently that someone was thinking about
> > > > modifying dhcpc to do nice things when the link state changes.
> > > >
> > > > Has this been done?
> > > >
> > > > If not, I think I will be doing it very soon.
> > >
> > > Why do you need this?
> > >
> > > Windows have such a behavior (of severing all TCP connections
> > > whenever I need to unplug my network cable for 5 seconds)
> > > and it is _awful_.
> > >
> > > I hope you plan to implement something less annoying then this.
> >
> > Perhaps he is talking more along the lines of doing an automatic renewal
> > when a link is upped.  For example, plugging into a new network.  You want
> > to get a new address on that net, not keep using an old one.  I have
> > implemented that several times in different DHCP clients.
>
> Why? If I unplug my machine from network, it does NOT
> automatically mean I should renew DHCP address.
>
> It is needed sometimes, but other times (e.g. "I need to unplug
> my machine for 10 seconds...") it will be utterly inconvenient.
>
> If you really want it, perhaps kernel sends a hotplug event
> or something like it on link down/link up,
> so you can hook onto it and kill/restart udhcpc?
> --
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>

How does the machine find out by itself that you are "just "unplugging
for 10 seconds and dont want to renew your address?

I would rather have the adapter renew the address anytime the
interface goes up. And notify the system that the interface is down
when the link goes down.

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items

From floydpink at gmail.com  Sat Feb 10 18:52:50 2007
From: floydpink at gmail.com (Jason Schoon)
Date: Sat, 10 Feb 2007 20:52:50 -0600
Subject: Detecting link state in dhcpc...
In-Reply-To: <a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
	<200702110309.32856.vda.linux@googlemail.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
Message-ID: <78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>

On 2/10/07, Rogelio Serrano <rogelio.serrano at gmail.com> wrote:
>
> On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > On Saturday 10 February 2007 19:35, Jason Schoon wrote:
> > > > > I recall reading on the list recently that someone was thinking
> about
> > > > > modifying dhcpc to do nice things when the link state changes.
> > > > >
> > > > > Has this been done?
> > > > >
> > > > > If not, I think I will be doing it very soon.
> > > >
> > > > Why do you need this?
> > > >
> > > > Windows have such a behavior (of severing all TCP connections
> > > > whenever I need to unplug my network cable for 5 seconds)
> > > > and it is _awful_.
> > > >
> > > > I hope you plan to implement something less annoying then this.
> > >
> > > Perhaps he is talking more along the lines of doing an automatic
> renewal
> > > when a link is upped.  For example, plugging into a new network.  You
> want
> > > to get a new address on that net, not keep using an old one.  I have
> > > implemented that several times in different DHCP clients.
> >
> > Why? If I unplug my machine from network, it does NOT
> > automatically mean I should renew DHCP address.
> >
> > It is needed sometimes, but other times (e.g. "I need to unplug
> > my machine for 10 seconds...") it will be utterly inconvenient.
> >
> > If you really want it, perhaps kernel sends a hotplug event
> > or something like it on link down/link up,
> > so you can hook onto it and kill/restart udhcpc?
> > --
> > vda
> > _______________________________________________
> > busybox mailing list
> > busybox at busybox.net
> > http://busybox.net/cgi-bin/mailman/listinfo/busybox
> >
>
> How does the machine find out by itself that you are "just "unplugging
> for 10 seconds and dont want to renew your address?
>
> I would rather have the adapter renew the address anytime the
> interface goes up. And notify the system that the interface is down
> when the link goes down.
>

Agreed, I see nothing wrong with sending a renewal.  It's not like it will
break any of your existing connections.

In my case, I am talking about an embedded device that is essentially
useless if not on a network also, so I definitely want to be able to take
some action if the link goes down as well.  In my case it happens that I
need to do this in static IP case also, so I have a link monitoring daemon
that takes care of it, rather than adding it to DHCP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070210/2c5588be/attachment.html 

From vda.linux at googlemail.com  Sat Feb 10 19:07:54 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 04:07:54 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
	<78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
Message-ID: <200702110407.54040.vda.linux@googlemail.com>

On Sunday 11 February 2007 03:52, Jason Schoon wrote:
> > > > to get a new address on that net, not keep using an old one.  I have
> > > > implemented that several times in different DHCP clients.
> > >
> > > Why? If I unplug my machine from network, it does NOT
> > > automatically mean I should renew DHCP address.
> > >
> > > It is needed sometimes, but other times (e.g. "I need to unplug
> > > my machine for 10 seconds...") it will be utterly inconvenient.
> > >
> > > If you really want it, perhaps kernel sends a hotplug event
> > > or something like it on link down/link up,
> > > so you can hook onto it and kill/restart udhcpc?
> >
> > How does the machine find out by itself that you are "just "unplugging
> > for 10 seconds and dont want to renew your address?
> >
> > I would rather have the adapter renew the address anytime the
> > interface goes up. And notify the system that the interface is down
> > when the link goes down.
> 
> Agreed, I see nothing wrong with sending a renewal.  It's not like it will
> break any of your existing connections.
> 
> In my case, I am talking about an embedded device that is essentially
> useless if not on a network also, so I definitely want to be able to take
> some action if the link goes down as well.  In my case it happens that I
> need to do this in static IP case also, so I have a link monitoring daemon
> that takes care of it, rather than adding it to DHCP.

Exactly what I am saying. Link state monitoring is a DIFFERENT thing,
not DHCP thing. I still think that this functionality should not
be added to udhcpc.
--
vda

From vda.linux at googlemail.com  Sat Feb 10 19:19:26 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 04:19:26 +0100
Subject: [PATCH] syslogd +realpath
Message-ID: <200702110419.26631.vda.linux@googlemail.com>

Hi,

Please test attached patch. For me it works correctly
for symlinked and non-symlinked /dev/log.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 2455 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070211/dfac7cf2/attachment.bin 

From rogelio.serrano at gmail.com  Sat Feb 10 19:24:58 2007
From: rogelio.serrano at gmail.com (Rogelio Serrano)
Date: Sun, 11 Feb 2007 03:24:58 +0000
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702110407.54040.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
	<78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
	<200702110407.54040.vda.linux@googlemail.com>
Message-ID: <a9951d2a0702101924t4c9bfddjcfd24a413a079a36@mail.gmail.com>

On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Sunday 11 February 2007 03:52, Jason Schoon wrote:
> > > > > to get a new address on that net, not keep using an old one.  I have
> > > > > implemented that several times in different DHCP clients.
> > > >
> > > > Why? If I unplug my machine from network, it does NOT
> > > > automatically mean I should renew DHCP address.
> > > >
> > > > It is needed sometimes, but other times (e.g. "I need to unplug
> > > > my machine for 10 seconds...") it will be utterly inconvenient.
> > > >
> > > > If you really want it, perhaps kernel sends a hotplug event
> > > > or something like it on link down/link up,
> > > > so you can hook onto it and kill/restart udhcpc?
> > >
> > > How does the machine find out by itself that you are "just "unplugging
> > > for 10 seconds and dont want to renew your address?
> > >
> > > I would rather have the adapter renew the address anytime the
> > > interface goes up. And notify the system that the interface is down
> > > when the link goes down.
> >
> > Agreed, I see nothing wrong with sending a renewal.  It's not like it will
> > break any of your existing connections.
> >
> > In my case, I am talking about an embedded device that is essentially
> > useless if not on a network also, so I definitely want to be able to take
> > some action if the link goes down as well.  In my case it happens that I
> > need to do this in static IP case also, so I have a link monitoring daemon
> > that takes care of it, rather than adding it to DHCP.
>
> Exactly what I am saying. Link state monitoring is a DIFFERENT thing,
> not DHCP thing. I still think that this functionality should not
> be added to udhcpc.
> --
> vda
>

I agree too.

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items

From vapier at gentoo.org  Sat Feb 10 20:55:08 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 10 Feb 2007 23:55:08 -0500
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702101935.37919.vda.linux@googlemail.com>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<20070209083605.GF15523@scorpius.homelinux.org>
	<200702101935.37919.vda.linux@googlemail.com>
Message-ID: <200702102355.09483.vapier@gentoo.org>

On Saturday 10 February 2007, Denis Vlasenko wrote:
> it happens so on glibc realpath() returns resolved link and
> uclibc returns NULL but fills lfile with resolved link.

no ... glibc and uClibc both return NULL for broken symlinks

> Patch which replaces realpath with readlink, anyone?

this wont be terribly robust as what if /dev/ is readonly and /dev/log is a 
relative symlink ... you'd have to make sure you chroot(/dev/) first
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070210/7ab61e8c/attachment.pgp 

From lists at zelow.no  Sun Feb 11 00:29:23 2007
From: lists at zelow.no (Thomas Lundquist)
Date: Sun, 11 Feb 2007 09:29:23 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702110407.54040.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
	<78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
	<200702110407.54040.vda.linux@googlemail.com>
Message-ID: <20070211082923.GA14307@zelow.no>

On Sun, Feb 11, 2007 at 04:07:54AM +0100, Denis Vlasenko wrote:
> 
> Exactly what I am saying. Link state monitoring is a DIFFERENT thing,
> not DHCP thing. I still think that this functionality should not
> be added to udhcpc.

as long as the interface are controlled by DHCP, the dhcp client should
get notice on link events and act upon it.

a renewal is the logical action.


Thomas.

From alexander.griesser at lkh-vil.or.at  Sun Feb 11 05:25:05 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 14:25:05 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <20070209175941.GT12488@aon.at>
References: <45CC9E16.9010407@cle-mens.de> <20070209175941.GT12488@aon.at>
Message-ID: <45CF1931.3010807@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernhard Fischer wrote:
> On Fri, Feb 09, 2007 at 05:15:18PM +0100, Dirk Clemens wrote:
>> I thing I have found a post bug in busybosy 1.3.1/mips.
>
> Can you reproduce this with the current 1.4.1 (?) release or with trunk?

Well, I think I'm suffering from a similar bug.
I don't know when it started to not work anymore, but currently (1.4.1)
I'm not able to do the following:

if [ "$REQUEST_METHOD" = "POST" ]; then
  read QUERY_STRING
fi

This results in waiting endlessly for the webserver to complete,
as if there was nothing coming on stdin for read to complete.

I gave `cat` a shot and that worked:

if [ "$REQUEST_METHOD" = "POST" ]; then
  cat >/tmp/out
fi

> What toolchain did you use to build busybox?

I'm running on Debian 4.0, Linux kernel 2.6.20, gcc 4.1.2 and libc
2.3.6.ds1-11.

If I missed something to specify for my toolchain, please tell me
and I'll get you this information.

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFzxkx66HVD6KUm1oRAksdAJsFBB7GuTo+ZzQ+jJvAB/SEleGcEQCgqUbh
Se5QZYWqImzyItTTCtYaCxI=
=rhld
-----END PGP SIGNATURE-----

From vda.linux at googlemail.com  Sun Feb 11 06:30:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 15:30:45 +0100
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702102355.09483.vapier@gentoo.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702101935.37919.vda.linux@googlemail.com>
	<200702102355.09483.vapier@gentoo.org>
Message-ID: <200702111530.45440.vda.linux@googlemail.com>

On Sunday 11 February 2007 05:55, Mike Frysinger wrote:
> On Saturday 10 February 2007, Denis Vlasenko wrote:
> > it happens so on glibc realpath() returns resolved link and
> > uclibc returns NULL but fills lfile with resolved link.
> 
> no ... glibc and uClibc both return NULL for broken symlinks

I don't understand how rev 16000 managed to work ok
with dangling symlinks, then:

? ? ? ? /* Create the syslog file so realpath() can work. */
? ? ? ? if (realpath(_PATH_LOG, lfile) != NULL) {
? ? ? ? ? ? ? ? unlink(lfile);
? ? ? ? }

? ? ? ? memset(&sunx, 0, sizeof(sunx));
? ? ? ? sunx.sun_family = AF_UNIX;
? ? ? ? strncpy(sunx.sun_path, lfile, sizeof(sunx.sun_path));
? ? ? ? sock_fd = xsocket(AF_UNIX, SOCK_DGRAM, 0);
? ? ? ? addrLength = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
? ? ? ? if (bind(sock_fd, (struct sockaddr *) &sunx, addrLength) < 0) {
? ? ? ? ? ? ? ? bb_perror_msg_and_die("Could not connect to socket " _PATH_LOG);
? ? ? ? }

unless glibc _also_ fills lfile, but returns NULL, just like uclibc.

Anyway, I am not very interested in realpath here,
I'm going to switch to readlink.

> > Patch which replaces realpath with readlink, anyone?
> 
> this wont be terribly robust as what if /dev/ is readonly and /dev/log is a 
> relative symlink ... you'd have to make sure you chroot(/dev/) first

I hope chdir("/dev") would suffice ;)
--
vda

From vda.linux at googlemail.com  Sun Feb 11 06:51:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 15:51:40 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CF1931.3010807@lkh-vil.or.at>
References: <45CC9E16.9010407@cle-mens.de> <20070209175941.GT12488@aon.at>
	<45CF1931.3010807@lkh-vil.or.at>
Message-ID: <200702111551.41002.vda.linux@googlemail.com>

On Sunday 11 February 2007 14:25, Alexander Griesser wrote:
> Bernhard Fischer wrote:
> > On Fri, Feb 09, 2007 at 05:15:18PM +0100, Dirk Clemens wrote:
> >> I thing I have found a post bug in busybosy 1.3.1/mips.
> >
> > Can you reproduce this with the current 1.4.1 (?) release or with trunk?
> 
> Well, I think I'm suffering from a similar bug.
> I don't know when it started to not work anymore, but currently (1.4.1)
> I'm not able to do the following:
> 
> if [ "$REQUEST_METHOD" = "POST" ]; then
>   read QUERY_STRING
> fi
> 
> This results in waiting endlessly for the webserver to complete,
> as if there was nothing coming on stdin for read to complete.
> 
> I gave `cat` a shot and that worked:
> 
> if [ "$REQUEST_METHOD" = "POST" ]; then
>   cat >/tmp/out
> fi

I would like to try it myself. Do you have a small testcase?
--
vda

From alexander.griesser at lkh-vil.or.at  Sun Feb 11 08:27:23 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 17:27:23 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702111551.41002.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de> <20070209175941.GT12488@aon.at>
	<45CF1931.3010807@lkh-vil.or.at>
	<200702111551.41002.vda.linux@googlemail.com>
Message-ID: <45CF43EB.8090103@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Vlasenko wrote:
> I would like to try it myself. Do you have a small testcase?

Well, I have this cgi-script that I built to try it out.

test.cgi:
- ------------------- 8< -------------------
#!/bin/sh

echo "<html>
<body>
<form method="post" action="/cgi-bin/test.cgi">
<input type="text" name="test">
<input type="submit" name="submit">
</form>"

if [ "$REQUEST_METHOD" = "POST" ]; then
  # This doesn't work at all, it hangs with this
  read QUERY_STRING
  echo $QUERY_STRING

  # This does only work, if the destination file has
  # already been created before, don't know why, but
  # I debugged this fact yesterday and it is reproducible
  # If the file is not available when cat tries to write
  # the data to it, it hangs as `read` does in the above
  # lines
  cat >/tmp/query
  cat /tmp/query
fi

echo "</body>
</html>"
- ------------------- 8< -------------------

I hope, this is what you meant with "testcase". If not, please tell
me what I need to provide so that you can reproduce it.

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFz0Pr66HVD6KUm1oRAkn4AKCjovrAqECmb73a2ts1KE8RiKPVZgCfZBSd
WKUmDKwPnm/riOcFFbOqUV0=
=hai/
-----END PGP SIGNATURE-----

From vda.linux at googlemail.com  Sun Feb 11 08:23:59 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 17:23:59 +0100
Subject: [RESOLVED] Re: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170929938.14212.37.camel@localhost>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
	<1170929938.14212.37.camel@localhost>
Message-ID: <200702111723.59599.vda.linux@googlemail.com>

On Thursday 08 February 2007 11:18, Natanael Copa wrote:
> parse_url sets target.path = ""
> 
> later, when guessing the out file name
> 
>  fname_out = bb_get_last_path_component(target.path);
> 
> bb_get_last_path_component() will write to target.path.

bb_get_last_component is a bad API, yes...
 
> Looks like its fixed in svn. Would be nice to have it fixed for 1.4.2.
> 
> Attached is a patch for 1.4.1.

Thanks, added to post 1.4.1 fixes
--
vda

From vda.linux at googlemail.com  Sun Feb 11 10:34:01 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 19:34:01 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CF43EB.8090103@lkh-vil.or.at>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111551.41002.vda.linux@googlemail.com>
	<45CF43EB.8090103@lkh-vil.or.at>
Message-ID: <200702111934.01919.vda.linux@googlemail.com>

On Sunday 11 February 2007 17:27, Alexander Griesser wrote:
> Denis Vlasenko wrote:
> > I would like to try it myself. Do you have a small testcase?
> 
> Well, I have this cgi-script that I built to try it out.
> 
> test.cgi:
> ------------------- 8< -------------------
> #!/bin/sh
> 
> echo "<html>
> <body>
> <form method="post" action="/cgi-bin/test.cgi">
> <input type="text" name="test">
> <input type="submit" name="submit">
> </form>"
> 
> if [ "$REQUEST_METHOD" = "POST" ]; then
>   # This doesn't work at all, it hangs with this
>   read QUERY_STRING
>   echo $QUERY_STRING
> 
>   # This does only work, if the destination file has
>   # already been created before, don't know why, but
>   # I debugged this fact yesterday and it is reproducible
>   # If the file is not available when cat tries to write
>   # the data to it, it hangs as `read` does in the above
>   # lines
>   cat >/tmp/query
>   cat /tmp/query
> fi
> 
> echo "</body>
> </html>"
> ------------------- 8< -------------------
> 
> I hope, this is what you meant with "testcase". If not, please tell
> me what I need to provide so that you can reproduce it.

Yes. Generally it's always better to explain problems
with exact details, not with somewhat vague descriptions.

I think I know where is the problem.

networking/httpd.c: replace

                close(config->accepted_socket);
                close(config->server_socket);

with

                if (config->accepted_socket > 1)
                        close(config->accepted_socket);
                if (config->server_socket > 1)
                        close(config->server_socket);

Does it work now?
--
vda

From alexander.griesser at lkh-vil.or.at  Sun Feb 11 10:54:28 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 19:54:28 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702111934.01919.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111551.41002.vda.linux@googlemail.com>
	<45CF43EB.8090103@lkh-vil.or.at>
	<200702111934.01919.vda.linux@googlemail.com>
Message-ID: <45CF6664.1060407@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Vlasenko wrote:
> I think I know where is the problem.
> 
> networking/httpd.c: replace
> 
>                 close(config->accepted_socket);
>                 close(config->server_socket);
> 
> with
> 
>                 if (config->accepted_socket > 1)
>                         close(config->accepted_socket);
>                 if (config->server_socket > 1)
>                         close(config->server_socket);
> 
> Does it work now?

No, unfortunately, the symptoms stay the same after this change.

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFz2Zk66HVD6KUm1oRApleAJ9AF7dDk6wckY9n1qmSf+LK8RvrygCbBPIi
szirOghA95JvjW+Xiu1jO/U=
=Hv9/
-----END PGP SIGNATURE-----

From vda.linux at googlemail.com  Sun Feb 11 11:08:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 20:08:25 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CF6664.1060407@lkh-vil.or.at>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111934.01919.vda.linux@googlemail.com>
	<45CF6664.1060407@lkh-vil.or.at>
Message-ID: <200702112008.25916.vda.linux@googlemail.com>

On Sunday 11 February 2007 19:54, Alexander Griesser wrote:
> Denis Vlasenko wrote:
> > I think I know where is the problem.
> >
> > networking/httpd.c: replace
> >
> >                 close(config->accepted_socket);
> >                 close(config->server_socket);
> >
> > with
> >
> >                 if (config->accepted_socket > 1)
> >                         close(config->accepted_socket);
> >                 if (config->server_socket > 1)
> >                         close(config->server_socket);
> >
> > Does it work now?
> 
> No, unfortunately, the symptoms stay the same after this change.

Make sure you killed/restarted httpd (so that you
don't use old version).

I noticed another problem - httpd may wait forever for
cgi output while cgi waits for httpd's output!

Attached patch fixes it too.
Please test it (patch is against current svn).
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 3499 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070211/650854cb/attachment.bin 

From alexander.griesser at lkh-vil.or.at  Sun Feb 11 11:31:04 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 20:31:04 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702112008.25916.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111934.01919.vda.linux@googlemail.com>
	<45CF6664.1060407@lkh-vil.or.at>
	<200702112008.25916.vda.linux@googlemail.com>
Message-ID: <45CF6EF8.4040701@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Vlasenko wrote:
>>> Does it work now?
>> No, unfortunately, the symptoms stay the same after this change.
> 
> Make sure you killed/restarted httpd (so that you
> don't use old version).

I did, don't worry :)

> I noticed another problem - httpd may wait forever for
> cgi output while cgi waits for httpd's output!

That sounds good...

> Attached patch fixes it too.

... and that one helped! Great, now it's working again :)

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFz27466HVD6KUm1oRAmcEAJ0WAcrrUbhe+YX2aFuN55cW+f2CjwCcCcje
5u2LHECPSUJqM0oEj2Yyy/s=
=uRxx
-----END PGP SIGNATURE-----

From rep.dot.nop at gmail.com  Sun Feb 11 11:42:32 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 11 Feb 2007 20:42:32 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702112008.25916.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111934.01919.vda.linux@googlemail.com>
	<45CF6664.1060407@lkh-vil.or.at>
	<200702112008.25916.vda.linux@googlemail.com>
Message-ID: <20070211194232.GE12488@aon.at>

On Sun, Feb 11, 2007 at 08:08:25PM +0100, Denis Vlasenko wrote:
>On Sunday 11 February 2007 19:54, Alexander Griesser wrote:

>-		dup2(inFd, 0);  // replace stdin with the pipe
>-		dup2(outFd, 1);  // replace stdout with the pipe
>+		if (config->accepted_socket > 1)
>+			close(config->accepted_socket);

Didn't we have an close_nonstdin?

From hias at horus.com  Sun Feb 11 11:38:13 2007
From: hias at horus.com (Matthias Reichl)
Date: Sun, 11 Feb 2007 20:38:13 +0100
Subject: [PATCH] fix httpd lockup in cgi POSTs
Message-ID: <20070211193813.GA29704@horus.com>

While debugging some lockup problems with the openwrt webif^2 firmware
upload page I discovered a bug in httpd.c:

In line 1216 it must really be safe_read(), not full_read().
Otherwise httpd may lock up in the case where the cgi-script
has sent some data before fully receiving all POSTed data.

httpd.c multiplexes fine using select() and only calls safe_read()
if data is available, whereas full_read() loops over safe_read()
without checking if data is available. In this case read() will
block...

so long,

Hias

--- busybox-1.4.1.orig/networking/httpd.c	2007-01-24 22:34:34.000000000 +0100
+++ busybox-1.4.1/networking/httpd.c	2007-02-11 20:37:01.000000000 +0100
@@ -1211,9 +1211,10 @@
 #if PIPESIZE >= MAX_MEMORY_BUFF
 # error "PIPESIZE >= MAX_MEMORY_BUFF"
 #endif
-			/* NB: was safe_read. If it *has to be* safe_read, */
-			/* please explain why in this comment... */
-			count = full_read(inFd, rbuf, PIPESIZE);
+			/* reverted back to safe_read, otherwise httpd may */
+			/* block if the cgi-script outputs page date before */
+			/* it has fully received all (POST) data */
+			count = safe_read(inFd, rbuf, PIPESIZE);
 			if (count == 0)
 				break;  /* closed */
 			if (count < 0)

From vda.linux at googlemail.com  Sun Feb 11 11:46:29 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 20:46:29 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <20070211194232.GE12488@aon.at>
References: <45CC9E16.9010407@cle-mens.de>
	<200702112008.25916.vda.linux@googlemail.com>
	<20070211194232.GE12488@aon.at>
Message-ID: <200702112046.29354.vda.linux@googlemail.com>

On Sunday 11 February 2007 20:42, Bernhard Fischer wrote:
> On Sun, Feb 11, 2007 at 08:08:25PM +0100, Denis Vlasenko wrote:
> >On Sunday 11 February 2007 19:54, Alexander Griesser wrote:
> 
> >-		dup2(inFd, 0);  // replace stdin with the pipe
> >-		dup2(outFd, 1);  // replace stdout with the pipe
> >+		if (config->accepted_socket > 1)
> >+			close(config->accepted_socket);
> 
> Didn't we have an close_nonstdin?

That one is for stdio (it's fclose, not close) and it
basically does "if (fp != stdin) fclose(fp);"

Not applicable here.
--
vda

From vda.linux at googlemail.com  Sun Feb 11 13:07:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 22:07:25 +0100
Subject: [PATCH] fix httpd lockup in cgi POSTs
In-Reply-To: <20070211193813.GA29704@horus.com>
References: <20070211193813.GA29704@horus.com>
Message-ID: <200702112207.25857.vda.linux@googlemail.com>

On Sunday 11 February 2007 20:38, Matthias Reichl wrote:
> While debugging some lockup problems with the openwrt webif^2 firmware
> upload page I discovered a bug in httpd.c:
> 
> In line 1216 it must really be safe_read(), not full_read().
> Otherwise httpd may lock up in the case where the cgi-script
> has sent some data before fully receiving all POSTed data.
> 
> httpd.c multiplexes fine using select() and only calls safe_read()
> if data is available, whereas full_read() loops over safe_read()
> without checking if data is available. In this case read() will
> block...

Thanks, this was fixed just minutes ago. Please test whether
current svn works for you.
--
vda

From stephane.billiart at gmail.com  Sun Feb 11 14:24:19 2007
From: stephane.billiart at gmail.com (Stephane Billiart)
Date: Sun, 11 Feb 2007 17:24:19 -0500
Subject: tar no longer extracting with setuid bits
Message-ID: <20070211222418.GA4818@tleilax.gmail.com>

While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
setuid files in tar files are no longer created with the setuid bit
while running as root.

The attached patch (which partially reverts r15775 of
archival/libunarchive/data_extract_all.c) fixes the problem.

Any idea why the chmod call was removed?

-- 
St?phane Billiart                      http://perso.orange.fr/billiart/
-------------- next part --------------
--- archival/libunarchive/data_extract_all.c.orig	2007-01-24 16:34:38.000000000 -0500
+++ archival/libunarchive/data_extract_all.c	2007-02-11 17:22:14.000000000 -0500
@@ -111,6 +111,12 @@
 		lchown(file_header->name, file_header->uid, file_header->gid);
 	}
 
+	if (!(archive_handle->flags & ARCHIVE_NOPRESERVE_PERM) &&
+		 (file_header->mode & S_IFMT) !+	{
+		chmod(file_header->name, file_header->mode);
+	}
+
 	if (archive_handle->flags & ARCHIVE_PRESERVE_DATE) {
 		struct utimbuf t;
 		t.actime 

From hias at horus.com  Sun Feb 11 15:49:51 2007
From: hias at horus.com (Matthias Reichl)
Date: Mon, 12 Feb 2007 00:49:51 +0100
Subject: [PATCH] fix httpd lockup in cgi POSTs
In-Reply-To: <200702112207.25857.vda.linux@googlemail.com>
References: <20070211193813.GA29704@horus.com>
	<200702112207.25857.vda.linux@googlemail.com>
Message-ID: <20070211234951.GA893@horus.com>

On Sun, Feb 11, 2007 at 10:07:25PM +0100, Denis Vlasenko wrote:
> Thanks, this was fixed just minutes ago. Please test whether
> current svn works for you.

Seems like I wasn't the only one fighting with this bug :-)

I just ran a quick test with the current svn (httpd only) and
it works fine!

so long,

Hias

From ddaney at avtrex.com  Sun Feb 11 23:23:45 2007
From: ddaney at avtrex.com (David Daney)
Date: Sun, 11 Feb 2007 23:23:45 -0800
Subject: Detecting link state in dhcpc...
In-Reply-To: <a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>	<200702101920.56047.vda.linux@googlemail.com>	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>	<200702110309.32856.vda.linux@googlemail.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
Message-ID: <45D01601.1080501@avtrex.com>

Rogelio Serrano wrote:
> On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>   
>> On Saturday 10 February 2007 19:35, Jason Schoon wrote:
>>     
>>>>> I recall reading on the list recently that someone was thinking about
>>>>> modifying dhcpc to do nice things when the link state changes.
>>>>>
>>>>> Has this been done?
>>>>>
>>>>> If not, I think I will be doing it very soon.
>>>>>           
>>>> Why do you need this?
>>>>
>>>> Windows have such a behavior (of severing all TCP connections
>>>> whenever I need to unplug my network cable for 5 seconds)
>>>> and it is _awful_.
>>>>
>>>> I hope you plan to implement something less annoying then this.
>>>>         

I am testing my patch now.  The behavior is optional in two ways:  The 
link state support is be enabled/disabled at configure time, and then if 
it is present, it is only used if a command line flag is specified.

Linux seems to be nicer than Windows in at least this respect.  A TCP 
connection is only lost if you are assigned a *different* address when 
you re-connect.  Really it is not lost per se, it just never receives 
any more incoming packets, and thus will die if you try to send data 
over it.

>>> Perhaps he is talking more along the lines of doing an automatic renewal
>>> when a link is upped.  For example, plugging into a new network.  You want
>>> to get a new address on that net, not keep using an old one.  I have
>>> implemented that several times in different DHCP clients.
>>>       
>> Why? If I unplug my machine from network, it does NOT
>> automatically mean I should renew DHCP address.
>>
>> It is needed sometimes, but other times (e.g. "I need to unplug
>> my machine for 10 seconds...") it will be utterly inconvenient.
>>
>> If you really want it, perhaps kernel sends a hotplug event
>> or something like it on link down/link up,
>> so you can hook onto it and kill/restart udhcpc?
>> --
>> vda
>> _______________________________________________
>> busybox mailing list
>> busybox at busybox.net
>> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>>
>>     
>
> How does the machine find out by itself that you are "just "unplugging
> for 10 seconds and dont want to renew your address?
>
> I would rather have the adapter renew the address anytime the
> interface goes up. And notify the system that the interface is down
> when the link goes down.
>
>   
For desktop systems it may be debatable if you would want to enable link 
state tracking.  However for some types of embedded systems it can be 
useful.  Since there will be zero runtime overhead when the support for 
link state tracking is disabled, I hope the patch will be acceptable 
(when and if I finish testing it and send it in)

David Daney

From natanael.copa at gmail.com  Mon Feb 12 07:56:21 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 12 Feb 2007 16:56:21 +0100
Subject: tar no longer extracting with setuid bits
In-Reply-To: <20070211222418.GA4818@tleilax.gmail.com>
References: <20070211222418.GA4818@tleilax.gmail.com>
Message-ID: <1171295781.2696.52.camel@localhost>

On Sun, 2007-02-11 at 17:24 -0500, Stephane Billiart wrote:
> While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
> setuid files in tar files are no longer created with the setuid bit
> while running as root.
> 
> The attached patch (which partially reverts r15775 of
> archival/libunarchive/data_extract_all.c) fixes the problem.

aww... this is a problem for me. (just verified, the sudo package on my
alpinelinux distro is broken) Could this please be fixed for 1.4.2 (+ in
trunk ofcourse)

> 
> Any idea why the chmod call was removed?
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox


From albrecht at rdi1.com  Mon Feb 12 07:25:09 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 10:25:09 -0500
Subject: Must really be safe_read(), not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
Message-ID: <1171293909.3280.0.camel@albrecht.rdi1.com>


Reverting the code back to using safe_read doesn't work if you don't fix
the way the first line is handled because you're not guaranteed a full
line with the safe_read.

You can verify this by writing a cgi program which redirects to another
location.

It will intermittently fail. This has nothing to do with how the cgi
program writes to standard output. It's a consequence of the fact that
the server doesn't buffer standard input so it has no right to expect a
full line with its first read of cgi output.

An expedient way to fix the problem is to do the full_read, that is,
receive all the cgi output before handling the first line.

If this is not sufficient then busybox httpd should line buffer standard
input so that it always handles the status line correctly. 

Paul Albrecht

From MatthewLCreech at eaton.com  Mon Feb 12 09:00:47 2007
From: MatthewLCreech at eaton.com (MatthewLCreech at eaton.com)
Date: Mon, 12 Feb 2007 12:00:47 -0500
Subject: Detecting link state in dhcpc...
Message-ID: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>

busybox-bounces at busybox.net wrote:
> 
> In my case, I am talking about an embedded device that is
> essentially useless if not on a network also, so I definitely
> want to be able to take some action if the link goes down as
> well.  In my case it happens that I need to do this in static
> IP case also, so I have a link monitoring daemon that takes
> care of it, rather than adding it to DHCP.

FWIW, I also have an embedded device which needs this kind of behavior,
so I used netplugd:

http://www.red-bean.com/~bos/

The netplugd script that gets run when the carrier state changes either
starts/kills udhcpc, or it runs the appropriate ifconfig commands,
depending on how the device is configured.  It's an easy alternative to
modifying BusyBox, and also keeps things consistent when you're not
using DHCP.  (Which sounds like it might be similar to what you've
already done for the static case)

-- 
Matthew L. Creech

From hias at horus.com  Mon Feb 12 09:09:59 2007
From: hias at horus.com (Matthias Reichl)
Date: Mon, 12 Feb 2007 18:09:59 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171293909.3280.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
Message-ID: <20070212170958.GA17291@horus.com>

On Mon, Feb 12, 2007 at 10:25:09AM -0500, Paul Albrecht wrote:
> Reverting the code back to using safe_read doesn't work if you don't fix
> the way the first line is handled because you're not guaranteed a full
> line with the safe_read.

ACK, you are right.

> An expedient way to fix the problem is to do the full_read, that is,
> receive all the cgi output before handling the first line.
> 
> If this is not sufficient then busybox httpd should line buffer standard
> input so that it always handles the status line correctly. 

If I understand the code correctly, it would be sufficient to do
something like

if (firstline)
    count = full_read(inFd, rbuf, 4);
    /* read 4 bytes so we can check if the line begins with "HTTP" */
} else {
    count = safe_read(inFd, rbuf, PIPESIZE);
}

Better yet, do a full line read for the first line or completely
switch to line buffered input, as you suggested.

so long,

Hias

From vda.linux at googlemail.com  Mon Feb 12 12:52:29 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 21:52:29 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171293909.3280.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
Message-ID: <200702122152.29070.vda.linux@googlemail.com>

On Monday 12 February 2007 16:25, Paul Albrecht wrote:
> 
> Reverting the code back to using safe_read doesn't work if you don't fix
> the way the first line is handled because you're not guaranteed a full
> line with the safe_read.
> 
> You can verify this by writing a cgi program which redirects to another
> location.

Testcase, please?

> It will intermittently fail. This has nothing to do with how the cgi
> program writes to standard output. It's a consequence of the fact that
> the server doesn't buffer standard input so it has no right to expect a
> full line with its first read of cgi output.

We don't care about first line. We care about first four charachers only,
I think.

> An expedient way to fix the problem is to do the full_read, that is,
> receive all the cgi output before handling the first line.
> 
> If this is not sufficient then busybox httpd should line buffer standard
> input so that it always handles the status line correctly. 

Yes, this will even handle the case when CGI writes "HTT" and
"P/1.0 200 OK" separately.
--
vda

From vda.linux at googlemail.com  Mon Feb 12 13:01:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 22:01:13 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <20070212170958.GA17291@horus.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<20070212170958.GA17291@horus.com>
Message-ID: <200702122201.13865.vda.linux@googlemail.com>

On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > If this is not sufficient then busybox httpd should line buffer standard
> > input so that it always handles the status line correctly. 
> 
> If I understand the code correctly, it would be sufficient to do
> something like
> 
> if (firstline)
>     count = full_read(inFd, rbuf, 4);
>     /* read 4 bytes so we can check if the line begins with "HTTP" */

So far I am happy with "bbox httpd doesn't support insane cgis
which split their HTTP response" way.

> } else {
>     count = safe_read(inFd, rbuf, PIPESIZE);
> }
> 
> Better yet, do a full line read for the first line or completely
> switch to line buffered input, as you suggested.

Are you suggesting using stdio?
Can't do that, or POSTDATA will break again.

You basically need to _open-code_ buffering here. Than will work.
--
vda

From vda.linux at googlemail.com  Mon Feb 12 13:03:58 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 22:03:58 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>
References: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>
Message-ID: <200702122203.58972.vda.linux@googlemail.com>

On Monday 12 February 2007 18:00, MatthewLCreech at eaton.com wrote:
> busybox-bounces at busybox.net wrote:
> > 
> > In my case, I am talking about an embedded device that is
> > essentially useless if not on a network also, so I definitely
> > want to be able to take some action if the link goes down as
> > well.  In my case it happens that I need to do this in static
> > IP case also, so I have a link monitoring daemon that takes
> > care of it, rather than adding it to DHCP.
> 
> FWIW, I also have an embedded device which needs this kind of behavior,
> so I used netplugd:
> 
> http://www.red-bean.com/~bos/
> 
> The netplugd script that gets run when the carrier state changes either
> starts/kills udhcpc, or it runs the appropriate ifconfig commands,
> depending on how the device is configured.  It's an easy alternative to
> modifying BusyBox, and also keeps things consistent when you're not
> using DHCP.  (Which sounds like it might be similar to what you've
> already done for the static case)

That's a good solution: add netplugd to bbox as a new applet.
--
vda

From albrecht at rdi1.com  Mon Feb 12 12:38:16 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 15:38:16 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171304015.3598.1.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171304015.3598.1.camel@albrecht.rdi1.com>
Message-ID: <1171312696.3800.8.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 18:09 +0100, Matthias Reichl wrote:
> On Mon, Feb 12, 2007 at 10:25:09AM -0500, Paul Albrecht wrote:
> > Reverting the code back to using safe_read doesn't work if you don't fix
> > the way the first line is handled because you're not guaranteed a full
> > line with the safe_read.
> 
> ACK, you are right.
> 
> > An expedient way to fix the problem is to do the full_read, that is,
> > receive all the cgi output before handling the first line.
> > 
> > If this is not sufficient then busybox httpd should line buffer standard
> > input so that it always handles the status line correctly. 
> 
> If I understand the code correctly, it would be sufficient to do
> something like
> 
> if (firstline)
>     count = full_read(inFd, rbuf, 4);
>     /* read 4 bytes so we can check if the line begins with "HTTP" */
> } else {
>     count = safe_read(inFd, rbuf, PIPESIZE);
> }
> 

Yes, I think that's probably sufficient. The busybox httpd cgi program
interaction is obviously idiosyncratic in that it doesn't parse headers
and expects the cgi program to write the status line if it wants to
return something other than OK status. I think this is usually handled
by using the status header, but I guess I don't really care. As they
say, "When in Rome ..."

:)


> Better yet, do a full line read for the first line or completely
> switch to line buffered input, as you suggested.
> 
> so long,
> 
> Hias
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox

From ddaney at avtrex.com  Mon Feb 12 13:36:10 2007
From: ddaney at avtrex.com (David Daney)
Date: Mon, 12 Feb 2007 13:36:10 -0800
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702122203.58972.vda.linux@googlemail.com>
References: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>
	<200702122203.58972.vda.linux@googlemail.com>
Message-ID: <45D0DDCA.1060808@avtrex.com>

Denis Vlasenko wrote:
> On Monday 12 February 2007 18:00, MatthewLCreech at eaton.com wrote:
>> busybox-bounces at busybox.net wrote:
>>> In my case, I am talking about an embedded device that is
>>> essentially useless if not on a network also, so I definitely
>>> want to be able to take some action if the link goes down as
>>> well.  In my case it happens that I need to do this in static
>>> IP case also, so I have a link monitoring daemon that takes
>>> care of it, rather than adding it to DHCP.
>> FWIW, I also have an embedded device which needs this kind of behavior,
>> so I used netplugd:
>>
>> http://www.red-bean.com/~bos/
>>
>> The netplugd script that gets run when the carrier state changes either
>> starts/kills udhcpc, or it runs the appropriate ifconfig commands,
>> depending on how the device is configured.  It's an easy alternative to
>> modifying BusyBox, and also keeps things consistent when you're not
>> using DHCP.  (Which sounds like it might be similar to what you've
>> already done for the static case)
> 
> That's a good solution: add netplugd to bbox as a new applet.

I am abandoning my patch to add it to udhcpd.

Currently I am looking at running ifplugd to see how that works.  If it 
looks OK, I will add it or netplugd to busybox.

Thanks,
David Daney

From vda.linux at googlemail.com  Mon Feb 12 14:05:00 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:05:00 +0100
Subject: tar no longer extracting with setuid bits
In-Reply-To: <20070211222418.GA4818@tleilax.gmail.com>
References: <20070211222418.GA4818@tleilax.gmail.com>
Message-ID: <200702122305.00198.vda.linux@googlemail.com>

On Sunday 11 February 2007 23:24, Stephane Billiart wrote:
> While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
> setuid files in tar files are no longer created with the setuid bit
> while running as root.
> 
> The attached patch (which partially reverts r15775 of
> archival/libunarchive/data_extract_all.c) fixes the problem.

Applied, thanks!

> Any idea why the chmod call was removed?

Probably because open is creating file with correct mode.
But setuid bits can be lost later.
--
vda

From albrecht at rdi1.com  Mon Feb 12 13:17:23 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 16:17:23 -0500
Subject: Must really be safe_read(), not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <200702122152.29070.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122152.29070.vda.linux@googlemail.com>
Message-ID: <1171315043.3897.33.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 21:52 +0100, Denis Vlasenko wrote: 
> On Monday 12 February 2007 16:25, Paul Albrecht wrote:
> > 
> > Reverting the code back to using safe_read doesn't work if you don't fix
> > the way the first line is handled because you're not guaranteed a full
> > line with the safe_read.
> > 
> > You can verify this by writing a cgi program which redirects to another
> > location.
> 
> Testcase, please?

I have already given you an example in a previous message, but here it
is again: 

echo -en "HTTP/1.0 302 Found\r\n"
echo -en "Location: http://www.busybox.net\r\n"
echo -en "\r\n"

> 
> > It will intermittently fail. This has nothing to do with how the cgi
> > program writes to standard output. It's a consequence of the fact that
> > the server doesn't buffer standard input so it has no right to expect a
> > full line with its first read of cgi output.
> 
> We don't care about first line. We care about first four charachers only,
> I think.
> 

I think the busybox httpd server cgi program interaction is obviously
idiosyncratic in that the server doesn't parse returned headers and
mucks with the status line.

I'm not really complaining, but however you expect the httpd server and
cgi program to interact to get a valid http response back to a user
should work. 

If you're going to write the status line if you don't get one back from
the cgi program you should do that and you're not doing that because
you're using an unbuffered read to get at least four characters of the
first line of cgi output and that doesn't always work.

> > An expedient way to fix the problem is to do the full_read, that is,
> > receive all the cgi output before handling the first line.
> > 
> > If this is not sufficient then busybox httpd should line buffer standard
> > input so that it always handles the status line correctly. 
> 
> Yes, this will even handle the case when CGI writes "HTT" and
> "P/1.0 200 OK" separately.

That's not the problem. For example, if a cgi program writes:

echo -en "HTTP/1.0 302 Found\r\n"

The busybox httpd server has no right to assume it's got more than a
byte of data when a safe_read completes with good status because its
input isn't buffered. 

> --
> 
> vda

From albrecht at rdi1.com  Mon Feb 12 13:33:02 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 16:33:02 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171312135.3800.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<20070212170958.GA17291@horus.com>
	<1171312135.3800.0.camel@albrecht.rdi1.com>
Message-ID: <1171315982.3897.49.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 22:01 +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > > If this is not sufficient then busybox httpd should line buffer standard
> > > input so that it always handles the status line correctly. 
> > 
> > If I understand the code correctly, it would be sufficient to do
> > something like
> > 
> > if (firstline)
> >     count = full_read(inFd, rbuf, 4);
> >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> 
> So far I am happy with "bbox httpd doesn't support insane cgis
> which split their HTTP response" way.
> 

A cgi program doesn't have to "split" its output for the problem to
occur because the data is read over a socket over a network and is not
buffered. There's simply no guarantee an unbuffered read gets a full
line of output from a cgi program however the data gets output.

If, for example, this is the first line of cgi program output:

echo -en "HTTP/1.0 302 Found\r\n

then when the busybox httpd server does its safe_read it can only count
on one byte with good status. It's a fact that usually the read will get
most of if not the entire line but that's not guaranteed because the
read isn't buffered.

> > } else {
> >     count = safe_read(inFd, rbuf, PIPESIZE);
> > }
> > 
> > Better yet, do a full line read for the first line or completely
> > switch to line buffered input, as you suggested.
> 
> Are you suggesting using stdio?
> Can't do that, or POSTDATA will break again.
> 
> You basically need to _open-code_ buffering here. Than will work.
> --
> 
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox

From hias at horus.com  Mon Feb 12 14:21:55 2007
From: hias at horus.com (Matthias Reichl)
Date: Mon, 12 Feb 2007 23:21:55 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <200702122201.13865.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<20070212170958.GA17291@horus.com>
	<200702122201.13865.vda.linux@googlemail.com>
Message-ID: <20070212222155.GB17291@horus.com>

On Mon, Feb 12, 2007 at 10:01:13PM +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > if (firstline)
> >     count = full_read(inFd, rbuf, 4);
> >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> 
> So far I am happy with "bbox httpd doesn't support insane cgis
> which split their HTTP response" way.

Would be OK for me, too. OTOH: it's a simple patch and it assures
that the current httpd could also deal with insane cgis.

> > Better yet, do a full line read for the first line or completely
> > switch to line buffered input, as you suggested.
> 
> Are you suggesting using stdio?
4> Can't do that, or POSTDATA will break again.
> 
> You basically need to _open-code_ buffering here. Than will work.

No, I was thinking about using a function like getLine() when
reading the first line from the cgi. But that's not needed ATM
and would only be useful for future versions of httpd if they'd like
to parse the full first line.

To clean up the patch a little bit more, I'd suggest something like
this:

static const char HTTP_200[] = "HTTP/1.0 200 OK\r\n\r\n";
/* httpd only checks for a response beginning with "HTTP" */
/* in the first line of cgi output */
#define HTTP_200_check_len 4
if (firstline)
	count = full_read(inFd, rbuf, HTTP_200_check_len);
} else {
	count = safe_read(inFd, rbuf, PIPESIZE);
}
...
	if (memcmp(rbuf, HTTP_200, HTTP_200_check_len) != 0) {
...
#undef HTTP_200_check_len

AFAICT this should work fine and it's clear for other developers.

The only thing that may go wrong is a cgi that outputs only
something like "hi\n" and then waits for POST data. Also insane,
and can only be handled with a getLine()-like approach.

so long,

Hias

From vda.linux at googlemail.com  Mon Feb 12 14:25:17 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:25:17 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171315043.3897.33.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122152.29070.vda.linux@googlemail.com>
	<1171315043.3897.33.camel@albrecht.rdi1.com>
Message-ID: <200702122325.17826.vda.linux@googlemail.com>

On Monday 12 February 2007 22:17, Paul Albrecht wrote:
> On Mon, 2007-02-12 at 21:52 +0100, Denis Vlasenko wrote: 
> > On Monday 12 February 2007 16:25, Paul Albrecht wrote:
> > > 
> > > Reverting the code back to using safe_read doesn't work if you don't fix
> > > the way the first line is handled because you're not guaranteed a full
> > > line with the safe_read.
> > > 
> > > You can verify this by writing a cgi program which redirects to another
> > > location.
> > 
> > Testcase, please?
> 
> I have already given you an example in a previous message, but here it
> is again: 
> 
> echo -en "HTTP/1.0 302 Found\r\n"
> echo -en "Location: http://www.busybox.net\r\n"
> echo -en "\r\n"

#!/bin/sh
echo -en "HTTP/1.0 302 Found\r\n"
echo -en "Location: http://www.busybox.net\r\n"
echo -en "\r\n"

Works for me 

> I think the busybox httpd server cgi program interaction is obviously
> idiosyncratic in that the server doesn't parse returned headers and
> mucks with the status line.
> 
> I'm not really complaining, but however you expect the httpd server and
> cgi program to interact to get a valid http response back to a user
> should work.

bbox applets usually start small and then add features / fix bugs
in the order of severity.

> If you're going to write the status line if you don't get one back from
> the cgi program you should do that and you're not doing that because
> you're using an unbuffered read to get at least four characters of the
> first line of cgi output and that doesn't always work.

I will gladly take good patch which does said buffering.

> > Yes, this will even handle the case when CGI writes "HTT" and
> > "P/1.0 200 OK" separately.
> 
> That's not the problem. For example, if a cgi program writes:
> 
> echo -en "HTTP/1.0 302 Found\r\n"
> 
> The busybox httpd server has no right to assume it's got more than a
> byte of data when a safe_read completes with good status because its
> input isn't buffered. 

Sorry, I don't understand this part. If cgi writes "HTTP/1.0 302 Found\r\n"
using one write syscall, httpd will read the same number of bytes (not less).
--
vda

From vda.linux at googlemail.com  Mon Feb 12 14:28:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:28:33 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171315982.3897.49.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171312135.3800.0.camel@albrecht.rdi1.com>
	<1171315982.3897.49.camel@albrecht.rdi1.com>
Message-ID: <200702122328.33155.vda.linux@googlemail.com>

On Monday 12 February 2007 22:33, Paul Albrecht wrote:
> > So far I am happy with "bbox httpd doesn't support insane cgis
> > which split their HTTP response" way.
> > 
> 
> A cgi program doesn't have to "split" its output for the problem to
> occur because the data is read over a socket over a network and is not
> buffered. There's simply no guarantee an unbuffered read gets a full
> line of output from a cgi program however the data gets output.

No, data is written thru the local pipe from cgi to httpd process.
--
vda

From vda.linux at googlemail.com  Mon Feb 12 14:34:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:34:03 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <20070212222155.GB17291@horus.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122201.13865.vda.linux@googlemail.com>
	<20070212222155.GB17291@horus.com>
Message-ID: <200702122334.03094.vda.linux@googlemail.com>

On Monday 12 February 2007 23:21, Matthias Reichl wrote:
> On Mon, Feb 12, 2007 at 10:01:13PM +0100, Denis Vlasenko wrote:
> > On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > > if (firstline)
> > >     count = full_read(inFd, rbuf, 4);
> > >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> > 
> > So far I am happy with "bbox httpd doesn't support insane cgis
> > which split their HTTP response" way.
> 
> Would be OK for me, too. OTOH: it's a simple patch and it assures
> that the current httpd could also deal with insane cgis.

NO, IT CAN'T.

If cgi will output "HTT" and then block in read() from fd#0
while httpd is also blocked in full_read() trying to get at least
four bytes, we will deadlock.

> > > Better yet, do a full line read for the first line or completely
> > > switch to line buffered input, as you suggested.
> > 
> > Are you suggesting using stdio?
> 4> Can't do that, or POSTDATA will break again.
> > 
> > You basically need to _open-code_ buffering here. Than will work.
> 
> No, I was thinking about using a function like getLine() when
> reading the first line from the cgi. But that's not needed ATM
> and would only be useful for future versions of httpd if they'd like
> to parse the full first line.
--
vda

From hias at horus.com  Mon Feb 12 16:42:51 2007
From: hias at horus.com (Matthias Reichl)
Date: Tue, 13 Feb 2007 01:42:51 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <200702122334.03094.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122201.13865.vda.linux@googlemail.com>
	<20070212222155.GB17291@horus.com>
	<200702122334.03094.vda.linux@googlemail.com>
Message-ID: <20070213004251.GA26535@horus.com>

On Mon, Feb 12, 2007 at 11:34:03PM +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 23:21, Matthias Reichl wrote:
> > Would be OK for me, too. OTOH: it's a simple patch and it assures
> > that the current httpd could also deal with insane cgis.
> 
> NO, IT CAN'T.
> 
> If cgi will output "HTT" and then block in read() from fd#0
> while httpd is also blocked in full_read() trying to get at least
> four bytes, we will deadlock.

OK, you are right. We have to avoid deadlock situations,

Here's a new patch. It delays the header check against "HTTP" until
enough bytes are read from the CGI. All this is done non-blocking.
In case of a premature EOF (eg CGI only writing "hi\n") a
"HTTP/1.0 200 OK" plus the data is sent. The rest of the code is
as before.

I hope this fixes the issues (at the moment :-)

so long,

Hias
-------------- next part --------------
--- busybox-svn.orig/networking/httpd.c	2007-02-11 23:29:09.000000000 +0100
+++ busybox-svn/networking/httpd.c	2007-02-13 01:36:58.000000000 +0100
@@ -1137,6 +1137,14 @@
 		fd_set readSet;
 		fd_set writeSet;
 		char wbuf[128];
+		/* default response if not set by cgi */
+		static const char HTTP_200[] = "HTTP/1.0 200 OK\r\n\r\n";
+		/* only check the first 4 bytes of cgi response (for "HTTP") */
+#define HTTP_200_CHECK_LEN 4
+#if HTTP_200_CHECK_LEN >= MAX_MEMORY_BUFF
+# error "HTTP_200_CHECK_LEN >= MAX_MEMORY_BUFF"
+#endif
+		int fcount = 0; /* byte counter for first line */
 		int nfound;
 		int count;
 
@@ -1206,41 +1214,59 @@
 			/* There is something to read from CGI */
 			int s = config->accepted_socket;
 			char *rbuf = config->buf;
+			if (firstLine) {
+				/* try to read the first bytes of the CGI response so we can
+				 * check if it contained a HTTP/x.y ... response
+				 * note: do it non-blocking, otherwise httpd might deadlock! */
+				count = safe_read(inFd, rbuf + fcount, HTTP_200_CHECK_LEN - fcount);
+				if (count == 0) {
+					/* eof and we couldn't check for a valid HTTP/... header,
+					 * so add one and write out the received data */
+					if (fcount) {
+							full_write(s, HTTP_200, sizeof(HTTP_200)-1);
+							full_write(s, rbuf, fcount);
+					}
+					break;  /* closed */
+				}
+				if (count < 0)
+					continue; /* huh, error, why continue?? */
+
+				fcount += count;
+
+				if (fcount == HTTP_200_CHECK_LEN) {
+					rbuf[fcount] = '\0';
+					/* check to see if the user script added headers */
+					/* (NB: buggy wrt cgi splitting "HTTP OK") */
+					if (memcmp(rbuf, HTTP_200, HTTP_200_CHECK_LEN) != 0) {
+						/* there is no "HTTP", do it ourself */
+						if (full_write(s, HTTP_200, sizeof(HTTP_200)-1) != sizeof(HTTP_200)-1)
+							break;
+					}
+					/* Example of valid GCI without "Content-type:"
+					 * echo -en "HTTP/1.0 302 Found\r\n"
+					 * echo -en "Location: http://www.busybox.net\r\n"
+					 * echo -en "\r\n"
+					if (!strstr(rbuf, "ontent-")) {
+						full_write(s, "Content-type: text/plain\r\n\r\n", 28);
+					}
+					 */
+					if (full_write(s, rbuf, fcount) != fcount)
+						break;
+					firstLine = 0;
+				}
+			} else {
 #define PIPESIZE PIPE_BUF
 #if PIPESIZE >= MAX_MEMORY_BUFF
 # error "PIPESIZE >= MAX_MEMORY_BUFF"
 #endif
-			/* Must use safe_read, not full_read, because
-			 * cgi may output a few first lines and then wait
-			 * for POSTDATA without closing stdout.
-			 * With full_read we may wait here forever. */
-			count = safe_read(inFd, rbuf, PIPESIZE);
-			if (count == 0)
-				break;  /* closed */
-			if (count < 0)
-				continue; /* huh, error, why continue?? */
-
-			if (firstLine) {
-				static const char HTTP_200[] = "HTTP/1.0 200 OK\r\n\r\n";
-				rbuf[count] = '\0';
-				/* check to see if the user script added headers */
-				/* (NB: buggy wrt cgi splitting "HTTP OK") */
-				if (memcmp(rbuf, HTTP_200, 4) != 0) {
-					/* there is no "HTTP", do it ourself */
-					full_write(s, HTTP_200, sizeof(HTTP_200)-1);
-				}
-				/* Example of valid GCI without "Content-type:"
-				 * echo -en "HTTP/1.0 302 Found\r\n"
-				 * echo -en "Location: http://www.busybox.net\r\n"
-				 * echo -en "\r\n"
-				if (!strstr(rbuf, "ontent-")) {
-					full_write(s, "Content-type: text/plain\r\n\r\n", 28);
-				}
-				 */
-				firstLine = 0;
+				count = safe_read(inFd, rbuf, PIPESIZE);
+				if (count == 0)
+					break;  /* closed */
+				if (count < 0)
+					continue; /* huh, error, why continue?? */
+				if (full_write(s, rbuf, count) != count)
+					break;
 			}
-			if (full_write(s, rbuf, count) != count)
-				break;
 			if (DEBUG)
 				fprintf(stderr, "cgi read %d bytes: '%.*s'\n", count, count, rbuf);
 		} /* if (FD_ISSET(inFd)) */

From vapier at gentoo.org  Mon Feb 12 16:56:25 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 12 Feb 2007 19:56:25 -0500
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702111530.45440.vda.linux@googlemail.com>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702102355.09483.vapier@gentoo.org>
	<200702111530.45440.vda.linux@googlemail.com>
Message-ID: <200702121956.26551.vapier@gentoo.org>

On Sunday 11 February 2007, Denis Vlasenko wrote:
> On Sunday 11 February 2007 05:55, Mike Frysinger wrote:
> > this wont be terribly robust as what if /dev/ is readonly and /dev/log is
> > a relative symlink ... you'd have to make sure you chroot(/dev/) first
>
> I hope chdir("/dev") would suffice ;)

err, sorry ... you are correct of course, i meant chdir() ... i seem to typo 
those quite frequently :/
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070212/728f0a25/attachment.pgp 

From gcohn at optusnet.com.au  Mon Feb 12 22:58:26 2007
From: gcohn at optusnet.com.au (Gerry Cohn)
Date: Tue, 13 Feb 2007 17:58:26 +1100
Subject: Udhcpc problem
Message-ID: <001301c74f3c$5bfd7dc0$0914a8c0@glap>

Hi all,
 
I am using BusyBox v1.00 (2005.08.15-23:44+0000) multi-call binary as part
of an embedded system based on the PXA270 processor.
Recently I have discovered a problem that has me baffled.
 
Up until a few days ago, no matter what dhcp server was used, I could
successfully obtain a lease.
I am now trying to use a Thomson Speedtouch 536 v6 Modem/Router and am
finding that the DHCPOFFER messages are being rejected.
I have also found that exactly the same thing happens with a Dynalink
RTA1320 modem/router.
Both of these units are based on Broadcom chips.
 
I am now at my wits end with this.
 
If anyone can offer any advice regarding a fix for this problem, I would be
forever grateful.
 
Regards,
 
Gerry Cohn

From bogus@does.not.exist.com  Mon Feb  5 23:08:39 2007
From: bogus@does.not.exist.com ()
Date: Tue, 06 Feb 2007 07:08:39 -0000
Subject: No subject
Message-ID: <mailman.4.1171351145.4267.busybox@busybox.net>

------=_NextPart_000_0014_01C74F98.8F6DF5C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>I am =
using BusyBox=20
v1.00 (2005.08.15-23:44+0000) multi-call binary as part of an embedded =
system=20
based on the PXA270 processor.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial =
size=3D2>Recently I have=20
discovered a problem that has me baffled.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>Up =
until a few days=20
ago, no matter what dhcp server was used, I could successfully obtain a=20
lease.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>I am =
now trying to=20
use a Thomson Speedtouch 536 v6 Modem/Router and am finding that the =
DHCPOFFER=20
messages are being rejected.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>I have =
also found=20
that exactly the same thing happens with a Dynalink RTA1320=20
modem/router.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>Both =
of these units=20
are based on Broadcom chips.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>I am =
now at my wits=20
end with this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>If =
anyone can offer=20
any advice regarding a fix for this problem, I would be forever=20
grateful.</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>Gerry=20
Cohn</FONT></SPAN></DIV>
<DIV><SPAN class=3D539264805-13022007><FONT face=3DArial size=3D2>From =
the land down=20
under</FONT></SPAN></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0014_01C74F98.8F6DF5C0--



From natanael.copa at gmail.com  Tue Feb 13 00:31:47 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Tue, 13 Feb 2007 09:31:47 +0100
Subject: tar no longer extracting with setuid bits
In-Reply-To: <200702122305.00198.vda.linux@googlemail.com>
References: <20070211222418.GA4818@tleilax.gmail.com>
	<200702122305.00198.vda.linux@googlemail.com>
Message-ID: <1171355507.2696.109.camel@localhost>

On Mon, 2007-02-12 at 23:05 +0100, Denis Vlasenko wrote:
> On Sunday 11 February 2007 23:24, Stephane Billiart wrote:
> > While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
> > setuid files in tar files are no longer created with the setuid bit
> > while running as root.
> > 
> > The attached patch (which partially reverts r15775 of
> > archival/libunarchive/data_extract_all.c) fixes the problem.
> 
> Applied, thanks!

Could this also be added to fixes-1.4.1, please?

Thanks!

Natanael Copa


From albrecht at rdi1.com  Tue Feb 13 05:34:40 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Tue, 13 Feb 2007 08:34:40 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171316917.4039.3.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122201.13865.vda.linux@googlemail.com>
	<20070212222155.GB17291@horus .com>
	<1171316917.4039.3.camel@albrecht.rdi1.com>
Message-ID: <1171373680.2437.13.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 23:34 +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 23:21, Matthias Reichl wrote:
> > On Mon, Feb 12, 2007 at 10:01:13PM +0100, Denis Vlasenko wrote:
> > > On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > > > if (firstline)
> > > >     count = full_read(inFd, rbuf, 4);
> > > >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> > > 
> > > So far I am happy with "bbox httpd doesn't support insane cgis
> > > which split their HTTP response" way.
> > 
> > Would be OK for me, too. OTOH: it's a simple patch and it assures
> > that the current httpd could also deal with insane cgis.
> 
> NO, IT CAN'T.
> 
> If cgi will output "HTT" and then block in read() from fd#0
> while httpd is also blocked in full_read() trying to get at least
> four bytes, we will deadlock.
> 

This scenario seems far fetched because http is a request/response
protocol.  It doesn't make a lot of sense for a cgi program to start
producing output--the http response--before it has read and processed
request.

> > > > Better yet, do a full line read for the first line or completely
> > > > switch to line buffered input, as you suggested.
> > > 
> > > Are you suggesting using stdio?
> > 4> Can't do that, or POSTDATA will break again.
> > > 
> > > You basically need to _open-code_ buffering here. Than will work.
> > 
> > No, I was thinking about using a function like getLine() when
> > reading the first line from the cgi. But that's not needed ATM
> > and would only be useful for future versions of httpd if they'd like
> > to parse the full first line.
> --
> 
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox

From albrecht at rdi1.com  Tue Feb 13 05:58:50 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Tue, 13 Feb 2007 08:58:50 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <200702122328.33155.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171312135.3800.0.camel@albrecht.rdi1.com>
	<1171315982.3897.49.camel@albrecht.rdi1.com>
	<200702122328.33155.vda.linux@googlemail.com>
Message-ID: <1171375130.2437.36.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 23:28 +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 22:33, Paul Albrecht wrote:
> > > So far I am happy with "bbox httpd doesn't support insane cgis
> > > which split their HTTP response" way.
> > > 
> > 
> > A cgi program doesn't have to "split" its output for the problem to
> > occur because the data is read over a socket over a network and is not
> > buffered. There's simply no guarantee an unbuffered read gets a full
> > line of output from a cgi program however the data gets output.
> 
> No, data is written thru the local pipe from cgi to httpd process.

Yes, of course, the cgi program and busybox httpd server communicate
over a pipe, not a tcp socket.

However, I still think that because the read syscall is unbuffered you
can't assume that if you write x bytes to one end of the pipe you're
guaranteed x bytes on the *first* read on the other end of the pipe.

I think you're supposed to check the number of bytes read and continue
doing reads until you get as much data as you're expecting or get end of
file.

Finally, whether you accept this explanation or not it's a fact that the
simple cgi program I posted in my previous message fails intermittently.

From ddaney at avtrex.com  Tue Feb 13 10:28:13 2007
From: ddaney at avtrex.com (David Daney)
Date: Tue, 13 Feb 2007 10:28:13 -0800
Subject: bb_sanitize_stdio_maybe_daemonize faulty logic...
Message-ID: <45D2033D.9030908@avtrex.com>

Consider this program:

---------------------------------------
#include <stdio.h>
#include <sys/socket.h>


static int open_a_socket()
{
     int s = socket(PF_INET, SOCK_DGRAM, 0);
     printf("Opened on fd %d\n", s);
     return s;
}


int
main(int argc, char *argv[])
{
     int c;

     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     c = open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();

     close(c);
     open_a_socket();

     return 0;
}
-----------------------------------

Note that the last open reuses the fd of the closed socket, but there 
are a lot of open sockets with fd values greater than the last socket 
opened.

Now look at bb_sanitize_stdio_maybe_daemonize:

-----------------------------------------
void bb_sanitize_stdio_maybe_daemonize(int daemonize)
{
         int fd;
         /* Mega-paranoid */
         fd = xopen(bb_dev_null, O_RDWR);
         while ((unsigned)fd < 2)
                 fd = dup(fd); /* have 0,1,2 open at least to /dev/null */
         if (daemonize) {
                 pid_t pid = fork();
                 if (pid < 0) /* wtf? */
                         bb_perror_msg_and_die("fork");
                 if (pid) /* parent */
                         exit(0);
                 /* child */
                 /* if daemonizing, make sure we detach from stdio */
                 setsid();
                 dup2(fd, 0);
                 dup2(fd, 1);
                 dup2(fd, 2);
         }
         while (fd > 2)
                 close(fd--); /* close everything after fd#2 */
}
-----------------------------------------

The result of the first xopen is used as a marker to try to find the 
highest active descriptor.  Then all descriptors greater than 2 and less 
than the marker are closed.

The problem is that the marker could fall in a hole in the middle of the 
range of open descriptors (as in the top example), in which case 
bb_sanitize_stdio_maybe_daemonize could leave some descriptors open that 
should have been closed.

David Daney

From hias at horus.com  Wed Feb 14 01:56:34 2007
From: hias at horus.com (Matthias Reichl)
Date: Wed, 14 Feb 2007 10:56:34 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <200702132355.14322.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122334.03094.vda.linux@googlemail.com>
	<20070213004251.GA26535@horus.com>
	<200702132355.14322.vda.linux@googlemail.com>
Message-ID: <20070214095634.GB901@horus.com>

On Tue, Feb 13, 2007 at 11:55:14PM +0100, Denis Vlasenko wrote:
> +???????????????int fcount = 0; /* byte counter for first line */
> 
> You reset counter on each while() iteration

Thanks, you are right. It's in the wrong scope.

> +???????????????????????????????if (fcount == HTTP_200_CHECK_LEN) {
> +???????????????????????????????????????rbuf[fcount] = '\0';
> 
> What is the purpose of rbuf[fcount] = '\0' ?

Nothing. This is just old copied code. It was "rbuf[count] = '\0'"
before, used by the (removed) "strstr..." check.

so long,

Hias

From rep.dot.nop at gmail.com  Wed Feb 14 02:51:07 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Wed, 14 Feb 2007 11:51:07 +0100
Subject: [PATCH, CFT] fix awk -v -v handling
Message-ID: <20070214105107.GA28069@aon.at>

Hi,

<wihen> can anyone confirm if awk is broken on 1.4.1?
<wihen> multiple -v don't work.

Confirmed. The attached, untested patch against trunk should fix it.

Please verify and apply to trunk and the 1_4 branch.

TIA and cheers,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox_trunk.awk-option-v-handling.patch
Type: text/x-diff
Size: 876 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070214/e40df374/attachment.bin 

From vapier at gentoo.org  Wed Feb 14 05:00:33 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Feb 2007 08:00:33 -0500
Subject: stop ignoring initramfs in df ?
Message-ID: <200702140800.33665.vapier@gentoo.org>

so i started to add a df build option, "ignore initramfs mount", that would 
control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
that in embedded/bootable systems, it is common to run right out of the 
initramfs rather than switching over to a "normal" root

however, i cant decide whether this warrants an actual build option ... the 
trade offs are that in the desktop case, you'd never want to see the rootfs 
output ... but does controlling literally 2 lines of code offset this ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070214/055ac0e3/attachment.pgp 

From ddaney at avtrex.com  Wed Feb 14 08:53:57 2007
From: ddaney at avtrex.com (David Daney)
Date: Wed, 14 Feb 2007 08:53:57 -0800
Subject: Patch: Fix zcip deamonization...
Message-ID: <45D33EA5.7050804@avtrex.com>

The mailing list was broken yesterday.  I am resending this message:

-------- Original Message --------
Subject: Patch: Fix zcip deamonization...
Date: Tue, 13 Feb 2007 13:09:24 -0800
From: David Daney <ddaney at avtrex.com>
To: busybox at busybox.net

In r17390 the call to xdaemon(0, 0) was replaced with a call to
bb_daemonize().  This does not work because bb_daemonize() closes all
open file descriptors and zcip opens its socket before daemonzing.


The fix is to revert to using xdaemon(0, 0).  I also removed the call to
setsid(), as it is usless in this context.

Please commit if OK.

Thanks
David Daney

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zcip.diff
Type: text/x-patch
Size: 361 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070214/293ba11b/attachment.bin 

From ddaney at avtrex.com  Wed Feb 14 10:54:43 2007
From: ddaney at avtrex.com (David Daney)
Date: Wed, 14 Feb 2007 10:54:43 -0800
Subject: bb_sanitize_stdio_maybe_daemonize faulty logic...
In-Reply-To: <200702141920.05128.vda.linux@googlemail.com>
References: <45D2033D.9030908@avtrex.com>
	<200702140044.09317.vda.linux@googlemail.com>
	<45D252A8.1020301@avtrex.com>
	<200702141920.05128.vda.linux@googlemail.com>
Message-ID: <45D35AF3.9090409@avtrex.com>

Denis Vlasenko wrote:
> On Wednesday 14 February 2007 01:07, David Daney wrote:
>>>>>> Yes, I know. Have better ideas (apart from closing all fds from 
>>>>>> 9999999999 to 3)?
>>>>> It is a difficult problem.  In practice you don't have to go all the way 
>>>>> to 9999999999, the value returned by ulimit -n would be high enough.
>>>>>
>>>>> You could also set the close-on-exec flag on all descriptors that should 
>>>>> not leak from busybox, then you would not need this part.
>>> You see, this function isn't meant to be 100.00% watertight.
>>>
>>> It just tries to close some stray opne fds, but does not
>>> promise to do it reliably for all weird cases.
>>>
>> It could easily be made 100% by:
>>
>> struct rlimit rl;
>> int i;
>> getrlimit(RLIMIT_NOFILE, &rl);
>> for (i = 3; i < rl.rlim_cur; i++)
>>      close(i);
> 
> This is what I meant by "close all fds from 9999999 to 3".

Fine.  You are the maintainer.  1024 is quite a bit smaller than 
9999999, but if you think it is useful as it is then I will not get too 
worked up about it.

David Daney

From vda.linux at googlemail.com  Wed Feb 14 12:47:58 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 14 Feb 2007 21:47:58 +0100
Subject: Patch: Fix zcip deamonization...
In-Reply-To: <45D33EA5.7050804@avtrex.com>
References: <45D33EA5.7050804@avtrex.com>
Message-ID: <200702142147.58814.vda.linux@googlemail.com>

On Wednesday 14 February 2007 17:53, David Daney wrote:
> The mailing list was broken yesterday.  I am resending this message:
> 
> -------- Original Message --------
> Subject: Patch: Fix zcip deamonization...
> Date: Tue, 13 Feb 2007 13:09:24 -0800
> From: David Daney <ddaney at avtrex.com>
> To: busybox at busybox.net
> 
> In r17390 the call to xdaemon(0, 0) was replaced with a call to
> bb_daemonize().  This does not work because bb_daemonize() closes all
> open file descriptors and zcip opens its socket before daemonzing.
> 
> 
> The fix is to revert to using xdaemon(0, 0).  I also removed the call to
> setsid(), as it is usless in this context.
> 
> Please commit if OK.

DOH! :(  Thanks!
--
vda

From vda.linux at googlemail.com  Wed Feb 14 12:51:39 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 14 Feb 2007 21:51:39 +0100
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702140800.33665.vapier@gentoo.org>
References: <200702140800.33665.vapier@gentoo.org>
Message-ID: <200702142151.39680.vda.linux@googlemail.com>

On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> so i started to add a df build option, "ignore initramfs mount", that would 
> control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> that in embedded/bootable systems, it is common to run right out of the 
> initramfs rather than switching over to a "normal" root
> 
> however, i cant decide whether this warrants an actual build option ... the 
> trade offs are that in the desktop case, you'd never want to see the rootfs 
> output ... but does controlling literally 2 lines of code offset this ?

I don't know what is a rationale for hiding that. It _is_ mounted there, right?
So why we are lying to user that it isn't there?

In my opinion we should just remove this feature.
--
vda

From vapier at gentoo.org  Wed Feb 14 14:34:48 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Feb 2007 17:34:48 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702142151.39680.vda.linux@googlemail.com>
References: <200702140800.33665.vapier@gentoo.org>
	<200702142151.39680.vda.linux@googlemail.com>
Message-ID: <200702141734.48564.vapier@gentoo.org>

On Wednesday 14 February 2007, Denis Vlasenko wrote:
> On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> > so i started to add a df build option, "ignore initramfs mount", that
> > would control the hardcoded filter in df.c for the "rootfs" mount ...
> > idea being that in embedded/bootable systems, it is common to run right
> > out of the initramfs rather than switching over to a "normal" root
> >
> > however, i cant decide whether this warrants an actual build option ...
> > the trade offs are that in the desktop case, you'd never want to see the
> > rootfs output ... but does controlling literally 2 lines of code offset
> > this ?
>
> I don't know what is a rationale for hiding that. It _is_ mounted there,
> right?

a small initramfs is always mounted in 2.6 kernels ... for most systems 
though, it isnt actually used

> So why we are lying to user that it isn't there? 

because to the layman, it can be confusing wtf this tiny little rootfs mount 
is about

> In my opinion we should just remove this feature.

i'm ok with that :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070214/0cbedc75/attachment.pgp 

From rep.dot.nop at gmail.com  Thu Feb 15 06:12:43 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 15 Feb 2007 15:12:43 +0100
Subject: make tar restore mode again [was: Re: svn commit:
	trunk/busybox/archival/libunarchive]
In-Reply-To: <20070212220658.50DDB485CC@busybox.net>
References: <20070212220658.50DDB485CC@busybox.net>
Message-ID: <20070215141243.GD18188@aon.at>

On Mon, Feb 12, 2007 at 02:06:58PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-12 14:06:56 -0800 (Mon, 12 Feb 2007)
>New Revision: 17869
>
>Log:
>make tar restore mode again
>
>
>Modified:
>   trunk/busybox/archival/libunarchive/data_extract_all.c

vda, mind also fixing this on the 1_4_branch, please?


From akennedy at techmoninc.com  Thu Feb 15 08:19:27 2007
From: akennedy at techmoninc.com (Andy Kennedy)
Date: Thu, 15 Feb 2007 10:19:27 -0600
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <20070209211142.GY12488@aon.at>
References: <45C0EA70.4080508@techmoninc.com> <45C0EBB2.1090604@seiner.com>
	<45C0F180.4000904@techmoninc.com> <45C11D80.20906@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com> <45CCCF5D.6040203@techmoninc.com>
	<20070209211142.GY12488@aon.at>
Message-ID: <45D4880F.7030607@techmoninc.com>

Bernhard Fischer wrote:
> On Fri, Feb 09, 2007 at 01:45:33PM -0600, Andy Kennedy wrote:
>   
>> Andy Kennedy wrote:
>>     
>>> To restate my problem (in case some kind developer decides to help me):
>>>
>>> When I have the kernel command line parameter "console=ttyS0,115200n8" 
>>> I get nice neat output on the serial line up until the init runs.  As 
>>> soon as init runs, I get missing chars.  So, I replace the BusyBox 
>>> init with minit, compiled from source and using the uCLibC gcc that I 
>>> let buildroot make for me.  Same problem.  For some reason, when the 
>>> system initializes -- after the kernel has reported all of its output, 
>>> my serial console goes splat.  When I initialize the console using 
>>> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
>>> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
>>> One of these letters will appear each time I send enter.
>>>
>>> I have tried everything I can think of.  There is no script setting 
>>> any of the line speeds -- in fact, I have even attempted to remove the 
>>> scripts and still get the same thing.  Removing the 
>>> console=ttyS0,115200n8 (or attempting any variant of it) has no 
>>> affect, except without the console= I get no good output on the line.  
>>> The only thing I haven't attempted yet is to replace the getty with an 
>>> equivalent to see if that makes a difference.  I have also tried 9600, 
>>> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
>>> every combination, but I still cannot get a serial console.
>>>
>>> Can anyone offer a suggestion as to how I might fix this -- or some 
>>> other place to start?
>>>
>>> Thanks in advance for any help you can offer,
>>> Andy
>>>       
>> Okay, now I'm really confused.  Here is what I have done so far:
>> Made my laptop boot with a console on ttyS0 and put a login shell on it 
>> (to verify that I can do it -- I was beginning to think maybe I needed 
>> to remove Linux from my computer and get rid of all of  it being to 
>> stupid to own a computer, much less program an embedded system) and I 
>> had no problems.  So, I took my syslinux disk and booted from it (the 
>> SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
>> everything comes up as you would expect.
>>
>> Given that this test worked there is one of about three possibilities:
>> 1) Cable issue.  Tested my serial cable on another embedded system (an 
>> Arcom Viper), checks out.  Replaced the break-out cable from the 
>> embedded system -- failed.  Tried a known good cable -- failed.  Tested 
>> a different VersaLogic board -- failed.  Now, here is the part that 
>> really yanked me around:
>>
>> The last time I booted the machine I didn't have the keyboard connected 
>> to the break-out cable.  The boot went as it normally does except the 
>> keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
>> BusyBox init takes over the console and prints all kind of whack.  I 
>> plug in the keyboard and the keyboard driver prints a perfect string 
>> onto the serial console.
>>
>> I've looked through the code to see what type of initialization init is 
>> doing to the console, but it doesn't look like it is re-initializing the 
>> sucker at all.  The only thing that I can think is that BusyBox is doing 
>> something that Linux doesn't do to interact with the ttyS0 so I'm not 
>> getting what I expect.
>>     
>
> IIRC busybox's init doesn't do anything special for serial lines.
>
> As vda already suggested, better seek help on lkml or try to find
> somebody to whom that <char><space><char>.. pattern sounds familiar.
>   
Found the problem.  Wasn't a bug in BusyBox, wasn't that I didn't know 
what I was doing either.  Found that the computer that has the UART 
16550A is configured such that the serial detection algorithm of Linux 
didn't see it as a 16550A, but a 16750.  Difference being that the 
16550A has a 16-Byte buffer, whereas the 16750 has a 64-byte buffer.  
The kernel, using the 16750 command set, waited for the buffer to get 
full, thus anything written to the serial line was getting trashed.  I 
have modified my kernel, for this specific computer, to "manually" set 
the kernel to 16550A as the serial interface.

So, with BusyBox's init, an inittab line of "ttyS0::respawn:-/bin/sh", 
and a kernel command line parameter of "console=ttyS0,115200n8" I get a 
nice, shiny, WORKING console and terminal on the serial port.

Thanks to all you that helped me with issue as your support led me to 
the underlying hardware issue.

Andy Kennedy

From ynakam at hitachisoft.jp  Wed Feb 14 23:37:01 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 15 Feb 2007 16:37:01 +0900
Subject: [PATCH 6/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155456.2d016051.ynakam@hitachisoft.jp>
References: <20070208155456.2d016051.ynakam@hitachisoft.jp>
Message-ID: <20070215163701.21d93627.ynakam@hitachisoft.jp>

On Thu, 8 Feb 2007 15:54:56 +0900
Yuichi Nakamura  wrote:

> [6/6] busybox-coreutils-06-id.patch
>  - -Z option support for id. Security context of process is shown by -Z option.
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> 
> 
> 

We found that -Z,-u,-g are exclusive, and modified previous patch.
Please review attached patch.

-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-id-06.v2.patch
Type: application/octet-stream
Size: 2727 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070215/6caa4bfd/attachment.obj 

From vda.linux at googlemail.com  Thu Feb 15 12:45:01 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 15 Feb 2007 21:45:01 +0100
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45D4880F.7030607@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com> <20070209211142.GY12488@aon.at>
	<45D4880F.7030607@techmoninc.com>
Message-ID: <200702152145.01126.vda.linux@googlemail.com>

On Thursday 15 February 2007 17:19, Andy Kennedy wrote:
> Bernhard Fischer wrote:
> > On Fri, Feb 09, 2007 at 01:45:33PM -0600, Andy Kennedy wrote:
> >   
> >> Andy Kennedy wrote:
> >>     
> >>> To restate my problem (in case some kind developer decides to help me):
> >>>
> >>> When I have the kernel command line parameter "console=ttyS0,115200n8" 
> >>> I get nice neat output on the serial line up until the init runs.  As 
> >>> soon as init runs, I get missing chars.  So, I replace the BusyBox 
> >>> init with minit, compiled from source and using the uCLibC gcc that I 
> >>> let buildroot make for me.  Same problem.  For some reason, when the 
> >>> system initializes -- after the kernel has reported all of its output, 
> >>> my serial console goes splat.  When I initialize the console using 
> >>> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
> >>> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
> >>> One of these letters will appear each time I send enter.
> >>>
> >>> I have tried everything I can think of.  There is no script setting 
> >>> any of the line speeds -- in fact, I have even attempted to remove the 
> >>> scripts and still get the same thing.  Removing the 
> >>> console=ttyS0,115200n8 (or attempting any variant of it) has no 
> >>> affect, except without the console= I get no good output on the line.  
> >>> The only thing I haven't attempted yet is to replace the getty with an 
> >>> equivalent to see if that makes a difference.  I have also tried 9600, 
> >>> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
> >>> every combination, but I still cannot get a serial console.
> >>>
> >>> Can anyone offer a suggestion as to how I might fix this -- or some 
> >>> other place to start?
> >>>
> >>> Thanks in advance for any help you can offer,
> >>> Andy
> >>>       
> >> Okay, now I'm really confused.  Here is what I have done so far:
> >> Made my laptop boot with a console on ttyS0 and put a login shell on it 
> >> (to verify that I can do it -- I was beginning to think maybe I needed 
> >> to remove Linux from my computer and get rid of all of  it being to 
> >> stupid to own a computer, much less program an embedded system) and I 
> >> had no problems.  So, I took my syslinux disk and booted from it (the 
> >> SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
> >> everything comes up as you would expect.
> >>
> >> Given that this test worked there is one of about three possibilities:
> >> 1) Cable issue.  Tested my serial cable on another embedded system (an 
> >> Arcom Viper), checks out.  Replaced the break-out cable from the 
> >> embedded system -- failed.  Tried a known good cable -- failed.  Tested 
> >> a different VersaLogic board -- failed.  Now, here is the part that 
> >> really yanked me around:
> >>
> >> The last time I booted the machine I didn't have the keyboard connected 
> >> to the break-out cable.  The boot went as it normally does except the 
> >> keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
> >> BusyBox init takes over the console and prints all kind of whack.  I 
> >> plug in the keyboard and the keyboard driver prints a perfect string 
> >> onto the serial console.
> >>
> >> I've looked through the code to see what type of initialization init is 
> >> doing to the console, but it doesn't look like it is re-initializing the 
> >> sucker at all.  The only thing that I can think is that BusyBox is doing 
> >> something that Linux doesn't do to interact with the ttyS0 so I'm not 
> >> getting what I expect.
> >>     
> >
> > IIRC busybox's init doesn't do anything special for serial lines.
> >
> > As vda already suggested, better seek help on lkml or try to find
> > somebody to whom that <char><space><char>.. pattern sounds familiar.
> >   
> Found the problem.  Wasn't a bug in BusyBox, wasn't that I didn't know 
> what I was doing either.  Found that the computer that has the UART 
> 16550A is configured such that the serial detection algorithm of Linux 
> didn't see it as a 16550A, but a 16750.  Difference being that the 
> 16550A has a 16-Byte buffer, whereas the 16750 has a 64-byte buffer.  
> The kernel, using the 16750 command set, waited for the buffer to get 
> full, thus anything written to the serial line was getting trashed.  I 
> have modified my kernel, for this specific computer, to "manually" set 
> the kernel to 16550A as the serial interface.

In case you will try to submit permanent fix for this into
mainlike kernel - I think that the only place where kernel
can decide that it is a 16750 is here:

drivers/serial/816:8250.c

        /*
         * No EFR.  Try to detect a TI16750, which only sets bit 5 of
         * the IIR when 64 byte FIFO mode is enabled when DLAB is set.
         * Try setting it with and without DLAB set.  Cheap clones
         * set bit 5 without DLAB set.
         */
        serial_outp(up, UART_LCR, 0);
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
        status1 = serial_in(up, UART_IIR) >> 5;
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
        serial_outp(up, UART_LCR, UART_LCR_DLAB);
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
        status2 = serial_in(up, UART_IIR) >> 5;
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
        serial_outp(up, UART_LCR, 0);

        DEBUG_AUTOCONF("iir1=%d iir2=%d ", status1, status2);

        if (status1 == 6 && status2 == 7) {
                up->port.type = PORT_16750;
                up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
                return;
        }
--
vda

From rob at landley.net  Thu Feb 15 13:44:15 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 16:44:15 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702140800.33665.vapier@gentoo.org>
References: <200702140800.33665.vapier@gentoo.org>
Message-ID: <200702151644.15320.rob@landley.net>

On Wednesday 14 February 2007 8:00 am, Mike Frysinger wrote:
> so i started to add a df build option, "ignore initramfs mount", that would 
> control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> that in embedded/bootable systems, it is common to run right out of the 
> initramfs rather than switching over to a "normal" root
> 
> however, i cant decide whether this warrants an actual build option ... the 
> trade offs are that in the desktop case, you'd never want to see the rootfs 
> output ... but does controlling literally 2 lines of code offset this ?

Look at the df I did in toybox.  I filter out overmounts (which hides 
initramfs if something's mounted over it but doesn't treat it specially), and 
I filter out mount points that have a total capacity (not free space) of zero 
(which nukes things like /proc and /sys).

> -mike

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From rob at landley.net  Thu Feb 15 13:46:23 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 16:46:23 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702142151.39680.vda.linux@googlemail.com>
References: <200702140800.33665.vapier@gentoo.org>
	<200702142151.39680.vda.linux@googlemail.com>
Message-ID: <200702151646.23104.rob@landley.net>

On Wednesday 14 February 2007 3:51 pm, Denis Vlasenko wrote:
> On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> > so i started to add a df build option, "ignore initramfs mount", that 
would 
> > control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> > that in embedded/bootable systems, it is common to run right out of the 
> > initramfs rather than switching over to a "normal" root
> > 
> > however, i cant decide whether this warrants an actual build option ... 
the 
> > trade offs are that in the desktop case, you'd never want to see the 
rootfs 
> > output ... but does controlling literally 2 lines of code offset this ?
> 
> I don't know what is a rationale for hiding that. It _is_ mounted there, 
right?
> So why we are lying to user that it isn't there?

Because 99% of the time something's mounted over it, so it's not an accessible 
mount point.  The knee jerk reaction was to hide initramfs specifically, but 
the general problem is actually mount points that aren't accessible because 
something else is mounted over them.

The logic to getting this to work right was nontrivial.  I was working on it 
while I was still doing busybox work, and I got a finished implementation of 
the way I think it should work into toybox months ago.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From rob at landley.net  Thu Feb 15 13:51:04 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 16:51:04 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702142151.39680.vda.linux@googlemail.com>
References: <200702140800.33665.vapier@gentoo.org>
	<200702142151.39680.vda.linux@googlemail.com>
Message-ID: <200702151651.04287.rob@landley.net>

On Wednesday 14 February 2007 3:51 pm, Denis Vlasenko wrote:
> On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> > so i started to add a df build option, "ignore initramfs mount", that 
would 
> > control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> > that in embedded/bootable systems, it is common to run right out of the 
> > initramfs rather than switching over to a "normal" root
> > 
> > however, i cant decide whether this warrants an actual build option ... 
the 
> > trade offs are that in the desktop case, you'd never want to see the 
rootfs 
> > output ... but does controlling literally 2 lines of code offset this ?
> 
> I don't know what is a rationale for hiding that. It _is_ mounted there, 
right?
> So why we are lying to user that it isn't there?
> 
> In my opinion we should just remove this feature.

P.S.

http://landley.net/notes-2006.html#28-10-2006
and
http://landley.net/notes-2006.html#29-10-2006

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From rob at landley.net  Thu Feb 15 14:02:46 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 17:02:46 -0500
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171375130.2437.36.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122328.33155.vda.linux@googlemail.com>
	<1171375130.2437.36.camel@albrecht.rdi1.com>
Message-ID: <200702151702.46730.rob@landley.net>

On Tuesday 13 February 2007 8:58 am, Paul Albrecht wrote:
> However, I still think that because the read syscall is unbuffered you
> can't assume that if you write x bytes to one end of the pipe you're
> guaranteed x bytes on the *first* read on the other end of the pipe.

http://www.opengroup.org/onlinepubs/009695399/functions/write.html

  After a write() to a regular file has successfully returned:
    o Any successful read() from each byte position in the file that was
      modified by that write shall return the data specified by the write()
      for that position until such byte positions are again modified.

  Write requests to a pipe or FIFO shall be handled in the same way as a
  regular file with the following exceptions:
    o There is no file offset associated with a pipe, hence each write request
      shall append to the end of the pipe.
    o Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
      data from other processes doing writes on the same pipe.

Yes, you can.

> I think you're supposed to check the number of bytes read and continue
> doing reads until you get as much data as you're expecting or get end of
> file.

A pipe is attached to a kernel buffer which his updated atomically by write() 
and read() syscalls.  There is _cannot_ be any propogation delay, nor partial 
writes of less than PIPE_BUF, in an SUSv3 compliant pipe implementation.  The 
spec says so.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From albrecht at rdi1.com  Thu Feb 15 13:53:13 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Thu, 15 Feb 2007 16:53:13 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171573780.2839.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122328.33155.vda.linux@googlemail.com>
	<1171375130.2437.36.camel@albrecht.rdi1.com>
	<1171573780.2839.0.camel@albrecht.rdi1.com>
Message-ID: <1171576393.2985.31.camel@albrecht.rdi1.com>

On Thu, 2007-02-15 at 17:02 -0500, Rob Landley wrote:
> On Tuesday 13 February 2007 8:58 am, Paul Albrecht wrote:
> > However, I still think that because the read syscall is unbuffered you
> > can't assume that if you write x bytes to one end of the pipe you're
> > guaranteed x bytes on the *first* read on the other end of the pipe.
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/write.html
> 
>   After a write() to a regular file has successfully returned:
>     o Any successful read() from each byte position in the file that was
>       modified by that write shall return the data specified by the write()
>       for that position until such byte positions are again modified.
> 
>   Write requests to a pipe or FIFO shall be handled in the same way as a
>   regular file with the following exceptions:
>     o There is no file offset associated with a pipe, hence each write request
>       shall append to the end of the pipe.
>     o Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
>       data from other processes doing writes on the same pipe.
> 
> Yes, you can.
> 

Thanks for clarifying what the standard is for pipes, but this doesn't
really help much because it's a fact that busybox httpd fails
intermittently when the I run a simple cgi script to redirect a request.

It doesn't seem to me to do much good to fall back on a standard if the
it isn't applicable in the real world. The user receiving garbage back
from a web server doesn't really care if the server is standard
conforming or not.

> > I think you're supposed to check the number of bytes read and continue
> > doing reads until you get as much data as you're expecting or get end of
> > file.
> 
> A pipe is attached to a kernel buffer which his updated atomically by write() 
> and read() syscalls.  There is _cannot_ be any propogation delay, nor partial 
> writes of less than PIPE_BUF, in an SUSv3 compliant pipe implementation.  The 
> spec says so.

Again, it's a fact that a simple cgi program that returns status back to
the busybox httpd server will intermittently fail in the manner I have
previously described.

If you're suggesting the it's a kernel bug perhaps you should post it to
the linux kernel mailing list because that's what I'm using for an
operating system.

From rob at landley.net  Thu Feb 15 15:01:13 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 18:01:13 -0500
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171576393.2985.31.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171573780.2839.0.camel@albrecht.rdi1.com>
	<1171576393.2985.31.camel@albrecht.rdi1.com>
Message-ID: <200702151801.13634.rob@landley.net>

On Thursday 15 February 2007 4:53 pm, Paul Albrecht wrote:
> Thanks for clarifying what the standard is for pipes, but this doesn't
> really help much because it's a fact that busybox httpd fails
> intermittently when the I run a simple cgi script to redirect a request.
> 
> It doesn't seem to me to do much good to fall back on a standard if the
> it isn't applicable in the real world. The user receiving garbage back
> from a web server doesn't really care if the server is standard
> conforming or not.

I didn't say there wasn't a bug, just that it's not in the Linux pipe 
implementation. :)

> Again, it's a fact that a simple cgi program that returns status back to
> the busybox httpd server will intermittently fail in the manner I have
> previously described.

Taking a wild guess without actually looking at the httpd code: nobody said 
that sigchild's delivery had to be delayed until a process that performs a 
blocking read gets scheduled again, just that if you do a read _after_ 
getting sigchild you should get all pending data in one gulp (or EOF).

> If you're suggesting the it's a kernel bug perhaps you should post it to
> the linux kernel mailing list because that's what I'm using for an
> operating system.

I'm not suggesting it's a kernel bug.  Lots and lots of other people would 
have hit it by now.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From tsattler at gmx.de  Thu Feb 15 17:26:03 2007
From: tsattler at gmx.de (Thomas Sattler)
Date: Fri, 16 Feb 2007 02:26:03 +0100
Subject: sort broken when using more than one -k's
Message-ID: <20070216012603.GA8224@nancy.sattler.local>

Hi there ...

Current busybox (1.4.1) seems to be broken in applet sort when more
than one -k's are used:

The example on http://www.busybox.net/downloads/BusyBox.html says

> $ echo -e "c 3\nb 2\nd 2" | sort -k 2,2n -k 1,1r

should result in

> d 2
> b 2
> c 3

which is what my (coreutils-6.4) sort does. busybox sort produces this:

> $ echo -e "c 3\nb 2\nd 2" | ./busybox sort -k 2,2n -k 1,1r
> d 2
> c 3
> b 2

Thomas Sattler

-- 
keep mailinglists in english, feel free to send PM in german

From christopher.fanning at gmail.com  Fri Feb 16 02:11:05 2007
From: christopher.fanning at gmail.com (Chris Fanning)
Date: Fri, 16 Feb 2007 11:11:05 +0100
Subject: nfsmount, rpc failed: 2
Message-ID: <215ff4410702160211p75d6f252we42f38eef53f19bf@mail.gmail.com>

Hello,

I am getting an error when using nfsmount.
nfsmount host:/export mountpoint
rpc failed: 2

I've looked about on the net and can't see anything about "rcp failed: 2"
I can mount this same export from another machine so I don't think
it's a server problem.

What does "rpc failed: 2" mean?

Thanks.
Chris.

From parmarsatpal at gmail.com  Fri Feb 16 02:48:00 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Fri, 16 Feb 2007 16:18:00 +0530
Subject: linux 2.6.18.2 with GCC 4.1.1 shell not coming
Message-ID: <457d2dc30702160248h30f4a51do10c3c4d4d535ca85@mail.gmail.com>

Hi all ;

 I am facing some  problem in porting linux kernel 2.6.18. I went through
some mailing list,archives and find mails refering exactly the problem I am
facing but unfortunetly I didnt get any working hints or solutions.I am
wondering if what I am facing is a known issue for embeded community. I
apprecaite if someone can  share hsi/her experinece on this isue.

*Problem:* We are porting linux-2.6.18.2 on ARM based chip, with
toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
init.c, before the shell comes up.

I have traced the problem and it seems to be that i don't recover from
the function console_init (in file init.c) .

Same kernel and rootfile system works fine when I compile with  with
gcc-4.0.3 toolchain (without EABI).So I cannot doubt UART interrupt, or
console driver.

*following mail list similar problem without  any clues:*

http://buildroot.uclibc.org/lists/buildroot/2007-February/001516.html

http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021541.html


here is my log;



Waiting for image to be downloaded via ICE...

Linux version 2.6.18.2 (sainin at bmpbuild2.noida.conexant.com) (gcc version
4.1.1)

 #2 Fri Feb 16 15:44:48 IST 2007

CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177

Machine: Conexant Edwards-Based IRD

Memory policy: ECC disabled, Data cache writeback

CPU0: D VIVT write-back cache

CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

Built 1 zonelists.  Total pages: 16384

Kernel command line: console=ttyRI0 root=/dev/ram  mem=64M debug=0

PID hash table entries: 512 (order: 9, 2048 bytes)

Console: colour dummy device 80x30

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 64MB = 64MB total

Memory: 55040KB available (1112K code, 479K data, 68K init)

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like a

n initrd

Freeing initrd memory: 8192K

NetWinder Floating Point Emulator V0.97 (double precision)

Initializing Cryptographic API

io scheduler noop registered (default)

ttyRI0 at MMIO 0xe0412000 (irq = 2) is a CNXTUART

ttyRI1 at MMIO 0xe0411000 (irq = 1) is a CNXTUART

ttyRI2 at MMIO 0xe0410000 (irq = 0) is a CNXTUART

RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize

mice: PS/2 mouse device common for all mice

RAMDISK: ext2 filesystem found at block 0

RAMDISK: Loading 8092KiB [1 disk] into ram disk... done.

VFS: Mounted root (ext2 filesystem) readonly.

Freeing init memory: 68K

Hello WOrld inside init.c

before console_init

 (no shell)
Thanks for your patience and time.

Regards
satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070216/a2579e70/attachment.html 

From parmarsatpal at gmail.com  Fri Feb 16 02:44:19 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Fri, 16 Feb 2007 16:14:19 +0530
Subject: porting linux 2.6.18.1(EABI) support GCC-4.1.1(eabi) shell not coming
Message-ID: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>

Hi all ;

 I am facing some  problem in porting linux kernel 2.6.18. I went through
some mailing list,archives and find mails refering exactly the problem I am
facing but unfortunetly I didnt get any working hints or solutions.I am
wondering if what I am facing is a known issue for embeded community. I
apprecaite if someone can  share hsi/her experinece on this isue.

*Problem:* We are porting linux-2.6.18.2 on ARM based chip, with
toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
init.c, before the shell comes up.

I have traced the problem and it seems to be that i don't recover from
the function console_init (in file init.c) .

Same kernel and rootfile system works fine when I compile with  with
gcc-4.0.3 toolchain (without EABI).So I cannot doubt UART interrupt, or
console driver.

*following mail list similar problem without  any clues:*

http://buildroot.uclibc.org/lists/buildroot/2007-February/001516.html

http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021541.html


here is my log;



Waiting for image to be downloaded via ICE...

Linux version 2.6.18.2 (sainin at bmpbuild2.noida.conexant.com) (gcc version
4.1.1)

 #2 Fri Feb 16 15:44:48 IST 2007

CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177

Machine: Conexant Edwards-Based IRD

Memory policy: ECC disabled, Data cache writeback

CPU0: D VIVT write-back cache

CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

Built 1 zonelists.  Total pages: 16384

Kernel command line: console=ttyRI0 root=/dev/ram  mem=64M debug=0

PID hash table entries: 512 (order: 9, 2048 bytes)

Console: colour dummy device 80x30

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 64MB = 64MB total

Memory: 55040KB available (1112K code, 479K data, 68K init)

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like a

n initrd

Freeing initrd memory: 8192K

NetWinder Floating Point Emulator V0.97 (double precision)

Initializing Cryptographic API

io scheduler noop registered (default)

ttyRI0 at MMIO 0xe0412000 (irq = 2) is a CNXTUART

ttyRI1 at MMIO 0xe0411000 (irq = 1) is a CNXTUART

ttyRI2 at MMIO 0xe0410000 (irq = 0) is a CNXTUART

RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize

mice: PS/2 mouse device common for all mice

RAMDISK: ext2 filesystem found at block 0

RAMDISK: Loading 8092KiB [1 disk] into ram disk... done.

VFS: Mounted root (ext2 filesystem) readonly.

Freeing init memory: 68K

Hello WOrld inside init.c

before console_init

 (no shell)
Thanks for your patience and time.

Regards
satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070216/aaec4f37/attachment.htm 

From tsattler at gmx.de  Fri Feb 16 02:56:19 2007
From: tsattler at gmx.de (Thomas Sattler)
Date: Fri, 16 Feb 2007 11:56:19 +0100
Subject: bad *sign file: busybox-1.4.1.tar.bz2.sign
Message-ID: <20070216105619.GA5754@nancy.sattler.local>

Hi there ...

http://www.busybox.net/downloads/busybox-1.4.1.tar.bz2.sign contains a
bad md5 checksum. Not that the checksum does not match, it's just not a
md5 checksum (md5 checksums consist of [0-9a-z] only):

5728403RSU309STQRSVVQ414U2U64052  busybox-1.4.1.tar.bz2

I computed the checksum myself which is

5728403bce309cdabcffa414e2e64052  busybox-1.4.1.tar.bz2

Note that this is identical in respect of the digits.

Thomas

-- 
keep mailinglists in english, feel free to send PM in german

From iggarpe at terra.es  Fri Feb 16 03:20:16 2007
From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=)
Date: Fri, 16 Feb 2007 12:20:16 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1
Message-ID: <45D59370.6090204@terra.es>

See attached patch.

Would be nice to rewrite the option parsing code to make use of the 
libbb functions.

Regards.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-slattach.diff
Url: http://busybox.net/lists/busybox/attachments/20070216/dd654357/attachment-0001.diff 

From iggarpe at terra.es  Fri Feb 16 03:21:57 2007
From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=)
Date: Fri, 16 Feb 2007 12:21:57 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1 (this is the GOOD one)
Message-ID: <45D593D5.9070507@terra.es>

Sorry, attached the wrong patch in previous message. This is the good one.

As I already said, would be nice to rewrite the option parsing code to 
make use of the libbb functions.

Regards.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.4.1-slattach.patch
Url: http://busybox.net/lists/busybox/attachments/20070216/d3a5931e/attachment.pot 

From tsattler at gmx.de  Fri Feb 16 03:54:01 2007
From: tsattler at gmx.de (Thomas Sattler)
Date: Fri, 16 Feb 2007 12:54:01 +0100
Subject: sort broken when using more than one -k's
In-Reply-To: <20070216012603.GA8224@nancy.sattler.local>
References: <20070216012603.GA8224@nancy.sattler.local>
Message-ID: <20070216115401.GA9027@nancy.sattler.local>

Hi again ...

I checked busybox releases: They all work, until (and including)
busybox-1.3.2, since busybox-1.4.0 sort is broken.

Available snapshots seem all to be broken. So the change in the
sources must be older than 20070117.

HTH
Thomas

-- 
keep mailinglists in english, feel free to send PM in german

From rep.dot.nop at gmail.com  Fri Feb 16 05:23:28 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 16 Feb 2007 14:23:28 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1 (this is the GOOD one)
In-Reply-To: <45D593D5.9070507@terra.es>
References: <45D593D5.9070507@terra.es>
Message-ID: <20070216132328.GA28870@aon.at>

On Fri, Feb 16, 2007 at 12:21:57PM +0100, Ignacio Garc?a P?rez wrote:
>Sorry, attached the wrong patch in previous message. This is the good one.
>
>As I already said, would be nice to rewrite the option parsing code to 
>make use of the libbb functions.
>
>Regards.
>
>
>

>diff -urN busybox-1.4.1/include/applets.h busybox-1.4.1-modified/include/applets.h
>--- busybox-1.4.1/include/applets.h	2007-01-24 22:34:48.000000000 +0100
>+++ busybox-1.4.1-modified/include/applets.h	2007-02-16 11:45:33.000000000 +0100
>@@ -262,6 +262,7 @@
> USE_FEATURE_SH_IS_LASH(APPLET_NOUSAGE(sh, lash, _BB_DIR_BIN, _BB_SUID_NEVER))
> USE_FEATURE_SH_IS_MSH(APPLET_NOUSAGE(sh, msh, _BB_DIR_BIN, _BB_SUID_NEVER))
> USE_SHA1SUM(APPLET_ODDNAME(sha1sum, md5_sha1_sum, _BB_DIR_USR_BIN, _BB_SUID_NEVER, sha1sum))
>+USE_SLATTACH(APPLET(slattach, _BB_DIR_SBIN, _BB_SUID_NEVER))
> USE_SLEEP(APPLET(sleep, _BB_DIR_BIN, _BB_SUID_NEVER))
> USE_SOFTLIMIT(APPLET_ODDNAME(softlimit, chpst, _BB_DIR_USR_BIN, _BB_SUID_NEVER, softlimit))
> USE_SORT(APPLET(sort, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
>diff -urN busybox-1.4.1/include/usage.h busybox-1.4.1-modified/include/usage.h
>--- busybox-1.4.1/include/usage.h	2007-01-24 22:34:48.000000000 +0100
>+++ busybox-1.4.1-modified/include/usage.h	2007-02-16 11:44:10.000000000 +0100
>@@ -2788,6 +2788,20 @@
>        "	-s	Don't output anything, status code shows success\n" \
>        "	-w	Warn about improperly formatted SHA1 checksum lines")
> 
>+#define slattach_trivial_usage \
>+	"[-cehmLF] [-s speed] [-p protocol] DEVICEs"
>+#define slattach_full_usage \
>+	"Attach network interface(s) to serial line(s).\n" \
>+	"Options:\n" \
>+	"\t-p\tset a specific kind of protocol (slip, cslip, slip6, clisp6 or adaptive).\n" \
>+	"\t-s\tset a specific line speed.\n"
>+	"\t-c\texecute a command when the line is hung up\n" \
>+	"\t-e\texit right after initializing device.\n" \
>+	"\t-h\texit when the carrier is lost.\n" \
>+	"\t-m\tdo NOT initialize the line in raw 8 bits mode.\n" \
>+	"\t-L\tenable 3-wire operation.\n" \
>+	"\t-F\tdisable RTS/CTS flow control.\n" \
>+ 
> #define sleep_trivial_usage \
> 	USE_FEATURE_FANCY_SLEEP("[") "N" USE_FEATURE_FANCY_SLEEP("]...")
> #define sleep_full_usage \
>diff -urN busybox-1.4.1/networking/Config.in busybox-1.4.1-modified/networking/Config.in
>--- busybox-1.4.1/networking/Config.in	2007-01-24 22:34:34.000000000 +0100
>+++ busybox-1.4.1-modified/networking/Config.in	2007-02-16 11:47:50.000000000 +0100
>@@ -523,6 +523,12 @@
> 	help
> 	  Route displays or manipulates the kernel's IP routing tables.
> 
>+config SLATTACH
>+	bool "slattach"
>+	default n
>+	help
>+	  Slattach is a small utility to attach network interfaces to serial lines.
>+
> config TELNET
> 	bool "telnet"
> 	default n
>diff -urN busybox-1.4.1/networking/Kbuild busybox-1.4.1-modified/networking/Kbuild
>--- busybox-1.4.1/networking/Kbuild	2007-01-24 22:34:34.000000000 +0100
>+++ busybox-1.4.1-modified/networking/Kbuild	2007-02-16 11:38:37.000000000 +0100
>@@ -32,6 +32,7 @@
> lib-$(CONFIG_PING)         += ping.o
> lib-$(CONFIG_PING6)        += ping6.o
> lib-$(CONFIG_ROUTE)        += route.o
>+lib-$(CONFIG_SLATTACH)     += slattach.o
> lib-$(CONFIG_TELNET)       += telnet.o
> lib-$(CONFIG_TELNETD)      += telnetd.o
> lib-$(CONFIG_TFTP)         += tftp.o
>diff -urN busybox-1.4.1/networking/slattach.c busybox-1.4.1-modified/networking/slattach.c
>--- busybox-1.4.1/networking/slattach.c	1970-01-01 01:00:00.000000000 +0100
>+++ busybox-1.4.1-modified/networking/slattach.c	2007-02-16 12:03:18.000000000 +0100
>@@ -0,0 +1,266 @@
>+/*
>+ *		Stripped down version of net-tools for busybox.
>+ *
>+ *		Author: Ignacio Garcia Perez (iggarpe at gmail dot com)
>+ *
>+ *		License: GPLv2 or later, see LICENSE file in this tarball.
>+ *
>+ *		There are some differences from the standard net-tools slattach:
>+ *
>+ *		- The -l option is not supported.
>+ *
>+ *		- Several devices can be specified in the command line. This is
>+ *		  very useful if you are handling many identical serial lines since
>+ *		  only one process is necessary to configure them all.
>+ *
>+ *		- The -F options allows disabling of RTS/CTS flow control.
>+ *
>+ */
>+
>+#include <unistd.h>
>+#include <stdlib.h>
>+#include <string.h>
>+#include <stdio.h>
>+#include <signal.h>
>+#include <errno.h>
>+#include <sys/socket.h>
>+#include <sys/types.h>
>+#include <sys/stat.h>
>+#include <fcntl.h>
>+#include <termios.h>
>+#include <sys/ioctl.h>
>+
>+#include "libbb.h"
>+
>+struct tty {
>+	const char *	device;
>+	int				handle;
>+	int				saved_disc;
>+	struct termios	saved_state;
>+	struct tty *	next;
>+};
>+
>+static struct tty *_tty_head = NULL;
>+static struct tty *_tty_tail = NULL;
>+
>+/* Line discipline code table */
>+
>+static struct { const char *name; int code; } _proto [] = {
>+	{ "slip",		0 },
>+	{ "cslip",		1 },
>+	{ "slip6",		2 },
>+	{ "cslip6",		3 },
>+	{ "adaptive",	8 },
>+	{ NULL }
>+};
>+
>+/*
>+ * Save tty state and line discipline
>+ */
>+
>+static int _save_state (struct tty *t) {
>+
>+	if (t->handle < 0) return 0;
>+
>+	if (tcgetattr(t->handle, &t->saved_state) < 0)			/* Save line status */
>+		{ bb_perror_msg("get state"); return -1; }
>+
>+	if (ioctl(t->handle, TIOCGETD, &t->saved_disc) < 0)		/* Save line discipline */
>+		{ bb_perror_msg("get discipline"); return -1; }
>+
>+	return 0;
>+}
>+
>+/*
>+ * Set tty state, line discipline and encapsulation
>+ */
>+
>+static int _set_state (struct tty *t, struct termios *state, int encap) {
>+
>+	int disc = N_SLIP;
>+
>+	if (t->handle < 0) return 0;
>+
>+	if (tcsetattr(t->handle, TCSANOW, state) < 0)			/* Set line status */
>+		{ bb_perror_msg("set state"); return -1; }
>+
>+	if (ioctl(t->handle, TIOCSETD, &disc) < 0)				/* Set line discliple (N_SLIP always) */
>+		{ bb_perror_msg("set discipline"); return -1; }
>+
>+	if (ioctl(t->handle, SIOCSIFENCAP, &encap) < 0)			/* Set encapsulation (SLIP, CSLIP, etc) */
>+		{ bb_perror_msg("set encapsulation"); return -1; }
>+
>+	return 0;
>+}
>+
>+/*
>+ * Restore state and line discipline for ALL managed ttys
>+ *
>+ * Restoring ALL managed ttys is the only way to have a single
>+ * hangup delay.
>+ *
>+ */
>+
>+static int _restore_state_and_close (void) {
>+
>+	struct tty *t;
>+	struct termios state;
>+
>+	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>+
>+		if (ioctl(t->handle, TIOCSETD, &t->saved_disc) < 0)			/* Restore line discipline */
>+			{ bb_perror_msg("set discipline"); return -1; }
>+
>+		memcpy(&state, &t->saved_state, sizeof(state));				/* Hangup */
>+		cfsetispeed(&state, B0);
>+		cfsetospeed(&state, B0);
>+		if (tcsetattr(t->handle, TCSANOW, &state) < 0)
>+			{ bb_perror_msg("set state"); return -1; }
>+	}
>+
>+	sleep(1);	/* The sleep time does not depend on the number of managed ttys */
>+
>+	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>+
>+		if (tcsetattr(t->handle, TCSANOW, &t->saved_state) < 0)		/* Restore line status */
>+			{ perror("set state"); return -1; }
>+
>+		close(t->handle); t->handle = -1;
>+	}
>+
>+	return 0;
>+}
>+
>+static void _sig_handler (int signo) {
>+	if (_restore_state_and_close() < 0) sleep_and_die();
>+	exit(0);
>+}
>+
>+int slattach_main (int argc, char **argv) {
>+
>+	int i, encap;
>+	struct tty *t;
>+	struct termios state;
>+	char buf [PATH_MAX];

That's a large buffer, imho. xmalloc() or make it
RESERVE_CONFIG_BUFFER(buf,PATH_MAX)

>+
>+	const char *proto = "cslip";	/* Protocol */
>+	const char *extcmd = NULL;		/* Command to execute after hangup */
>+
>+	int baud = -1;		/* Line baud rate (value) */
>+	int baud_code = -1;	/* Line baud rate (system code) */
>+	int local = 0;		/* Local mode (disable carrier watch) */
>+	int quit = 0;		/* Initialize and exit */
>+	int watch = 0;		/* watch for line hangup */
>+	int raw = 1;		/* Initialize line in raw 8 bit mode */
>+	int flow = 1;		/* Disable RTS/CTS flow control (not in net-tools slattach !!!) */

most of these should use one variable and mask their bits in.
>+
>+	/* Parse command line options */
>+	/* TODO: use bb lib getopt_whatever? */

getopt32, yes.

The block below is just too bloated.
>+
>+	for (i = 1; i < argc; i++) {
>+
>+		if (argv[i][0] == '-') switch (argv[i][1]) {
>+			case 'p': proto = argv[++i]; break;
>+			case 's': baud = atoi(argv[++i]); break;
>+			case 'c': extcmd = argv[++i]; break;
>+			case 'e': quit = 1; break;
>+			case 'h': watch = 1; break;
>+			case 'm': raw = 0; break;
>+			case 'L': local = 1; break;
>+			case 'F': flow = 0; break;
>+			default: bb_error_msg_and_die("invalid option %s", argv[i]);
>+		}
>+
>+		else {
>+			t = (struct tty *)malloc(sizeof(struct tty));
>+			if (t == NULL) bb_error_msg_and_die("not enough memory");

No. xmalloc() instead

>+
>+			t->device = argv[i];
>+			t->handle = -1;
>+			t->next = NULL;
>+
>+			if (_tty_head == NULL) _tty_head = _tty_tail = t;
>+			else { _tty_tail->next = t; _tty_tail = t; }
>+		}
>+	}
>+
>+	if (_tty_head == NULL) bb_show_usage();
>+
>+	for (i = 0; _proto[i].name != NULL; i++)
>+		if (!strcmp(_proto[i].name, proto)) break;

index_in_str_array() instead

>+	if (_proto[i].name == NULL) bb_error_msg_and_die("invalid protocol %s", proto);
>+	encap = _proto[i].code;
>+
>+	baud_code = tty_value_to_baud(baud);
>+	if (baud_code < 0) bb_error_msg_and_die("invalid baud rate %i", baud);
>+
>+	/* Trap signals in order to restore tty states upon exit */
>+
>+	if (!quit) {
>+		signal(SIGHUP, _sig_handler);
>+		signal(SIGINT, _sig_handler);
>+		signal(SIGQUIT, _sig_handler);
>+		signal(SIGTERM, _sig_handler);
>+	}
>+
>+	/* Configure ttys */
>+
>+	for (t = _tty_head; t != NULL; t = t->next) {
>+
>+		t->handle = open(t->device, O_RDWR | O_NDELAY);
>+		if (t->handle < 0) {
>+			snprintf(buf, sizeof(buf), "/dev/%s", t->device);

concat_path_file() instead. Should make that huge buf from above
superfluous.

>+			t->handle = open(buf, O_RDWR | O_NDELAY);
>+			if (t->handle < 0) bb_perror_msg_and_die("open %s", t->device);
>+		}
>+
>+		if (_save_state(t) < 0) sleep_and_die();
>+
>+		memcpy(&state, &t->saved_state, sizeof(state));
>+
>+		if (raw) {
>+			memset(&state.c_cc, 0, sizeof(state.c_cc));
>+			state.c_cc[VMIN]	= 1;
>+			state.c_iflag		= IGNBRK | IGNPAR;
>+			state.c_oflag		= 0;
>+			state.c_lflag		= 0;
>+			state.c_cflag		= CS8 | HUPCL | CREAD
>+								| (local ? CLOCAL : 0) | (flow ? CRTSCTS : 0);
>+		}
>+
>+		if (baud_code >= 0) {

Didn't we check above that boud_rate not is < 0 above? drop it then.

>+			cfsetispeed(&state, baud_code);
>+			cfsetospeed(&state, baud_code);
>+		}
>+
>+		if (_set_state(t, &state, encap) < 0)
>+			{ _restore_state_and_close(); sleep_and_die(); }
>+	}
>+
>+	/* Exit now if option -e was passed */
>+
>+	if (quit) exit(0);
>+
>+	/* Watch line for hangup */
>+
>+	for (;;) {
>+
>+		if (watch)
>+			for (t = _tty_head; t != NULL; t = t->next)
>+				if (ioctl(t->handle, TIOCMGET, &i) < 0 || !(i & TIOCM_CAR))
>+					quit = 1;
>+
>+		if (quit) break;

would a while (!option_mask32 & QUIT) be smaller?

>+		sleep(15);
>+	}
>+
>+	/* Execute command on hangup */
>+
>+	if (extcmd != NULL) system(extcmd);
>+
>+	/* Restore states and exit */
>+
>+	_restore_state_and_close();
>+	return 0;
>+}
>+

From natanael.copa at gmail.com  Fri Feb 16 14:45:37 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 16 Feb 2007 23:45:37 +0100
Subject: serial console and log-in
Message-ID: <1171665937.2696.252.camel@localhost>

Hi,

>From the serial console kernel documentation:

 If no console device is specified, the first device found capable of
 acting as a system console will be used. At this time, the system
 first looks for a VGA card and then for a serial port. So if you don't
 have a VGA card in your system the first serial port will automatically
 become the console.

Is there some way to autodetect if the console is a serial console, and
if it is, activate a line like this in inittab:

ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100

And if /dev/console is not a serial console, it will not activate any
getty on the serial console.

The current problem is, that even if console goes to serial port so I
can see the kernel messages and bootscript output, busybox init will
never give a login from inittab unless the previous line is there.

But I'd prefer not to turn it on by default, in case somebody happen to
have something sensitive attatched to the serial port when running my
distro as rescue cd for example.

Natanael Copa


From vda.linux at googlemail.com  Fri Feb 16 16:39:09 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 01:39:09 +0100
Subject: nfsmount, rpc failed: 2
In-Reply-To: <215ff4410702160211p75d6f252we42f38eef53f19bf@mail.gmail.com>
References: <215ff4410702160211p75d6f252we42f38eef53f19bf@mail.gmail.com>
Message-ID: <200702170139.10011.vda.linux@googlemail.com>

On Friday 16 February 2007 11:11, Chris Fanning wrote:
> Hello,
> 
> I am getting an error when using nfsmount.
> nfsmount host:/export mountpoint
> rpc failed: 2

nfsmount is not a part of busybox, it's a program from nfs-utils, I think.

What happens when you run busybox's mount -t nfs host:/export mountpoint?
If you get an error, consider collecting strace log too.

> I've looked about on the net and can't see anything about "rcp failed: 2"
> I can mount this same export from another machine so I don't think
> it's a server problem.
> 
> What does "rpc failed: 2" mean?

I don't know. Maybe this?

#define ENOENT           2      /* No such file or directory */

enum nfsstat {
        NFS_OK= 0,              /* no error */
        NFSERR_PERM=1,          /* Not owner */
        NFSERR_NOENT=2,         /* No such file or directory */
--
vda

From chemuduguntar at gmail.com  Fri Feb 16 18:49:27 2007
From: chemuduguntar at gmail.com (Ravi Chemudugunta)
Date: Sat, 17 Feb 2007 15:49:27 +1300
Subject: Busybox build problem
Message-ID: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>

# make allnoconfig; make

  LINK    busybox_unstripped
/home/brion/busybox-1.4.1/scripts/trylink: 5: function: not found
/home/brion/busybox-1.4.1/scripts/trylink: 11: Syntax error: "}" unexpected
make: *** [busybox_unstripped] Error 2

This error occurs on *ubuntu due to the use of dash as the default
shell (sh->dash).  the scripts included were designed with bash which
uses some non-posix extensions which dash strives to meet
(posix-ness).

cd /bin
rm sh
ln -s bash sh

The reason for including dash is speed so your system might boot
slower or not at all.

hope this helps,

ravi

From vda.linux at googlemail.com  Sat Feb 17 07:28:28 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 16:28:28 +0100
Subject: porting linux 2.6.18.1(EABI) support GCC-4.1.1(eabi) shell not
	coming
In-Reply-To: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>
References: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>
Message-ID: <200702171628.28843.vda.linux@googlemail.com>

On Friday 16 February 2007 11:44, satpal parmar wrote:
> Hi all ;
> 
>  I am facing some  problem in porting linux kernel 2.6.18. I went through
> some mailing list,archives and find mails refering exactly the problem I am
> facing but unfortunetly I didnt get any working hints or solutions.I am
> wondering if what I am facing is a known issue for embeded community. I
> apprecaite if someone can  share hsi/her experinece on this isue.
> 
> *Problem:* We are porting linux-2.6.18.2 on ARM based chip, with
> toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
> We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
> init.c, before the shell comes up.
> 
> I have traced the problem and it seems to be that i don't recover from
> the function console_init (in file init.c) .

That's why I keep saying "you don't need any stinking init,
shell script will suffice". Because init has some really obscure
and ugly code (even our own init, which is *supposed to be*
small and simple).

Here we go:

static char console[CONSOLE_BUFF_SIZE] = "/dev/console";
static const char *log_console = VC_5;

static void console_init(void)
{
        int fd;
        int tried = 0;
        struct vt_stat vt;
        struct serial_struct sr;
        char *s;

        if ((s = getenv("CONSOLE")) != NULL || (s = getenv("console")) != NULL) {
                safe_strncpy(console, s, sizeof(console));
        } else {
                /* 2.2 kernels: identify the real console backend and try to use it */
                if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
                        /* this is a serial console */
                        snprintf(console, sizeof(console) - 1, SC_FORMAT, sr.line);
                } else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
                        /* this is linux virtual tty */
                        snprintf(console, sizeof(console) - 1, VC_FORMAT, vt.v_active);
                } else {
                        safe_strncpy(console, "/dev/console", sizeof(console));
                        tried++;
                }
        }

        while ((fd = open(console, O_RDONLY | O_NONBLOCK)) < 0 && tried < 2) {
                /* Can't open selected console -- try logical system console and VT_MASTER */
                safe_strncpy(console, (tried == 0 ? "/dev/console" : "/dev/tty0"), sizeof(console));
                tried++;
        }
        if (fd < 0) {
                /* Perhaps we should panic here? */
#if !ENABLE_SYSLOGD
                log_console =
#endif
                safe_strncpy(console, bb_dev_null, sizeof(console));
        } else {
		... set TERM ...
		close(fd)
	}
}

int init_main(int argc, char **argv)
{
 ...a few irrelevant things skipped...
        /* Figure out where the default console should be */
        console_init();
        /* Close whatever files are open, and reset the console. */
        close(0);
        close(1);
        close(2);
        if (device_open(console, O_RDWR | O_NOCTTY) == 0) {
                set_term();
                close(0);
        }

<bitching>
Hello? What a fsck is going on here? Why we are closing perfectly
fine open stdio desriptors which kernel gave us?
init=/bin/sh manages to work without such idiosyncrasies, why
we need a pile of this code - just for setting TERM?
</bitching>

After some grepping around:

console is = getenv("CONSOLE"/"console"), "/dev/console", "/dev/tty0"
or "/dev/null". It is used only in two places: in init_main
(shown above) and in new_init_action() is cons is "":

static void new_init_action(int action, const char *command, const char *cons)
{
        struct init_action *new_action, *a, *last;
        if (*cons == '\0')
                cons = console_name;

[cons subsequently ended up in init_action::terminal and
is used for open() and access() - not too hard to adapt
those places for just dup()ing fd#0 if we will want to fix the mess...]

Also note that 'console' is an awful variable name - grepping for it
is bound to produce tons of false positives. I think console_name is better.

log_console is vt#5 unless we failed to open getenv("CONSOLE"/"console"),
"/dev/console" and "/dev/tty0" (then console = "/dev/null"),
or if opened console turned out to be a serial line (in that case
log_console = console). log_console is used only by
message(LOG, ...) in init.c, nowhere else.

This is awfully messy.

> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing init memory: 68K
> Hello WOrld inside init.c
> before console_init
>  (no shell)
> Thanks for your patience and time.
> 
> Regards
> satpal

satpal, any chance you can pinpoint what exactly is failing
in init_console?
--
vda

From vda.linux at googlemail.com  Sat Feb 17 07:38:17 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 16:38:17 +0100
Subject: bad *sign file: busybox-1.4.1.tar.bz2.sign
In-Reply-To: <20070216105619.GA5754@nancy.sattler.local>
References: <20070216105619.GA5754@nancy.sattler.local>
Message-ID: <200702171638.17078.vda.linux@googlemail.com>

Hello Thomas,

On Friday 16 February 2007 11:56, Thomas Sattler wrote:
> http://www.busybox.net/downloads/busybox-1.4.1.tar.bz2.sign contains a
> bad md5 checksum. Not that the checksum does not match, it's just not a
> md5 checksum (md5 checksums consist of [0-9a-z] only):
> 
> 5728403RSU309STQRSVVQ414U2U64052  busybox-1.4.1.tar.bz2
> 
> I computed the checksum myself which is
> 
> 5728403bce309cdabcffa414e2e64052  busybox-1.4.1.tar.bz2
> 
> Note that this is identical in respect of the digits.

Oh no. This is a known (and already fixed) googfup on my part
regarding upper/lower case conversion. Apparently I used buggy
md5sum version when I made those files.

Corrected signatures are uploaded. Sorry.
--
vda

From m.pommerenke at avm.de  Fri Feb 16 03:15:56 2007
From: m.pommerenke at avm.de (m.pommerenke at avm.de)
Date: Fri, 16 Feb 2007 12:15:56 +0100
Subject: linux 2.6.18.2 with GCC 4.1.1 shell not coming
In-Reply-To: <457d2dc30702160248h30f4a51do10c3c4d4d535ca85@mail.gmail.com>
Message-ID: <OFBCDDFD71.59C791E7-ONC1257284.003D0ACE-C1257284.003DE2CC@avm.de>

Hi,

I had the same problem. We found out the gcc used an floating point
instruction FSTMX to push multible register onto the stack.
(on user space applications) This instruction ist not emulated by the
kernel floating point emulater.

I had configured the uclibc haveing a floating point processor. After
correcting this and rebuilding the gcc everything worked fine.


Martin Pommerenke





|-------------+--------------------------->
|             |                           |
|             | "satpal parmar"           |
|             | <parmarsatpal at gmail.com>  |
|             | Gesendet von:             |
|             | busybox-bounces at busybox.ne|
|             | t                         |
|             |                           |
|             |                           |
|             | 16.02.2007 11:48          |
|-------------+--------------------------->
  >-----------------------------------------------------------------------------------------------------------|
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  | An:                                                                                                       |
  |                                                                                                           |
  |          linux-arm-kernel at lists.arm.linux.org.uk, busybox at busybox.net, arm-gnu at codesourcery.com           |
  |                                                                                                           |
  | Kopie:                                                                                                    |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  | Thema:                                                                                                    |
  |                                                                                                           |
  |          linux 2.6.18.2 with GCC 4.1.1 shell not coming                                                   |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  >-----------------------------------------------------------------------------------------------------------|




Hi all ;

 I am facing some  problem in porting linux kernel 2.6.18. I went through
some mailing list,archives and find mails refering exactly the problem I am
facing but unfortunetly I didnt get any working hints or solutions.I am
wondering if what I am facing is a known issue for embeded community. I
apprecaite if someone can  share hsi/her experinece on this isue.

Problem: We are porting linux-2.6.18.2 on ARM based chip, with
toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
init.c, before the shell comes up.

I have traced the problem and it seems to be that i don't recover from
the function console_init (in file init.c) .

Same kernel and rootfile system works fine when I compile with  with
gcc-4.0.3 toolchain (without EABI).So I cannot doubt UART interrupt, or
console driver.

following mail list similar problem without  any clues:

http://buildroot.uclibc.org/lists/buildroot/2007-February/001516.html

http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021541.html


here is my log;




Waiting for image to be downloaded via ICE...


Linux version 2.6.18.2 (sainin at bmpbuild2.noida.conexant.com ) (gcc version
4.1.1)


 #2 Fri Feb 16 15:44:48 IST 2007


CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177


Machine: Conexant Edwards-Based IRD


Memory policy: ECC disabled, Data cache writeback


CPU0: D VIVT write-back cache


CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets


CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets


Built 1 zonelists.  Total pages: 16384


Kernel command line: console=ttyRI0 root=/dev/ram  mem=64M debug=0


PID hash table entries: 512 (order: 9, 2048 bytes)


Console: colour dummy device 80x30


Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)


Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)


Memory: 64MB = 64MB total


Memory: 55040KB available (1112K code, 479K data, 68K init)


Mount-cache hash table entries: 512


CPU: Testing write buffer coherency: ok


checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like a


n initrd


Freeing initrd memory: 8192K


NetWinder Floating Point Emulator V0.97 (double precision)


Initializing Cryptographic API


io scheduler noop registered (default)


ttyRI0 at MMIO 0xe0412000 (irq = 2) is a CNXTUART


ttyRI1 at MMIO 0xe0411000 (irq = 1) is a CNXTUART


ttyRI2 at MMIO 0xe0410000 (irq = 0) is a CNXTUART


RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize


mice: PS/2 mouse device common for all mice


RAMDISK: ext2 filesystem found at block 0


RAMDISK: Loading 8092KiB [1 disk] into ram disk... done.


VFS: Mounted root (ext2 filesystem) readonly.


Freeing init memory: 68K


Hello WOrld inside init.c


before console_init


 (no shell)


Thanks for your patience and time.

Regards
satpal


 _______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox


From vda.linux at googlemail.com  Sat Feb 17 07:54:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 16:54:40 +0100
Subject: Busybox build problem
In-Reply-To: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
Message-ID: <200702171654.40381.vda.linux@googlemail.com>

On Saturday 17 February 2007 03:49, Ravi Chemudugunta wrote:
> # make allnoconfig; make
> 
>   LINK    busybox_unstripped
> /home/brion/busybox-1.4.1/scripts/trylink: 5: function: not found
> /home/brion/busybox-1.4.1/scripts/trylink: 11: Syntax error: "}" unexpected
> make: *** [busybox_unstripped] Error 2
> 
> This error occurs on *ubuntu due to the use of dash as the default
> shell (sh->dash).  the scripts included were designed with bash which
> uses some non-posix extensions which dash strives to meet
> (posix-ness).
> 
> cd /bin
> rm sh
> ln -s bash sh
> 
> The reason for including dash is speed so your system might boot
> slower or not at all.

I applaud ubuntu's efforts of trying to use smaller shell.
Really. bash is too big for any sensible embedded system.

Unfortunately it means that fixing just busybox's stripts
is not a solution - there are tons of other shell scripts
lying aroung.

dash should support "function". It shouldn't be too hard - 
dash already supports

do_something () {
    ...
}

It's just a matter of recognizing slightly diffeent syntax:

function do_something {
    ...
}

--
vda

From vda.linux at googlemail.com  Sat Feb 17 08:00:10 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 17:00:10 +0100
Subject: serial console and log-in
In-Reply-To: <1171665937.2696.252.camel@localhost>
References: <1171665937.2696.252.camel@localhost>
Message-ID: <200702171700.10195.vda.linux@googlemail.com>

On Friday 16 February 2007 23:45, Natanael Copa wrote:
> Hi,
> 
> >From the serial console kernel documentation:
> 
>  If no console device is specified, the first device found capable of
>  acting as a system console will be used. At this time, the system
>  first looks for a VGA card and then for a serial port. So if you don't
>  have a VGA card in your system the first serial port will automatically
>  become the console.
> 
> Is there some way to autodetect if the console is a serial console, and
> if it is, activate a line like this in inittab:
> 
> ttyS0 ::respawn:/sbin/getty -L ttyS0 115200 vt100 
> 
> And if /dev/console is not a serial console, it will not activate any
> getty on the serial console.

I propose making it possible to start getty (or whatever)
on any device which happens to be init's fd#0 (which is passed to it
by kernel). This way you will automatically get your getty whereever
kernel's console happened to be this time.

Proposed syntax:

::respawn:/sbin/getty - 115200 vt100 

or

0::respawn:/sbin/getty - 115200 vt100 

or 

stdin::respawn:/sbin/getty - 115200 vt100 

We should fix init's crazy handling of console and stdio fd's first
(see my earlier mail today). Not too hard, I just need people who
are willing to test changes.
--
vda

From vda.linux at googlemail.com  Sat Feb 17 10:09:34 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 19:09:34 +0100
Subject: sort broken when using more than one -k's
In-Reply-To: <20070216012603.GA8224@nancy.sattler.local>
References: <20070216012603.GA8224@nancy.sattler.local>
Message-ID: <200702171909.34408.vda.linux@googlemail.com>

On Friday 16 February 2007 02:26, Thomas Sattler wrote:
> Hi there ...
> 
> Current busybox (1.4.1) seems to be broken in applet sort when more
> than one -k's are used:
> 
> The example on http://www.busybox.net/downloads/BusyBox.html says
> 
> > $ echo -e "c 3\nb 2\nd 2" | sort -k 2,2n -k 1,1r
> 
> should result in
> 
> > d 2
> > b 2
> > c 3
> 
> which is what my (coreutils-6.4) sort does. busybox sort produces this:
> 
> > $ echo -e "c 3\nb 2\nd 2" | ./busybox sort -k 2,2n -k 1,1r
> > d 2
> > c 3
> > b 2

Thanks, fixed in svn. Patch is attached.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 5192 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070217/4d475980/attachment.bin 

From hias at horus.com  Sat Feb 17 11:22:34 2007
From: hias at horus.com (Matthias Reichl)
Date: Sat, 17 Feb 2007 20:22:34 +0100
Subject: FEATURE_IFCONFIG_BROADCAST_PLUS broken
Message-ID: <20070217192233.GA18191@horus.com>

I just noticed that "ifconfig eth0 broadcast +" doesn't work, although
the FEATURE_IFCONFIG_BROADCAST_PLUS is enabled.

busybox 1.3.0 and 1.4.1 say "ifconfig: +: unknown host", current
svn says "ifconfig: bad address '+'".

I tested several older versions, this feature works fine up to 1.2.2.1
so I guess the bug must have sneaked in somewhere between October
and December last year.

so long,

Hias

From hias at horus.com  Sat Feb 17 12:43:16 2007
From: hias at horus.com (Matthias Reichl)
Date: Sat, 17 Feb 2007 21:43:16 +0100
Subject: FEATURE_IFCONFIG_BROADCAST_PLUS broken
In-Reply-To: <20070217192233.GA18191@horus.com>
References: <20070217192233.GA18191@horus.com>
Message-ID: <20070217204316.GA21241@horus.com>

Please forget about this. Busybox works fine, the problem was sitting
in front of the computer...

so long,

Hias

From vda.linux at googlemail.com  Sat Feb 17 14:35:58 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 23:35:58 +0100
Subject: [PATCH] init cleanup - request for testing
In-Reply-To: <20070217133359.bfc52cea95091b0fffcb409eab6296ba.e20c8bfcab.wbe@email.secureserver.net>
References: <20070217133359.bfc52cea95091b0fffcb409eab6296ba.e20c8bfcab.wbe@email.secureserver.net>
Message-ID: <200702172335.58060.vda.linux@googlemail.com>

On Saturday 17 February 2007 21:33, akennedy at techmoninc.com wrote:
> > We should fix init's crazy handling of console and stdio fd's first
> > (see my earlier mail today). Not too hard, I just need people who
> > are willing to test changes.
> 
> I'll do some testing for you.  I can at least test the serial stuff ;).

Wow, nice.

Attached patch is a first step in making init's handling
of console simpler and hopefully saner.

We do not close fd 0,1,2 up-front and don't try to painfully discover
the name of console device - because we don't need to. It is
_already_ open_ for us!

open_new_terminal() now recognizes a special case of empty
tty name which means "just use existing fd 0".

log_console is retained - there can be users of that feature.
On serial lines, log_console is automatically redirected
to fd #2 (old code was trying to find the name of console,
open console again, yadda, yadda... it's all gone.
fd #2 _is_ the console).

On Friday 16 February 2007 23:45, Natanael Copa wrote:
> The current problem is, that even if console goes to serial port so I
> can see the kernel messages and bootscript output, busybox init will
> never give a login from inittab unless the previous line is there.

I did not test it, but maybe

::respawn:/sbin/getty - 115200 vt100

already works: i.e. starts a getty on /dev/tty1 or on /dev/ttyS0,
depending on kernel's command line.

Please test whether that works and whether such getty
is able to obtain controlling tty.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.patch
Type: text/x-diff
Size: 22138 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070217/db70e013/attachment.bin 

From natanael.copa at gmail.com  Sat Feb 17 19:28:13 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 18 Feb 2007 04:28:13 +0100
Subject: Busybox build problem
In-Reply-To: <200702171654.40381.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
Message-ID: <20070218042813.154d9403.natanael.copa@gmail.com>

On Sat, 17 Feb 2007 16:54:40 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On Saturday 17 February 2007 03:49, Ravi Chemudugunta wrote:
> > # make allnoconfig; make
> > 
> >   LINK    busybox_unstripped
> > /home/brion/busybox-1.4.1/scripts/trylink: 5: function: not found

Without looking at the code, this could probably be walked around by
s/sh/bash/ on first line.

> > /home/brion/busybox-1.4.1/scripts/trylink: 11: Syntax error: "}" unexpected
> > make: *** [busybox_unstripped] Error 2
> > 
> > This error occurs on *ubuntu due to the use of dash as the default
> > shell (sh->dash).  the scripts included were designed with bash which
... 
> Unfortunately it means that fixing just busybox's stripts
> is not a solution - there are tons of other shell scripts
> lying aroung.
> 
> dash should support "function". It shouldn't be too hard - 

Since busybox ash is based on dash, this applies to busybox ash too.

I am using gentoo's bash centric init scripts, patching them to work
with busybox's ash. Its amazing how much really works in dash/ash and
most things that don't work are this kind of "meaningless" bash
features that just add bloat to your shell and can easy be avoided by
doing simple changes in the script. (like removing the "function"
keyword from function declarations)

I'd prefer people stop using bash specific things, rather than trying
to patch all shells to support all bash wierdness.

Natanael

From busybox at lists.lammerts.org  Sat Feb 17 20:04:19 2007
From: busybox at lists.lammerts.org (Eric Lammerts)
Date: Sat, 17 Feb 2007 23:04:19 -0500
Subject: [PATCH] svlogd bug?
Message-ID: <45D7D043.8080208@lists.lammerts.org>


Hi,
When I create a 'finish' script, runsv just keeps running it over and 
over again. It never goes back to 'run'.

Attached patch (against current svn) fixes it.

Eric

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: runsv-patch
Url: http://busybox.net/lists/busybox/attachments/20070217/670a6e95/attachment.asc 

From vda.linux at googlemail.com  Sun Feb 18 03:03:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 18 Feb 2007 12:03:13 +0100
Subject: Busybox build problem
In-Reply-To: <20070218042813.154d9403.natanael.copa@gmail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
Message-ID: <200702181203.13453.vda.linux@googlemail.com>

On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > Unfortunately it means that fixing just busybox's stripts
> > is not a solution - there are tons of other shell scripts
> > lying aroung.
> > 
> > dash should support "function". It shouldn't be too hard - 
> 
> Since busybox ash is based on dash, this applies to busybox ash too.
> 
> I am using gentoo's bash centric init scripts, patching them to work
> with busybox's ash. Its amazing how much really works in dash/ash and
> most things that don't work are this kind of "meaningless" bash
> features that just add bloat to your shell and can easy be avoided by
> doing simple changes in the script. (like removing the "function"
> keyword from function declarations)
> 
> I'd prefer people stop using bash specific things,

It's too late. Face the reality. bash installed base is too big.

> rather than trying 
> to patch all shells to support all bash wierdness.

How you realistically imagine everyone starting to audit all their
scripts for usage of "function"? How many man-years will it take?
Then compare it to the effort required to add support for this feature
to dash.
--
vda

From vda.linux at googlemail.com  Sun Feb 18 03:05:06 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 18 Feb 2007 12:05:06 +0100
Subject: [PATCH] svlogd bug?
In-Reply-To: <45D7D043.8080208@lists.lammerts.org>
References: <45D7D043.8080208@lists.lammerts.org>
Message-ID: <200702181205.06289.vda.linux@googlemail.com>

On Sunday 18 February 2007 05:04, Eric Lammerts wrote:
> 
> Hi,
> When I create a 'finish' script, runsv just keeps running it over and 
> over again. It never goes back to 'run'.
> 
> Attached patch (against current svn) fixes it.

Applied, thanks!
--
vda

From chemuduguntar at gmail.com  Sun Feb 18 03:16:07 2007
From: chemuduguntar at gmail.com (Ravi Chemudugunta)
Date: Mon, 19 Feb 2007 00:16:07 +1300
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <7a4208ef0702180316j7cc2e6cdwfb5d43507ba80d6@mail.gmail.com>

the posix nazis will want you denis =)

I think its noble of dash adhering to posix standards (whatever they are for
shells) ... as you mentioned the base for bash is too big to 'cleanup' to
work with dash...I would have all scripts by default run on bash, unless
explicitly defined inside the scripts...for e.g. leave sh pointing to bash
but inside the shell scripts which are 'cleaned' ... have them execute
against dash with #!/bin/dash or fork dash that is like bash
(grammatically).


On 2/19/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > > Unfortunately it means that fixing just busybox's stripts
> > > is not a solution - there are tons of other shell scripts
> > > lying aroung.
> > >
> > > dash should support "function". It shouldn't be too hard -
> >
> > Since busybox ash is based on dash, this applies to busybox ash too.
> >
> > I am using gentoo's bash centric init scripts, patching them to work
> > with busybox's ash. Its amazing how much really works in dash/ash and
> > most things that don't work are this kind of "meaningless" bash
> > features that just add bloat to your shell and can easy be avoided by
> > doing simple changes in the script. (like removing the "function"
> > keyword from function declarations)
> >
> > I'd prefer people stop using bash specific things,
>
> It's too late. Face the reality. bash installed base is too big.
>
> > rather than trying
> > to patch all shells to support all bash wierdness.
>
> How you realistically imagine everyone starting to audit all their
> scripts for usage of "function"? How many man-years will it take?
> Then compare it to the effort required to add support for this feature
> to dash.
> --
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070219/fc59f8d2/attachment.htm 

From psmith at netezza.com  Sun Feb 18 07:40:21 2007
From: psmith at netezza.com (Paul Smith)
Date: Sun, 18 Feb 2007 10:40:21 -0500
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <1171813222.14708.80.camel@homebase>

On Sun, 2007-02-18 at 12:03 +0100, Denis Vlasenko wrote:

> > I'd prefer people stop using bash specific things,
> 
> It's too late. Face the reality. bash installed base is too big.

I disagree; major distributions such as Ubuntu are right now ditching
bash as /bin/sh, for other shells like dash and ash: they are doing this
to try to get more efficiency and speed during bootup etc.  They are not
compromising and they are forcing packages to clean up their sloppy
shell programming, and make /bin/sh scripts conform to POSIX.

> How you realistically imagine everyone starting to audit all their
> scripts for usage of "function"? How many man-years will it take?
> Then compare it to the effort required to add support for this feature
> to dash.

That, of course, is up to you.  However, I will point out that I can
count on the fingers of one hand (with some left over) the number of
package shell scripts I've ever seen that use "function".  And I've been
building free software since the 1980's.

I've seen lots scripts that are written to require bash, don't get me
wrong.  But for all different sorts of reasons and "function" is not a
common one, in my experience.

YMMV...

From vda.linux at googlemail.com  Sun Feb 18 08:12:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 18 Feb 2007 17:12:51 +0100
Subject: Busybox build problem
In-Reply-To: <1171813222.14708.80.camel@homebase>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
	<1171813222.14708.80.camel@homebase>
Message-ID: <200702181712.51372.vda.linux@googlemail.com>

On Sunday 18 February 2007 16:40, Paul Smith wrote:
> On Sun, 2007-02-18 at 12:03 +0100, Denis Vlasenko wrote:
> 
> > > I'd prefer people stop using bash specific things,
> > 
> > It's too late. Face the reality. bash installed base is too big.
> 
> I disagree; major distributions such as Ubuntu are right now ditching
> bash as /bin/sh, for other shells like dash and ash: they are doing this
> to try to get more efficiency and speed during bootup etc.

bash is not a reason why bootup is slow. For desktop machine,
bash is small enough (700kb IIRC) to not matter.

Bootup is slow because of SysV init scripts. I ditched them,
and my boot is fast enough for me ever since.

> They are not 
> compromising and they are forcing packages to clean up their sloppy
> shell programming, and make /bin/sh scripts conform to POSIX.

Standards are not gods, they are just codified practice.
What is so terribly wrong with "function" syntax?

> > How you realistically imagine everyone starting to audit all their
> > scripts for usage of "function"? How many man-years will it take?
> > Then compare it to the effort required to add support for this feature
> > to dash.
> 
> That, of course, is up to you.  However, I will point out that I can
> count on the fingers of one hand (with some left over) the number of
> package shell scripts I've ever seen that use "function".  And I've been
> building free software since the 1980's.

Wow, you read makefiles and supporting shell script machinery
of every package you build? Must be terribly time consuming task...
--
vda

From psmith at netezza.com  Sun Feb 18 16:40:08 2007
From: psmith at netezza.com (Paul Smith)
Date: Sun, 18 Feb 2007 19:40:08 -0500
Subject: Busybox build problem
In-Reply-To: <200702181712.51372.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
	<1171813222.14708.80.camel@homebase>
	<200702181712.51372.vda.linux@googlemail.com>
Message-ID: <1171845609.14708.108.camel@homebase>

On Sun, 2007-02-18 at 17:12 +0100, Denis Vlasenko wrote:

> > > It's too late. Face the reality. bash installed base is too big.
> > 
> > I disagree; major distributions such as Ubuntu are right now ditching
> > bash as /bin/sh, for other shells like dash and ash: they are doing this
> > to try to get more efficiency and speed during bootup etc.
> 
> bash is not a reason why bootup is slow. For desktop machine,
> bash is small enough (700kb IIRC) to not matter.
> 
> Bootup is slow because of SysV init scripts. I ditched them,
> and my boot is fast enough for me ever since.

Ubuntu is ditching SysV init scripts also; as of their previous release
they're now using Upstart https://wiki.ubuntu.com/ReplacementInit
although they're going there incrementally (so many of the services in
Edgy still use traditional scripts).  For a general purpose desktop
system you must have something more advanced than hardcoded scripting
(see the use cases described in the Wiki page above for some things that
need to be supported).

Anyway, this is neither here nor there; regardless of the reasons for it
and whether the reasons are correct or not, the fact remains that Ubuntu
(at least) does not use bash as /bin/sh, and they are convincing many
common packages to clean up their scripting.

> Standards are not gods, they are just codified practice.
> What is so terribly wrong with "function" syntax?

Nothing, other than the mild criticism that it's redundant and
potentially confusing ("this function doesn't have 'function' and this
one does... why is that?  What's the difference?" followed by a
time-wasting search through the documentation).  I have no problem with
adding it if you want to.  All I'm saying is that I don't believe
there's a technical reason to add it; I don't think "bash is ubiquitous
and so we should implement its idiosyncrasies" is accurate.

> > > How you realistically imagine everyone starting to audit all their
> > > scripts for usage of "function"? How many man-years will it take?
> > > Then compare it to the effort required to add support for this feature
> > > to dash.
> > 
> > That, of course, is up to you.  However, I will point out that I can
> > count on the fingers of one hand (with some left over) the number of
> > package shell scripts I've ever seen that use "function".  And I've been
> > building free software since the 1980's.
> 
> Wow, you read makefiles and supporting shell script machinery
> of every package you build? Must be terribly time consuming task...

I'm not sure where this hostile tone is coming from.

In fact, I've build hundreds of packages over many years on systems that
were NOT Linux, including various BSD's, SunOS, Solaris, HPUX, AIX,
DG-UX, OSF1, and others, and not one of those used or uses bash
as /bin/sh.  And while I had portability problems galore, and ran across
many bash-isms in files marked as /bin/sh, I hardly ever ran across a
situation where the failure was the use of "function" in a shell script.

From vapier at gentoo.org  Sun Feb 18 19:54:28 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 18 Feb 2007 22:54:28 -0500
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <200702182254.29429.vapier@gentoo.org>

On Sunday 18 February 2007, Denis Vlasenko wrote:
> On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > I'd prefer people stop using bash specific things,
>
> It's too late. Face the reality. bash installed base is too big.

if you want to use bashisms, that's fine, but at least declare the shebang 
properly:
#!/bin/bash
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070218/a4cbdec9/attachment.pgp 

From natanael.copa at gmail.com  Mon Feb 19 02:32:55 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 19 Feb 2007 11:32:55 +0100
Subject: serial console and log-in
In-Reply-To: <200702171700.10195.vda.linux@googlemail.com>
References: <1171665937.2696.252.camel@localhost>
	<200702171700.10195.vda.linux@googlemail.com>
Message-ID: <1171881175.9155.4.camel@localhost>

On Sat, 2007-02-17 at 17:00 +0100, Denis Vlasenko wrote:
> On Friday 16 February 2007 23:45, Natanael Copa wrote:
> > Hi,
> > 
> > Is there some way to autodetect if the console is a serial console, and
> > if it is, activate a line like this in inittab:
> > 
> > ttyS0 ::respawn:/sbin/getty -L ttyS0 115200 vt100 
> > 
> > And if /dev/console is not a serial console, it will not activate any
> > getty on the serial console.
> 
> I propose making it possible to start getty (or whatever)
> on any device which happens to be init's fd#0 (which is passed to it
> by kernel). This way you will automatically get your getty whereever
> kernel's console happened to be this time.
> 
> Proposed syntax:
> 
> ::respawn:/sbin/getty - 115200 vt100 
> 
> or
> 
> 0::respawn:/sbin/getty - 115200 vt100 
> 
> or 
> 
> stdin::respawn:/sbin/getty - 115200 vt100 

Yes. something like that was exactly what I was hoping for.

> We should fix init's crazy handling of console and stdio fd's first
> (see my earlier mail today). Not too hard, I just need people who
> are willing to test changes.

I'm willing to test. I think I will be able to allocate some time during
the week. Unfortunally, the serial-only box hasn't arrived yet and you
can't remove the vga card in qemu afaik.

Thanks!
> --
> vda


From natanael.copa at gmail.com  Mon Feb 19 02:39:49 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 19 Feb 2007 11:39:49 +0100
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <1171881589.9155.11.camel@localhost>

On Sun, 2007-02-18 at 12:03 +0100, Denis Vlasenko wrote:
> On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > > Unfortunately it means that fixing just busybox's stripts
> > > is not a solution - there are tons of other shell scripts
> > > lying aroung.
> > > 
> > > dash should support "function". It shouldn't be too hard - 
> > 
> > Since busybox ash is based on dash, this applies to busybox ash too.
> > 
> > I am using gentoo's bash centric init scripts, patching them to work
> > with busybox's ash. Its amazing how much really works in dash/ash and
> > most things that don't work are this kind of "meaningless" bash
> > features that just add bloat to your shell and can easy be avoided by
> > doing simple changes in the script. (like removing the "function"
> > keyword from function declarations)
> > 
> > I'd prefer people stop using bash specific things,
> 
> It's too late. Face the reality. bash installed base is too big.
> 
> > rather than trying 
> > to patch all shells to support all bash wierdness.
> 
> How you realistically imagine everyone starting to audit all their
> scripts for usage of "function"? How many man-years will it take?
> Then compare it to the effort required to add support for this feature
> to dash.

I am doing it with gentoo init scripts. It's not that much work. (less
than rewrite for runinit). I'm doing it because bash is almost the size
as my entire busybox.

In your case, on a building machine, sure, you can expect bash to be
there. In that case, as someone already explained, use the:

#!/bin/bash



From vda.linux at googlemail.com  Mon Feb 19 15:46:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 20 Feb 2007 00:46:25 +0100
Subject: Busybox build problem
In-Reply-To: <1171845609.14708.108.camel@homebase>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702181712.51372.vda.linux@googlemail.com>
	<1171845609.14708.108.camel@homebase>
Message-ID: <200702200046.25206.vda.linux@googlemail.com>

On Monday 19 February 2007 01:40, Paul Smith wrote:
> > > That, of course, is up to you.  However, I will point out that I can
> > > count on the fingers of one hand (with some left over) the number of
> > > package shell scripts I've ever seen that use "function".  And I've been
> > > building free software since the 1980's.
> > 
> > Wow, you read makefiles and supporting shell script machinery
> > of every package you build? Must be terribly time consuming task...
> 
> I'm not sure where this hostile tone is coming from.

Oops, sorry. :(
--
vda

From marco-glatz at web.de  Tue Feb 20 06:55:59 2007
From: marco-glatz at web.de (Marco Glatz)
Date: Tue, 20 Feb 2007 15:55:59 +0100
Subject: segfault with ls
Message-ID: <580912971@web.de>

hello,

i have a strange problem here. when i do "ls -l /dev" i get a segmentation fault, runnig strace does not show any errors, and when running ls-cmd from within a shell-script, then it works. i'm using latest busybox with udev-104 and kernel 2.6.19


marco
_______________________________________________________________________
Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222


From akennedy at techmoninc.com  Tue Feb 20 13:50:25 2007
From: akennedy at techmoninc.com (akennedy at techmoninc.com)
Date: Tue, 20 Feb 2007 14:50:25 -0700
Subject: serial console and log-in
Message-ID: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>



> -------- Original Message --------
> Subject: RE: serial console and log-in
> From: akennedy at techmoninc.com
> Date: Sat, February 17, 2007 2:33 pm
> To: Denis Vlasenko <vda.linux at googlemail.com>
> 
> > We should fix init's crazy handling of console and stdio fd's first
> > (see my earlier mail today). Not too hard, I just need people who
> > are willing to test changes.
> 
> I'll do some testing for you.  I can at least test the serial stuff ;).
> 
> Andy

Serial console works with

::respawn:-/bin/sh

Haven't tested anything else, but I'd guess if that works, so does everything else.

Andy

From vda.linux at googlemail.com  Tue Feb 20 16:04:57 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 21 Feb 2007 01:04:57 +0100
Subject: serial console and log-in
In-Reply-To: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
Message-ID: <200702210104.57030.vda.linux@googlemail.com>

On Tuesday 20 February 2007 22:50, akennedy at techmoninc.com wrote:
> 
> > -------- Original Message --------
> > Subject: RE: serial console and log-in
> > From: akennedy at techmoninc.com
> > Date: Sat, February 17, 2007 2:33 pm
> > To: Denis Vlasenko <vda.linux at googlemail.com>
> > 
> > > We should fix init's crazy handling of console and stdio fd's first
> > > (see my earlier mail today). Not too hard, I just need people who
> > > are willing to test changes.
> > 
> > I'll do some testing for you.  I can at least test the serial stuff ;).
> > 
> > Andy
> 
> Serial console works with
> 
> ::respawn:-/bin/sh
> 
> Haven't tested anything else, but I'd guess if that works, so does everything else.

Ok, will apply that patch to svn.

A bit more tests will be useful.
Does it work _without_ serial console?
In both cases, is there controlling tty? IOW:

echo TEST >/dev/tty
TEST

This is good (controlling tty exists)

echo TEST >/dev/tty
sh: /dev/tty: No such device or address

This isn't good.
--
vda

From navalnovel at gmail.com  Wed Feb 21 00:54:54 2007
From: navalnovel at gmail.com (Naval Saini)
Date: Wed, 21 Feb 2007 14:24:54 +0530
Subject: Fwd: [arm-gnu] porting linux 2.6.18.1(EABI) support GCC-4.1.1(eabi)
	shell not coming
In-Reply-To: <d8dd82df0702190709m18c4d778i33b8f54bd6100c3f@mail.gmail.com>
References: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>
	<20070216202631.GA17153@mvista.com>
	<200702162204.51805.openembedded@hrw.one.pl>
	<er56n2$ihh$1@sea.gmane.org>
	<d8dd82df0702190709m18c4d778i33b8f54bd6100c3f@mail.gmail.com>
Message-ID: <d8dd82df0702210054y723f717axdd8a6ec042184b3b@mail.gmail.com>

Hi:

Hi Keon Kooi, it seems your patch is what we needed.

I further saw that, before we applied your patch there was a 'clz r1, r3'
instruction in objdump of busybox binary. At this instruction (maybe there
are others too) that we were getting an exception and jumping into the
kernel. This instruction is supported in v5 arch but not in v4, that we are
using (found on net).

So is this patch explained or is there more we are missing for informative
purpose on what this patch does? Its good enuf the shell is up.

Thanks and regards,
Naval Saini

On 2/19/07, Naval Saini <navalnovel at gmail.com> wrote:
>
> Hi Everyone:
>
> We have been able to move past init ( in busybox ).
> Earlier we were getting stuck while making first IOCTL  (with TIOCGSERIAL)
> call and then while close (2).   ( i commened console_init and hardcoded
> '/dev/console' in it ; and commened the line close (2) , next )
>
> But even after init, we donot get the shell.
>
> I find myself making a flurry of calls to do_notify_resume ( )    ( and
> then a do_signal , ... here is my result from printk's i put in the kernel -
> do_signal )
>
>  do_signal - syscall 0 , current->pid 119, current->gid 119
>  do_signal - syscall 1073913928 , current->pid 1, current->gid 1, signr -
> 0
>  do_signal - syscall 0 , current->pid 121, current->gid 121
>  do_signal - syscall 1073913928 , current->pid 1, current->gid 1, signr -
> 0
>  do_signal - syscall 0 , current->pid 123, current->gid 123
>  ...
>
> I find the value in parameter syscall quite absurd. Thats cause, when do_notify_resume
> calls do_signal ; the value in parameter (its the third param) is 10, 75,
> etc... but when i printk it, its 0 or some weird value.
>
> The stack frame in do_signal is as follows :-
>    do_signal
>    do_notify_resume
>    work_pending (asm)
>    exception                   ( SR: 0x ... some addr. )
>
>
> Also , would it be helpful to know, for which instruction/s is/are causing
> this exception?
>
> Help needed in zeroing down on the issue.
> By the way, other than the EABI patch for V4, i have tried all previous
> suggestions (without effect).  :-)
>
> Thanks for all the mails.
> Regards,
> Naval
>
> On 2/17/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Marcin Juszkiewicz schreef:
> > > Dnia pi?tek, 16 lutego 2007, George G. Davis napisa?:
> > >>> CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
> > >> ISTR hereing that ARM eABI support in GCC requires/assumes an ARMv5TE
> > >> or greater processor.  Yet you're using an ARMv4T based processor.  I
> > >> don't know for certain if this is causing problems for you here but
> > >> perhaps other may comment on status of GCC ARM eABI support on ARMv4T
> > >> targets, e.g. if you built userland under the assumption that the
> > >> processor is ARMv5TE or above, it aint gonna work on an ARMv4T based
> > >> processor?
> > >
> > > ?ngstr?m distribution supports armv4t/EABI. All needed parts of
> > toolchain
> > > are available in OpenEmbedded buildsystem.
> > >
> > > We use gcc 4.1.1/binutils 2.17.50.0.5/glibc 2.5 with amount of patches
> > to
> > > get it working properly. IIRC only armv4 (for example sa1100) are not
> > > supported in EABI.
> >
> > You can disable thumb-interworking and patch each and every -Werror out
> > of libc to get it
> > to compile for strongarm. Or pester the gcc people to implement proper
> > armv4 support.
> >
> > regards,
> >
> > Koen
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070221/5dad195d/attachment.html 

From parmarsatpal at gmail.com  Wed Feb 21 01:23:10 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Wed, 21 Feb 2007 14:53:10 +0530
Subject: time command wrong values
Message-ID: <457d2dc30702210123o139f0246wbce0910e93e07eec@mail.gmail.com>

Hi all;

             I am facing a very weird problem. I have ported linux kernel
2.6.18.2 on arm 9 base board.When I use time command from buzybox to
understanding the performance characteristics of a single program I am
getting  some finite values for real but sys and user values are always
zero.


/ # dd if=/dev/ram0  of=/dev/ram1  count=10000000
16384+0 records in
16384+0 records out

/ # time dd if=/dev/ram0  of=/dev/ram1  count=10000000
16384+0 records in
16384+0 records out
real    0m 0.80s
user    0m 0.00s
sys     0m 0.00s

/ # time dd if=/dev/ram0  of=/dev/ram1  count=100000000
16384+0 records in
16384+0 records out
real    0m 0.80s
user    0m 0.00s
sys     0m 0.00s

/ # time dd if=/dev/ram0  of=/dev/ram1  count=1000000000
16384+0 records in
16384+0 records out
real    0m 0.80s
user    0m 0.00s
sys     0m 0.00s
/ # time dd if=/dev/ram0  of=/dev/ram1  count=1000
1000+0 records in
1000+0 records out
real    0m 0.06s
user    0m 0.00s
sys     0m 0.00s

When I tried this same load *on linux system* I get following values.

time dd if=/dev/ram0  of=/dev/ram1  count=1000

real    0m0.022s
user    0m0.000s
sys     0m0.002s

Am I doing things wrong? My uneducated  guess is that there can some problem
in BSp side . Any thoughts?

Thanks in adavnce.

satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070221/468d860e/attachment.htm 

From natanael.copa at gmail.com  Wed Feb 21 02:44:17 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Wed, 21 Feb 2007 11:44:17 +0100
Subject: serial console and log-in
In-Reply-To: <200702210104.57030.vda.linux@googlemail.com>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
	<200702210104.57030.vda.linux@googlemail.com>
Message-ID: <1172054657.12630.38.camel@localhost>

On Wed, 2007-02-21 at 01:04 +0100, Denis Vlasenko wrote:
> On Tuesday 20 February 2007 22:50, akennedy at techmoninc.com wrote:
> > 
> > > -------- Original Message --------
> > > Subject: RE: serial console and log-in
> > > From: akennedy at techmoninc.com
> > > Date: Sat, February 17, 2007 2:33 pm
> > > To: Denis Vlasenko <vda.linux at googlemail.com>
> > > 
> > > > We should fix init's crazy handling of console and stdio fd's first
> > > > (see my earlier mail today). Not too hard, I just need people who
> > > > are willing to test changes.
> > > 
> > > I'll do some testing for you.  I can at least test the serial stuff ;).
> > > 
> > > Andy
> > 
> > Serial console works with
> > 
> > ::respawn:-/bin/sh
> > 
> > Haven't tested anything else, but I'd guess if that works, so does everything else.
> 
> Ok, will apply that patch to svn.

> A bit more tests will be useful.
> Does it work _without_ serial console?
> In both cases, is there controlling tty? IOW:
> 
> echo TEST >/dev/tty
> TEST
> 
> This is good (controlling tty exists)
> 
> echo TEST >/dev/tty
> sh: /dev/tty: No such device or address
> 
> This isn't good.

I backported the svn init to 1.4.1 (i depend on releases).

My inittab line looks like this:

::respawn:/sbin/getty - 9600 vt100

I got a login prompt but no controlling tty:

-ash: cant't access tty; job control turned off

~$ echo TEST > /dev/tty
-ash: cannot create /dev/tty: No such device or address

That was on a VGA console.

Then I tried to run it in qemu, with -nographic. It booted, it gave me a
login, but same as VGA, no controlling tty.


--
Natanael Copa


From stephane.billiart at gmail.com  Wed Feb 21 06:24:24 2007
From: stephane.billiart at gmail.com (Stephane Billiart)
Date: Wed, 21 Feb 2007 09:24:24 -0500
Subject: truncated syslog messages
Message-ID: <20070221142424.GA15913@salusa.home.net>

The problem:

server# logger "message to syslog"
server# killall syslogd
server# tail /var/log/messages 
Feb 21 08:50:19 server syslog.info syslogd started: BusyBox v1.5.0.svn
Feb 21 08:50:23 server kern.warn kernel: TSC 
Feb 21 08:50:31 server user.notice root: messa
Feb 21 08:51:25 server syslog.info syslogd exiting
server# ls -l /dev/log /var/syslog
lrwxrwxrwx    1 root     root           11 Jan  4  1980 /dev/log -> /var/syslog=
srw-rw-rw-    1 root     root            0 Feb 21 08:50 /var/syslog=

All messages syslog receives are truncated, not the ones it writes itself...

My embedded system runs linux 2.6.19.2 with uClibc 0.9.27.
I have mdev activated in busybox, /dev is a ramfs partition and /var is tmpfs.
I tried with and without CONFIG_FEATURE_IPC_SYSLOG and get the same results

I see the problem with the SVN and 1.4.1 versions but not with 1.2.2.1
With glibc 2.3.6, everything is fine also.

There's been a lot of changes in syslogd recently.
I started looking at the code but so far did not find anything to explain
those short reads from /dev/log.

Any idea?

-- 
St?phane Billiart                      http://perso.orange.fr/billiart/

From iggarpe at terra.es  Thu Feb 22 03:29:13 2007
From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=)
Date: Thu, 22 Feb 2007 12:29:13 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1 (this is the GOOD one)
In-Reply-To: <20070216132328.GA28870@aon.at>
References: <45D593D5.9070507@terra.es> <20070216132328.GA28870@aon.at>
Message-ID: <45DD7E89.7010805@terra.es>

Bernhard Fischer escribi?:

Thank you for the corrections. Question is, should I correct the code 
and submit a new patch?

I ask because that would be practical if I was to maintain the slattach 
applet code, which as far as I know I'm not.

Nacho.
> On Fri, Feb 16, 2007 at 12:21:57PM +0100, Ignacio Garc?a P?rez wrote:
>   
>> Sorry, attached the wrong patch in previous message. This is the good one.
>>
>> As I already said, would be nice to rewrite the option parsing code to 
>> make use of the libbb functions.
>>
>> Regards.
>>
>>
>>
>>     
>
>   
>> diff -urN busybox-1.4.1/include/applets.h busybox-1.4.1-modified/include/applets.h
>> --- busybox-1.4.1/include/applets.h	2007-01-24 22:34:48.000000000 +0100
>> +++ busybox-1.4.1-modified/include/applets.h	2007-02-16 11:45:33.000000000 +0100
>> @@ -262,6 +262,7 @@
>> USE_FEATURE_SH_IS_LASH(APPLET_NOUSAGE(sh, lash, _BB_DIR_BIN, _BB_SUID_NEVER))
>> USE_FEATURE_SH_IS_MSH(APPLET_NOUSAGE(sh, msh, _BB_DIR_BIN, _BB_SUID_NEVER))
>> USE_SHA1SUM(APPLET_ODDNAME(sha1sum, md5_sha1_sum, _BB_DIR_USR_BIN, _BB_SUID_NEVER, sha1sum))
>> +USE_SLATTACH(APPLET(slattach, _BB_DIR_SBIN, _BB_SUID_NEVER))
>> USE_SLEEP(APPLET(sleep, _BB_DIR_BIN, _BB_SUID_NEVER))
>> USE_SOFTLIMIT(APPLET_ODDNAME(softlimit, chpst, _BB_DIR_USR_BIN, _BB_SUID_NEVER, softlimit))
>> USE_SORT(APPLET(sort, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
>> diff -urN busybox-1.4.1/include/usage.h busybox-1.4.1-modified/include/usage.h
>> --- busybox-1.4.1/include/usage.h	2007-01-24 22:34:48.000000000 +0100
>> +++ busybox-1.4.1-modified/include/usage.h	2007-02-16 11:44:10.000000000 +0100
>> @@ -2788,6 +2788,20 @@
>>        "	-s	Don't output anything, status code shows success\n" \
>>        "	-w	Warn about improperly formatted SHA1 checksum lines")
>>
>> +#define slattach_trivial_usage \
>> +	"[-cehmLF] [-s speed] [-p protocol] DEVICEs"
>> +#define slattach_full_usage \
>> +	"Attach network interface(s) to serial line(s).\n" \
>> +	"Options:\n" \
>> +	"\t-p\tset a specific kind of protocol (slip, cslip, slip6, clisp6 or adaptive).\n" \
>> +	"\t-s\tset a specific line speed.\n"
>> +	"\t-c\texecute a command when the line is hung up\n" \
>> +	"\t-e\texit right after initializing device.\n" \
>> +	"\t-h\texit when the carrier is lost.\n" \
>> +	"\t-m\tdo NOT initialize the line in raw 8 bits mode.\n" \
>> +	"\t-L\tenable 3-wire operation.\n" \
>> +	"\t-F\tdisable RTS/CTS flow control.\n" \
>> + 
>> #define sleep_trivial_usage \
>> 	USE_FEATURE_FANCY_SLEEP("[") "N" USE_FEATURE_FANCY_SLEEP("]...")
>> #define sleep_full_usage \
>> diff -urN busybox-1.4.1/networking/Config.in busybox-1.4.1-modified/networking/Config.in
>> --- busybox-1.4.1/networking/Config.in	2007-01-24 22:34:34.000000000 +0100
>> +++ busybox-1.4.1-modified/networking/Config.in	2007-02-16 11:47:50.000000000 +0100
>> @@ -523,6 +523,12 @@
>> 	help
>> 	  Route displays or manipulates the kernel's IP routing tables.
>>
>> +config SLATTACH
>> +	bool "slattach"
>> +	default n
>> +	help
>> +	  Slattach is a small utility to attach network interfaces to serial lines.
>> +
>> config TELNET
>> 	bool "telnet"
>> 	default n
>> diff -urN busybox-1.4.1/networking/Kbuild busybox-1.4.1-modified/networking/Kbuild
>> --- busybox-1.4.1/networking/Kbuild	2007-01-24 22:34:34.000000000 +0100
>> +++ busybox-1.4.1-modified/networking/Kbuild	2007-02-16 11:38:37.000000000 +0100
>> @@ -32,6 +32,7 @@
>> lib-$(CONFIG_PING)         += ping.o
>> lib-$(CONFIG_PING6)        += ping6.o
>> lib-$(CONFIG_ROUTE)        += route.o
>> +lib-$(CONFIG_SLATTACH)     += slattach.o
>> lib-$(CONFIG_TELNET)       += telnet.o
>> lib-$(CONFIG_TELNETD)      += telnetd.o
>> lib-$(CONFIG_TFTP)         += tftp.o
>> diff -urN busybox-1.4.1/networking/slattach.c busybox-1.4.1-modified/networking/slattach.c
>> --- busybox-1.4.1/networking/slattach.c	1970-01-01 01:00:00.000000000 +0100
>> +++ busybox-1.4.1-modified/networking/slattach.c	2007-02-16 12:03:18.000000000 +0100
>> @@ -0,0 +1,266 @@
>> +/*
>> + *		Stripped down version of net-tools for busybox.
>> + *
>> + *		Author: Ignacio Garcia Perez (iggarpe at gmail dot com)
>> + *
>> + *		License: GPLv2 or later, see LICENSE file in this tarball.
>> + *
>> + *		There are some differences from the standard net-tools slattach:
>> + *
>> + *		- The -l option is not supported.
>> + *
>> + *		- Several devices can be specified in the command line. This is
>> + *		  very useful if you are handling many identical serial lines since
>> + *		  only one process is necessary to configure them all.
>> + *
>> + *		- The -F options allows disabling of RTS/CTS flow control.
>> + *
>> + */
>> +
>> +#include <unistd.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +#include <stdio.h>
>> +#include <signal.h>
>> +#include <errno.h>
>> +#include <sys/socket.h>
>> +#include <sys/types.h>
>> +#include <sys/stat.h>
>> +#include <fcntl.h>
>> +#include <termios.h>
>> +#include <sys/ioctl.h>
>> +
>> +#include "libbb.h"
>> +
>> +struct tty {
>> +	const char *	device;
>> +	int				handle;
>> +	int				saved_disc;
>> +	struct termios	saved_state;
>> +	struct tty *	next;
>> +};
>> +
>> +static struct tty *_tty_head = NULL;
>> +static struct tty *_tty_tail = NULL;
>> +
>> +/* Line discipline code table */
>> +
>> +static struct { const char *name; int code; } _proto [] = {
>> +	{ "slip",		0 },
>> +	{ "cslip",		1 },
>> +	{ "slip6",		2 },
>> +	{ "cslip6",		3 },
>> +	{ "adaptive",	8 },
>> +	{ NULL }
>> +};
>> +
>> +/*
>> + * Save tty state and line discipline
>> + */
>> +
>> +static int _save_state (struct tty *t) {
>> +
>> +	if (t->handle < 0) return 0;
>> +
>> +	if (tcgetattr(t->handle, &t->saved_state) < 0)			/* Save line status */
>> +		{ bb_perror_msg("get state"); return -1; }
>> +
>> +	if (ioctl(t->handle, TIOCGETD, &t->saved_disc) < 0)		/* Save line discipline */
>> +		{ bb_perror_msg("get discipline"); return -1; }
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Set tty state, line discipline and encapsulation
>> + */
>> +
>> +static int _set_state (struct tty *t, struct termios *state, int encap) {
>> +
>> +	int disc = N_SLIP;
>> +
>> +	if (t->handle < 0) return 0;
>> +
>> +	if (tcsetattr(t->handle, TCSANOW, state) < 0)			/* Set line status */
>> +		{ bb_perror_msg("set state"); return -1; }
>> +
>> +	if (ioctl(t->handle, TIOCSETD, &disc) < 0)				/* Set line discliple (N_SLIP always) */
>> +		{ bb_perror_msg("set discipline"); return -1; }
>> +
>> +	if (ioctl(t->handle, SIOCSIFENCAP, &encap) < 0)			/* Set encapsulation (SLIP, CSLIP, etc) */
>> +		{ bb_perror_msg("set encapsulation"); return -1; }
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Restore state and line discipline for ALL managed ttys
>> + *
>> + * Restoring ALL managed ttys is the only way to have a single
>> + * hangup delay.
>> + *
>> + */
>> +
>> +static int _restore_state_and_close (void) {
>> +
>> +	struct tty *t;
>> +	struct termios state;
>> +
>> +	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>> +
>> +		if (ioctl(t->handle, TIOCSETD, &t->saved_disc) < 0)			/* Restore line discipline */
>> +			{ bb_perror_msg("set discipline"); return -1; }
>> +
>> +		memcpy(&state, &t->saved_state, sizeof(state));				/* Hangup */
>> +		cfsetispeed(&state, B0);
>> +		cfsetospeed(&state, B0);
>> +		if (tcsetattr(t->handle, TCSANOW, &state) < 0)
>> +			{ bb_perror_msg("set state"); return -1; }
>> +	}
>> +
>> +	sleep(1);	/* The sleep time does not depend on the number of managed ttys */
>> +
>> +	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>> +
>> +		if (tcsetattr(t->handle, TCSANOW, &t->saved_state) < 0)		/* Restore line status */
>> +			{ perror("set state"); return -1; }
>> +
>> +		close(t->handle); t->handle = -1;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static void _sig_handler (int signo) {
>> +	if (_restore_state_and_close() < 0) sleep_and_die();
>> +	exit(0);
>> +}
>> +
>> +int slattach_main (int argc, char **argv) {
>> +
>> +	int i, encap;
>> +	struct tty *t;
>> +	struct termios state;
>> +	char buf [PATH_MAX];
>>     
>
> That's a large buffer, imho. xmalloc() or make it
> RESERVE_CONFIG_BUFFER(buf,PATH_MAX)
>
>   
>> +
>> +	const char *proto = "cslip";	/* Protocol */
>> +	const char *extcmd = NULL;		/* Command to execute after hangup */
>> +
>> +	int baud = -1;		/* Line baud rate (value) */
>> +	int baud_code = -1;	/* Line baud rate (system code) */
>> +	int local = 0;		/* Local mode (disable carrier watch) */
>> +	int quit = 0;		/* Initialize and exit */
>> +	int watch = 0;		/* watch for line hangup */
>> +	int raw = 1;		/* Initialize line in raw 8 bit mode */
>> +	int flow = 1;		/* Disable RTS/CTS flow control (not in net-tools slattach !!!) */
>>     
>
> most of these should use one variable and mask their bits in.
>   
>> +
>> +	/* Parse command line options */
>> +	/* TODO: use bb lib getopt_whatever? */
>>     
>
> getopt32, yes.
>
> The block below is just too bloated.
>   
>> +
>> +	for (i = 1; i < argc; i++) {
>> +
>> +		if (argv[i][0] == '-') switch (argv[i][1]) {
>> +			case 'p': proto = argv[++i]; break;
>> +			case 's': baud = atoi(argv[++i]); break;
>> +			case 'c': extcmd = argv[++i]; break;
>> +			case 'e': quit = 1; break;
>> +			case 'h': watch = 1; break;
>> +			case 'm': raw = 0; break;
>> +			case 'L': local = 1; break;
>> +			case 'F': flow = 0; break;
>> +			default: bb_error_msg_and_die("invalid option %s", argv[i]);
>> +		}
>> +
>> +		else {
>> +			t = (struct tty *)malloc(sizeof(struct tty));
>> +			if (t == NULL) bb_error_msg_and_die("not enough memory");
>>     
>
> No. xmalloc() instead
>
>   
>> +
>> +			t->device = argv[i];
>> +			t->handle = -1;
>> +			t->next = NULL;
>> +
>> +			if (_tty_head == NULL) _tty_head = _tty_tail = t;
>> +			else { _tty_tail->next = t; _tty_tail = t; }
>> +		}
>> +	}
>> +
>> +	if (_tty_head == NULL) bb_show_usage();
>> +
>> +	for (i = 0; _proto[i].name != NULL; i++)
>> +		if (!strcmp(_proto[i].name, proto)) break;
>>     
>
> index_in_str_array() instead
>
>   
>> +	if (_proto[i].name == NULL) bb_error_msg_and_die("invalid protocol %s", proto);
>> +	encap = _proto[i].code;
>> +
>> +	baud_code = tty_value_to_baud(baud);
>> +	if (baud_code < 0) bb_error_msg_and_die("invalid baud rate %i", baud);
>> +
>> +	/* Trap signals in order to restore tty states upon exit */
>> +
>> +	if (!quit) {
>> +		signal(SIGHUP, _sig_handler);
>> +		signal(SIGINT, _sig_handler);
>> +		signal(SIGQUIT, _sig_handler);
>> +		signal(SIGTERM, _sig_handler);
>> +	}
>> +
>> +	/* Configure ttys */
>> +
>> +	for (t = _tty_head; t != NULL; t = t->next) {
>> +
>> +		t->handle = open(t->device, O_RDWR | O_NDELAY);
>> +		if (t->handle < 0) {
>> +			snprintf(buf, sizeof(buf), "/dev/%s", t->device);
>>     
>
> concat_path_file() instead. Should make that huge buf from above
> superfluous.
>
>   
>> +			t->handle = open(buf, O_RDWR | O_NDELAY);
>> +			if (t->handle < 0) bb_perror_msg_and_die("open %s", t->device);
>> +		}
>> +
>> +		if (_save_state(t) < 0) sleep_and_die();
>> +
>> +		memcpy(&state, &t->saved_state, sizeof(state));
>> +
>> +		if (raw) {
>> +			memset(&state.c_cc, 0, sizeof(state.c_cc));
>> +			state.c_cc[VMIN]	= 1;
>> +			state.c_iflag		= IGNBRK | IGNPAR;
>> +			state.c_oflag		= 0;
>> +			state.c_lflag		= 0;
>> +			state.c_cflag		= CS8 | HUPCL | CREAD
>> +								| (local ? CLOCAL : 0) | (flow ? CRTSCTS : 0);
>> +		}
>> +
>> +		if (baud_code >= 0) {
>>     
>
> Didn't we check above that boud_rate not is < 0 above? drop it then.
>
>   
>> +			cfsetispeed(&state, baud_code);
>> +			cfsetospeed(&state, baud_code);
>> +		}
>> +
>> +		if (_set_state(t, &state, encap) < 0)
>> +			{ _restore_state_and_close(); sleep_and_die(); }
>> +	}
>> +
>> +	/* Exit now if option -e was passed */
>> +
>> +	if (quit) exit(0);
>> +
>> +	/* Watch line for hangup */
>> +
>> +	for (;;) {
>> +
>> +		if (watch)
>> +			for (t = _tty_head; t != NULL; t = t->next)
>> +				if (ioctl(t->handle, TIOCMGET, &i) < 0 || !(i & TIOCM_CAR))
>> +					quit = 1;
>> +
>> +		if (quit) break;
>>     
>
> would a while (!option_mask32 & QUIT) be smaller?
>
>   
>> +		sleep(15);
>> +	}
>> +
>> +	/* Execute command on hangup */
>> +
>> +	if (extcmd != NULL) system(extcmd);
>> +
>> +	/* Restore states and exit */
>> +
>> +	_restore_state_and_close();
>> +	return 0;
>> +}
>> +
>>     
>
>
>   


From ceesaxp at gmail.com  Thu Feb 22 11:22:31 2007
From: ceesaxp at gmail.com (Andrei Popov)
Date: Thu, 22 Feb 2007 22:22:31 +0300
Subject: gethostbyname Resolver Error
In-Reply-To: <f29fbf3a0702221036n640bc78r7cce2169c49d6c2@mail.gmail.com>
References: <f29fbf3a0702221036n640bc78r7cce2169c49d6c2@mail.gmail.com>
Message-ID: <f29fbf3a0702221122p2557c9e4se142623d3dbbfefc@mail.gmail.com>

Hi,

I am running BusyBox on WRT54G as part of OpenWRT firmware.  WRT
serves a local WLAN, being connected via a leased line to ISP, and
then through a PPTP VPN to Internet.  ISP runs several VPN gateway
servers, all are replying to a common host name -- let's call it
vpn.corbina.net but with different IP addresses -- 195.14.38.x.

Up until recently there were fewer than 20 servers in the VPN pool,
but a few days ago ISP has added several new servers to cope with the
load, pushing the total number of them to 23.  From that moment
uClib's gethostbyname stopped resolving names to IP addresses and
returns an unkown resolver error:

$ ping vpn.corbina.net
ping: vpn.corbina.net: Resolver error

$ nslookup vpn.corbina.net
Server:         localhost
Address:        127.0.0.1

nslookup: vpn.corbina.net: Resolver error

It would seem that because of a large number of entries returned by
the DNS server, gethostbyname fails to provide an name to IP mapping.
Are there any known work-arounds to this?


Thanks & please keep me on cc, as I am not subscribed to the mailing list.

Andrei

From ynakam at hitachisoft.jp  Fri Feb 23 00:47:33 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:33 +0900
Subject: [PATCH 0/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174733.e67e5fc6.ynakam@hitachisoft.jp>

Hi.

The following patches provide SELinux options(like -Z) and applets to coreutils.
To maintain SELinux system, some commands must be extended to be able to handle 
attribute in SELinux(such as security context).

Current patch is version 3. 
We submitted previous patches some weeks ago, and some reviews were done.
chcon and runcon applets are added, since last patch.
I think that's all for coreutils.

We hope the patches are merged into busybox svn tree.

[1/8] busybox-coreutils-common-01.v3.patch
 - common component for SELinux options, applets
   like usage messages, the definition of applets and Kbuild/Config.in.

[2/8] busybox-coreutils-02-copy.v3.patch
  - cp: -c option support. 
      -c option: security context is preserved during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.
   -Z option is also supported, security context can be set during file copy.
(annotation) The reason why the above options are required:
  SELinux stores secutiry context of files/directories in its
  xattr area, but most of commands don't pay attention for xattr.
  Thus, it's not preserved during file copy includes a case when mv
  falled back into read/write copy.
  We have to preserve them to keep consistency of the secure system.

[3/8] busybox-coreutils-03-mk.v3.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.
 This improves compatibility with up-streamed coreutils.


[4/8] busybox-coreutils-04-stat.v3.patch
 - -Z option support for stat. Security context of file is shown by -Z option.
 Security context of file is very important attribute for SELinux, 
 so it should be shown in stat.

[5/8]  busybox-coreutils-05-ls.v3.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced
 by -Z option in recent coreutils, so -Z have to be added by this patch.

[6/8] busybox-coreutils-06-id.v3.patch
 - -Z option support for id. Security context of process is shown by -Z option.

[7/8] busybox-coreutils-07-chcon.v3.patch
 - chcon - change security context of file. 
  chcon provides one of the core facilities to associate a correct security
  context within files. It enables to change whole or specific parts of the
  security context within them.

[8/8] busybox-coreutils-08-runcon.v3.patch
 - runcon - run application with specified security context.
  runcon provides one of the core facilities to run application with explicitly
  specified security context. It enables users to run their application under
  the least privilege set explicitly.


This project is originated from some of JPSEUG(Japan SELinux User Group). 
We have more patches to support SELinux commands/options.
For list of our work, please visit following site.
http://code.google.com/p/sebusybox/

Regards,
Yuichi Nakamura

From ynakam at hitachisoft.jp  Fri Feb 23 00:47:39 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:39 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174739.300d673a.ynakam@hitachisoft.jp>

[1/8] busybox-coreutils-common-01.v3.patch
 - common component for SELinux options, applets

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>





-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v3.patch
Type: application/octet-stream
Size: 9162 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/5ac1700a/attachment.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 00:47:47 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:47 +0900
Subject: [PATCH 2/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174747.4ced9178.ynakam@hitachisoft.jp>

[2/8] busybox-coreutils-02-copy.v3.patch
  - cp: -Z,-c option support. 
      -c option: security context is preserved during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.
    -Z option: security context can be set during file copy.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.v3.patch
Type: application/octet-stream
Size: 7808 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/c3e3e5dc/attachment-0001.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 00:47:53 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:53 +0900
Subject: [PATCH 3/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174753.db70e01c.ynakam@hitachisoft.jp>

[3/8] busybox-coreutils-03-mk.v3.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.

Signed-off-by:  Yoshinori Sato <ysato at users.sourceforge.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-mk-03.v3.patch
Type: application/octet-stream
Size: 2216 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/fe7a5ef8/attachment.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 00:48:01 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:01 +0900
Subject: [PATCH 4/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174801.76d28c39.ynakam@hitachisoft.jp>

[4/8] busybox-coreutils-04-stat.v3.patch
 - -Z option support for stat. Security context of file is shown by -Z option.

Signed-off-by:  Yoshinori Sato <ysato at users.sourceforge.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-stat-04.v3.patch
Type: application/octet-stream
Size: 10382 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/52b62a04/attachment.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 00:48:07 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:07 +0900
Subject: [PATCH 5/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>

[5/8]  busybox-coreutils-05-ls.v3.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.

Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-ls-05.v3.patch
Type: application/octet-stream
Size: 592 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/06b7e03d/attachment.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 00:48:17 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:17 +0900
Subject: [PATCH 6/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174817.ee9be179.ynakam@hitachisoft.jp>

[6/8] busybox-coreutils-06-id.v3.patch
 - -Z option support for id. Security context of process is shown by -Z option.

Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>





-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-id-06.v3.patch
Type: application/octet-stream
Size: 2727 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/4f2956ab/attachment-0001.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 00:48:23 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:23 +0900
Subject: [PATCH 7/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>

[7/8] busybox-coreutils-07-chcon.v3.patch
 - chcon - change security context of file. 

Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>





-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-chcon-07.v3.patch
Type: application/octet-stream
Size: 6322 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/421ad5e7/attachment.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 00:49:29 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:49:29 +0900
Subject: [PATCH 8/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174929.18e547ea.ynakam@hitachisoft.jp>

[8/8] busybox-coreutils-08-runcon.v3.patch
 - runcon - run application with specified security context.
  runcon provides one of the core facilities to run application with explicitly
  specified security context. It enables users to run their application under
  the least privilege set explicitly.

Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>






-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-runcon-08.v3.patch
Type: application/octet-stream
Size: 4463 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/805dd01b/attachment.obj 

From wharms at bfs.de  Fri Feb 23 03:07:02 2007
From: wharms at bfs.de (walter harms)
Date: Fri, 23 Feb 2007 12:07:02 +0100
Subject: gethostbyname Resolver Error
In-Reply-To: <f29fbf3a0702221122p2557c9e4se142623d3dbbfefc@mail.gmail.com>
References: <f29fbf3a0702221036n640bc78r7cce2169c49d6c2@mail.gmail.com>
	<f29fbf3a0702221122p2557c9e4se142623d3dbbfefc@mail.gmail.com>
Message-ID: <45DECAD6.4040104@bfs.de>

hi Andrei,
i am sorry that you have that problem, personally, i would try the ulibc mailing list.
This is the busybox ml. A tool that provides stuff in /bin like ls,cp,mv etc.
it *can* use uclib but also any other libc.

re,
 walter



Andrei Popov wrote:
> Hi,
> 
> I am running BusyBox on WRT54G as part of OpenWRT firmware.  WRT
> serves a local WLAN, being connected via a leased line to ISP, and
> then through a PPTP VPN to Internet.  ISP runs several VPN gateway
> servers, all are replying to a common host name -- let's call it
> vpn.corbina.net but with different IP addresses -- 195.14.38.x.
> 
> Up until recently there were fewer than 20 servers in the VPN pool,
> but a few days ago ISP has added several new servers to cope with the
> load, pushing the total number of them to 23.  From that moment
> uClib's gethostbyname stopped resolving names to IP addresses and
> returns an unkown resolver error:
> 
> $ ping vpn.corbina.net
> ping: vpn.corbina.net: Resolver error
> 
> $ nslookup vpn.corbina.net
> Server:         localhost
> Address:        127.0.0.1
> 
> nslookup: vpn.corbina.net: Resolver error
> 
> It would seem that because of a large number of entries returned by
> the DNS server, gethostbyname fails to provide an name to IP mapping.
> Are there any known work-arounds to this?
> 
> 
> Thanks & please keep me on cc, as I am not subscribed to the mailing list.
> 
> Andrei
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
> 
> 

From Kim.Heino at bluegiga.com  Fri Feb 23 05:28:22 2007
From: Kim.Heino at bluegiga.com (Kim B. Heino)
Date: Fri, 23 Feb 2007 15:28:22 +0200
Subject: dpkg - updating a package can break dependencies
Message-ID: <45DEEBF6.8030907@bluegiga.com>

Hello,

When installing a new package with dpkg dependencies are checked 
correctly. But when I try to update an existing package, the 
dependencies are checked against the old package, not against new 
package. Thus the new package can break dependencies.

Attached patch fixes this problem. It should apply cleanly to todays 
snapshot.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dpkg-collision.patch
Type: text/x-patch
Size: 507 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070223/af07ba1c/attachment.bin 

From dick at streefland.net  Fri Feb 23 14:31:33 2007
From: dick at streefland.net (Dick Streefland)
Date: Fri, 23 Feb 2007 23:31:33 +0100
Subject: memory leak in awk applet
Message-ID: <20070223223133.GB6022@streefland.xs4all.nl>

I noticed that awk leaks memory when you read the $<N> variables
repeatably. You can easily reproduce this with the following script:

BEGIN{
	for (;;)
	{
		"echo foo" | getline;
		foo = $1;
	}
}

The problem is that the same string is allocated by bb_xstrdup() over
and over again. The following patch stops the leak, but I'm not
completely sure if it is the right fix:

diff -pu busybox-1.4.1/editors/awk.c.orig busybox-1.4.1/editors/awk.c
--- busybox-1.4.1/editors/awk.c.orig	2007-01-24 22:34:50.000000000 +0100
+++ busybox-1.4.1/editors/awk.c	2007-02-23 23:28:36.000000000 +0100
@@ -740,7 +740,7 @@ static var *copyvar(var *dest, const var
 {
 	if (dest != src) {
 		clrvar(dest);
-		dest->type |= (src->type & ~VF_DONTTOUCH);
+		dest->type |= (src->type & ~(VF_DONTTOUCH|VF_FSTR));
 		dest->number = src->number;
 		if (src->string)
 			dest->string = xstrdup(src->string);

-- 
Dick

From dick at streefland.net  Fri Feb 23 15:00:31 2007
From: dick at streefland.net (Dick Streefland)
Date: Sat, 24 Feb 2007 00:00:31 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <20070223230031.GA23727@streefland.xs4all.nl>

On Friday 2007-02-02 23:14, Brion Finlay wrote:
| Alternatively, since awk is being invoked anyway, this line could be changed
| to just a single line awk invocation to do away with the sed, the grep, and
| the echo:
| 
| awk '/^#? ?CONFIG_/ {gsub(/\"/,"\\\\\"",$0); print "\"" $0 "\\n\"";}'
| $config
| 
| I tested this change under bash and dash and it also works in both shells.

I just ran into this dash/bash problem and (before I found this
discussion) worked around it by replacing the whole line by a single
sed invocation:

sed '/^#\? \?CONFIG/!d; s/"/\\"/g; s/.*/"&\\n"/' $config

-- 
Dick

From Alexander at Kriegisch.name  Sat Feb 24 03:33:59 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 12:33:59 +0100
Subject: Replacing CR (\r) character with sed
Message-ID: <45E022A7.4010002@Kriegisch.name>

I wonder how I can make sed work as a replacement for dos2unix. I do
know how to strip CR characters with tr or dos2unix, but I have reasons
to do it with sed besides just wanting to know how. Those reasons include
  - a bug in some tr versions making it strip special characters like
    German umlauts unintentionally (I have no influence on the version
    of tr used by other people) and
  - dos2unix not being part of our DSL router firmware mod's busybox
    (again, I have it, but many others don't).

I played around with several variants working in other sed versions,
tried to use basic regex mode as well as the -r switch for extended
regex syntax, but to no avail. BTW, I have not tried to put the sed
script into a file, as I want to use it as a command line argument.

Hints are most welcome.
Regards
-- 
Alexander Kriegisch

From vda.linux at googlemail.com  Sat Feb 24 04:31:34 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 13:31:34 +0100
Subject: ash test suite
In-Reply-To: <f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>
References: <45B719C7.8010503@bfs.de> <45BF6F79.4020601@bfs.de>
	<f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>
Message-ID: <200702241331.34553.vda.linux@googlemail.com>

Guys,

On Thursday 01 February 2007 14:23, Yuwen Dai wrote:
> On 1/31/07, walter harms <wharms at bfs.de> wrote:
> >
> > your are right,
> > note:  have removed the original diff for a 'diff -y | less' to see more
> > clearly the differences.
> > take also a look at the readme inside the ash* tests.
> 
> 
> I see ash-* directories as well as test files in the same directory. While
> in Bash testsuite, all test files are in same level, no subdirectories.  Did
> you intend to put all all the test files into subdirectories?

Can you send me the testsuite?

If it is not polished, send it as-is anyway.
--
vda

From vda.linux at googlemail.com  Sat Feb 24 04:57:55 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 13:57:55 +0100
Subject: Replacing CR (\r) character with sed
In-Reply-To: <45E022A7.4010002@Kriegisch.name>
References: <45E022A7.4010002@Kriegisch.name>
Message-ID: <200702241357.55093.vda.linux@googlemail.com>

On Saturday 24 February 2007 12:33, Alexander Kriegisch wrote:
> I wonder how I can make sed work as a replacement for dos2unix. I do
> know how to strip CR characters with tr or dos2unix, but I have reasons
> to do it with sed besides just wanting to know how. Those reasons include
>   - a bug in some tr versions making it strip special characters like
>     German umlauts unintentionally (I have no influence on the version
>     of tr used by other people) and
>   - dos2unix not being part of our DSL router firmware mod's busybox
>     (again, I have it, but many others don't).
> 
> I played around with several variants working in other sed versions,
> tried to use basic regex mode as well as the -r switch for extended
> regex syntax, but to no avail. BTW, I have not tried to put the sed
> script into a file, as I want to use it as a command line argument.

bash-3.2# echo -ne 'dos\r\ntext\r\n' | hexdump -C
00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
0000000b

bash-3.2# echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
00000009

--
vda

From Alexander at Kriegisch.name  Sat Feb 24 05:14:12 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 14:14:12 +0100
Subject: Replacing CR (\r) character with sed
In-Reply-To: <200702241357.55093.vda.linux@googlemail.com>
References: <45E022A7.4010002@Kriegisch.name>
	<200702241357.55093.vda.linux@googlemail.com>
Message-ID: <45E03A24.6010209@Kriegisch.name>

Sorry, Denis,

I want to do this with busybox (ash, not bash). I know it works in a
bash, but when I try this in my busybox, I get the following:

$ uname -a
Linux fritz.box 2.6.13.1-ohio #1 Sun Feb 18 14:18:07 CET 2007 mips unknown
$ echo -ne 'dos\r\ntext\r\n' | hexdump -C
00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
0000000b
$ echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
0000000b

--
Alexander Kriegisch

> On Saturday 24 February 2007 12:33, Alexander Kriegisch wrote:
>> I wonder how I can make sed work as a replacement for dos2unix. I do
>> know how to strip CR characters with tr or dos2unix, but I have reasons
>> to do it with sed besides just wanting to know how. Those reasons include
>>   - a bug in some tr versions making it strip special characters like
>>     German umlauts unintentionally (I have no influence on the version
>>     of tr used by other people) and
>>   - dos2unix not being part of our DSL router firmware mod's busybox
>>     (again, I have it, but many others don't).
>>
>> I played around with several variants working in other sed versions,
>> tried to use basic regex mode as well as the -r switch for extended
>> regex syntax, but to no avail. BTW, I have not tried to put the sed
>> script into a file, as I want to use it as a command line argument.
> 
> bash-3.2# echo -ne 'dos\r\ntext\r\n' | hexdump -C
> 00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
> 0000000b
> 
> bash-3.2# echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
> 00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
> 00000009
> 
> --
> vda
> 

From strange at nsk.no-ip.org  Sat Feb 24 05:26:16 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Sat, 24 Feb 2007 13:26:16 +0000
Subject: Replacing CR (\r) character with sed
In-Reply-To: <45E03A24.6010209@Kriegisch.name>
References: <45E022A7.4010002@Kriegisch.name>
	<200702241357.55093.vda.linux@googlemail.com>
	<45E03A24.6010209@Kriegisch.name>
Message-ID: <20070224132616.GA12329@nsk.no-ip.org>

On Sat, Feb 24, 2007 at 02:14:12PM +0100, Alexander Kriegisch wrote:
> Sorry, Denis,
> 
> I want to do this with busybox (ash, not bash). I know it works in a
> bash, but when I try this in my busybox, I get the following:
> 
> $ uname -a
> Linux fritz.box 2.6.13.1-ohio #1 Sun Feb 18 14:18:07 CET 2007 mips unknown
> $ echo -ne 'dos\r\ntext\r\n' | hexdump -C
> 00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
> 0000000b
> $ echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
> 00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
> 0000000b

$ echo -ne 'dos\r\ntext\r\n' |  sed "s/`echo -ne '\r'`//g" | hexdump -C
00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
00000009

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070224/a62e5416/attachment.pgp 

From Alexander at Kriegisch.name  Sat Feb 24 05:48:58 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 14:48:58 +0100
Subject: Replacing CR (\r) character with sed
In-Reply-To: <20070224132616.GA12329@nsk.no-ip.org>
References: <45E022A7.4010002@Kriegisch.name>
	<200702241357.55093.vda.linux@googlemail.com>
	<45E03A24.6010209@Kriegisch.name>
	<20070224132616.GA12329@nsk.no-ip.org>
Message-ID: <45E0424A.3080704@Kriegisch.name>

> $ echo -ne 'dos\r\ntext\r\n' |  sed "s/`echo -ne '\r'`//g" | hexdump -C
> 00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
> 00000009

Bingo! Thanks. :)
--
Alexander Kriegisch

From vda.linux at googlemail.com  Sat Feb 24 07:01:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:11 +0100
Subject: [PATCH 5/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>
References: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>
Message-ID: <200702241601.11806.vda.linux@googlemail.com>

On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
> [5/8]  busybox-coreutils-05-ls.v3.patch
>  - -Z option support for ls. Security context of file is shown by -Z option.
>    In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.
> 
> Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>

+       USE_FEATURE_AUTOWIDTH("T:w:")
+    USE_SELINUX("Z");

Use tab here instead of four spaces.
--
vda

From vda.linux at googlemail.com  Sat Feb 24 07:01:06 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:06 +0100
Subject: [PATCH 0/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174733.e67e5fc6.ynakam@hitachisoft.jp>
References: <20070223174733.e67e5fc6.ynakam@hitachisoft.jp>
Message-ID: <200702241601.06224.vda.linux@googlemail.com>

On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> Hi.
> 
> The following patches provide SELinux options(like -Z) and applets to coreutils.
> To maintain SELinux system, some commands must be extended to be able to handle 
> attribute in SELinux(such as security context).
> 
> Current patch is version 3. 
> We submitted previous patches some weeks ago, and some reviews were done.
> chcon and runcon applets are added, since last patch.
> I think that's all for coreutils.

Thanks for persistent effort. Review follows.
--
vda

From vda.linux at googlemail.com  Sat Feb 24 07:01:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:13 +0100
Subject: [PATCH 8/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174929.18e547ea.ynakam@hitachisoft.jp>
References: <20070223174929.18e547ea.ynakam@hitachisoft.jp>
Message-ID: <200702241601.13536.vda.linux@googlemail.com>

On Friday 23 February 2007 09:49, Yuichi Nakamura wrote:
> [8/8] busybox-coreutils-08-runcon.v3.patch
>  - runcon - run application with specified security context.
>   runcon provides one of the core facilities to run application with explicitly
>   specified security context. It enables users to run their application under
>   the least privilege set explicitly.
> 
> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>

+       char *role = NULL;
+       char *range = NULL;
+       char *user = NULL;
+       char *type = NULL;
+       char *context = NULL;
+       unsigned int opts;
+
+       selinux_or_die();
+
+       opts = getopt32(argc, argv, "r:t:u:l:ch", &role, &type, &user, &range);
+
+       if (!role && !type && !user && !range) {
+               if (optind >= argc)
+                       bb_error_msg_and_die("must specify -c, -t, -u, -l, -r, or context");
+               context = argv[optind++];
+       }

Testing if(!(opt & MASK_role_type_user_range)) will result in smaller code.
--
vda

From vda.linux at googlemail.com  Sat Feb 24 07:01:12 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:12 +0100
Subject: [PATCH 7/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>
References: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>
Message-ID: <200702241601.12758.vda.linux@googlemail.com>

On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
> [7/8] busybox-coreutils-07-chcon.v3.patch
>  - chcon - change security context of file. 
> 
> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>

+#define OPT_QUIET              (1<<3)  /* 'f' */
+#define OPT_REFERENCE          (1<<4)  /* '\n' */
+#define OPT_USER               (1<<5)  /* 'u' */

...


+       {"quiet",       0,      NULL,   'f'},
+       {"reference",   1,      NULL,   '\n' }, /* no short option */
+       {"user",        1,      NULL,   'u' },
+       {"role",        1,      NULL,   'r' },
+       {"type",        1,      NULL,   't' },
+       {"range",       1,      NULL,   'l' },
+       {"verbose",     0,      NULL,   'v' },
+       {NULL,          0,      NULL,   0 },
+};
+#endif
+
+int chcon_main(int argc, char *argv[]);
+int chcon_main(int argc, char *argv[])
+{
+       char *reference_file;
+       char **target_files;
+       int i, opts, errors = 0;
+
+#ifdef CONFIG_FEATURE_CHCON_LONG_OPTIONS
+       applet_long_options = chcon_options;
+#endif
+       opt_complementary = "-1"  /* at least 1 param */
+               ":q--v:v--q";     /* 'verbose' and 'quiet' are exclusive */
+       opts = getopt32(argc, argv, "Rchf\n:u:r:t:l:v",
+                       &reference_file, &user, &role, &type, &range);
+       if (opts & OPT_REFERENCE) {
+               if (opts & OPT_COMPONENT_SPECIFIED)
+                       bb_error_msg_and_die("conflicting security context specifiers given");


Again see wget.c how to not pass '\n' to getopt32.

You can make OPT_REFERENCE and OPT_COMPONENT_SPECIFIED
exclusive by using suitable opt_complementary.
--
vda

From vda.linux at googlemail.com  Sat Feb 24 07:01:14 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:14 +0100
Subject: [PATCH 2/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174747.4ced9178.ynakam@hitachisoft.jp>
References: <20070223174747.4ced9178.ynakam@hitachisoft.jp>
Message-ID: <200702241601.14214.vda.linux@googlemail.com>

On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> [2/8] busybox-coreutils-02-copy.v3.patch
>   - cp: -Z,-c option support. 
>       -c option: security context is preserved during file copy.
>   - mv 
>     In SELinux, it is recommended to preserve security context 
>     when file is moved. By this patch, file context is preserved 
>     during file move.
>   - install
>     When file is copied by install, security context of installed file 
>     becomes different from value configured in file_contexts file.
>     By this patch, security context is set according to file_contexts file.
>     -Z option: security context can be set during file copy.
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>

        FILEUTILS_MAKE_SOFTLINK = 0x40,
+#if ENABLE_SELINUX
+       FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
+       FILEUTILS_SET_SECURITY_CONTEXT = 0x100
+#endif
 };
-#define FILEUTILS_CP_OPTSTR "pdRfils"

+#define FILEUTILS_CP_OPTSTR "pdRfils" USE_SELINUX("c\b")
+
 extern const char *applet_name;
...
        { "owner",               0, NULL, 'o' },
+#if ENABLE_SELINUX
+       { "context",             1, NULL, 'Z' },
+       { "preserve_context",    0, NULL, '\b'},
+       { "preserve-context",    0, NULL, '\b'},
+
+#endif
        { 0, 0, 0, 0 }

Hmmm... we typically use high ascii values for this kind
of "fake" option chars. Example in wget.c:

        static const struct option wget_long_options[] = {
...
                { "user-agent",       required_argument, NULL, 'U' },
                { "passive-ftp",      no_argument, NULL, 0xff },
                { "header",           required_argument, NULL, 0xfe },
                { 0, 0, 0, 0 }
        };
        applet_long_options = wget_long_options;
#endif
        opt_complementary = "-1" USE_FEATURE_WGET_LONG_OPTIONS(":\xfe::");
        opt = getopt32(argc, argv, "cqO:P:Y:U:",   ...);

Notice that in this example we avoid giving "strange" chars to getopt32
*at all*, preventing our applets from having "hidden" options a-la
"wget $'-\xff' ftp://kernel.org/".

Can you avoid passing '\b' to getopt32 in install etc?


+                       bb_error_msg("warning: ignoring --preserve-context. "
+                                        "The kernel is not SELinux-enabled.\n" );

bb_error_msg don't need trailing '\n'.
I already mentioned that in the previous round of review.


+#if ENABLE_SELINUX
+       if ((flags & FILEUTILS_PRESERVE_SECURITY_CONTEXT) && is_selinux_enabled() > 0){
+               security_context_t con;
+               if (lgetfilecon (source, &con) >= 0){
+                       if (setfscreatecon(con) < 0) {
+                               bb_perror_msg ("cannot set setfscreatecon %s", con);
+                               freecon(con);
+                               return -1;
+                       }
+               }else{
+                       if( errno == ENOTSUP || errno == ENODATA ) {
+                               setfscreatecon(NULL);
+                       } else {
+                               bb_perror_msg ("cannot  lgetfilecon %s", source);
+                               return -1;
+                       }
+               }
+       }
+#endif

Usage of whitespace is very different from the rest of busybox code here.

--
vda

From vda.linux at googlemail.com  Sat Feb 24 07:01:14 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:14 +0100
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174739.300d673a.ynakam@hitachisoft.jp>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
Message-ID: <200702241601.14808.vda.linux@googlemail.com>

On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> [1/8] busybox-coreutils-common-01.v3.patch
>  - common component for SELinux options, applets
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>

        "       -i      Interactive, prompt before overwrite\n" \
        "       -R,-r   Copy directories recursively\n" \
-       "       -l,-s   Create (sym)links"
+       "       -l,-s   Create (sym)links\n"

 #define cpio_trivial_usage \

Why?


 USE_RPM2CPIO(APPLET(rpm2cpio, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_RUNCON(APPLET(runcon, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
 USE_RUN_PARTS(APPLET_ODDNAME(run-parts, run_parts, _BB_DIR_BIN, _BB_SUID_NEVER, run_parts))
 USE_RUNLEVEL(APPLET(runlevel, _BB_DIR_SBIN, _BB_SUID_NEVER))

*Must* be in ASCII order.


--
vda

From vda.linux at googlemail.com  Sat Feb 24 09:03:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 18:03:37 +0100
Subject: memory leak in awk applet
In-Reply-To: <20070223223133.GB6022@streefland.xs4all.nl>
References: <20070223223133.GB6022@streefland.xs4all.nl>
Message-ID: <200702241803.37090.vda.linux@googlemail.com>

On Friday 23 February 2007 23:31, Dick Streefland wrote:
> I noticed that awk leaks memory when you read the $<N> variables
> repeatably. You can easily reproduce this with the following script:
> 
> BEGIN{
> 	for (;;)
> 	{
> 		"echo foo" | getline;
> 		foo = $1;
> 	}
> }
> 
> The problem is that the same string is allocated by bb_xstrdup() over
> and over again. The following patch stops the leak, but I'm not
> completely sure if it is the right fix:
> 
> diff -pu busybox-1.4.1/editors/awk.c.orig busybox-1.4.1/editors/awk.c
> --- busybox-1.4.1/editors/awk.c.orig	2007-01-24 22:34:50.000000000 +0100
> +++ busybox-1.4.1/editors/awk.c	2007-02-23 23:28:36.000000000 +0100
> @@ -740,7 +740,7 @@ static var *copyvar(var *dest, const var
>  {
>  	if (dest != src) {
>  		clrvar(dest);
> -		dest->type |= (src->type & ~VF_DONTTOUCH);
> +		dest->type |= (src->type & ~(VF_DONTTOUCH|VF_FSTR));
>  		dest->number = src->number;
>  		if (src->string)
>  			dest->string = xstrdup(src->string);

Looks ok to me. Applied, thanks!
--
vda

From Alexander at Kriegisch.name  Sat Feb 24 12:10:04 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 21:10:04 +0100
Subject: tar -t segmentation fault
Message-ID: <45E09B9C.8080302@Kriegisch.name>

I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
when listing tar archives, no matter whether they are uncompressed or
compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
problems, though.

Could ba a bug. Please acknowledge or ask me for more information. I
think it ought to be easily reproducible.

Regards
-- 
Alexander Kriegisch

From natanael.copa at gmail.com  Sat Feb 24 16:43:02 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 01:43:02 +0100
Subject: tar -t segmentation fault
In-Reply-To: <45E09B9C.8080302@Kriegisch.name>
References: <45E09B9C.8080302@Kriegisch.name>
Message-ID: <20070225014302.a30264ab.natanael.copa@gmail.com>

On Sat, 24 Feb 2007 21:10:04 +0100
Alexander Kriegisch <Alexander at Kriegisch.name> wrote:

> I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> when listing tar archives, no matter whether they are uncompressed or
> compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> problems, though.
> 
> Could ba a bug. Please acknowledge or ask me for more information. I
> think it ought to be easily reproducible.

I can confirm this on x86/uclibc. I have tested with and wihtout the
patches for 1.4.1.

gdb output:

This GDB was configured as "i386-gentoo-linux-uclibc"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set args tar -ztf /var/cache/distfiles/dnrd-2.20.1.tar.gz
(gdb) run
Starting program: /busybox/busybox-1.4.1/busybox_unstripped tar -ztf /var/cache/distfiles/dnrd-2.20.1.tar.gz
warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4

Program received signal SIGSEGV, Segmentation fault.
tar_main (argc=3, argv=0xffd77798) at archival/tar.c:835
835                             llist_t *temp = excludes->link;
(gdb) bt
#0  tar_main (argc=3, argv=0xffd77798) at archival/tar.c:835
#1  0x08048342 in run_applet_by_name (name=0xffd77b74 "tar", argc=3, 
    argv=0xffd77798) at applets/applets.c:489
#2  0x08048491 in busybox_main (argc=4, argv=0xffd77794)
    at applets/busybox.c:143
#3  0x080482fb in run_applet_by_name (name=0xffd77b61 "busybox_unstripped", 
    argc=4, argv=0xffd77794) at applets/applets.c:480
#4  0x080483bd in main (argc=-2656364, argv=0xffd77794) at applets/busybox.c:72
(gdb) 

config:
al-1.5 busybox-1.4.1 # sed 's/\#.*//; /^$/d' .config
CONFIG_HAVE_DOT_CONFIG=y
CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe"
CONFIG_STATIC=y
CONFIG_DEBUG=y
CONFIG_DEBUG_PESSIMIZE=y
CONFIG_NO_DEBUG_LIB=y
CONFIG_INSTALL_APPLET_SYMLINKS=y
CONFIG_PREFIX="./_install"
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SIZE_VS_SPEED=2
CONFIG_BUNZIP2=y
CONFIG_GUNZIP=y
CONFIG_GZIP=y
CONFIG_TAR=y
CONFIG_FEATURE_TAR_CREATE=y
CONFIG_FEATURE_TAR_BZIP2=y
CONFIG_FEATURE_TAR_LZMA=y
CONFIG_FEATURE_TAR_FROM=y
CONFIG_FEATURE_TAR_GZIP=y
CONFIG_FEATURE_TAR_COMPRESS=y
CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y
CONFIG_FEATURE_LESS_MAXLINES=
CONFIG_FEATURE_SH_IS_NONE=y
CONFIG_FEATURE_COMMAND_HISTORY=
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=

From vda.linux at googlemail.com  Sat Feb 24 16:44:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 01:44:03 +0100
Subject: tar -t segmentation fault
In-Reply-To: <45E09B9C.8080302@Kriegisch.name>
References: <45E09B9C.8080302@Kriegisch.name>
Message-ID: <200702250144.03251.vda.linux@googlemail.com>

On Saturday 24 February 2007 21:10, Alexander Kriegisch wrote:
> I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> when listing tar archives, no matter whether they are uncompressed or
> compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> problems, though.
> 
> Could ba a bug. Please acknowledge or ask me for more information. I
> think it ought to be easily reproducible.

I think it's http://bugs.busybox.net/view.php?id=1183
--
vda

From natanael.copa at gmail.com  Sat Feb 24 16:51:08 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 01:51:08 +0100
Subject: ash test suite
In-Reply-To: <200702241331.34553.vda.linux@googlemail.com>
References: <45B719C7.8010503@bfs.de> <45BF6F79.4020601@bfs.de>
	<f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>
	<200702241331.34553.vda.linux@googlemail.com>
Message-ID: <20070225015108.0d679f85.natanael.copa@gmail.com>

On Sat, 24 Feb 2007 13:31:34 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> Guys,
> 
> On Thursday 01 February 2007 14:23, Yuwen Dai wrote:
> > On 1/31/07, walter harms <wharms at bfs.de> wrote:
> > >
> > > your are right,
> > > note:  have removed the original diff for a 'diff -y | less' to see more
> > > clearly the differences.
> > > take also a look at the readme inside the ash* tests.
> > 
> > 
> > I see ash-* directories as well as test files in the same directory. While
> > in Bash testsuite, all test files are in same level, no subdirectories.  Did
> > you intend to put all all the test files into subdirectories?
> 
> Can you send me the testsuite?
> 
> If it is not polished, send it as-is anyway.

yes. would be nice to have it in svn. I know some things to test that i
know will fail. For example:

function foo() {
}

[ "yes" || "" ] && echo hello

[[ "yes" && "yes" ]] && echo hello

I dont care so much about "function", but I could probalby reduce
my bash->ash patches with 50% if test could do [ ... && ... ]

(im patching bash scripts to make them run on busybox ash)

There are some issues with arrays too but I expect that to be
non-trivial to fix in bb ash.


From vda.linux at googlemail.com  Sat Feb 24 16:52:16 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 01:52:16 +0100
Subject: tar -t segmentation fault
In-Reply-To: <20070225014302.a30264ab.natanael.copa@gmail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<20070225014302.a30264ab.natanael.copa@gmail.com>
Message-ID: <200702250152.16360.vda.linux@googlemail.com>

On Sunday 25 February 2007 01:43, Natanael Copa wrote:
> On Sat, 24 Feb 2007 21:10:04 +0100
> Alexander Kriegisch <Alexander at Kriegisch.name> wrote:
> 
> > I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> > when listing tar archives, no matter whether they are uncompressed or
> > compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> > problems, though.
> > 
> > Could ba a bug. Please acknowledge or ask me for more information. I
> > think it ought to be easily reproducible.
> 
> I can confirm this on x86/uclibc. I have tested with and wihtout the
> patches for 1.4.1.

http://bugs.busybox.net/view.php?id=1183 - fixed.

Does svn work for you?
--
vda

From vda.linux at googlemail.com  Sat Feb 24 16:54:22 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 01:54:22 +0100
Subject: ash test suite
In-Reply-To: <20070225015108.0d679f85.natanael.copa@gmail.com>
References: <45B719C7.8010503@bfs.de>
	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
Message-ID: <200702250154.22207.vda.linux@googlemail.com>

On Sunday 25 February 2007 01:51, Natanael Copa wrote:
> On Sat, 24 Feb 2007 13:31:34 +0100
> Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > Can you send me the testsuite?
> > 
> > If it is not polished, send it as-is anyway.
> 
> yes. would be nice to have it in svn. I know some things to test that i
> know will fail. For example:
> 
> function foo() {
> }
> 
> [ "yes" || "" ] && echo hello
> 
> [[ "yes" && "yes" ]] && echo hello
> 
> I dont care so much about "function", but I could probalby reduce
> my bash->ash patches with 50% if test could do [ ... && ... ]

bash-3.2# [ "yes" || "" ] && echo hello
bash: [: missing `]'
bash: : command not found

I suspect a bug in the example.
--
vda

From natanael.copa at gmail.com  Sat Feb 24 17:06:10 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 02:06:10 +0100
Subject: eject and umount /dev/cdrom fails on busybox-1.4.1
Message-ID: <20070225020610.e7aaeeaa.natanael.copa@gmail.com>

I noticed that "eject" fails on busybox-1.4.1. Looks like it fails on
umount. 

~ $ mount /dev/cdrom
~ $ umount /dev/cdrom
umount: cannot umount /dev/cdrom: Invalid argument
~ $ mount
rootfs on / type rootfs (rw)
/dev/none on / type tmpfs (rw)
proc on /proc type proc (rw)
none on /sys type sysfs (rw)
mdev on /dev type tmpfs (rw)
none on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/md1 on /var type ext3 (rw,data=ordered)
/dev/cdrom on /media/cdrom type iso9660 (ro)

umount /media/cdrom works.

Funny enough, unmouting /dev/loop0 works:

~ $ mount -o loop /media/cdrom/modules.cmg /lib/modules/
mount: /dev/loop0 is write-protected, mounting read-only
mount: /dev/loop0 is write-protected, mounting read-only
mount: /dev/loop0 is write-protected, mounting read-only
mount: /dev/loop0 is write-protected, mounting read-only
~ $ mount
rootfs on / type rootfs (rw)
/dev/none on / type tmpfs (rw)
proc on /proc type proc (rw)
none on /sys type sysfs (rw)
mdev on /dev type tmpfs (rw)
none on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/md1 on /var type ext3 (rw,data=ordered)
/dev/cdrom on /media/cdrom type iso9660 (ro)
/dev/loop0 on /lib/modules type cramfs (ro)
~ $ umount /dev/loop0
~ $

/dev/cdrom is a symbolic link to /dev/hda

here is the strace output (gdb dont work on that pax'ed kernel, sorry):

open("/proc/mounts", O_RDONLY)          = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x59d0ffd0) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "rootfs / rootfs rw 0 0\n/dev/none"..., 4096) = 251
read(4, "", 4096)                       = 0
close(4)                                = 0
readlink("/dev", 0x59d0e0ec, 4095)      = -1 EINVAL (Invalid argument)
readlink("/dev/cdrom", "hda", 4095)     = 3
readlink("/dev/hda", 0x59d0e0ec, 4095)  = -1 EINVAL (Invalid argument)
oldumount("/dev/cdrom")                 = -1 EINVAL (Invalid argument)
write(2, "umount", 6umount)                   = 6
write(2, ": ", 2: )                       = 2
write(2, "cannot umount ", 14cannot umount )          = 14
write(2, "/dev/cdrom", 10/dev/cdrom)              = 10
write(2, ": ", 2: )                       = 2
write(2, "Invalid argument", 16Invalid argument)        = 16
write(2, "\n", 1
)                       = 1
_exit(1)                                = ?
Process 30996 detached

From psmith at netezza.com  Sat Feb 24 18:31:05 2007
From: psmith at netezza.com (Paul Smith)
Date: Sat, 24 Feb 2007 21:31:05 -0500
Subject: ash test suite
In-Reply-To: <200702250154.22207.vda.linux@googlemail.com>
References: <45B719C7.8010503@bfs.de>
	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
	<200702250154.22207.vda.linux@googlemail.com>
Message-ID: <1172370665.16437.19.camel@homebase>

On Sun, 2007-02-25 at 01:54 +0100, Denis Vlasenko wrote:

> bash-3.2# [ "yes" || "" ] && echo hello
> bash: [: missing `]'
> bash: : command not found
> 
> I suspect a bug in the example.

Correct; this is not valid shell syntax.  Perhaps they mean:

  [ "yes" -o "" ] && echo hello

You can't use a shell "or" operator (||) inside a test invocation; the
|| will end the command.

From Alexander at Kriegisch.name  Sat Feb 24 22:01:58 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 25 Feb 2007 07:01:58 +0100
Subject: tar -t segmentation fault
In-Reply-To: <200702250152.16360.vda.linux@googlemail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<20070225014302.a30264ab.natanael.copa@gmail.com>
	<200702250152.16360.vda.linux@googlemail.com>
Message-ID: <45E12656.9060103@Kriegisch.name>

> http://bugs.busybox.net/view.php?id=1183 - fixed.
> 
> Does svn work for you?

I applied
http://www.busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/archival/tar.c?rev=17772&r1=17740&r2=17772&makepatch=1&diff_format=u

It works, thank you.
--
Alexander Kriegisch

From natanael.copa at gmail.com  Sun Feb 25 05:42:51 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 14:42:51 +0100
Subject: ash test suite
In-Reply-To: <200702250154.22207.vda.linux@googlemail.com>
References: <45B719C7.8010503@bfs.de>
	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
	<200702250154.22207.vda.linux@googlemail.com>
Message-ID: <20070225144251.80d33097.natanael.copa@gmail.com>

On Sun, 25 Feb 2007 01:54:22 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On Sunday 25 February 2007 01:51, Natanael Copa wrote:
> > On Sat, 24 Feb 2007 13:31:34 +0100
> > Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > > Can you send me the testsuite?
> > > 
> > > If it is not polished, send it as-is anyway.
> > 
> > yes. would be nice to have it in svn. I know some things to test that i
> > know will fail. For example:
> > 
> > function foo() {
> > }
> > 
> > [ "yes" || "" ] && echo hello
> > 
> > [[ "yes" && "yes" ]] && echo hello
> > 
> > I dont care so much about "function", but I could probalby reduce
> > my bash->ash patches with 50% if test could do [ ... && ... ]
> 
> bash-3.2# [ "yes" || "" ] && echo hello
> bash: [: missing `]'
> bash: : command not found
> 
> I suspect a bug in the example.

Yes it was a bug. Sorry.

[[ "yes" || "" ]] echo hello

Natanael Copa

From natanael.copa at gmail.com  Sun Feb 25 07:10:15 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 16:10:15 +0100
Subject: tar -t segmentation fault
In-Reply-To: <200702250152.16360.vda.linux@googlemail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<20070225014302.a30264ab.natanael.copa@gmail.com>
	<200702250152.16360.vda.linux@googlemail.com>
Message-ID: <20070225161015.7e1a80a1.natanael.copa@gmail.com>

On Sun, 25 Feb 2007 01:52:16 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On Sunday 25 February 2007 01:43, Natanael Copa wrote:
> > On Sat, 24 Feb 2007 21:10:04 +0100
> > Alexander Kriegisch <Alexander at Kriegisch.name> wrote:
> > 
> > > I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> > > when listing tar archives, no matter whether they are uncompressed or
> > > compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> > > problems, though.
> > > 
> > > Could ba a bug. Please acknowledge or ask me for more information. I
> > > think it ought to be easily reproducible.
> > 
> > I can confirm this on x86/uclibc. I have tested with and wihtout the
> > patches for 1.4.1.
> 
> http://bugs.busybox.net/view.php?id=1183 - fixed.
> 
> Does svn work for you?

Applied same patch as Alexander and it works. Could it be added to the fixes-1.4.1?

thanks

> --
> vda

From natanael.copa at gmail.com  Sun Feb 25 07:17:36 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 16:17:36 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
Message-ID: <20070225161736.d3cd295d.natanael.copa@gmail.com>

The attatched patch adds support for group with the --chuid.

  start-stop-daemon --chuid user:group

Patch is against 1.4.1.

btw... the usage message is wrong:
 
  -U|--chuid <username>|<uid>     Start process with this name

its -c and not -U for --chuid short opt.

thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-ssd-chuid.patch
Type: application/octet-stream
Size: 493 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070225/09956c9f/attachment.obj 

From vda.linux at googlemail.com  Sun Feb 25 12:55:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 21:55:13 +0100
Subject: tar -t segmentation fault
In-Reply-To: <20070225161015.7e1a80a1.natanael.copa@gmail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<200702250152.16360.vda.linux@googlemail.com>
	<20070225161015.7e1a80a1.natanael.copa@gmail.com>
Message-ID: <200702252155.13293.vda.linux@googlemail.com>

On Sunday 25 February 2007 16:10, Natanael Copa wrote:
> > > I can confirm this on x86/uclibc. I have tested with and wihtout the
> > > patches for 1.4.1.
> > 
> > http://bugs.busybox.net/view.php?id=1183 - fixed.
> > 
> > Does svn work for you?
> 
> Applied same patch as Alexander and it works. Could it be added to the fixes-1.4.1?

Added.
--
vda

From vda.linux at googlemail.com  Sun Feb 25 13:50:50 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 22:50:50 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <20070225161736.d3cd295d.natanael.copa@gmail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
Message-ID: <200702252250.50488.vda.linux@googlemail.com>

On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> The attatched patch adds support for group with the --chuid.
> 
>   start-stop-daemon --chuid user:group
> 
> Patch is against 1.4.1.

Thanks. I see that we do something similar in chown.
I want to make this code common.

Please try attached patch which does that.

> btw... the usage message is wrong:
>  
>   -U|--chuid <username>|<uid>     Start process with this name
> 
> its -c and not -U for --chuid short opt.

Corrected, along with description.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 7428 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070225/c467db28/attachment.bin 

From wharms at bfs.de  Mon Feb 26 00:08:58 2007
From: wharms at bfs.de (walter harms)
Date: Mon, 26 Feb 2007 09:08:58 +0100
Subject: ash test suite
In-Reply-To: <20070225015108.0d679f85.natanael.copa@gmail.com>
References: <45B719C7.8010503@bfs.de>
	<45BF6F79.4020601@bfs.de>	<f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
Message-ID: <45E2959A.1080702@bfs.de>




> }
> 
> [ "yes" || "" ] && echo hello
> 
> [[ "yes" && "yes" ]] && echo hello
> 

this exposes an other problem anyway. in ash [ is used just like [[
therefore the [[ specific tests fail. Someone will need the extent test.

re,
 wh

From rogelio.serrano at gmail.com  Mon Feb 26 00:54:09 2007
From: rogelio.serrano at gmail.com (Rogelio Serrano)
Date: Mon, 26 Feb 2007 08:54:09 +0000
Subject: zcip
Message-ID: <a9951d2a0702260054p727a93a4x7f293e8568325545@mail.gmail.com>

how much of rfc 3927 is implemented by busybox zcip?

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items

From natanael.copa at gmail.com  Mon Feb 26 06:06:38 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 26 Feb 2007 15:06:38 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <200702252250.50488.vda.linux@googlemail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
Message-ID: <1172498798.27284.1.camel@localhost>

On Sun, 2007-02-25 at 22:50 +0100, Denis Vlasenko wrote:
> On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> > The attatched patch adds support for group with the --chuid.
> > 
> >   start-stop-daemon --chuid user:group
> > 
> > Patch is against 1.4.1.
> 
> Thanks. I see that we do something similar in chown.
> I want to make this code common.
> 
> Please try attached patch which does that.

Works for me. (I'm using 1.4.1 + patches in production though)

> 
> > btw... the usage message is wrong:
> >  
> >   -U|--chuid <username>|<uid>     Start process with this name
> > 
> > its -c and not -U for --chuid short opt.
> 
> Corrected, along with description.

Thanks!



From tternes at gmail.com  Mon Feb 26 05:51:23 2007
From: tternes at gmail.com (Thaddeus Ternes)
Date: Mon, 26 Feb 2007 07:51:23 -0600
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <200702252250.50488.vda.linux@googlemail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
Message-ID: <ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>

On 2006/7/16, I posted a patch that added chuid support to
start-stop-daemon.  See this thread for the original patch:

http://busybox.net/lists/busybox/2006-July/023212.html

I'm including a modification of that patch to add chgid support as
well.  The syntax is a bit different the previous proposed patch on
this thread, but it may be of interest to some.

I have to note that I haven't tried this against recent builds of
Busybox.  The project I'm working on is locked at 1.2.2.1 right now,
so I patch against that.  This patch will likely not work against
current SVN, but could obviously be coaxed to fit in with a little
love.

Hopefully it's of use to somebody still using older builds.

-Thaddeus

diff -Naur busybox-1.2.2.1.clean/debianutils/start_stop_daemon.c
busybox-1.2.2.1/debianutils/start_stop_daemon.c
--- busybox-1.2.2.1.clean/debianutils/start_stop_daemon.c	2006-06-30
17:42:04.000000000 -0500
+++ busybox-1.2.2.1/debianutils/start_stop_daemon.c	2007-02-06
11:10:38.000000000 -0600
@@ -22,8 +22,11 @@

 static int signal_nr = 15;
 static int user_id = -1;
+static int group_id = -1;
 static int quiet;
 static char *userspec = NULL;
+static char *chuid = NULL;
+static char *chgid = NULL;
 static char *cmdname = NULL;
 static char *execname = NULL;
 static char *pidfile = NULL;
@@ -211,6 +214,8 @@
 	{ "name",			1,		NULL,		'n' },
 	{ "signal",			1,		NULL,		's' },
 	{ "user",			1,		NULL,		'u' },
+	{ "chuid", 			1,		NULL,		'c' },
+	{ "chgid", 			1,		NULL,		'g' },
 	{ "exec",			1,		NULL,		'x' },
 	{ "pidfile",		1,		NULL,		'p' },
 #if ENABLE_FEATURE_START_STOP_DAEMON_FANCY
@@ -249,9 +254,9 @@
 	opt = bb_getopt_ulflags(argc, argv, "KSbqm"
 //		USE_FEATURE_START_STOP_DAEMON_FANCY("ovR:")
 		USE_FEATURE_START_STOP_DAEMON_FANCY("ov")
-		"a:n:s:u:x:p:"
+		"a:n:s:u:c:g:x:p:"
 //		USE_FEATURE_START_STOP_DAEMON_FANCY(,&retry_arg)
-		,&startas, &cmdname, &signame, &userspec, &execname, &pidfile);
+		,&startas, &cmdname, &signame, &userspec, &chuid, &chgid,
&execname, &pidfile);

 	quiet = (opt & SSD_OPT_QUIET)
 			USE_FEATURE_START_STOP_DAEMON_FANCY(&& !(opt & SSD_OPT_VERBOSE));
@@ -301,6 +306,17 @@
 		fprintf(pidf, "%d\n", pidt);
 		fclose(pidf);
 	}
+	if(chgid) {
+		if(sscanf(chgid, "%d", &group_id) != 1)
+			group_id = bb_xgetgrnam(chgid);
+		setgid(group_id);
+	}
+	if(chuid) {
+		if(sscanf(chuid, "%d", &user_id) != 1)
+			user_id = bb_xgetpwnam(chuid);
+		setuid(user_id);
+	}
+
 	execv(startas, argv);
 	bb_perror_msg_and_die ("unable to start %s", startas);
 }
diff -Naur busybox-1.2.2.1.clean/include/usage.h busybox-1.2.2.1/include/usage.h
--- busybox-1.2.2.1.clean/include/usage.h	2006-06-30 17:42:10.000000000 -0500
+++ busybox-1.2.2.1/include/usage.h	2007-02-06 11:10:45.000000000 -0600
@@ -2693,7 +2693,9 @@
 	"\n\t-o|--oknodo\t\t\texit status 0 if nothing done" \
 	"\n\t-v|--verbose\t\t\tbe verbose" \
 ) \
-	"\n\t-s|--signal <signal>\t\tsignal to send (default TERM)"
+	"\n\t-s|--signal <signal>\t\tsignal to send (default TERM)" \
+	"\n\t-g|--chgid <group>|<gid>\tstart process with this group" \
+	"\n\t-c|--chuid <username>|<uid>\tstart process with this name"

 #ifdef CONFIG_FEATURE_STAT_FORMAT
 #  define USAGE_STAT_FORMAT(a) a


On 2/25/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> > The attatched patch adds support for group with the --chuid.
> >
> >   start-stop-daemon --chuid user:group
> >
> > Patch is against 1.4.1.
>
> Thanks. I see that we do something similar in chown.
> I want to make this code common.
>
> Please try attached patch which does that.
>
> > btw... the usage message is wrong:
> >
> >   -U|--chuid <username>|<uid>     Start process with this name
> >
> > its -c and not -U for --chuid short opt.
>
> Corrected, along with description.
> --
> vda
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox_start-stop-daemon_chuid_chgid.patch
Type: application/octet-stream
Size: 2474 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070226/b0f91bc4/attachment.obj 

From ddaney at avtrex.com  Mon Feb 26 09:33:14 2007
From: ddaney at avtrex.com (David Daney)
Date: Mon, 26 Feb 2007 09:33:14 -0800
Subject: zcip
In-Reply-To: <a9951d2a0702260054p727a93a4x7f293e8568325545@mail.gmail.com>
References: <a9951d2a0702260054p727a93a4x7f293e8568325545@mail.gmail.com>
Message-ID: <45E319DA.60802@avtrex.com>

Rogelio Serrano wrote:
> how much of rfc 3927 is implemented by busybox zcip?
> 

As far as I know: All of it.  You will however need to apply a kernel 
patch for full compliance.  Search the list archives for mail from me 
for the patch.

David Daney

From kaigai at kaigai.gr.jp  Mon Feb 26 09:45:46 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Tue, 27 Feb 2007 02:45:46 +0900
Subject: [BUGFIX] matchpathcon didn't abort, if exclusive options were given.
Message-ID: <45E31CCA.8000102@kaigai.gr.jp>

Hi,

This small patch fixes a bug when exclusive options were given
to matchpathcon.
The reason of this problem is lacking of '?' in opt_complementary.

This patch enables to abort, if inconsistent options are given.

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-libselinux-bugfix-matchpathcon.patch
Type: text/x-patch
Size: 547 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/6321e1cb/attachment.bin 

From ynakam at hitachisoft.jp  Sun Feb 25 17:31:14 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Mon, 26 Feb 2007 10:31:14 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.14808.vda.linux@googlemail.com>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
	<200702241601.14808.vda.linux@googlemail.com>
Message-ID: <20070226103114.71efbc26.ynakam@hitachisoft.jp>

Thank you for review!

On Sat, 24 Feb 2007 16:01:14 +0100
Denis Vlasenko wrote:
> On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> > [1/8] busybox-coreutils-common-01.v3.patch
> >  - common component for SELinux options, applets
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> > Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> 
>         "       -i      Interactive, prompt before overwrite\n" \
>         "       -R,-r   Copy directories recursively\n" \
> -       "       -l,-s   Create (sym)links"
> +       "       -l,-s   Create (sym)links\n"
> 
>  #define cpio_trivial_usage \
> 
> Why?
Removed this one.

>  USE_RPM2CPIO(APPLET(rpm2cpio, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
> +USE_RUNCON(APPLET(runcon, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
>  USE_RUN_PARTS(APPLET_ODDNAME(run-parts, run_parts, _BB_DIR_BIN, _BB_SUID_NEVER, run_parts))
>  USE_RUNLEVEL(APPLET(runlevel, _BB_DIR_SBIN, _BB_SUID_NEVER))
> 
> *Must* be in ASCII order.
Fixed.


> 
> 
> --
> vda

Attached is reviesed patch.


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v4.patch
Type: application/octet-stream
Size: 10143 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070226/840b26b6/attachment-0001.obj 

From ynakam at hitachisoft.jp  Sun Feb 25 17:52:49 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Mon, 26 Feb 2007 10:52:49 +0900
Subject: [PATCH 2/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.14214.vda.linux@googlemail.com>
References: <20070223174747.4ced9178.ynakam@hitachisoft.jp>
	<200702241601.14214.vda.linux@googlemail.com>
Message-ID: <20070226105249.98bf6e55.ynakam@hitachisoft.jp>

On Sat, 24 Feb 2007 16:01:14 +0100
Denis Vlasenko  wrote:
> On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> > [2/8] busybox-coreutils-02-copy.v3.patch
> >   - cp: -Z,-c option support. 
> >       -c option: security context is preserved during file copy.
> >   - mv 
> >     In SELinux, it is recommended to preserve security context 
> >     when file is moved. By this patch, file context is preserved 
> >     during file move.
> >   - install
> >     When file is copied by install, security context of installed file 
> >     becomes different from value configured in file_contexts file.
> >     By this patch, security context is set according to file_contexts file.
> >     -Z option: security context can be set during file copy.
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
>         FILEUTILS_MAKE_SOFTLINK = 0x40,
> +#if ENABLE_SELINUX
> +       FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
> +       FILEUTILS_SET_SECURITY_CONTEXT = 0x100
> +#endif
>  };
> -#define FILEUTILS_CP_OPTSTR "pdRfils"
> 
> +#define FILEUTILS_CP_OPTSTR "pdRfils" USE_SELINUX("c\b")
> +
>  extern const char *applet_name;
> ...
>         { "owner",               0, NULL, 'o' },
> +#if ENABLE_SELINUX
> +       { "context",             1, NULL, 'Z' },
> +       { "preserve_context",    0, NULL, '\b'},
> +       { "preserve-context",    0, NULL, '\b'},
> +
> +#endif
>         { 0, 0, 0, 0 }
> 
> Hmmm... we typically use high ascii values for this kind
> of "fake" option chars. Example in wget.c:
> 
>         static const struct option wget_long_options[] = {
> ...
>                 { "user-agent",       required_argument, NULL, 'U' },
>                 { "passive-ftp",      no_argument, NULL, 0xff },
>                 { "header",           required_argument, NULL, 0xfe },
>                 { 0, 0, 0, 0 }
>         };
>         applet_long_options = wget_long_options;
> #endif
>         opt_complementary = "-1" USE_FEATURE_WGET_LONG_OPTIONS(":\xfe::");
>         opt = getopt32(argc, argv, "cqO:P:Y:U:",   ...);
> 
> Notice that in this example we avoid giving "strange" chars to getopt32
> *at all*, preventing our applets from having "hidden" options a-la
> "wget $'-\xff' ftp://kernel.org/".
> 
> Can you avoid passing '\b' to getopt32 in install etc?
Fixed. Using "0xff" instead.


> 
> 
> +                       bb_error_msg("warning: ignoring --preserve-context. "
> +                                        "The kernel is not SELinux-enabled.\n" );
> 
> bb_error_msg don't need trailing '\n'.
> I already mentioned that in the previous round of review.
> 
> 
> +#if ENABLE_SELINUX
> +       if ((flags & FILEUTILS_PRESERVE_SECURITY_CONTEXT) && is_selinux_enabled() > 0){
> +               security_context_t con;
> +               if (lgetfilecon (source, &con) >= 0){
> +                       if (setfscreatecon(con) < 0) {
> +                               bb_perror_msg ("cannot set setfscreatecon %s", con);
> +                               freecon(con);
> +                               return -1;
> +                       }
> +               }else{
> +                       if( errno == ENOTSUP || errno == ENODATA ) {
> +                               setfscreatecon(NULL);
> +                       } else {
> +                               bb_perror_msg ("cannot  lgetfilecon %s", source);
> +                               return -1;
> +                       }
> +               }
> +       }
> +#endif
> 
> Usage of whitespace is very different from the rest of busybox code here.
Fixed. And I found other bad usage of white space, and fixed.

> 
> --
> vda

Attached is revised patch(v4).

--
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.v4.patch
Type: application/octet-stream
Size: 7805 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070226/91d09e74/attachment-0001.obj 

From ynakam at hitachisoft.jp  Sun Feb 25 17:54:09 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Mon, 26 Feb 2007 10:54:09 +0900
Subject: [PATCH 5/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.11806.vda.linux@googlemail.com>
References: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>
	<200702241601.11806.vda.linux@googlemail.com>
Message-ID: <20070226105409.3a228ff6.ynakam@hitachisoft.jp>

On Sat, 24 Feb 2007 16:01:11 +0100
Denis Vlasenko  wrote:
> On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
> > [5/8]  busybox-coreutils-05-ls.v3.patch
> >  - -Z option support for ls. Security context of file is shown by -Z option.
> >    In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.
> > 
> > Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> +       USE_FEATURE_AUTOWIDTH("T:w:")
> +    USE_SELINUX("Z");
> 
> Use tab here instead of four spaces.
Fixed.

> --
> vda

Attached is revised patch(v4).

-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-ls-05.v4.patch
Type: application/octet-stream
Size: 589 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070226/c6186ea1/attachment.obj 

From kaigai at kaigai.gr.jp  Mon Feb 26 09:40:22 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Tue, 27 Feb 2007 02:40:22 +0900
Subject: [PATCH 7/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.12758.vda.linux@googlemail.com>
References: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>
	<200702241601.12758.vda.linux@googlemail.com>
Message-ID: <45E31B86.8080200@kaigai.gr.jp>

Hi, Denis.

Thanks for your reviews.

Denis Vlasenko wrote:
> On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
>> [7/8] busybox-coreutils-07-chcon.v3.patch
>>  - chcon - change security context of file. 
>>
>> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> 
> +#define OPT_QUIET              (1<<3)  /* 'f' */
> +#define OPT_REFERENCE          (1<<4)  /* '\n' */
> +#define OPT_USER               (1<<5)  /* 'u' */
> 
> ...
> 
> 
> +       {"quiet",       0,      NULL,   'f'},
> +       {"reference",   1,      NULL,   '\n' }, /* no short option */
> +       {"user",        1,      NULL,   'u' },
> +       {"role",        1,      NULL,   'r' },
> +       {"type",        1,      NULL,   't' },
> +       {"range",       1,      NULL,   'l' },
> +       {"verbose",     0,      NULL,   'v' },
> +       {NULL,          0,      NULL,   0 },
> +};
> +#endif
> +
> +int chcon_main(int argc, char *argv[]);
> +int chcon_main(int argc, char *argv[])
> +{
> +       char *reference_file;
> +       char **target_files;
> +       int i, opts, errors = 0;
> +
> +#ifdef CONFIG_FEATURE_CHCON_LONG_OPTIONS
> +       applet_long_options = chcon_options;
> +#endif
> +       opt_complementary = "-1"  /* at least 1 param */
> +               ":q--v:v--q";     /* 'verbose' and 'quiet' are exclusive */
> +       opts = getopt32(argc, argv, "Rchf\n:u:r:t:l:v",
> +                       &reference_file, &user, &role, &type, &range);
> +       if (opts & OPT_REFERENCE) {
> +               if (opts & OPT_COMPONENT_SPECIFIED)
> +                       bb_error_msg_and_die("conflicting security context specifiers given");
> 
> 
> Again see wget.c how to not pass '\n' to getopt32.
> 
> You can make OPT_REFERENCE and OPT_COMPONENT_SPECIFIED
> exclusive by using suitable opt_complementary.

OK, fixed.

* '\n' was replaced by '0xff'
* Checks for exclusive options were added. chcon applet will will abort
   if --reference and '-u','-r','-t','-l' are appeared concurrently,

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-chcon-07.v4.patch
Type: text/x-patch
Size: 6357 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/3c22b222/attachment.bin 

From kaigai at kaigai.gr.jp  Mon Feb 26 09:40:38 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Tue, 27 Feb 2007 02:40:38 +0900
Subject: [PATCH 8/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.13536.vda.linux@googlemail.com>
References: <20070223174929.18e547ea.ynakam@hitachisoft.jp>
	<200702241601.13536.vda.linux@googlemail.com>
Message-ID: <45E31B96.3060406@kaigai.gr.jp>

Hi, Denis

Thanks for your reviews.

Denis Vlasenko wrote:
> On Friday 23 February 2007 09:49, Yuichi Nakamura wrote:
>> [8/8] busybox-coreutils-08-runcon.v3.patch
>>  - runcon - run application with specified security context.
>>   runcon provides one of the core facilities to run application with explicitly
>>   specified security context. It enables users to run their application under
>>   the least privilege set explicitly.
>>
>> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> 
> +       char *role = NULL;
> +       char *range = NULL;
> +       char *user = NULL;
> +       char *type = NULL;
> +       char *context = NULL;
> +       unsigned int opts;
> +
> +       selinux_or_die();
> +
> +       opts = getopt32(argc, argv, "r:t:u:l:ch", &role, &type, &user, &range);
> +
> +       if (!role && !type && !user && !range) {
> +               if (optind >= argc)
> +                       bb_error_msg_and_die("must specify -c, -t, -u, -l, -r, or context");
> +               context = argv[optind++];
> +       }
> 
> Testing if(!(opt & MASK_role_type_user_range)) will result in smaller code.

I'm sorry, it was overlooked.
The attached patch replace the above if-conditions by a single logical
operation as you suggested.

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-runcon-08.v4.patch
Type: text/x-patch
Size: 4558 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/c2c09d76/attachment.bin 

From vda.linux at googlemail.com  Mon Feb 26 14:45:31 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 26 Feb 2007 23:45:31 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <1172498798.27284.1.camel@localhost>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
	<1172498798.27284.1.camel@localhost>
Message-ID: <200702262345.31317.vda.linux@googlemail.com>

On Monday 26 February 2007 15:06, Natanael Copa wrote:
> On Sun, 2007-02-25 at 22:50 +0100, Denis Vlasenko wrote:
> > On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> > > The attatched patch adds support for group with the --chuid.
> > > 
> > >   start-stop-daemon --chuid user:group
> > > 
> > > Patch is against 1.4.1.
> > 
> > Thanks. I see that we do something similar in chown.
> > I want to make this code common.
> > 
> > Please try attached patch which does that.
> 
> Works for me. (I'm using 1.4.1 + patches in production though)

Ok, applying then.
--
vda

From vda.linux at googlemail.com  Mon Feb 26 14:45:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 26 Feb 2007 23:45:37 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
	<ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>
Message-ID: <200702262345.37726.vda.linux@googlemail.com>

On Monday 26 February 2007 14:51, Thaddeus Ternes wrote:
> On 2006/7/16, I posted a patch that added chuid support to
> start-stop-daemon.  See this thread for the original patch:
> 
> http://busybox.net/lists/busybox/2006-July/023212.html
> 
> I'm including a modification of that patch to add chgid support as
> well.  The syntax is a bit different the previous proposed patch on
> this thread, but it may be of interest to some.

If there is a "standard" start-stop-daemon (I suppose there is,
but I don't use Debian, so I don't know for sure), it's better
to match it, I think.

With the patch Natanael just tested, bbox ssd supports:

--chuid <user>[:[<group>]]
or
--chuid :<group>

Does this match "standard"? If not, I will gladly take
patches which fix that...
--
vda

From strange at nsk.no-ip.org  Mon Feb 26 15:00:31 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Mon, 26 Feb 2007 23:00:31 +0000
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <200702262345.37726.vda.linux@googlemail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
	<ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>
	<200702262345.37726.vda.linux@googlemail.com>
Message-ID: <20070226230031.GA19584@nsk.no-ip.org>

On Mon, Feb 26, 2007 at 11:45:37PM +0100, Denis Vlasenko wrote:
> On Monday 26 February 2007 14:51, Thaddeus Ternes wrote:
> > On 2006/7/16, I posted a patch that added chuid support to
> > start-stop-daemon.  See this thread for the original patch:
> > 
> > http://busybox.net/lists/busybox/2006-July/023212.html
> > 
> > I'm including a modification of that patch to add chgid support as
> > well.  The syntax is a bit different the previous proposed patch on
> > this thread, but it may be of interest to some.
> 
> If there is a "standard" start-stop-daemon (I suppose there is,
> but I don't use Debian, so I don't know for sure), it's better
> to match it, I think.
> 
> With the patch Natanael just tested, bbox ssd supports:
> 
> --chuid <user>[:[<group>]]
> or
> --chuid :<group>
> 
> Does this match "standard"? If not, I will gladly take
> patches which fix that...
> --

man page:

 -g|--group group|gid
        Change to group or gid when starting the process.

 -c|--chuid username|uid
        Change to this username/uid before starting the process. You can
        also  specify a group by appending a :, then the group or gid in
        the same way as you would for the `chown' command  (user:group).
        When  using  this  option  you must realize that the primary and
        supplemental groups are set as well, even if the --group  option
        is  not  specified.   The --group option is only for groups that
        the user isn't normally a member  of  (like  adding  per/process
        group membership for generic users like nobody).

According to source code, username is mandatory (otherwise getpwnam will
fail and cause the process to terminate).

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070226/368453bd/attachment-0001.pgp 

From ynakam at hitachisoft.jp  Mon Feb 26 15:42:58 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Tue, 27 Feb 2007 08:42:58 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070226103114.71efbc26.ynakam@hitachisoft.jp>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
	<200702241601.14808.vda.linux@googlemail.com>
	<20070226103114.71efbc26.ynakam@hitachisoft.jp>
Message-ID: <20070227084258.93dc26e2.ynakam@hitachisoft.jp>

In previous patch, 
definitions about another SELinux-related applet was included.
I am sorry, and I've removed that one.
Please use attached patch instead of busybox-coreutils-common-01.v4.patch.


On Mon, 26 Feb 2007 10:31:14 +0900
Yuichi Nakamura  wrote:

> Thank you for review!
> 
> On Sat, 24 Feb 2007 16:01:14 +0100
> Denis Vlasenko wrote:
> > On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> > > [1/8] busybox-coreutils-common-01.v3.patch
> > >  - common component for SELinux options, applets
> > > 
> > > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> > > Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> > 
> >         "       -i      Interactive, prompt before overwrite\n" \
> >         "       -R,-r   Copy directories recursively\n" \
> > -       "       -l,-s   Create (sym)links"
> > +       "       -l,-s   Create (sym)links\n"
> > 
> >  #define cpio_trivial_usage \
> > 
> > Why?
> Removed this one.
> 
> >  USE_RPM2CPIO(APPLET(rpm2cpio, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
> > +USE_RUNCON(APPLET(runcon, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
> >  USE_RUN_PARTS(APPLET_ODDNAME(run-parts, run_parts, _BB_DIR_BIN, _BB_SUID_NEVER, run_parts))
> >  USE_RUNLEVEL(APPLET(runlevel, _BB_DIR_SBIN, _BB_SUID_NEVER))
> > 
> > *Must* be in ASCII order.
> Fixed.
> 
> 
> > 
> > 
> > --
> > vda
> 
> Attached is reviesed patch.
> 
> 
> -- 
> Yuichi Nakamura
> Hitachi Software Engineering Co., Ltd.
> SELinux Policy Editor: http://seedit.sourceforge.net/
> 
> 


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v5.patch
Type: application/octet-stream
Size: 8893 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/3ec842c1/attachment.obj 

From marco.braga at gmail.com  Mon Feb 26 15:22:55 2007
From: marco.braga at gmail.com (Marco Braga)
Date: Tue, 27 Feb 2007 00:22:55 +0100
Subject: Multiple configuration scripts
Message-ID: <d459bb380702261522m75db77e6tcf0b7bf4a77a6a39@mail.gmail.com>

Hello,

pardon me if this is a newbie question, but google did not help me.

I am trying to build a busybox based embedded system from scratch. I'd like
to use busybox in initramfs and in the main root fs. The first one should be
a minimal busybox statically linked, while in the main root fs I can put a
more complete one. Now, the question: is there any simple "make trick" to
compile BB using 2 separate config files instead of copying/linking
".config" to 2 separate configs?

Specifically, at the moment I've created 2 different config files, one for
initramfs and one for rootfs. The first one selects static linking, few
applets, and a specific initramfs target directory. The second config
selects a dynamic linked BB with complete apples and a different target dir.

Now, is there any simple and elegant way to edit and compile without having
to copy or link the configs to .config? Anything like, for example, "make
menuconfig initramfs.config"?
A script will work, but I am looking for the "official" way to do this.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070227/dad98912/attachment.htm 

From ynakam at hitachisoft.jp  Mon Feb 26 18:15:12 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Tue, 27 Feb 2007 11:15:12 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <e739902b0702261759wc2fc2fap4e353c87385f5a0b@mail.gmail.com>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
	<200702241601.14808.vda.linux@googlemail.com>
	<20070226103114.71efbc26.ynakam@hitachisoft.jp>
	<20070227084258.93dc26e2.ynakam@hitachisoft.jp>
	<e739902b0702261759wc2fc2fap4e353c87385f5a0b@mail.gmail.com>
Message-ID: <20070227111512.1fa673b7.ynakam@hitachisoft.jp>

Hi.

It seems that it is a bug of init.c.
We have not noticed that, 
please submit that patch independently to busybox.net list.

Regards,
Yuichi Nakamura

On Mon, 26 Feb 2007 17:59:41 -0800
"Ryan Bradetich"  wrote:

> Hello Nakamura-san,
> 
> I have been using your patches against the latest SVN snapshot of
> busybox.  In my testing I get a compiler error in the init/init.c
> file.  I do not believe these patched introduce the error, but was
> curious if your patch set was going to address this error, or if I
> should submit this patch independently of your work.
> 
> I have attached the patch I am using for reference.
> 
> Thanks for your work!
> 
> - Ryan

From rbradetich at gmail.com  Mon Feb 26 18:39:39 2007
From: rbradetich at gmail.com (Ryan Bradetich)
Date: Mon, 26 Feb 2007 18:39:39 -0800
Subject: [PATCH] Fix compile error when init/init.c is compiled with
	ENABLE_SELINUX.
Message-ID: <e739902b0702261839p2d50cac9kf53eccf913efb429@mail.gmail.com>

Hello all,

Here is a trivial patch to fix a compile error in init.c when
ENABLE_SELINUX is defined.

Thanks,

- Ryan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-init.patch
Type: text/x-patch
Size: 556 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070226/eb46689b/attachment.bin 

From terry1 at beam.ltd.uk  Tue Feb 27 01:22:25 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Tue, 27 Feb 2007 09:22:25 +0000
Subject: Modifying init to create /dev/console ?
Message-ID: <45E3F851.4060004@beam.ltd.uk>

Hi,

I am trying to create a basic Linux system based on Busybox and would 
like the ability to create the root file system as a normal user and 
without any /dev entries. The startup script would create the /dev 
entries as needed.
However, init and other programs obviously require /dev/console (and 
other /dev entries).

I was wondering about adding an option to init where it would create a 
tmpfs file system, mount it on /dev and create a /dev/console node if no 
/dev/console was found. I guess it could do a bit more and function as 
udev as well.

Do people with Busybox experience think that this a reasonable thing to 
do ??

Cheers


Terry

From Alexander at Kriegisch.name  Tue Feb 27 07:52:24 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Tue, 27 Feb 2007 16:52:24 +0100
Subject: ls on symlinked directories
Message-ID: <45E453B8.3070807@Kriegisch.name>

This might be a classical question which has been answered here before.
If so, I apologise.

There are a few known bugs in coreutils/ls.c which have been documented,
but not tackled for years. I am speaking of these:

>  * KNOWN BUGS:
>  * 1. ls -l of a directory doesn't give "total <blocks>" header
>  * 2. ls of a symlink to a directory doesn't list directory contents
>  * 3. hidden files can make column width too large

I am especially interested in getting #2 fixed. I don't intend to urge
anybody, I would just like to know if there are reasons for not fixing
this (it is really annoying). Maybe somebody can take the time to look
into this.
-- 
Alexander Kriegisch

From somlo at cmu.edu  Tue Feb 27 09:50:41 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Tue, 27 Feb 2007 12:50:41 -0500
Subject: PATCH: RFC3397 domain search support
Message-ID: <20070227175041.GC13939@hedwig.net.cmu.edu>

Denis,

Enclosed below is a patch that adds RFC3397 support to udhcp. It adds
an 'option search' to the udhcpd.conf file on the server side, and
fills the 'search' environment variable on the client side before
udhcpc.script is called. Both client and server need to comply for
this to be useful (e.g., isc dhcp version 3.1.0 or later), so the
default setting for this in the build script is off.

I tested it with isc 3.1.0 alpha, and it seems to work.

Please let me know what you think. Apply if you like.

Regards,
Gabriel

On Mon, Jan 29, 2007 at 09:06:14PM -0600, Jason Schoon wrote:
> Great idea, but if you need this functionality you should add support to
> udhcp for option 119, specified in RFC3397.  This is the exact problem that
> was solved by that new option.



diff -NarU5 busybox-svn-17929.orig/networking/udhcp/Config.in busybox-svn-17929/networking/udhcp/Config.in
--- busybox-svn-17929.orig/networking/udhcp/Config.in	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/Config.in	2007-02-27 12:03:52.000000000 -0500
@@ -63,5 +63,13 @@
 	  If selected, udhcpd will output extra debugging output.  If using
 	  this option, compile uDHCP with "-g", and do not fork the daemon to
 	  the background.
 
 	  See http://udhcp.busybox.net for further details.
+
+config FEATURE_RFC3397
+	bool "Support for RFC3397 domain search (experimental)"
+	default n
+	depends on APP_UDHCPD || APP_UDHCPC
+	help
+	  If selected, both client and server will support passing of domain
+	  search lists via option 119, specified in RFC3397.
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/Kbuild busybox-svn-17929/networking/udhcp/Kbuild
--- busybox-svn-17929.orig/networking/udhcp/Kbuild	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/Kbuild	2007-02-24 09:41:22.000000000 -0500
@@ -14,5 +14,6 @@
 				   script.o
 lib-$(CONFIG_APP_UDHCPD)	+= dhcpd.o arpping.o files.o leases.o \
 				   serverpacket.o static_leases.o
 lib-$(CONFIG_APP_DUMPLEASES)	+= dumpleases.o
 lib-$(CONFIG_APP_DHCPRELAY)     += dhcprelay.o
+lib-$(CONFIG_FEATURE_RFC3397)   += domain_codec.o
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/domain_codec.c busybox-svn-17929/networking/udhcp/domain_codec.c
--- busybox-svn-17929.orig/networking/udhcp/domain_codec.c	1969-12-31 19:00:00.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/domain_codec.c	2007-02-26 18:01:49.000000000 -0500
@@ -0,0 +1,205 @@
+/* vi: set sw=4 ts=4: */
+
+/* RFC1035 domain compression routines (C) 2007 Gabriel Somlo <somlo at cmu.edu>
+ *
+ * Loosely based on the isc-dhcpd implementation by dhankins at isc.org
+ *
+ * Licensed under GPLv2 or later, see file LICENSE in this tarball for details.
+ */
+
+#if ENABLE_FEATURE_RFC3397
+
+#include "common.h"
+#include "options.h"
+
+#define NS_MAXDNAME  1025	/* max domain name length */
+#define NS_MAXCDNAME  255	/* max compressed domain name length */
+#define NS_MAXLABEL    63	/* max label length */
+#define NS_MAXDNSRCH    6	/* max domains in search path */
+#define NS_CMPRSFLGS 0xc0	/* name compression pointer flag */
+
+
+/* expand a RFC1035-compressed list of domain names "cstr", of length "clen";
+ * returns a newly allocated string containing the space-separated domains,
+ * prefixed with the contents of string pre, or NULL if an error occurs.
+ */
+char *dname_dec(const uint8_t *cstr, int clen, const char *pre)
+{
+	const uint8_t *c;
+	int crtpos, retpos, depth, plen = 0, len = 0;
+	char *dst = NULL;
+
+	if (!cstr)
+		return NULL;
+
+	if (pre)
+		plen = strlen(pre);
+
+	/* We make two passes over the cstr string. First, we compute
+	 * how long the resulting string would be. Then we allocate a
+	 * new buffer of the required length, and fill it in with the
+	 * expanded content. The advantage of this approach is not
+	 * having to deal with requiring callers to supply their own
+	 * buffer, then having to check if it's sufficiently large, etc.
+	 */
+
+	while (!dst) {
+
+		if (len > 0) {	/* second pass? allocate dst buffer and copy pre */
+			dst = xmalloc(len + plen);
+			memcpy(dst, pre, plen);
+		}
+
+		crtpos = retpos = depth = len = 0;
+
+		while (crtpos < clen) {
+			c = cstr + crtpos;
+
+			if ((*c & NS_CMPRSFLGS) != 0) {	/* pointer */
+				if (crtpos + 2 > clen)		/* no offset to jump to? abort */
+					return NULL;
+				if (retpos == 0)			/* toplevel? save return spot */
+					retpos = crtpos + 2;
+				depth++;
+				crtpos = ((*c & 0x3f) << 8) | (*(c + 1) & 0xff); /* jump */
+			} else if (*c) {			/* label */
+				if (crtpos + *c + 1 > clen)		/* label too long? abort */
+					return NULL;
+				if (dst)
+					memcpy(dst + plen + len, c + 1, *c);
+				len += *c + 1;
+				crtpos += *c + 1;
+				if (dst)
+					*(dst + plen + len - 1) = '.';
+			} else {					/* null: end of current domain name */
+				if (retpos == 0) {			/* toplevel? keep going */
+					crtpos++;
+				} else {					/* return to toplevel saved spot */
+					crtpos = retpos;
+					retpos = depth = 0;
+				}
+				if (dst)
+					*(dst + plen + len - 1) = ' ';
+			}
+
+			if (depth > NS_MAXDNSRCH || /* too many jumps? abort, it's a loop */
+				len > NS_MAXDNAME * NS_MAXDNSRCH) /* result too long? abort */
+				return NULL;
+		}
+
+		if (!len)			/* expanded string has 0 length? abort */
+			return NULL;
+
+		if (dst)
+			*(dst + plen + len - 1) = '\0';
+	}
+
+	return dst;
+}
+
+/* Convert a domain name (src) from human-readable "foo.blah.com" format into
+ * RFC1035 encoding "\003foo\004blah\003com\000". Return allocated string, or
+ * NULL if an error occurs.
+ */
+static uint8_t *convert_dname(const char *src)
+{
+	uint8_t c, *res, *lp, *rp;
+	int len;
+
+	res = xmalloc(strlen(src) + 2);
+	rp = lp = res;
+	rp++;
+
+	for (;;) {
+		c = (uint8_t)*src++;
+		if (c == '.' || c == '\0') {	/* end of label */
+			len = rp - lp - 1;
+			/* label too long, too short, or two '.'s in a row? abort */
+			if (len > NS_MAXLABEL || len == 0 || (c == '.' && *src == '.')) {
+				free(res);
+				return NULL;
+			}
+			*lp = len;
+			lp = rp++;
+			if (c == '\0' || *src == '\0')	/* end of dname */
+				break;
+		} else {
+			if (c >= 0x41 && c <= 0x5A)		/* uppercase? convert to lower */
+				c += 0x20;
+			*rp++ = c;
+		}
+	}
+
+	*lp = 0;
+	if (rp - res > NS_MAXCDNAME) {	/* dname too long? abort */
+		free(res);
+		return NULL;
+	}
+	return res;
+}
+
+/* returns the offset within cstr at which dname can be found, or -1
+ */
+static int find_offset(const uint8_t *cstr, int clen, const uint8_t *dname)
+{
+	const uint8_t *c, *d;
+	int off, inc;
+
+	/* find all labels in cstr */
+	off = 0;
+	while (off < clen) {
+		c = cstr + off;
+
+		if ((*c & NS_CMPRSFLGS) != 0) {	/* pointer, skip */
+			off += 2;
+		} else if (*c) {	/* label, try matching dname */
+			inc = *c + 1;
+			d = dname;
+			while (*c == *d && memcmp(c + 1, d + 1, *c) == 0) {
+				if (*c == 0)	/* match, return offset */
+					return off;
+				d += *c + 1;
+				c += *c + 1;
+				if ((*c & NS_CMPRSFLGS) != 0)	/* pointer, jump */
+					c = cstr + (((*c & 0x3f) << 8) | (*(c + 1) & 0xff));
+			}
+			off += inc;
+		} else {	/* null, skip */
+			off++;
+		}
+	}
+
+	return -1;
+}
+
+/* computes string to be appended to cstr so that src would be added to
+ * the compression (best case, it's a 2-byte pointer to some offset within
+ * cstr; worst case, it's all of src, converted to rfc3011 format).
+ * The computed string is returned directly; its length is returned via retlen;
+ * NULL and 0, respectively, are returned if an error occurs.
+ */
+uint8_t *dname_enc(const uint8_t *cstr, int clen, const char *src, int *retlen)
+{
+	uint8_t *d, *dname;
+	int off;
+
+	dname = convert_dname(src);
+	if (dname == NULL) {
+		*retlen = 0;
+		return NULL;
+	}
+
+	for (d = dname; *d != 0; d += *d + 1) {
+		off = find_offset(cstr, clen, d);
+		if (off >= 0) {	/* found a match, add pointer and terminate string */
+			*d++ = NS_CMPRSFLGS;
+			*d = off;
+			break;
+		}
+	}
+
+	*retlen = d - dname + 1;
+	return dname;
+}		
+
+#endif /* ENABLE_FEATURE_RFC3397 */
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/files.c busybox-svn-17929/networking/udhcp/files.c
--- busybox-svn-17929.orig/networking/udhcp/files.c	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/files.c	2007-02-24 09:41:22.000000000 -0500
@@ -102,10 +102,16 @@
 
 	existing = find_option(*opt_list, option->code);
 	if (!existing) {
 		DEBUG("Attaching option %s to list", option->name);
 
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035)
+			/* reuse buffer and length for RFC1035-formatted string */
+			buffer = dname_enc(NULL, 0, buffer, &length);
+#endif
+
 		/* make a new option */
 		new = xmalloc(sizeof(struct option_set));
 		new->data = xmalloc(length + 2);
 		new->data[OPT_CODE] = option->code;
 		new->data[OPT_LEN] = length;
@@ -115,16 +121,26 @@
 		while (*curr && (*curr)->data[OPT_CODE] < option->code)
 			curr = &(*curr)->next;
 
 		new->next = *curr;
 		*curr = new;
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035 && buffer != NULL)
+			free(buffer);
+#endif
 		return;
 	}
 
 	/* add it to an existing option */
 	DEBUG("Attaching option %s to existing member of list", option->name);
 	if (option->flags & OPTION_LIST) {
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035)
+			/* reuse buffer and length for RFC1035-formatted string */
+			buffer = dname_enc(existing->data + 2,
+									existing->data[OPT_LEN], buffer, &length);
+#endif
 		if (existing->data[OPT_LEN] + length <= 255) {
 			existing->data = xrealloc(existing->data,
 					existing->data[OPT_LEN] + length + 3);
 			if ((option->flags & TYPE_MASK) == OPTION_STRING) {
 				/* ' ' can bring us to 256 - bad */
@@ -135,10 +151,14 @@
 				existing->data[OPT_LEN]++;
 			}
 			memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
 			existing->data[OPT_LEN] += length;
 		} /* else, ignore the data, we could put this in a second option in the future */
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035 && buffer != NULL)
+			free(buffer);
+#endif
 	} /* else, ignore the new data */
 }
 
 
 /* read a dhcp option and add it to opt_list */
@@ -181,10 +201,13 @@
 			retval = read_ip(val, buffer);
 			if (!(val = strtok(NULL, ", \t/-"))) retval = 0;
 			if (retval) retval = read_ip(val, buffer + 4);
 			break;
 		case OPTION_STRING:
+#if ENABLE_FEATURE_RFC3397
+		case OPTION_STR1035:
+#endif
 			length = strlen(val);
 			if (length > 0) {
 				if (length > 254) length = 254;
 				opt = val;
 				retval = 1;
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/options.c busybox-svn-17929/networking/udhcp/options.c
--- busybox-svn-17929.orig/networking/udhcp/options.c	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/options.c	2007-02-24 09:41:22.000000000 -0500
@@ -9,11 +9,11 @@
 #include "options.h"
 
 
 /* supported options are easily added here */
 const struct dhcp_option dhcp_options[] = {
-	/* name[10]     flags                                   code */
+	/* name[12]     flags                                   code */
 	{"subnet",      OPTION_IP | OPTION_REQ,                 0x01},
 	{"timezone",    OPTION_S32,                             0x02},
 	{"router",      OPTION_IP | OPTION_LIST | OPTION_REQ,   0x03},
 	{"timesvr",     OPTION_IP | OPTION_LIST,                0x04},
 	{"namesvr",     OPTION_IP | OPTION_LIST,                0x05},
@@ -41,10 +41,13 @@
 	{"vendorclass", OPTION_STRING,                          0x3C},
 	{"clientid",    OPTION_STRING,                          0x3D},
 	{"tftp",        OPTION_STRING,                          0x42},
 	{"bootfile",    OPTION_STRING,                          0x43},
 	{"userclass",   OPTION_STRING,                          0x4D},
+#if ENABLE_FEATURE_RFC3397
+	{"search",      OPTION_STR1035 | OPTION_LIST | OPTION_REQ, 0x77},
+#endif
 	/* MSIE's "Web Proxy Autodiscovery Protocol" support */
 	{"wpad",        OPTION_STRING,                          0xfc},
 	{"",            0x00,                                   0x00}
 };
 
@@ -52,10 +55,13 @@
 const unsigned char option_lengths[] = {
 	[OPTION_IP] =      4,
 	[OPTION_IP_PAIR] = 8,
 	[OPTION_BOOLEAN] = 1,
 	[OPTION_STRING] =  1,
+#if ENABLE_FEATURE_RFC3397
+	[OPTION_STR1035] = 1,
+#endif
 	[OPTION_U8] =      1,
 	[OPTION_U16] =     2,
 	[OPTION_S16] =     2,
 	[OPTION_U32] =     4,
 	[OPTION_S32] =     4
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/options.h busybox-svn-17929/networking/udhcp/options.h
--- busybox-svn-17929.orig/networking/udhcp/options.h	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/options.h	2007-02-24 09:41:22.000000000 -0500
@@ -7,10 +7,13 @@
 
 enum {
 	OPTION_IP=1,
 	OPTION_IP_PAIR,
 	OPTION_STRING,
+#if ENABLE_FEATURE_RFC3397
+	OPTION_STR1035,	/* RFC1035 compressed domain name list */
+#endif
 	OPTION_BOOLEAN,
 	OPTION_U8,
 	OPTION_U16,
 	OPTION_S16,
 	OPTION_U32,
@@ -31,7 +34,11 @@
 
 uint8_t *get_option(struct dhcpMessage *packet, int code);
 int end_option(uint8_t *optionptr);
 int add_option_string(uint8_t *optionptr, uint8_t *string);
 int add_simple_option(uint8_t *optionptr, uint8_t code, uint32_t data);
+#if ENABLE_FEATURE_RFC3397
+char *dname_dec(const uint8_t *cstr, int clen, const char *pre);
+uint8_t *dname_enc(const uint8_t *cstr, int clen, const char *src, int *retlen);
+#endif
 
 #endif
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/script.c busybox-svn-17929/networking/udhcp/script.c
--- busybox-svn-17929.orig/networking/udhcp/script.c	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/script.c	2007-02-24 09:41:22.000000000 -0500
@@ -17,10 +17,13 @@
 /* get a rough idea of how long an option will be (rounding up...) */
 static const int max_option_length[] = {
 	[OPTION_IP] =		sizeof("255.255.255.255 "),
 	[OPTION_IP_PAIR] =	sizeof("255.255.255.255 ") * 2,
 	[OPTION_STRING] =	1,
+#if ENABLE_FEATURE_RFC3397
+	[OPTION_STR1035] =  1,
+#endif
 	[OPTION_BOOLEAN] =	sizeof("yes "),
 	[OPTION_U8] =		sizeof("255 "),
 	[OPTION_U16] =		sizeof("65535 "),
 	[OPTION_S16] =		sizeof("-32768 "),
 	[OPTION_U32] =		sizeof("4294967295 "),
@@ -51,25 +54,27 @@
 	for (i = 0; i < 32 && !((bits >> i) & 1); i++);
 	return 32 - i;
 }
 
 
-/* Fill dest with the text of option 'option'. */
-static void fill_options(char *dest, uint8_t *option,
-			const struct dhcp_option *type_p)
+/* Allocate and fill with the text of option 'option'. */
+static char *alloc_fill_opts(uint8_t *option, const struct dhcp_option *type_p)
 {
-	int type, optlen;
+	int len, type, optlen;
 	uint16_t val_u16;
 	int16_t val_s16;
 	uint32_t val_u32;
 	int32_t val_s32;
-	int len = option[OPT_LEN - 2];
-
-	dest += sprintf(dest, "%s=", type_p->name);
+	char *dest, *ret;
 
+	len = option[OPT_LEN - 2];
 	type = type_p->flags & TYPE_MASK;
 	optlen = option_lengths[type];
+
+	dest = ret = xmalloc(upper_length(len, type) + strlen(type_p->name) + 2);
+	dest += sprintf(ret, "%s=", type_p->name);
+
 	for (;;) {
 		switch (type) {
 		case OPTION_IP_PAIR:
 			dest += sprintip(dest, "", option);
 			*(dest++) = '/';
@@ -101,17 +106,25 @@
 			dest += sprintf(dest, "%ld", (long) ntohl(val_s32));
 			break;
 		case OPTION_STRING:
 			memcpy(dest, option, len);
 			dest[len] = '\0';
-			return;	 /* Short circuit this case */
+			return ret;	 /* Short circuit this case */
+#if ENABLE_FEATURE_RFC3397
+		case OPTION_STR1035:
+			/* unpack option into dest; use ret for prefix (i.e., "optname=") */
+			dest = dname_dec(option, len, ret);
+			free(ret);
+			return dest;
+#endif
 		}
 		option += optlen;
 		len -= optlen;
 		if (len <= 0) break;
 		dest += sprintf(dest, " ");
 	}
+	return ret;
 }
 
 
 /* put all the parameters into an environment */
 static char **fill_envp(struct dhcpMessage *packet)
@@ -153,13 +166,11 @@
 
 	for (i = 0; dhcp_options[i].code; i++) {
 		temp = get_option(packet, dhcp_options[i].code);
 		if (!temp)
 			continue;
-		envp[j] = xmalloc(upper_length(temp[OPT_LEN - 2],
-			dhcp_options[i].flags & TYPE_MASK) + strlen(dhcp_options[i].name) + 2);
-		fill_options(envp[j++], temp, &dhcp_options[i]);
+		envp[j++] = alloc_fill_opts(temp, &dhcp_options[i]);
 
 		/* Fill in a subnet bits option for things like /24 */
 		if (dhcp_options[i].code == DHCP_SUBNET) {
 			memcpy(&subnet, temp, 4);
 			envp[j++] = xasprintf("mask=%d", mton(&subnet));

From vda.linux at googlemail.com  Tue Feb 27 09:59:38 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 18:59:38 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E3F851.4060004@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
Message-ID: <200702271859.38772.vda.linux@googlemail.com>

On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
> I am trying to create a basic Linux system based on Busybox and would 
> like the ability to create the root file system as a normal user and 
> without any /dev entries. The startup script would create the /dev 
> entries as needed.
> However, init and other programs obviously require /dev/console (and 
> other /dev entries).
> 
> I was wondering about adding an option to init where it would create a 
> tmpfs file system, mount it on /dev and create a /dev/console node if no 
> /dev/console was found. I guess it could do a bit more and function as 
> udev as well.

I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.

http://busybox.net/~vda/example_fs/README
--
vda

From vapier at gentoo.org  Tue Feb 27 10:28:05 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 27 Feb 2007 13:28:05 -0500
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E3F851.4060004@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
Message-ID: <200702271328.06297.vapier@gentoo.org>

On Tuesday 27 February 2007, Terry Barnaby wrote:
> However, init and other programs obviously require /dev/console (and
> other /dev entries).

they dont require /dev/console

> I was wondering about adding an option to init where it would create a
> tmpfs file system, mount it on /dev and create a /dev/console node if no
> /dev/console was found. I guess it could do a bit more and function as
> udev as well.

it wouldnt work ... the kernel opens up /dev/console before executing init, so 
even if /sbin/init created the device node, it wouldnt matter

also, this is what init scripts are for ... such / policy handling does not 
belong hardcoded in the C code
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/d22d4891/attachment.pgp 

From vda.linux at googlemail.com  Tue Feb 27 11:17:52 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 20:17:52 +0100
Subject: [PATCH] Fix compile error when init/init.c is compiled with
	ENABLE_SELINUX.
In-Reply-To: <e739902b0702261839p2d50cac9kf53eccf913efb429@mail.gmail.com>
References: <e739902b0702261839p2d50cac9kf53eccf913efb429@mail.gmail.com>
Message-ID: <200702272017.52689.vda.linux@googlemail.com>

On Tuesday 27 February 2007 03:39, Ryan Bradetich wrote:
> Hello all,
> 
> Here is a trivial patch to fix a compile error in init.c when
> ENABLE_SELINUX is defined.

Applied, thanks!
--
vda

From vda.linux at googlemail.com  Tue Feb 27 11:23:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 20:23:43 +0100
Subject: ls on symlinked directories
In-Reply-To: <45E453B8.3070807@Kriegisch.name>
References: <45E453B8.3070807@Kriegisch.name>
Message-ID: <200702272023.43468.vda.linux@googlemail.com>

On Tuesday 27 February 2007 16:52, Alexander Kriegisch wrote:
> This might be a classical question which has been answered here before.
> If so, I apologise.
> 
> There are a few known bugs in coreutils/ls.c which have been documented,
> but not tackled for years. I am speaking of these:
> 
> >  * KNOWN BUGS:
> >  * 1. ls -l of a directory doesn't give "total <blocks>" header

Indeed (/usr/bin/ls is from coreutils-6.3):

# ls -l /sys
drwxr-xr-x   29 root     root            0 Feb 27 17:56 block
drwxr-xr-x   11 root     root            0 Feb 27 17:56 bus
drwxr-xr-x   22 root     root            0 Feb 27 17:56 class
drwxr-xr-x    7 root     root            0 Feb 27 18:56 devices
drwxr-xr-x    3 root     root            0 Feb 27 18:56 firmware
drwxr-xr-x    2 root     root            0 Feb 27 18:56 fs
drwxr-xr-x    3 root     root            0 Feb 27 18:56 kernel
drwxr-xr-x   50 root     root            0 Feb 27 17:57 module
drwxr-xr-x    2 root     root            0 Feb 27 18:56 power
# /usr/bin/ls -l /sys
total 0
drwxr-xr-x 29 root root 0 2007-02-27 17:56 block
drwxr-xr-x 11 root root 0 2007-02-27 17:56 bus
drwxr-xr-x 22 root root 0 2007-02-27 17:56 class
drwxr-xr-x  7 root root 0 2007-02-27 18:56 devices
drwxr-xr-x  3 root root 0 2007-02-27 18:56 firmware
drwxr-xr-x  2 root root 0 2007-02-27 18:56 fs
drwxr-xr-x  3 root root 0 2007-02-27 18:56 kernel
drwxr-xr-x 50 root root 0 2007-02-27 17:57 module
drwxr-xr-x  2 root root 0 2007-02-27 18:56 power

But I don't miss this feature. Is it a real problem?

> >  * 2. ls of a symlink to a directory doesn't list directory contents

Coreutils doesn't do it either:

# ls -l /etc
lrwxrwxrwx    1 root     root           11 May 21  2006 /etc -> /.local/etc
# /usr/bin/ls -l /etc
lrwxrwxrwx 1 root root 11 2006-05-21 22:08 /etc -> /.local/etc

(hmmm.... I like coreutils' ISO date/time!)

> >  * 3. hidden files can make column width too large

Can you elaborate on #3?
--
vda

From vda.linux at googlemail.com  Tue Feb 27 11:40:21 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 20:40:21 +0100
Subject: serial console and log-in
In-Reply-To: <1172054657.12630.38.camel@localhost>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
	<200702210104.57030.vda.linux@googlemail.com>
	<1172054657.12630.38.camel@localhost>
Message-ID: <200702272040.22024.vda.linux@googlemail.com>

On Wednesday 21 February 2007 11:44, Natanael Copa wrote:
> > A bit more tests will be useful.
> > Does it work _without_ serial console?
> > In both cases, is there controlling tty? IOW:
> > 
> > echo TEST >/dev/tty
> > TEST
> > 
> > This is good (controlling tty exists)
> > 
> > echo TEST >/dev/tty
> > sh: /dev/tty: No such device or address
> > 
> > This isn't good.
> 
> I backported the svn init to 1.4.1 (i depend on releases).
> 
> My inittab line looks like this:
> 
> ::respawn:/sbin/getty - 9600 vt100
> 
> I got a login prompt but no controlling tty:
> 
> -ash: cant't access tty; job control turned off
> 
> ~$ echo TEST > /dev/tty
> -ash: cannot create /dev/tty: No such device or address
> 
> That was on a VGA console.
> 
> Then I tried to run it in qemu, with -nographic. It booted, it gave me a
> login, but same as VGA, no controlling tty.

I expected that. It stems from the fact that /dev/console
cannot be a ctty.

I'm not sure this can be classified as 'bug'.
--
vda

From vda.linux at googlemail.com  Tue Feb 27 13:12:18 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 22:12:18 +0100
Subject: PATCH: RFC3397 domain search support
In-Reply-To: <20070227175041.GC13939@hedwig.net.cmu.edu>
References: <20070227175041.GC13939@hedwig.net.cmu.edu>
Message-ID: <200702272212.18051.vda.linux@googlemail.com>

On Tuesday 27 February 2007 18:50, Gabriel L. Somlo wrote:
> Denis,
> 
> Enclosed below is a patch that adds RFC3397 support to udhcp. It adds
> an 'option search' to the udhcpd.conf file on the server side, and
> fills the 'search' environment variable on the client side before
> udhcpc.script is called. Both client and server need to comply for
> this to be useful (e.g., isc dhcp version 3.1.0 or later), so the
> default setting for this in the build script is off.
> 
> I tested it with isc 3.1.0 alpha, and it seems to work.
> 
> Please let me know what you think. Apply if you like.

Applied, thanks.
--
vda

From strange at nsk.no-ip.org  Tue Feb 27 13:41:17 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 27 Feb 2007 21:41:17 +0000
Subject: ls on symlinked directories
In-Reply-To: <200702272023.43468.vda.linux@googlemail.com>
References: <45E453B8.3070807@Kriegisch.name>
	<200702272023.43468.vda.linux@googlemail.com>
Message-ID: <20070227214117.GB30382@nsk.no-ip.org>

On Tue, Feb 27, 2007 at 08:23:43PM +0100, Denis Vlasenko wrote:
> > >  * 2. ls of a symlink to a directory doesn't list directory contents
> 
> Coreutils doesn't do it either:

It does w/o -l:
$ ls /usr/tmp 
<bunch of files>
$ busybox ls /usr/tmp
/usr/tmp

Busybox is 1.2.2.1.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/2e02847c/attachment.pgp 

From terry1 at beam.ltd.uk  Tue Feb 27 13:45:49 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Tue, 27 Feb 2007 21:45:49 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702271328.06297.vapier@gentoo.org>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271328.06297.vapier@gentoo.org>
Message-ID: <45E4A68D.9020008@beam.ltd.uk>

Mike Frysinger wrote:
> On Tuesday 27 February 2007, Terry Barnaby wrote:
>> However, init and other programs obviously require /dev/console (and
>> other /dev entries).
> 
> they dont require /dev/console
> 
>> I was wondering about adding an option to init where it would create a
>> tmpfs file system, mount it on /dev and create a /dev/console node if no
>> /dev/console was found. I guess it could do a bit more and function as
>> udev as well.
> 
> it wouldnt work ... the kernel opens up /dev/console before executing init, so 
> even if /sbin/init created the device node, it wouldnt matter
> 
> also, this is what init scripts are for ... such / policy handling does not 
> belong hardcoded in the C code
> -mike

No, they don't require /dev/console just to operate, but if you want 
debug printout they do :)

Init could easily reopen its controlling terminal to the created 
/dev/console and continue ...

The reason I was looking at getting init to create /dev/console was so 
that I could debug my init scripts that are not working when 
/dev/console does not exist ...

Terry

From terry1 at beam.ltd.uk  Tue Feb 27 13:53:22 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Tue, 27 Feb 2007 21:53:22 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702271859.38772.vda.linux@googlemail.com>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271859.38772.vda.linux@googlemail.com>
Message-ID: <45E4A852.5050209@beam.ltd.uk>

Denis Vlasenko wrote:
> On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
>> I am trying to create a basic Linux system based on Busybox and would 
>> like the ability to create the root file system as a normal user and 
>> without any /dev entries. The startup script would create the /dev 
>> entries as needed.
>> However, init and other programs obviously require /dev/console (and 
>> other /dev entries).
>>
>> I was wondering about adding an option to init where it would create a 
>> tmpfs file system, mount it on /dev and create a /dev/console node if no 
>> /dev/console was found. I guess it could do a bit more and function as 
>> udev as well.
> 
> I think you are on the right track, but move in the wrong direction
> along that track. Code shouldn't be added to init, it should be removed.
> 
> http://busybox.net/~vda/example_fs/README
> --
> vda

Hi Denis,

But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)

Terry

From vda.linux at googlemail.com  Tue Feb 27 14:09:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 23:09:37 +0100
Subject: truncated syslog messages
In-Reply-To: <20070221142424.GA15913@salusa.home.net>
References: <20070221142424.GA15913@salusa.home.net>
Message-ID: <200702272309.37746.vda.linux@googlemail.com>

On Wednesday 21 February 2007 15:24, Stephane Billiart wrote:
> The problem:
> 
> server# logger "message to syslog"
> server# killall syslogd
> server# tail /var/log/messages 
> Feb 21 08:50:19 server syslog.info syslogd started: BusyBox v1.5.0.svn
> Feb 21 08:50:23 server kern.warn kernel: TSC 
> Feb 21 08:50:31 server user.notice root: messa
> Feb 21 08:51:25 server syslog.info syslogd exiting
> server# ls -l /dev/log /var/syslog
> lrwxrwxrwx    1 root     root           11 Jan  4  1980 /dev/log -> /var/syslog=
> srw-rw-rw-    1 root     root            0 Feb 21 08:50 /var/syslog=
> 
> All messages syslog receives are truncated, not the ones it writes itself...
> 
> My embedded system runs linux 2.6.19.2 with uClibc 0.9.27.
> I have mdev activated in busybox, /dev is a ramfs partition and /var is tmpfs.
> I tried with and without CONFIG_FEATURE_IPC_SYSLOG and get the same results

busybox and uclibc .config? syslogd parameters?

> I see the problem with the SVN and 1.4.1 versions but not with 1.2.2.1
> With glibc 2.3.6, everything is fine also.

glibc 2.4 and uclibc x86_64 svn (patched to fix stdio bug) works ok with

syslogd -m 0 -n -S -s 999 -b 9 -O $PWD/syslog

here

> There's been a lot of changes in syslogd recently.
> I started looking at the code but so far did not find anything to explain
> those short reads from /dev/log.

Adding few printf's is probably the fastest method to narrow it down.
Example:


static void log_locally(char *msg)
{
        static time_t last;
        struct flock fl;
        int len = strlen(msg);

+fprintf(stderr, "log_locally: '%s'\n", msg);

#if ENABLE_FEATURE_IPC_SYSLOG
...

static void timestamp_and_log(int pri, char *msg, int len)
{
        char *timestamp;

+fprintf(stderr, "timestamp_and_log: %d '%s'\n", len, msg);

        if (len < 16 || msg[3] != ' ' || msg[6] != ' '
         || msg[9] != ':' || msg[12] != ':' || msg[15] != ' '
        ) {
...

static void split_escape_and_log(char *tmpbuf, int len)
{
        char *p = tmpbuf;

+fprintf(stderr, "split_escape_and_log: %d '%s'\n", len, tmpbuf);

        tmpbuf += len;
        while (p < tmpbuf) {


Then killall syslogd, run new one with -n from the console,
and watch debug output.
--
vda

From vda.linux at googlemail.com  Tue Feb 27 14:35:02 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 23:35:02 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E4A852.5050209@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271859.38772.vda.linux@googlemail.com>
	<45E4A852.5050209@beam.ltd.uk>
Message-ID: <200702272335.02502.vda.linux@googlemail.com>

On Tuesday 27 February 2007 22:53, Terry Barnaby wrote:
> Denis Vlasenko wrote:
> > On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
> >> I am trying to create a basic Linux system based on Busybox and would 
> >> like the ability to create the root file system as a normal user and 
> >> without any /dev entries. The startup script would create the /dev 
> >> entries as needed.
> >> However, init and other programs obviously require /dev/console (and 
> >> other /dev entries).
> >>
> >> I was wondering about adding an option to init where it would create a 
> >> tmpfs file system, mount it on /dev and create a /dev/console node if no 
> >> /dev/console was found. I guess it could do a bit more and function as 
> >> udev as well.
> > 
> > I think you are on the right track, but move in the wrong direction
> > along that track. Code shouldn't be added to init, it should be removed.
> > 
> > http://busybox.net/~vda/example_fs/README
> > --
> > vda
> 
> Hi Denis,
> 
> But then you end up with init implemented in several shell scripts.
> I guess it depends if you prefer 'C' or shell programs :)

Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda

From strange at nsk.no-ip.org  Tue Feb 27 15:49:38 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 27 Feb 2007 23:49:38 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E3F851.4060004@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
Message-ID: <20070227234938.GA2357@nsk.no-ip.org>

On Tue, Feb 27, 2007 at 09:22:25AM +0000, Terry Barnaby wrote:
> Hi,
> 
> I am trying to create a basic Linux system based on Busybox and would 
> like the ability to create the root file system as a normal user and 
> without any /dev entries. The startup script would create the /dev 
> entries as needed.
> However, init and other programs obviously require /dev/console (and 
> other /dev entries).

Are you using initramfs? You can create cpios with special files,
different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
in the Linux source tree.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/6e2577fe/attachment.pgp 

From terry1 at beam.ltd.uk  Wed Feb 28 01:23:22 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 09:23:22 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <20070227234938.GA2357@nsk.no-ip.org>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
Message-ID: <45E54A0A.6030207@beam.ltd.uk>

Luciano Miguel Ferreira Rocha wrote:
> On Tue, Feb 27, 2007 at 09:22:25AM +0000, Terry Barnaby wrote:
>> Hi,
>>
>> I am trying to create a basic Linux system based on Busybox and would 
>> like the ability to create the root file system as a normal user and 
>> without any /dev entries. The startup script would create the /dev 
>> entries as needed.
>> However, init and other programs obviously require /dev/console (and 
>> other /dev entries).
> 
> Are you using initramfs? You can create cpios with special files,
> different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
> in the Linux source tree.
> 

Hi Luciano,

Yes, I am using initramfs and thanks for the info. I could use this for 
the boot initrd, but the system then mounts its real root fs using a 
read only NFS mount. I would prefer not to have a /dev/console in my NFS 
mounted file system either ...

Cheers

Terry

From terry1 at beam.ltd.uk  Wed Feb 28 01:46:22 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 09:46:22 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702272335.02502.vda.linux@googlemail.com>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271859.38772.vda.linux@googlemail.com>
	<45E4A852.5050209@beam.ltd.uk>
	<200702272335.02502.vda.linux@googlemail.com>
Message-ID: <45E54F6E.7090003@beam.ltd.uk>

Denis Vlasenko wrote:
> On Tuesday 27 February 2007 22:53, Terry Barnaby wrote:
>> Denis Vlasenko wrote:
>>> On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
>>>> I am trying to create a basic Linux system based on Busybox and would 
>>>> like the ability to create the root file system as a normal user and 
>>>> without any /dev entries. The startup script would create the /dev 
>>>> entries as needed.
>>>> However, init and other programs obviously require /dev/console (and 
>>>> other /dev entries).
>>>>
>>>> I was wondering about adding an option to init where it would create a 
>>>> tmpfs file system, mount it on /dev and create a /dev/console node if no 
>>>> /dev/console was found. I guess it could do a bit more and function as 
>>>> udev as well.
>>> I think you are on the right track, but move in the wrong direction
>>> along that track. Code shouldn't be added to init, it should be removed.
>>>
>>> http://busybox.net/~vda/example_fs/README
>>> --
>>> vda
>> Hi Denis,
>>
>> But then you end up with init implemented in several shell scripts.
>> I guess it depends if you prefer 'C' or shell programs :)
> 
> Shell programs are easier to tailor for particular system without
> messing up with compiler and toolchain - exactly what you need
> for "I want to create /dev/console".
> --
> vda

Hi Denis,

I notice your http://busybox.net/~vda/example_fs has /dev/console and 
/dev/null nodes. Have you managed to get a busybox system to boot and 
run using shell scripts without these nodes ?

In my system the final rootfs will be a read-only NFS mount and I don't 
want to have a /dev/console in the NFS mounted file system. So I need to 
create this at boot time. My shell scripts do not appear to run from 
init if I do not have a /dev/console though ...

Terry

From strange at nsk.no-ip.org  Wed Feb 28 02:16:45 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Wed, 28 Feb 2007 10:16:45 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E54A0A.6030207@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
	<45E54A0A.6030207@beam.ltd.uk>
Message-ID: <20070228101645.GA13363@nsk.no-ip.org>

On Wed, Feb 28, 2007 at 09:23:22AM +0000, Terry Barnaby wrote:
> Yes, I am using initramfs and thanks for the info. I could use this for 
> the boot initrd, but the system then mounts its real root fs using a 
> read only NFS mount. I would prefer not to have a /dev/console in my NFS 
> mounted file system either ...

Well, you'll still need some RW paths in your system. You can accomplish
that for /dev and get a working one too by keeping the one in initramfs:

mount --bind /dev /nfsroot/dev
...
switch_root

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/7eb11e7d/attachment.pgp 

From Alexander at Kriegisch.name  Wed Feb 28 02:18:28 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Wed, 28 Feb 2007 11:18:28 +0100
Subject: ls on symlinked directories
In-Reply-To: <200702272023.43468.vda.linux@googlemail.com>
References: <45E453B8.3070807@Kriegisch.name>
	<200702272023.43468.vda.linux@googlemail.com>
Message-ID: <45E556F4.907@Kriegisch.name>

Hi community!

Accidentally, I answered Denis' first reply without sending a copy to
the list, so now I am quoting our conversation FYI in ascending
chronological order below. Just two more annotations:

1. Busybox also has the ls -L switch mentioned in my last post. It works
   fine, even without Denis' patch, i.e. ls -L <symlinked_dir> shows a
   dereferenced and detailed directory listing. Even so, the patch is
   great and should be integrated into Bb.

2. The attached patch is my version with the cleaned up diff header
   lines, not Denis' original.

Regards
--
Alexander Kriegisch


----------------------------------------------------------------------


Hi Denis!

>>> >>>  * KNOWN BUGS:
>>> >>>  * 1. ls -l of a directory doesn't give "total <blocks>" header
> >
> > But I don't miss this feature. Is it a real problem?

Nope.

>>> >>>  * 2. ls of a symlink to a directory doesn't list directory contents
> >
> > Coreutils doesn't do it either:

Whatever Coreutils is. I was comparing the behaviour to that of other
(desktop) Linuxes. And each one I know shows the symlinked directory's
content. It is not a good argument that another tool is also buggy. It
is listed as a known bug by the author, after all.

>>> >>>  * 3. hidden files can make column width too large
> >
> > Can you elaborate on #3?

No, I was really just writing because of #2, as I said. I only quoted
all three, because SVN says they are all several years old. I would be
happy enough geeting #2 fixed.


Kind regards
--
Alexander Kriegisch


----------------------------------------------------------------------


On Tuesday 27 February 2007 22:34, Alexander Kriegisch wrote:
>>>> > >>>  * 2. ls of a symlink to a directory doesn't list directory
contents
>> > >
>> > > Coreutils doesn't do it either:
> >
> > Whatever Coreutils is.

coreutils is the GNU package which is used by virtually all Linux
distributions. It contains ls, among other utilities.

> > I was comparing the behaviour to that of other
> > (desktop) Linuxes. And each one I know shows the symlinked directory's
> > content.

Does ls -l follow links on your desktop Linux?
If yes, which distro is it?

> > It is not a good argument that another tool is also buggy.

I am not arguing whether it is bug or not. I want to
simply match coreutils ls, in case people parse
ls output in shell scripts.

> > It is listed as a known bug by the author, after all.

As others indicate, the bug is that bbox ls _without_ -l
doesn't follow links, but GNU ls does.

Attached patch makes bbox ls compatible with GNU coreutils one
regarding link dereferencing.
--
vda


----------------------------------------------------------------------


> > Does ls -l follow links on your desktop Linux? If yes, which distro
> > is it?
> >
> > As others indicate, the bug is that bbox ls _without_ -l
> > doesn't follow links, but GNU ls does.

You are right, it only follows without -l by default. My mistake, I
apologise. There are two switches that can do this, if necessary (Ubuntu
6.10 and others). Quote from the ls manpage:

> > -H, --dereference-command-line
> >     follow symbolic links listed on the command line
> > --dereference-command-line-symlink-to-dir
> >     follow each command line symbolic link that points to a directory

The difference is that the former (-lH) also works for symlinked files
(lists the size and modification date of the referenced file rather than
that of the link), whereas the latter only expands directories. It would
be nice to have those switches in Busybox, too, but if they are not part
of Coreutils, I understand we won't get them. I will try and apply your
patch and check the behaviour of ls without the -l switch, though, and
give you feedback later.

Thanks for now, I think that especially you support on this list is
exemplary. Compliments
--
Alexander Kriegisch


----------------------------------------------------------------------


> > Attached patch makes bbox ls compatible with GNU coreutils one
> > regarding link dereferencing.

As promised, here is my feedback: It works. Thank you. Maybe you could
provide patches for 1.4.1 and other relevant versions still supported. I
guess there might be more users wishing to profit from this.

BTW: I called by patch file busybox-1.4.1-ls_symlink.patch and slightly
changed the header, like so:

Before:
diff -d -urpN busybox.7/coreutils/ls.c busybox.8/coreutils/ls.c
--- busybox.7/coreutils/ls.c	2007-02-11 17:14:18.000000000 +0100
+++ busybox.8/coreutils/ls.c	2007-02-28 00:21:14.000000000 +0100

After:
--- coreutils/ls.c	2007-02-11 17:14:18.000000000 +0100
+++ coreutils/ls.c	2007-02-28 00:21:14.000000000 +0100


----------------------------------------------------------------------


Sorry, yet another message. BTW, was it on purpose to keep this
conversation private and not send copies to the list?

I wrote:
> > You are right, it only follows without -l by default. My mistake, I
> > apologise. There are two switches that can do this, if necessary (Ubuntu
> > 6.10 and others). Quote from the ls manpage:
> >
>> >> -H, --dereference-command-line
>> >>     follow symbolic links listed on the command line
>> >> --dereference-command-line-symlink-to-dir
>> >>     follow each command line symbolic link that points to a directory
> >
> > The difference is that the former (-lH) also works for symlinked files
> > (lists the size and modification date of the referenced file rather than
> > that of the link), whereas the latter only expands directories. It would
> > be nice to have those switches in Busybox, too, but if they are not part
> > of Coreutils, I understand we won't get them. I will try and apply your
> > patch and check the behaviour of ls without the -l switch, though, and
> > give you feedback later.

There also is this option:
> > -L, --dereference
> >     when showing file information for a symbolic link, show information
> >     for the file the link references rather than for the link itself

In Coreutils 6.7 (current version, I did not check others and don't know
which one exactly Busybox is intended to compatible with) we have this:

> > enum Dereference_symlink
> >   {
> >     DEREF_UNDEFINED = 1,
> >     DEREF_NEVER,
> >     DEREF_COMMAND_LINE_ARGUMENTS,      /* -H */
> >     DEREF_COMMAND_LINE_SYMLINK_TO_DIR, /* the default, in certain
cases */
> >     DEREF_ALWAYS                       /* -L */
> >   };

Greetings from Germany (where are you?)
--
Alexander Kriegisch


----------------------------------------------------------------------

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.4.1-ls_symlink.patch
Url: http://busybox.net/lists/busybox/attachments/20070228/61c6147d/attachment.pot 

From terry1 at beam.ltd.uk  Wed Feb 28 02:37:48 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 10:37:48 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <20070228101645.GA13363@nsk.no-ip.org>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
	<45E54A0A.6030207@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org>
Message-ID: <45E55B7C.3010906@beam.ltd.uk>

Luciano Miguel Ferreira Rocha wrote:
> On Wed, Feb 28, 2007 at 09:23:22AM +0000, Terry Barnaby wrote:
>> Yes, I am using initramfs and thanks for the info. I could use this for 
>> the boot initrd, but the system then mounts its real root fs using a 
>> read only NFS mount. I would prefer not to have a /dev/console in my NFS 
>> mounted file system either ...
> 
> Well, you'll still need some RW paths in your system. You can accomplish
> that for /dev and get a working one too by keeping the one in initramfs:
> 
> mount --bind /dev /nfsroot/dev
> ...
> switch_root
> 
I guess I could do that, but I would like the initial boot tmpfs to have 
gone once the system is booted so that the NFS mounted file system is 
the only one in operation. I have created tmpfs file systems for 
/dev,/tmp etc in my /etc/init.d/rcS script and this works fine if there 
is a /dev/console ...

I have had a quick look at the busybox init, and it appears that if 
there is not a /dev/console or /dev/null then it will not run any of the 
scripts .... So /dev/console or /dev/null is required for init to run.

I am still thinking it would be best to add the ability for init to 
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as 
possible to at-least get debug info from programs running.


Terry

From terry1 at beam.ltd.uk  Wed Feb 28 03:55:40 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 11:55:40 +0000
Subject: [PATCH]: Modifying init to create /dev/console and /dev/null
In-Reply-To: <45E55B7C.3010906@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
	<45E54A0A.6030207@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org>
	<45E55B7C.3010906@beam.ltd.uk>
Message-ID: <45E56DBC.9030407@beam.ltd.uk>

Hi,

I have decided to have a go and add support to init to create
a tmpfs file system on /dev and the two main device nodes /dev/console 
and /dev/null if no /dev/console exists on the rootfs.

This feature is enabled with the FEATURE_INIT_UDEV option.

If this option is enabled and the file /dev/console does not exist then
init will mount a tmpfs file system on /dev and create the basic device 
nodes /dev/console and /dev/null. This allows a system to boot and run 
without any device nodes in the root file system. The system startup 
scripts can create additional device nodes as needed or a full udev 
implementation can then take over.

I am using this for my own system at the moment and thought I would 
release the patch for interest. This is probably not the best way to 
achieve the task in hand, but it does work well.

Cheers


Terry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beam-init-udev-1.patch
Type: text/x-patch
Size: 1963 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/f73e4e37/attachment.bin 

From Thomas.Necker at marconi.com  Wed Feb 28 08:30:18 2007
From: Thomas.Necker at marconi.com (Thomas Necker)
Date: Wed, 28 Feb 2007 17:30:18 +0100
Subject: sed: missing LF
Message-ID: <OF758DBA6F.2C713D02-ONC1257290.005A3C0E@uk.marconicomms.com>

I have the following file test.cfg:

ADDRESS=
NETMASK=
GATEWAY=

When I issue the command

sed "/^ADDRESS/c\ADDRESS=1.2.3.4"

I get

ADDRESS=1.2.3.4NETMASK=
GATEWAY=

instead of

ADDRESS=1.2.3.4
NETMASK=
GATEWAY=

So, a LF is missing. I'm using Busybox 1.4.0. It worked with 1.0.

Thomas

From ddaney at avtrex.com  Wed Feb 28 09:33:54 2007
From: ddaney at avtrex.com (David Daney)
Date: Wed, 28 Feb 2007 09:33:54 -0800
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E4A68D.9020008@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>	<200702271328.06297.vapier@gentoo.org>
	<45E4A68D.9020008@beam.ltd.uk>
Message-ID: <45E5BD02.6050606@avtrex.com>

Terry Barnaby wrote:
> Mike Frysinger wrote:
>> On Tuesday 27 February 2007, Terry Barnaby wrote:
>>> However, init and other programs obviously require /dev/console (and
>>> other /dev entries).
>> they dont require /dev/console
>>
>>> I was wondering about adding an option to init where it would create a
>>> tmpfs file system, mount it on /dev and create a /dev/console node if no
>>> /dev/console was found. I guess it could do a bit more and function as
>>> udev as well.
>> it wouldnt work ... the kernel opens up /dev/console before executing init, so 
>> even if /sbin/init created the device node, it wouldnt matter
>>
>> also, this is what init scripts are for ... such / policy handling does not 
>> belong hardcoded in the C code
>> -mike
> 
> No, they don't require /dev/console just to operate, but if you want 
> debug printout they do :)
> 
> Init could easily reopen its controlling terminal to the created 
> /dev/console and continue ...
> 
> The reason I was looking at getting init to create /dev/console was so 
> that I could debug my init scripts that are not working when 
> /dev/console does not exist ...
> 

Why do you think what Make says is false?  All your posts on this 
subject are premised on that false belief.

I think it is time that you change your assumption that you can boot a 
system that does not contain /dev/console in its root file system.  You 
cannot do it with a standard Linux kernel.

As I see it you have two choices:

1) Put /dev/console in your root filesystem.
2) Hack up your kernel so that /dev/console is not needed.

David Daney

From florian at alphacore.net  Wed Feb 28 11:44:31 2007
From: florian at alphacore.net (Florian Fainelli)
Date: Wed, 28 Feb 2007 20:44:31 +0100
Subject: [PATCH] ping.c : fix min/max packet size usage
Message-ID: <45E5DB9F.2030704@alphacore.net>

Hi all,

An OpenWrt user reported that using packet size lower than 15, you could
trigger the following bug :

ping -s 1 -c 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 1 data bytes
9 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=291869364.5 ms


The following patch adds maximum length checking for ICMP packets, as
well as minimum usable size. Also, I noticed that datalen was not used
when generating packets, when not specified, datalen is initialized to
DEFDATALEN.

Thanks.

--- busybox-1.4.1/networking/ping.c     2007-01-24 22:34:34.000000000 +0100
+++ busybox-1.4.1.new/networking/ping.c 2007-02-28 20:35:59.000000000 +0100
@@ -70,7 +70,7 @@
        struct sockaddr_in pingaddr;
        struct icmp *pkt;
        int pingsock, c;
-       char packet[DEFDATALEN + MAXIPLEN + MAXICMPLEN];
+       char packet[datalen + MAXIPLEN + MAXICMPLEN];

        pingsock = create_icmp_socket();

@@ -86,7 +86,7 @@
        pkt->icmp_type = ICMP_ECHO;
        pkt->icmp_cksum = in_cksum((unsigned short *) pkt, sizeof(packet));

-       c = sendto(pingsock, packet, DEFDATALEN + ICMP_MINLEN, 0,
+       c = sendto(pingsock, packet, datalen + ICMP_MINLEN, 0,
                           (struct sockaddr *) &pingaddr, sizeof(struct
sockaddr_in));

        if (c < 0) {
@@ -257,8 +257,8 @@

        gettimeofday(&tv, NULL);

-       /* discard if too short */
-       if (sz < (datalen + ICMP_MINLEN))
+       /* discard if too short / long */
+       if (sz < (datalen + ICMP_MINLEN) || sz > (MAXICMPLEN))
                return;

        /* check IP header */
@@ -274,6 +274,10 @@
                ++nreceived;
                tp = (struct timeval *) icmppkt->icmp_data;

+               /* If packet is too short, results will be truncated */
+               if (sz < (ICMP_MINLEN + sizeof(tv.tv_sec) +
sizeof(tv.tv_usec)))
+                       return;
+
                if ((tv.tv_usec -= tp->tv_usec) < 0) {
                        --tv.tv_sec;
                        tv.tv_usec += 1000000;

From terry1 at beam.ltd.uk  Wed Feb 28 13:29:45 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 21:29:45 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E5BD02.6050606@avtrex.com>
References: <45E3F851.4060004@beam.ltd.uk>	<200702271328.06297.vapier@gentoo.org>
	<45E4A68D.9020008@beam.ltd.uk> <45E5BD02.6050606@avtrex.com>
Message-ID: <45E5F449.2090308@beam.ltd.uk>

David Daney wrote:
> Terry Barnaby wrote:
>> Mike Frysinger wrote:
>>> On Tuesday 27 February 2007, Terry Barnaby wrote:
>>>> However, init and other programs obviously require /dev/console (and
>>>> other /dev entries).
>>> they dont require /dev/console
>>>
>>>> I was wondering about adding an option to init where it would create a
>>>> tmpfs file system, mount it on /dev and create a /dev/console node 
>>>> if no
>>>> /dev/console was found. I guess it could do a bit more and function as
>>>> udev as well.
>>> it wouldnt work ... the kernel opens up /dev/console before executing 
>>> init, so even if /sbin/init created the device node, it wouldnt matter
>>>
>>> also, this is what init scripts are for ... such / policy handling 
>>> does not belong hardcoded in the C code
>>> -mike
>>
>> No, they don't require /dev/console just to operate, but if you want 
>> debug printout they do :)
>>
>> Init could easily reopen its controlling terminal to the created 
>> /dev/console and continue ...
>>
>> The reason I was looking at getting init to create /dev/console was so 
>> that I could debug my init scripts that are not working when 
>> /dev/console does not exist ...
>>
> 
> Why do you think what Make says is false?  All your posts on this 
> subject are premised on that false belief.
> 
> I think it is time that you change your assumption that you can boot a 
> system that does not contain /dev/console in its root file system.  You 
> cannot do it with a standard Linux kernel.
> 
> As I see it you have two choices:
> 
> 1) Put /dev/console in your root filesystem.
> 2) Hack up your kernel so that /dev/console is not needed.
> 
> David Daney

Hi,

Because, you can !
You can boot a system without /dev/console and get init to create the 
basic /dev/console and continue. At least with the 2.6.19 kernel. My 
patch to the Busybox init later in this thread does this and with an 
un-modified kernel (in fact a standard Fedora 6 binary kernel).

I can now boot my system without any /dev nodes in sight. Init mounts a 
tmpfs file system on /dev and creates the two necessary nodes 
/dev/console and /dev/null and the rcS init script creates the rest.
However, being new to Busybox I'm not sure that this is the best 
approach ...

Cheers

Terry

From vda.linux at googlemail.com  Wed Feb 28 14:38:47 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 28 Feb 2007 23:38:47 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E54F6E.7090003@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702272335.02502.vda.linux@googlemail.com>
	<45E54F6E.7090003@beam.ltd.uk>
Message-ID: <200702282338.47578.vda.linux@googlemail.com>

On Wednesday 28 February 2007 10:46, Terry Barnaby wrote:
> Denis Vlasenko wrote:
> > On Tuesday 27 February 2007 22:53, Terry Barnaby wrote:
> >> Denis Vlasenko wrote:
> >>> On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
> >>>> I am trying to create a basic Linux system based on Busybox and would 
> >>>> like the ability to create the root file system as a normal user and 
> >>>> without any /dev entries. The startup script would create the /dev 
> >>>> entries as needed.
> >>>> However, init and other programs obviously require /dev/console (and 
> >>>> other /dev entries).
> >>>>
> >>>> I was wondering about adding an option to init where it would create a 
> >>>> tmpfs file system, mount it on /dev and create a /dev/console node if no 
> >>>> /dev/console was found. I guess it could do a bit more and function as 
> >>>> udev as well.
> >>> I think you are on the right track, but move in the wrong direction
> >>> along that track. Code shouldn't be added to init, it should be removed.
> >>>
> >>> http://busybox.net/~vda/example_fs/README
> >>> --
> >>> vda
> >> Hi Denis,
> >>
> >> But then you end up with init implemented in several shell scripts.
> >> I guess it depends if you prefer 'C' or shell programs :)
> > 
> > Shell programs are easier to tailor for particular system without
> > messing up with compiler and toolchain - exactly what you need
> > for "I want to create /dev/console".
> > --
> > vda
> 
> Hi Denis,
> 
> I notice your http://busybox.net/~vda/example_fs has /dev/console and 
> /dev/null nodes. Have you managed to get a busybox system to boot and 
> run using shell scripts without these nodes ?

Yes, see below
 
> In my system the final rootfs will be a read-only NFS mount and I don't 
> want to have a /dev/console in the NFS mounted file system. So I need to 
> create this at boot time. My shell scripts do not appear to run from 
> init if I do not have a /dev/console though ...

This is the script which runs as /linuxrc (PID=1) in my initrd.
Notice that it mounts ramfs on /dev and creates console
and null there before chrooting into new ("real") root.
--
vda

#!/bin/sh

export PATH=/bin:/usr/bin

if ! test "$INIT"; then
    INIT=/sbin/init
fi

cd /
# devfs allows me to use /dev/ide/.../.../.. root= param
#mount -n -t devfs none /dev
mount -n -t proc none /proc
#mount -n -t sysfs none /sys

echo "# Mounting root fs"
/script/mount_root

# Clean up
#umount /sys
umount /proc

echo "# Chrooting into root fs"
test -d /new_root/dev -a -d /new_root/proc || {
    echo "Root fs (ls -l):"
    cd /new_root; ls -l
    echo "Root fs has no /dev and/or /proc!"
    echo "Fatal, cannot continue booting"
    while true; do sleep 32000; done
}
mount -n -t ramfs none /new_root/dev || {
    echo "! mount -n -t ramfs none /new_root/dev failed, continuing in 10 sec"
    sleep 10
}
cp -dp /dev/console /dev/null /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc || {
    echo "pivot_root failed. Fatal, cannot continue booting"
    while true; do sleep 32000; done
}

exec \
chroot . \
sh -c '\
umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
exec /bin/env - $INIT
'

echo "chroot . sh failed. Fatal, cannot continue booting"
while true; do sleep 32000; done

From vda.linux at googlemail.com  Wed Feb 28 14:43:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 28 Feb 2007 23:43:40 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E55B7C.3010906@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org>
	<45E55B7C.3010906@beam.ltd.uk>
Message-ID: <200702282343.40891.vda.linux@googlemail.com>

On Wednesday 28 February 2007 11:37, Terry Barnaby wrote:
> Luciano Miguel Ferreira Rocha wrote:
> I have had a quick look at the busybox init, and it appears that if 
> there is not a /dev/console or /dev/null then it will not run any of the 
> scripts .... So /dev/console or /dev/null is required for init to run.
> 
> I am still thinking it would be best to add the ability for init to 
> create a basic /dev with /dev/console etc if these do not exist. This
> still appears a cleaner way of doing things to me at the moment ...
> This could be done internally or by calling an external script from
> init although it would be nice if /dev/console existed as early on as 
> possible to at-least get debug info from programs running.

kernel boored with: init=/somewhere/fix_dev.sh

fix_dev.sh:

#!/bin/sh
mknod ... /dev/....
exec /sbin/init "$@"

No hacking in init! :)

Do you see any problems with this approach?
--
vda

From vda.linux at googlemail.com  Wed Feb 28 15:14:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Mar 2007 00:14:19 +0100
Subject: [PATCH] ping.c : fix min/max packet size usage
In-Reply-To: <45E5DB9F.2030704@alphacore.net>
References: <45E5DB9F.2030704@alphacore.net>
Message-ID: <200703010014.19437.vda.linux@googlemail.com>

On Wednesday 28 February 2007 20:44, Florian Fainelli wrote:
> Hi all,
> 
> An OpenWrt user reported that using packet size lower than 15, you could
> trigger the following bug :
> 
> ping -s 1 -c 1 192.168.0.1
> PING 192.168.0.1 (192.168.0.1): 1 data bytes
> 9 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=291869364.5 ms
> 
> The following patch adds maximum length checking for ICMP packets, as
> well as minimum usable size. Also, I noticed that datalen was not used
> when generating packets, when not specified, datalen is initialized to
> DEFDATALEN.

Thanks!

Unfortunately after 1.4.1 ping and ping6 got merged into one ping.c
(saving kilobytes of code) and your patch doesn't apply to current svn.

Care to rediff?

ping.c from current svn is attached.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ping.c
Type: text/x-csrc
Size: 20563 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070301/f15aa685/attachment-0001.c 

From vda.linux at googlemail.com  Wed Feb 28 15:26:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Mar 2007 00:26:56 +0100
Subject: serial console and log-in
In-Reply-To: <1172674255.27284.58.camel@localhost>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
	<200702272040.22024.vda.linux@googlemail.com>
	<1172674255.27284.58.camel@localhost>
Message-ID: <200703010026.56844.vda.linux@googlemail.com>

On Wednesday 28 February 2007 15:50, Natanael Copa wrote:
> > > I backported the svn init to 1.4.1 (i depend on releases).
> > > 
> > > My inittab line looks like this:
> > > 
> > > ::respawn:/sbin/getty - 9600 vt100
> > > 
> > > I got a login prompt but no controlling tty:
> > > 
> > > -ash: cant't access tty; job control turned off
> > > 
> > > ~$ echo TEST > /dev/tty
> > > -ash: cannot create /dev/tty: No such device or address
> > > 
> > > That was on a VGA console.
> > > 
> > > Then I tried to run it in qemu, with -nographic. It booted, it gave me a
> > > login, but same as VGA, no controlling tty.
> > 
> > I expected that. It stems from the fact that /dev/console
> > cannot be a ctty.
> > 
> > I'm not sure this can be classified as 'bug'.
> 
> Probably not. But then I need another feature :-/
> 
> Something like running a specified row only when controlling terminal is
> serial.
> 
> ttyS0:serial:respawn:/sbin/getty -L ttyS0 9600 vt100
> 
> Drawback is that it needs to use an unused field in inittab.

How about writing small hack which analyzes stdin (fd #0)
and closes fd #0,1,2 + reopens/dups /dev/ttyN or /dev/ttySn:


/* From <linux/vt.h> */
struct vt_stat {
        unsigned short v_active;        /* active vt */
        unsigned short v_signal;        /* signal to send */
        unsigned short v_state; /* vt bitmask */
};
enum { VT_GETSTATE = 0x5603 };  /* get global vt state info */

/* From <linux/serial.h> */
struct serial_struct {
        int     type;
        int     line;
        unsigned int    port;
        int     irq;
        int     flags;
        int     xmit_fifo_size;
        int     custom_divisor;
        int     baud_base;
        unsigned short  close_delay;
        char    io_type;
        char    reserved_char[1];
        int     hub6;
        unsigned short  closing_wait; /* time to wait before closing */
        unsigned short  closing_wait2; /* no longer used... */
        unsigned char   *iomem_base;
        unsigned short  iomem_reg_shift;
        unsigned int    port_high;
        unsigned long   iomap_base;     /* cookie passed into ioremap */
        int     reserved[1];
};

        int fd;
        struct vt_stat vt;
        struct serial_struct sr;
        char console[64];

        /* identify the real console backend and try to use it */
        if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
                /* this is a serial console */
                snprintf(console, sizeof(console) - 1, "/dev/ttyS%d", sr.line);
        } else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
                /* this is linux virtual tty */
                snprintf(console, sizeof(console) - 1, "/dev/tty%d", vt.v_active);
        } else {
               /* unable to figure it out */
               ...
        }

	fd = xopen(console, O_RDWR);
	dup2(fd, 0);
	dup2(fd, 1);
	dup2(fd, 2);
	while (fd > 2) close(fd--);

then exec it's argv?

Use it like this:

::respawn:/somewhere/cttyhack /sbin/getty - 9600 vt100

Care to try? ;)
--
vda

From vapier at gentoo.org  Wed Feb 28 17:24:48 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 28 Feb 2007 20:24:48 -0500
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E5BD02.6050606@avtrex.com>
References: <45E3F851.4060004@beam.ltd.uk> <45E4A68D.9020008@beam.ltd.uk>
	<45E5BD02.6050606@avtrex.com>
Message-ID: <200702282024.49671.vapier@gentoo.org>

On Wednesday 28 February 2007, David Daney wrote:
> I think it is time that you change your assumption that you can boot a
> system that does not contain /dev/console in its root file system.  You
> cannot do it with a standard Linux kernel.

perhaps you need to change your assumption ?  you can boot Linux without 
a /dev/console just fine ... you dont get status output, but in an embedded 
system, big whoop
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/5e091f32/attachment.pgp 

From vapier at gentoo.org  Wed Feb 28 17:26:05 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 28 Feb 2007 20:26:05 -0500
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702282343.40891.vda.linux@googlemail.com>
References: <45E3F851.4060004@beam.ltd.uk> <45E55B7C.3010906@beam.ltd.uk>
	<200702282343.40891.vda.linux@googlemail.com>
Message-ID: <200702282026.06317.vapier@gentoo.org>

On Wednesday 28 February 2007, Denis Vlasenko wrote:
> fix_dev.sh:
>
> #!/bin/sh
> mknod ... /dev/....
> exec /sbin/init "$@"
>
> No hacking in init! :)
>
> Do you see any problems with this approach?

you should add redirects so that /sbin/init opens /dev/console for its stdin 
and stdout ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/9669d51e/attachment.pgp 

From ddaney at avtrex.com  Wed Feb 28 18:15:21 2007
From: ddaney at avtrex.com (David Daney)
Date: Wed, 28 Feb 2007 18:15:21 -0800
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702282024.49671.vapier@gentoo.org>
References: <45E3F851.4060004@beam.ltd.uk> <45E4A68D.9020008@beam.ltd.uk>
	<45E5BD02.6050606@avtrex.com>
	<200702282024.49671.vapier@gentoo.org>
Message-ID: <45E63739.1010806@avtrex.com>

Mike Frysinger wrote:
> On Wednesday 28 February 2007, David Daney wrote:
>> I think it is time that you change your assumption that you can boot a
>> system that does not contain /dev/console in its root file system.  You
>> cannot do it with a standard Linux kernel.
> 
> perhaps you need to change your assumption ?  you can boot Linux without 
> a /dev/console just fine ... you dont get status output, but in an embedded 
> system, big whoop
> -mike

I am obviously wrong for newer kernels.  Sorry for that.

But in my past hacking with 2.4 kernels I seem to remember that the 
kernel would panic if the rootfs was missing /dev/console.  However I 
suppose I could be wrong about that as well.

David Daney

From terry1 at beam.ltd.uk  Wed Feb 28 22:49:18 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Thu, 01 Mar 2007 06:49:18 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702282343.40891.vda.linux@googlemail.com>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org>
	<45E55B7C.3010906@beam.ltd.uk>
	<200702282343.40891.vda.linux@googlemail.com>
Message-ID: <45E6776E.2090801@beam.ltd.uk>

Denis Vlasenko wrote:
> On Wednesday 28 February 2007 11:37, Terry Barnaby wrote:
>> Luciano Miguel Ferreira Rocha wrote:
>> I have had a quick look at the busybox init, and it appears that if 
>> there is not a /dev/console or /dev/null then it will not run any of the 
>> scripts .... So /dev/console or /dev/null is required for init to run.
>>
>> I am still thinking it would be best to add the ability for init to 
>> create a basic /dev with /dev/console etc if these do not exist. This
>> still appears a cleaner way of doing things to me at the moment ...
>> This could be done internally or by calling an external script from
>> init although it would be nice if /dev/console existed as early on as 
>> possible to at-least get debug info from programs running.
> 
> kernel boored with: init=/somewhere/fix_dev.sh
> 
> fix_dev.sh:
> 
> #!/bin/sh
> mknod ... /dev/....
> exec /sbin/init "$@"
> 
> No hacking in init! :)
> 
> Do you see any problems with this approach?
> --
> vda
Hi,

No problems I can see with this approach apart from the kernel boot line 
needing changing in all places and I'm not sure if it will work across a 
switch_root. But, I do prefer getting init to do the work. Using init, I 
believe, is cleaner, simpler and more in keeping with what init is 
supposed to do, assuming you want to use the init boot approach of 
course (and no hacking in sh! :) )

Cheers


Terry

From wimpunk at gmail.com  Wed Feb 28 08:13:13 2007
From: wimpunk at gmail.com (Wim Vinckier)
Date: Wed, 28 Feb 2007 17:13:13 +0100
Subject: [PATCH]: Modifying init to create /dev/console and /dev/null
In-Reply-To: <45E56DBC.9030407@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org> <45E54A0A.6030207@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org> <45E55B7C.3010906@beam.ltd.uk>
	<45E56DBC.9030407@beam.ltd.uk>
Message-ID: <5c43128e0702280813g243d0ab4n5bf5a688309a9dc6@mail.gmail.com>

Nice, looks like the patch I just needed. :-)

On 2/28/07, Terry Barnaby <terry1 at beam.ltd.uk> wrote:
> Hi,
>
> I have decided to have a go and add support to init to create
> a tmpfs file system on /dev and the two main device nodes /dev/console
> and /dev/null if no /dev/console exists on the rootfs.
>
> This feature is enabled with the FEATURE_INIT_UDEV option.
>
> If this option is enabled and the file /dev/console does not exist then
> init will mount a tmpfs file system on /dev and create the basic device
> nodes /dev/console and /dev/null. This allows a system to boot and run
> without any device nodes in the root file system. The system startup
> scripts can create additional device nodes as needed or a full udev
> implementation can then take over.
>
> I am using this for my own system at the moment and thought I would
> release the patch for interest. This is probably not the best way to
> achieve the task in hand, but it does work well.
>
> Cheers
>
>
> Terry
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
>


-- 
You have been on the computer to long when you start tilting your head
sideways to smile :-)

From strange at nsk.no-ip.org  Thu Feb  1 00:57:58 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Thu, 1 Feb 2007 00:57:58 +0000
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45C11D80.20906@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com> <45C0EBB2.1090604@seiner.com>
	<45C0F180.4000904@techmoninc.com> <45C11D80.20906@techmoninc.com>
Message-ID: <20070201005758.GA19486@nsk.no-ip.org>

On Wed, Jan 31, 2007 at 04:51:44PM -0600, Andy Kennedy wrote:
> Anyone have ANY idea about this???  Anyone else have a buildroot/busybox 
> setup that uses a serial console?

Currently working on an ARM development box:

1. kernel booted via serial line, with:
  root=/dev/ram console=ttyAM

kernel boot messages appear...
init and rc messages appear...
Please press Enter to activate this console.                                    
arm.foo login:

2. inittab:
::askfirst:/bin/login                                                           

(Spawn login on /dev/console. Either ttyAM or tty1, depending on boot
option. In this case, ttyAM.
Other option would have been, instead of that line:
 ttyAM::askfirst:/bin/login
 tty1::askfirst:/bin/login
)

3. boot scripts set serial speed:
for d in /dev/ttyS* /dev/ttyAM* /dev/ttyUSB*; do
    [ -e "$d" ] && stty -F $d ospeed 57600
done

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/67c44e2e/attachment-0002.pgp 

From brion.finlay at gmail.com  Thu Feb  1 06:26:20 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Thu, 1 Feb 2007 00:26:20 -0600
Subject: Busybox build problem
Message-ID: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>

This seems like it should be a simple question that other people have had
problems with, but I cannot get Busybox to build.  I have tried google-ing
for similar problems, searching the mail archives, and reading the FAQs and
all of the documentation, but I cannot figure out what is going on.

I am using a fairly fresh install of Ubuntu 6.1, and I have installed enough
of the development packages to build a custom kernel.  (I mention this
because Ubuntu does not preinstall many development packages, so it is
possible I am still missing some, but I have installed quite a few.)

The GCC version is 4.1.2.
sed is GNU Sed version 4.1.5

Here are the compile problems that I get:

Busybox 1.4.1
# make defconfig; make

...
include/bbconfigopts.h:1088: error: missing terminating " character
(repeated for each line)
include/bbconfigopts.h:1089: error: expected expression before ';' token
make[1]: *** [miscutils/bbconfig.o] Error 1
make: *** [miscutils] Error 2


# make allnoconfig; make

  LINK    busybox_unstripped
/home/brion/busybox-1.4.1/scripts/trylink: 5: function: not found
/home/brion/busybox-1.4.1/scripts/trylink: 11: Syntax error: "}" unexpected
make: *** [busybox_unstripped] Error 2

Busybox 1.4.0
same errors as 1.4.1

Busybox 1.3.2
same errors as 1.4.1

Busybox 1.2.2
# make defconfig; make OR # make allnoconfig; make
 GEN .depend
/home/brion/busybox-1.2.2/include/bbconfigopts.h:13 hmm, unterminated
make[1]: *** [.depend] Error 1
make: *** [_all] Error 2

Busybox 1.0.0
Works fine


I'm sure it is something wrong with my environment, but I do not know what.
Does anyone have any hints?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070201/cd768fc0/attachment-0001.htm 

From akennedy at techmoninc.com  Thu Feb  1 07:21:40 2007
From: akennedy at techmoninc.com (akennedy at techmoninc.com)
Date: Thu, 01 Feb 2007 00:21:40 -0700
Subject: Busybox build problem
Message-ID: <20070201002140.bfc52cea95091b0fffcb409eab6296ba.9cd207e1ee.wbe@email.secureserver.net>


> I'm sure it is something wrong with my environment, but I do not know what.  Does anyone have any hints?
Attempt the build with BuildRoot.  This will install uclibc and a gcc
that will work with it to build BusyBox.  I've found it VERY difficult
to build BusyBox with GLibC.

Andy



From mwigge at marcant.net  Thu Feb  1 08:04:16 2007
From: mwigge at marcant.net (Markus Wigge)
Date: Thu, 01 Feb 2007 09:04:16 +0100
Subject: version 1.4.1
Message-ID: <45C19F00.4060903@marcant.net>

Hi,

I'm a little bit confused, I recently read about busybox 1.4.1 and found 
an archive I could download but there is no tag for it in subversion and 
it is not announced on the web?

Is this an official version or what?

bye,
   Markus



From vapier at gentoo.org  Thu Feb  1 08:12:33 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Feb 2007 03:12:33 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200701300108.09929.vda.linux@googlemail.com>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
Message-ID: <200702010312.34740.vapier@gentoo.org>

On Monday 29 January 2007, Denis Vlasenko wrote:
> I propose to simply never define anything "modular"
>
> If people run "make modules",  well, that's their problems.

there are a bunch of env config settings which can cause problems ... what i'm 
looking at is busybox gets integrated into a larger build system which 
includes a kernel and next thing i know, busybox is failing because it's 
trying to generate depmod and build modules
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/33de39e9/attachment-0002.pgp 

From aurel at gnuage.org  Thu Feb  1 13:03:23 2007
From: aurel at gnuage.org (Aurelien Jacobs)
Date: Thu, 1 Feb 2007 14:03:23 +0100
Subject: busybox 1.4.1 build failure
Message-ID: <20070201140323.4dc138fa.aurel@gnuage.org>

Hi,

When upgrading from bb-1.4.0 to bb-1.4.1 I got the following error
(gcc-4.1.1, uClibc for i386 target):

  CC      networking/interface.o
cc1: warnings being treated as errors
networking/interface.c: In function 'in_ether':
networking/interface.c:853: warning: pointer targets in assignment differ in signedness
make[1]: *** [networking/interface.o] Error 1
make: *** [networking] Error 2

The attached patch fixes it.

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 90_build_fix.diff
Type: text/x-diff
Size: 413 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/94b338fe/attachment-0002.bin 

From yuwend at gmail.com  Thu Feb  1 13:23:42 2007
From: yuwend at gmail.com (Yuwen Dai)
Date: Thu, 1 Feb 2007 21:23:42 +0800
Subject: ash test suite
In-Reply-To: <45BF6F79.4020601@bfs.de>
References: <45B719C7.8010503@bfs.de>
	<f7e548110701240121ga2c4b1ej288f660ce7c6e6c6@mail.gmail.com>
	<45B75AF8.8050304@bfs.de>
	<f7e548110701290138w4e6b600g50263bbcd0d6f04f@mail.gmail.com>
	<45BDE4E6.200@bfs.de>
	<f7e548110701290553n206d528dt276a1764fa70d53b@mail.gmail.com>
	<45BDFDAA.8040508@bfs.de>
	<f7e548110701292155n4d52575ex5fb6d52d7fa6beea@mail.gmail.com>
	<45BF6F79.4020601@bfs.de>
Message-ID: <f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>

On 1/31/07, walter harms <wharms at bfs.de> wrote:
>
> your are right,
> note:  have removed the original diff for a 'diff -y | less' to see more
> clearly the differences.
> take also a look at the readme inside the ash* tests.


I see ash-* directories as well as test files in the same directory. While
in Bash testsuite, all test files are in same level, no subdirectories.  Did
you intend to put all all the test files into subdirectories?

Best regards,
Yuwen


re,
> wh
>
> inside the ash*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070201/c9b57984/attachment-0001.htm 

From wangbj at lzu.edu.cn  Thu Feb  1 13:56:04 2007
From: wangbj at lzu.edu.cn (Wang, Baojun)
Date: Thu, 1 Feb 2007 21:56:04 +0800
Subject: busybox 1.4.0(with patches) crosscompile failed:
Message-ID: <370399254.25716@eyou.net>

hi,


the cross compiler are being built using the clfs embedded way which can be 
found at: http://cross-lfs.org/view/clfs-embedded/x86/

after patching all patches, 

# make defconfig
# make menuconfig # select ash as default shell
# make CROSS_COMPILE=i686-pc-linux-uclibc- V=1

encounter the fellowing error:

  
i686-pc-linux-uclibc-gcc -Wp,-MD,miscutils/.taskset.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include 
include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(taskset)"  -D"KBUILD_MODNAME=KBUILD_STR(taskset)" -c -o 
miscutils/taskset.o miscutils/taskset.c
miscutils/taskset.c: In function '__from_cpuset':
miscutils/taskset.c:22: error: 'CPU_SETSIZE' undeclared (first use in this 
function)
miscutils/taskset.c:22: error: (Each undeclared identifier is reported only 
once
miscutils/taskset.c:22: error: for each function it appears in.)
cc1: warnings being treated as errors
miscutils/taskset.c:26: warning: implicit declaration of function 'CPU_ISSET'
miscutils/taskset.c: In function 'taskset_main':
miscutils/taskset.c:67: warning: implicit declaration of function 'CPU_ZERO'
miscutils/taskset.c:68: error: 'CPU_SETSIZE' undeclared (first use in this 
function)
miscutils/taskset.c:70: warning: implicit declaration of function 'CPU_SET'
miscutils/taskset.c:77: warning: implicit declaration of 
function 'sched_getaffinity'
miscutils/taskset.c:85: warning: implicit declaration of 
function 'sched_setaffinity'
make[1]: *** [miscutils/taskset.o] Error 1
make: *** [miscutils] Error 2

-- 
Wang, Baojun                                        Lanzhou University
Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
School of Information Science and Engeneering        wangbj at lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000                     .P.R.China
Tel:+86-931-8912025                                Fax:+86-931-8912022
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/0eb146e7/attachment-0002.pgp 

From strange at nsk.no-ip.org  Thu Feb  1 15:03:29 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Thu, 1 Feb 2007 15:03:29 +0000
Subject: Busybox build problem
In-Reply-To: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
Message-ID: <20070201150329.GB8446@nsk.no-ip.org>

On Thu, Feb 01, 2007 at 12:26:20AM -0600, Brion Finlay wrote:
> Here are the compile problems that I get:
<snip>

Could you show the lines giving the errors?

> I'm sure it is something wrong with my environment, but I do not know what.
> Does anyone have any hints?

You could have hardware problems.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/7ec746b7/attachment-0002.pgp 

From wangbj at lzu.edu.cn  Thu Feb  1 15:12:06 2007
From: wangbj at lzu.edu.cn (Wang, Baojun)
Date: Thu, 1 Feb 2007 23:12:06 +0800
Subject: busybox 1.4.0(with patches) crosscompile failed:
In-Reply-To: <370338889.00965@lzu.edu.cn>
References: <370338889.00965@lzu.edu.cn>
Message-ID: <370403821.29556@eyou.net>

On Thursday 01 February 2007 21:56, Wang, Baojun wrote:
> hi,
>
>
> the cross compiler are being built using the clfs embedded way which can be
> found at: http://cross-lfs.org/view/clfs-embedded/x86/
>
> after patching all patches,
>
> # make defconfig
> # make menuconfig # select ash as default shell
> # make CROSS_COMPILE=i686-pc-linux-uclibc- V=1
>
> encounter the fellowing error:
>
>
> i686-pc-linux-uclibc-gcc -Wp,-MD,miscutils/.taskset.o.d   -std=gnu99
> -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include
> include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)"
> -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror
> -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc
> -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1
> -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386
> -mpreferred-stack-boundary=2 -Wdeclaration-after-statement
> -Wno-pointer-sign    -D"KBUILD_STR(s)=#s"
> -D"KBUILD_BASENAME=KBUILD_STR(taskset)" 
> -D"KBUILD_MODNAME=KBUILD_STR(taskset)" -c -o miscutils/taskset.o
> miscutils/taskset.c
> miscutils/taskset.c: In function '__from_cpuset':
> miscutils/taskset.c:22: error: 'CPU_SETSIZE' undeclared (first use in this
> function)
> miscutils/taskset.c:22: error: (Each undeclared identifier is reported only
> once
> miscutils/taskset.c:22: error: for each function it appears in.)
> cc1: warnings being treated as errors
> miscutils/taskset.c:26: warning: implicit declaration of function
> 'CPU_ISSET' miscutils/taskset.c: In function 'taskset_main':
> miscutils/taskset.c:67: warning: implicit declaration of function
> 'CPU_ZERO' miscutils/taskset.c:68: error: 'CPU_SETSIZE' undeclared (first
> use in this function)
> miscutils/taskset.c:70: warning: implicit declaration of function 'CPU_SET'
> miscutils/taskset.c:77: warning: implicit declaration of
> function 'sched_getaffinity'
> miscutils/taskset.c:85: warning: implicit declaration of
> function 'sched_setaffinity'
> make[1]: *** [miscutils/taskset.o] Error 1
> make: *** [miscutils] Error 2

ok: fix this by modifying the cross compiler usr/include/sched.h, 

diff -u /mnt/clfs/usr/include/sched.h /usr/include/sched.h
--- /mnt/clfs/usr/include/sched.h       2007-02-01 22:12:28.000000000 +0800
+++ /usr/include/sched.h        2005-09-11 04:51:07.000000000 +0800
@@ -63,8 +63,7 @@
 extern int sched_rr_get_interval (__pid_t __pid, struct timespec *__t) 
__THROW;


-//#if 0 /*def __USE_GNU*/
-#ifdef __USE_GNU
+#ifdef __USE_GNU
 /* Access macros for `cpu_set'.  */
 #define CPU_SETSIZE __CPU_SETSIZE
 #define CPU_SET(cpu, cpusetp)  __CPU_SET (cpu, cpusetp

the related linux header version is 2.6.19.2, not sure why 2.6.19.2 use
  #if 0
instead of
  # ifdef __USE_GNU
...

my desktop with linux header version 2.6.19.2 also have this problem..


after fixing this, ether_wakup seems refuse to build with uClibc(snapshot 
version)

i686-pc-linux-uclibc-gcc -Wp,-MD,networking/.ether-wake.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.3.2/libbb -include 
include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.3.2)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign -m32   -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ether_wake)"  -D"KBUILD_MODNAME=KBUILD_STR(ether_wake)" -c -o 
networking/ether-wake.o networking/ether-wake.c
networking/ether-wake.c:227:3: error: #warning Need to implement 
ether_hostton() for uClibc
make[1]: *** [networking/ether-wake.o] Error 1
make: *** [networking] Error 2

I use `readelf -s' to find symbol `ether_hostton, it doesn't exist, however, 
it's availiable in glibc.

after I un-select CONFIG_ETHER_WAKEUP, I still get the following problem:

i686-pc-linux-uclibc-gcc -Wp,-MD,networking/libiproute/.iptunnel.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include 
include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign -m32   -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(iptunnel)"  -D"KBUILD_MODNAME=KBUILD_STR(iptunnel)" -c -o 
networking/libiproute/iptunnel.o networking/libiproute/iptunnel.c
In file included from /mnt/clfs/usr/include/linux/if_tunnel.h:4,
                 from networking/libiproute/iptunnel.c:33:
/mnt/clfs/usr/include/linux/if.h:119: error: redefinition of 'struct ifmap'
/mnt/clfs/usr/include/linux/if.h:155: error: redefinition of 'struct ifreq'
/mnt/clfs/usr/include/linux/if.h:205: error: redefinition of 'struct ifconf'
In file included from /mnt/clfs/usr/include/linux/if_tunnel.h:5,
                 from networking/libiproute/iptunnel.c:33:
/mnt/clfs/usr/include/linux/ip.h:84: error: redefinition of 'struct iphdr'
make[1]: *** [networking/libiproute/iptunnel.o] Error 1
make: *** [networking/libiproute] Error 2

and fixed (although straight) by:

--- busybox-1.4.0.orig/networking/libiproute/iptunnel.c 2007-01-20 
05:22:58.000000000 +0800
+++ busybox-1.4.0/networking/libiproute/iptunnel.c      2007-02-01 
22:41:34.000000000 +0800
@@ -21,15 +21,13 @@
 #include <string.h>
 #include <unistd.h>

-#include <netinet/ip.h>
-
-#include <net/if.h>
 #include <net/if_arp.h>

 #include <asm/types.h>
 #ifndef __constant_htons
 #define __constant_htons htons
 #endif
+#include <linux/if.h>
 #include <linux/if_tunnel.h>

 #include "rt_names.h"

I think maybe the 2.6.19.2 linux header is not a prefered version to build 
busybox.. any ideas? thanks!

-- 
Wang, Baojun                                        Lanzhou University
Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
School of Information Science and Engeneering        wangbj at lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000                     .P.R.China
Tel:+86-931-8912025                                Fax:+86-931-8912022
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/789809e8/attachment-0002.pgp 

From rep.dot.nop at gmail.com  Thu Feb  1 15:18:28 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 1 Feb 2007 16:18:28 +0100
Subject: no sched_setaffinity in uClibc [was: Re: busybox 1.4.0(with patches)
	crosscompile failed:]
In-Reply-To: <200702012156.07524.wangbj@lzu.edu.cn>
References: <200702012156.07524.wangbj@lzu.edu.cn>
Message-ID: <20070201151828.GA24370@aon.at>

On Thu, Feb 01, 2007 at 09:56:04PM +0800, Wang, Baojun wrote:
>hi,
>
>
>the cross compiler are being built using the clfs embedded way which can be 
>found at: http://cross-lfs.org/view/clfs-embedded/x86/
>
>after patching all patches, 
>
># make defconfig
># make menuconfig # select ash as default shell
># make CROSS_COMPILE=i686-pc-linux-uclibc- V=1
>
>encounter the fellowing error:
>
>  
>i686-pc-linux-uclibc-gcc -Wp,-MD,miscutils/.taskset.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include 


uClibc trunk has no support for sched_[sg]etaffinity.

Turn that applet off.
-- 
>include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(taskset)"  -D"KBUILD_MODNAME=KBUILD_STR(taskset)" -c -o 
>miscutils/taskset.o miscutils/taskset.c
>miscutils/taskset.c: In function '__from_cpuset':
>miscutils/taskset.c:22: error: 'CPU_SETSIZE' undeclared (first use in this 
>function)
>miscutils/taskset.c:22: error: (Each undeclared identifier is reported only 
>once
>miscutils/taskset.c:22: error: for each function it appears in.)
>cc1: warnings being treated as errors
>miscutils/taskset.c:26: warning: implicit declaration of function 'CPU_ISSET'
>miscutils/taskset.c: In function 'taskset_main':
>miscutils/taskset.c:67: warning: implicit declaration of function 'CPU_ZERO'
>miscutils/taskset.c:68: error: 'CPU_SETSIZE' undeclared (first use in this 
>function)
>miscutils/taskset.c:70: warning: implicit declaration of function 'CPU_SET'
>miscutils/taskset.c:77: warning: implicit declaration of 
>function 'sched_getaffinity'
>miscutils/taskset.c:85: warning: implicit declaration of 
>function 'sched_setaffinity'
>make[1]: *** [miscutils/taskset.o] Error 1
>make: *** [miscutils] Error 2
>
>-- 
>Wang, Baojun                                        Lanzhou University
>Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
>School of Information Science and Engeneering        wangbj at lzu.edu.cn
>Tianshui South Road 222. Lanzhou 730000                     .P.R.China
>Tel:+86-931-8912025                                Fax:+86-931-8912022



>_______________________________________________
>busybox mailing list
>busybox at busybox.net
>http://busybox.net/cgi-bin/mailman/listinfo/busybox


From somlo at cmu.edu  Thu Feb  1 21:07:00 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 16:07:00 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <78a54e1b0701301258k5e2446fdi90a4c69bb7e4d0e7@mail.gmail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<78a54e1b0701291906i58239c8at93fe71bab40b1da2@mail.gmail.com>
	<20070130195006.GD21905@hedwig.net.cmu.edu>
	<78a54e1b0701301258k5e2446fdi90a4c69bb7e4d0e7@mail.gmail.com>
Message-ID: <20070201210700.GA20549@hedwig.net.cmu.edu>

On Tue, Jan 30, 2007 at 02:58:50PM -0600, Jason Schoon wrote:
> On 1/30/07, Gabriel L. Somlo <somlo at cmu.edu> wrote:
> >And what to do about all the (pre isc 3.1.0) clients that just dump the
> >content of option 15 into the search string ? :)
> 
> They still will.  Or they will disregard the option entirely.

So, the way I see it, 3.1.0 and later clients will first look for the
domain-search option to add to resolv.conf, and default to domain-name
if the former isn't being sent by the server. As far as pre-3.1.0
clients:

> They will not
> have your patch, so they will not be expecting to receive multiple strings
> in a single field.  They will be expecting this field to contain a single
> domain value.

no, they'll expect a single string :) which may contain spaces. Which
is the way this is being done today, via the domain-name option.
Here's a quote from the dhcp-options man page that comes with 3.1.0a3:

	The domain-search option specifies a 'search list' of
	Domain Names to be used by the client to locate
	not-fully-qualified domain names. The difference between
	this option and historic use of the domain-name option
	                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	for the same ends is that this option is encoded in
	^^^^^^^^^^^^^^^^^^
	RFC1035 compressed labels on the wire.

The problem with udhcpd is that it won't allow quoted strings to be
parsed from the udhcpd.conf file (which would allow passing single
strings that contain spaces).

So, we either complicate parsing of strings from the config file, or
we make certain string-type options listable, and insert single spaces
between members of the "list", ending up with longer strings that
contain spaces.

We'd have to do one or the other of these anyway, even for RFC3397, as
we'll try to pass multiple strings (or one space-separated line of
them) to the domain-search option.

My patch did this in one of the two possible ways. Do you think it
should be done the other way (i.e., by adding support for parsing
quoted strings from the config file) ?

Speaking of RFC3397, I've written a compact function that expands
RFC1035-compressed strings, and it's included at the bottom of this
email, if anyone wants to poke at it. I'm working on a compression
function, at which time I'll whip up a patch to add 3397 to udhcpd.

Either way, adding 3397 support won't fix my original problem, which
is to support passing space-separated strings via the domain-name
option, which is something lots of people do, today, with isc dhcpd...

Cheers.
Gabriel


#define NS_CMPRSFLGS 0xc0	/* name compression pointer flag */

/* expand a RFC1035-compressed list of domain names "src", of length "slen";
 * returns a newly allocated string containing the space-separated domains,
 * or NULL if an error occurs.
 */
char *ns_name_expand(const unsigned char *src, unsigned slen) {
	const unsigned char *c;
	unsigned crtpos, retpos, len = 0;
	char *dst = NULL;

	if (!src || !slen)
		return NULL;

	/* We make two passes over the src string. First, we compute
	 * how long the resulting string would be. Then we allocate a
	 * new buffer of the required length, and fill it in with the
	 * expanded content. The advantage of this approach is not
	 * having to deal with requiring callers to supply their own
	 * buffer, then having to check if it's sufficiently large, etc.
	 */

	while (!dst) {

		if (len > 0)	/* second pass? allocate dst buffer */
			dst = xmalloc(len);

		len = crtpos = retpos = 0;

		while (crtpos < slen) {
			c = src + crtpos;

			if (*c & NS_CMPRSFLGS) { /* pointer */
				if (retpos == 0) /* toplevel? save ret. spot */
					retpos = crtpos + 2;
				crtpos = *(c + 1);/* jump to pointed location */
			} else if (*c) { /* label */
				if (dst)
					memcpy(dst + len, c + 1, *c);
				len += (*c + 1);
				crtpos += (*c + 1);
				if (dst)
					*(dst + len - 1) = '.';
			} else {  /* null -- end of current domain name */
				if (retpos == 0) { /* toplevel? keep going */
					crtpos++;
				} else {   /* go back to toplevel saved spot */
					crtpos = retpos;
					retpos = 0;
				}
				if (dst)
					*(dst + len - 1) = ' ';
			}
		}

		if (dst)
			*(dst + len - 1) = '\0';
	}

	return dst;
}


From vda.linux at googlemail.com  Thu Feb  1 22:08:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:08:20 +0100
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <20070126170058.GA31444@hedwig.net.cmu.edu>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
Message-ID: <200702012308.20367.vda.linux@googlemail.com>

On Friday 26 January 2007 18:00, Gabriel L. Somlo wrote:
> Denis & All,
> 
> Whatever I specify as the value for "option domain" in udhcpd.conf
> ends up being on the "search" line in my client's /etc/resolv.conf
> 
> As such, I discovered that specifying multiple values for
> "option domain" doesn't work with udhcpd.
> 
> The following patch fixes that by making "domain" accept a list of
> options, and by insuring that STRING type options with multiple values
> end up being separated by spaces (instead of being cat-ed together).
> 
> Let me know what you think.
> 
> Thanks,
> Gabriel 
> 
> 
> diff -NarU5 busybox-svn-17463.orig/networking/udhcp/files.c busybox-svn-17463/networking/udhcp/files.c
> --- busybox-svn-17463.orig/networking/udhcp/files.c	2007-01-22 11:17:58.000000000 -0500
> +++ busybox-svn-17463/networking/udhcp/files.c	2007-01-26 11:52:26.000000000 -0500
> @@ -106,11 +106,16 @@
>  	if (existing) {
>  		DEBUG("Attaching option %s to existing member of list", option->name);
>  		if (option->flags & OPTION_LIST) {
>  			if (existing->data[OPT_LEN] + length <= 255) {
>  				existing->data = realloc(existing->data,

realloc? why not xrealloc?

> -						existing->data[OPT_LEN] + length + 2);
> +						existing->data[OPT_LEN] + length + 3);
> +				if ((option->flags & TYPE_MASK) == OPTION_STRING) {
> +					/* add space separator between STRING options in a list */
> +					*(existing->data + existing->data[OPT_LEN] + 2) = ' ';
> +					existing->data[OPT_LEN]++;
> +				}
>  				memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
>  				existing->data[OPT_LEN] += length;

You can overflow existing->data[OPT_LEN].

The below version should fix that (and even mostly fit
into 80 column displays). Can you try it?

static void attach_option(struct option_set **opt_list,
                const struct dhcp_option *option, char *buffer, int length)
{
        struct option_set *existing, *new, **curr;

        existing = find_option(*opt_list, option->code);
        if (!existing) {
                DEBUG("Attaching option %s to list", option->name);

                /* make a new option */
                new = xmalloc(sizeof(struct option_set));
                new->data = xmalloc(length + 2);
                new->data[OPT_CODE] = option->code;
                new->data[OPT_LEN] = length;
                memcpy(new->data + 2, buffer, length);

                curr = opt_list;
                while (*curr && (*curr)->data[OPT_CODE] < option->code)
                        curr = &(*curr)->next;

                new->next = *curr;
                *curr = new;
                return;
        }

        /* add it to an existing option */
        DEBUG("Attaching option %s to existing member of list", option->name);
        if (option->flags & OPTION_LIST) {
                if (existing->data[OPT_LEN] + length <= 255) {
                        existing->data = xrealloc(existing->data,
                                        existing->data[OPT_LEN] + length + 3);
                        if ((option->flags & TYPE_MASK) == OPTION_STRING) {
                                if (existing->data[OPT_LEN] + length >= 255)
                                        return;
                                /* add space separator between STRING options in a list */
                                existing->data[existing->data[OPT_LEN] + 2] = ' ';
                                existing->data[OPT_LEN]++;
                        }
                        memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
                        existing->data[OPT_LEN] += length;
                } /* else, ignore the data, we could put this in a second option in the future */
        } /* else, ignore the new data */
}

--
vda


From kaigai at ak.jp.nec.com  Thu Feb  1 05:44:22 2007
From: kaigai at ak.jp.nec.com (KaiGai Kohei)
Date: Thu, 01 Feb 2007 14:44:22 +0900
Subject: [busybox:00323] Re: [PATCH 4/8] busybox -- libselinux utilities
	applets
In-Reply-To: <20070131140419.GA11967@aon.at>
References: <45B8C039.10907@kaigai.gr.jp> <45B8C244.7040609@kaigai.gr.jp>
	<200701270059.34996.vda.linux@googlemail.com>
	<45BDFF61.3050604@kaigai.gr.jp> <20070130092817.GA32212@aon.at>
	<45C087FB.7000007@ak.jp.nec.com> <20070131140419.GA11967@aon.at>
Message-ID: <45C17E36.9080104@ak.jp.nec.com>

Bernhard, Thanks for your comments.

Bernhard Fischer wrote:
> On Wed, Jan 31, 2007 at 09:13:47PM +0900, KaiGai Kohei wrote:
>> Bernhard, Thanks for your comments.
>>
>> The attached patch fixes following items:
>> - avcstat and togglesebool applet were removed
>> - xis_selinux_enabled() was added at libbb/xfuncs.c
>> - unneccesary headers were removed.
>> - bb_error_msg_and_die() + strerror() were replaced
>>  with bb_perror_msg_and_die()
>> - "Selinux Utilities" at menuconfig got dependency with CONFIG_SELINUX
>> - some cleanups.
>>
> [snip]
>> Index: sebusybox-libselinux-0131/libbb/xfuncs.c
>> ===================================================================
>> --- sebusybox-libselinux-0131/libbb/xfuncs.c	(revision 17684)
>> +++ sebusybox-libselinux-0131/libbb/xfuncs.c	(working copy)
>> @@ -574,6 +574,17 @@
>> 		bb_perror_msg_and_die("can't stat '%s'", name);
>> }
>>
>> +// xis_selinux_enabled() - die if SELinux is disabled.
>> +void xis_selinux_enabled(void)
>> +{
>> +#ifdef CONFIG_SELINUX
> 
> Please rather use #if ENABLE_SELINUX

OK, Fixed.

>> +	if (!is_selinux_enabled())
>> +		bb_error_msg_and_die("SELinux is disabled");
>> +#else
>> +	bb_error_msg_and_die("SELinux support is disabled");
>> +#endif
>> +}

It have a possibility to print incorrect message when is_selinux_enabled()
return -1. It may happen when libselinux could not open "/proc/filesystem"
due to resource limitation and so on.

>> /* It is perfectly ok to pass in a NULL for either width or for
>>  * height, in which case that value will not be set.  */
>> int get_terminal_width_height(const int fd, int *width, int *height)
>> Index: sebusybox-libselinux-0131/Makefile
>> ===================================================================
>> --- sebusybox-libselinux-0131/Makefile	(revision 17684)
>> +++ sebusybox-libselinux-0131/Makefile	(working copy)
>> @@ -442,6 +442,7 @@
>> 		networking/udhcp/ \
>> 		procps/ \
>> 		runit/ \
>> +		selinux/ \
>> 		shell/ \
>> 		sysklogd/ \
>> 		util-linux/ \
>> Index: sebusybox-libselinux-0131/include/libbb.h
>> ===================================================================
>> --- sebusybox-libselinux-0131/include/libbb.h	(revision 17684)
>> +++ sebusybox-libselinux-0131/include/libbb.h	(working copy)
>> @@ -571,6 +571,7 @@
>> extern void renew_current_security_context(void);
>> extern void set_current_security_context(security_context_t sid);
>> #endif
>> +extern void xis_selinux_enabled(void);
>> extern int restricted_shell(const char *shell);
>> extern void setup_environment(const char *shell, int loginshell, int changeenv, const struct passwd *pw);
>> extern int correct_password(const struct passwd *pw);
>> Index: sebusybox-libselinux-0131/include/usage.h
>> ===================================================================
>> --- sebusybox-libselinux-0131/include/usage.h	(revision 17684)
>> +++ sebusybox-libselinux-0131/include/usage.h	(working copy)
>> @@ -1013,6 +1013,9 @@
>>        "	-6	When using port/proto only search IPv6 space\n" \
>>        "	-SIGNAL	When used with -k, this signal will be used to kill"
>>
>> +#define getenforce_trivial_usage
>> +#define getenforce_full_usage
>> +
>> #define getopt_trivial_usage \
>>        "[OPTIONS]..."
>> #define getopt_full_usage \
>> @@ -1047,6 +1050,11 @@
>>        " esac\n" \
>>        "done\n"
>>
>> +#define getsebool_trivial_usage \
>> +	"-a or getsebool boolean..."
>> +#define getsebool_full_usage \
>> +	"-a     Show all SELinux booleans."
>> +
>> #define getty_trivial_usage \
>>        "[OPTIONS]... baud_rate,... line [termtype]"
>> #define getty_full_usage \
>> @@ -1896,6 +1904,15 @@
>>        "/dev/hda[0-15]\n"
>> #endif
>>
>> +#define matchpathcon_trivial_usage \
>> +	"[-n] [-N] [-f file_contexts_file] [-p prefix] [-V]"
>> +#define matchpathcon_full_usage \
>> +	"\t-n Do not display path.\n" \
>> +	"\t-N Do not use translations.\n" \
>> +	"\t-f file_context_file Use alternate file_context file\n" \
>> +	"\t-p prefix Use prefix to speed translations\n" \
>> +	"\t-V Verify file context on disk matches defaults"
> 
> This isn't easily readable. Perhaps put some \t\t before the explanation

Did the comment means that the following style is more preferable?
If so, it was fixed.

     "\t-n\tDo not display path.\n" \
     "\t-N\tDo not use translations.\n" \
     "\t-f\tfile_context_file Use alternate file_context file\n" \
     "\t-p\tprefix Use prefix to speed translations\n" \
     "\t-V\tVerify file context on disk matches defaults"

  - snip -

>> ===================================================================
>> --- sebusybox-libselinux-0131/selinux/getenforce.c	(revision 0)
>> +++ sebusybox-libselinux-0131/selinux/getenforce.c	(revision 0)
>> @@ -0,0 +1,33 @@
>> +/*
>> + * getenforce
>> + *
>> + * Based on libselinux 1.33.1
>> + * Port to BusyBox  Hiroshi Shinji <shiroshi at my.email.ne.jp>
>> + *
>> + */
>> +
>> +#include "busybox.h"
>> +
>> +int getenforce_main(int argc, char **argv)
>> +{
>> +	int rc;
>> +
> ->+	rc = is_selinux_enabled();
> ->+	if (rc < 0)
> ->+		bb_error_msg_and_die("is_selinux_enabled() failed");
> 
> That's exactly the place where you should use xis_selinux_enabled(). It
> obviously has to return an int due to this :)
> 
> 	xis_selinux_enabled();

It prints different message.
getenforce have to print "Disabled", when SELinux is disabled.
But xis_selinux_enabled() print "SELinux is disabled".

If shell script refers the output, it easily become a incompatibility
between up-streamed getenforce and busybox's one.

> ->+	if (rc == 1) {
>> +		rc = security_getenforce();
>> +		if (rc < 0)
>> +			bb_error_msg_and_die("getenforce() failed");
>> +
>> +		if (rc)
>> +			puts("Enforcing");
>> +		else
>> +			puts("Permissive");
> ->+	} else {
> ->+		puts("Disabled");
> ->+	}
>> +
>> +	return 0;
>> +}
>> Index: sebusybox-libselinux-0131/selinux/selinuxenabled.c
>> ===================================================================
>> --- sebusybox-libselinux-0131/selinux/selinuxenabled.c	(revision 0)
>> +++ sebusybox-libselinux-0131/selinux/selinuxenabled.c	(revision 0)
>> @@ -0,0 +1,13 @@
>> +/*
>> + * selinuxenabled
>> + * 
>> + * Based on libselinux 1.33.1
>> + * Port to BusyBox  Hiroshi Shinji <shiroshi at my.email.ne.jp>
>> + *
>> + */
>> +#include "busybox.h"
>> +
>> +int selinuxenabled_main(int argc, char **argv)
>> +{
>> +	return !is_selinux_enabled();
>> +}
>> Index: sebusybox-libselinux-0131/selinux/getsebool.c
>> ===================================================================
>> --- sebusybox-libselinux-0131/selinux/getsebool.c	(revision 0)
>> +++ sebusybox-libselinux-0131/selinux/getsebool.c	(revision 0)
>> @@ -0,0 +1,73 @@
>> +/*
>> + * getsebool
>> + *
>> + * Based on libselinux 1.33.1
>> + * Port to BusyBox  Hiroshi Shinji <shiroshi at my.email.ne.jp>
>> + *
>> + */
>> +
>> +#include "busybox.h"
>> +
>> +#define GETSEBOOL_OPT_ALL	1
>> +
>> +int getsebool_main(int argc, char **argv)
>> +{
>> +	int i, rc = 0, active, pending, len = 0;
>> +	char **names;
>> +	unsigned long opt;
>> +
>> +	opt = getopt32(argc, argv, "a");
>> +
>> +	xis_selinux_enabled();
>> +
>> +	if (opt & GETSEBOOL_OPT_ALL) {
>> +		if (argc > 2)
>> +			bb_show_usage();
>> +
>> +		rc = security_get_boolean_names(&names, &len);
>> +		if (rc)
>> +			bb_perror_msg_and_die("cannot get boolean names: ");
>> +
>> +		if (!len) {
>> +			puts("No booleans");
>> +			return 0;
>> +		}
>> +	}
>> +
>> +	if (!len) {
>> +		if (argc < 2)
>> +			bb_show_usage();
>> +		len = argc - 1;
>> +		names = xmalloc(sizeof(char *) * len);
>> +		for (i = 0; i < len; i++)
>> +			names[i] = xstrdup(argv[i + 1]);
>> +	}
> 
> I still think that the whole applet above can be written smaller.
> 
> Perhaps you can reuse i instead of "opt" without a size penalty?
> Also, var & val is bloat there, i guess. Smaller if you just
> if (i) { /* GETSEBOOL_OPT_ALL set */

I think what 'i' holds an option bitmask is not obviously to understand.
It should not be used as an alternative of 'opt'.

I modified only a point where '&' operation was removed from
the 'if (...)' block, to reduce the space of constant.

>> +
>> +	for (i = 0; i < len; i++) {
>> +		active = security_get_boolean_active(names[i]);
>> +		if (active < 0) {
>> +			bb_error_msg("error getting active value for %s", names[i]);
>> +			rc = -1;
>> +			goto out;
>> +		}
>> +		pending = security_get_boolean_pending(names[i]);
>> +		if (pending < 0) {
>> +			bb_error_msg("error getting pending value for %s", names[i]);
>> +			rc = -1;
>> +			goto out;
>> +		}
>> +		printf("%s --> %s", names[i], (active ? "on" : "off"));
>> +		if (pending != active)
>> +			printf(" pending: %s", (pending ? "on" : "off"));
>> +		putchar('\n');
>> +	}
>> +
>> +      out:
> 
> Please put this at the start of the line as it's easier to find labels
> there.

OK, Fixed.

>> +	if (ENABLE_FEATURE_CLEAN_UP) {
>> +		for (i = 0; i < len; i++)
>> +			free(names[i]);
>> +		free(names);
>> +	}
>> +
>> +	return rc;
>> +}
> [snip Kbuild and make stuff which is ok]
>> Index: sebusybox-libselinux-0131/selinux/matchpathcon.c
>> ===================================================================
>> --- sebusybox-libselinux-0131/selinux/matchpathcon.c	(revision 0)
>> +++ sebusybox-libselinux-0131/selinux/matchpathcon.c	(revision 0)
>> @@ -0,0 +1,98 @@
>> +/* matchpathcon  -  get the default security context for the specified
>> + *                  path from the file contexts configuration.
>> + *                  based on libselinux-1.32
>> + * Port to busybox: KaiGai Kohei <kaigai at kaigai.gr.jp>
>> + *
>> + */
>> +#include "busybox.h"
>> +
>> +static int printmatchpathcon(char *path, int header)
>> +{
>> +	char *buf;
>> +	int rc = matchpathcon(path, 0, &buf);
>> +	if (rc < 0) {
>> +		fprintf(stderr, "matchpathcon(%s) failed: %s\n",
>> +			path, strerror(errno));
>> +		return 1;
>> +	}
> 
> Nah.. Please fix. (bb_perror_msg_and_die("%s", path);)

Dying here is not a compatible behavior.
I replaced fprintf() + strerror() by bb_perror_mag() without '_and_die()'.

>> +	if (header)
>> +		printf("%s\t%s\n", path, buf);
>> +	else
>> +		printf("%s\n", buf);
>> +
>> +	freecon(buf);
>> +	return 0;
>> +}
>> +
>> +#define MATCHPATHCON_OPT_NOT_PRINT	(1<<0)	/* -n */
>> +#define MATCHPATHCON_OPT_NOT_TRANS	(1<<1)	/* -N */
>> +#define MATCHPATHCON_OPT_FCONTEXT	(1<<2)	/* -f */
>> +#define MATCHPATHCON_OPT_PREFIX		(1<<3)	/* -p */
>> +#define MATCHPATHCON_OPT_VERIFY		(1<<4)	/* -V */
>> +
>> +int matchpathcon_main(int argc, char **argv)
>> +{
>> +	int i;
>> +	int header = 1;
>> +	int verify = 0;
>> +	int notrans = 0;
>> +	int error = 0;
> 
> It's very likely smaller to use one (smallu)int and mask those bits -- or use
> opts or remove opts altogether and use option_mask32. You need to see
> which one creates smaller code.
> 
>> +	unsigned long opts;
> 
> See above.

Are you saying to re-define the above variables as 'char' ?
Its effect is a bit unclear for me, but I replaced it with 'char'.

>> +	char *fcontext, *prefix;
>> +
> ->+	if (argc < 2)
> ->+		bb_show_usage();
>> +
>> +	opt_complementary = "?:f--p:p--f";
> 
> from libbb/getopt32.c:
>  "-N"   A dash as the first char in a opt_complementary group followed
>         by a single digit (0-9) means that at least N non-option
>         arguments must be present on the command line
> 
> so we want (don't need '?', i think):
> 	opt_complementary = "-1:f--p:p--f";

Thanks for this information.
I removed 'if (argc < 2) ...' and adopted the above opt_complementary.

>> +	opts = getopt32(argc, argv, "nNf:p:V", &fcontext, &prefix);
>> +
>> +	if (opts & MATCHPATHCON_OPT_NOT_PRINT)
>> +		header = 0;
>> +	if (opts & MATCHPATHCON_OPT_NOT_TRANS) {
>> +		notrans = 1;
>> +		set_matchpathcon_flags(MATCHPATHCON_NOTRANS);
>> +	}
>> +	if (opts & MATCHPATHCON_OPT_FCONTEXT) {
>> +		if (matchpathcon_init(fcontext))
>> +			bb_error_msg_and_die("error while processing %s: %s",
>> +					     fcontext, errno ? strerror(errno) : "invalid");
> bb_perror_msg_and_die

OK, Fixed.

>> +	}
>> +	if (opts & MATCHPATHCON_OPT_PREFIX) {
>> +		if (matchpathcon_init_prefix(NULL, prefix))
>> +			bb_error_msg_and_die("error while processing %s:  %s",
>> +					     prefix, errno ? strerror(errno) : "invalid");
> bb_perror_msg_and_die

OK, Fixed

>> +	}
>> +	if (opts & MATCHPATHCON_OPT_VERIFY)
>> +		verify = 1;
>> +
>> +	for (i = optind; i < argc; i++) {
>> +		security_context_t con;
>> +		int rc;
> 
> Is caching argv[i] here smaller?

add 'char *path = argv[i]' here and replace argv[i] with path to avoid
a iteration of indirect reference.

>> +
>> +		if (!verify) {
>> +			error += printmatchpathcon(argv[i], header);
>> +			continue;
>> +		}
>> +
>> +		if (selinux_file_context_verify(argv[i], 0)) {
>> +			printf("%s verified.\n", argv[i]);
>> +			continue;
>> +		}
>> +
>> +		if (notrans)
>> +			rc = lgetfilecon_raw(argv[i], &con);
>> +		else
>> +			rc = lgetfilecon(argv[i], &con);
>> +
>> +		if (rc >= 0) {
>> +			printf("%s has context %s, should be ", argv[i], con);
>> +			error += printmatchpathcon(argv[i], 0);
>> +			freecon(con);
>> +		} else {
>> +			printf("actual context unknown: %s, should be ", strerror(errno));
>> +			error += printmatchpathcon(argv[i], 0);
>> +		}
>> +	}
>> +	matchpathcon_fini();
>> +	return error;
>> +}
>> Index: sebusybox-libselinux-0131/selinux/setenforce.c
>> ===================================================================
>> --- sebusybox-libselinux-0131/selinux/setenforce.c	(revision 0)
>> +++ sebusybox-libselinux-0131/selinux/setenforce.c	(revision 0)
>> @@ -0,0 +1,33 @@
>> +/*
>> + * setenforce
>> + *
>> + * Based on libselinux 1.33.1
>> + * Port to BusyBox  Hiroshi Shinji <shiroshi at my.email.ne.jp>
>> + *
>> + */
>> +
>> +#include "busybox.h"
>> +
>> +int setenforce_main(int argc, char **argv)
>> +{
>> +	int rc = 0;
>> +	if (argc != 2)
>> +		bb_show_usage();
>> +
>> +	xis_selinux_enabled();
>> +
>> +	if ((argv[1][0] == '0' || argv[1][0] == '1') && argv[1][1] == '\0') {
>> +		rc = security_setenforce(atoi(argv[1]));
>> +	} else {
>> +		if (strcasecmp(argv[1], "enforcing") == 0) {
>> +			rc = security_setenforce(1);
>> +		} else if (strcasecmp(argv[1], "permissive") == 0) {
> 
> rc = security_setenforce(index_in_substr_array);
> Isn't case-insensitive, but would suffice IMO and would make that applet
> considerably smaller. What do you think?

In the attached one, I add 'setenforce_options' array as you say.
Do you think it is a preferable way?

>> +			rc = security_setenforce(0);
>> +		} else
>> +			bb_show_usage();
>> +	}
>> +	if (rc < 0)
>> +		bb_perror_msg_and_die("setenforce() failed : ");
>> +
>> +	return 0;
>> +}

Thanks,
-- 
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai at ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-libselinux.v4.patch
Type: text/x-patch
Size: 15535 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/69420f0b/attachment-0002.bin 

From vda.linux at googlemail.com  Thu Feb  1 22:15:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:15:51 +0100
Subject: version 1.4.1
In-Reply-To: <45C19F00.4060903@marcant.net>
References: <45C19F00.4060903@marcant.net>
Message-ID: <200702012315.51620.vda.linux@googlemail.com>

On Thursday 01 February 2007 09:04, Markus Wigge wrote:
> Hi,
> 
> I'm a little bit confused, I recently read about busybox 1.4.1 and found 
> an archive I could download but there is no tag for it in subversion and 
> it is not announced on the web?
> 
> Is this an official version or what?

I added relevant text in news.html in busybox cvs and expected it
to appear at busybox.net after a day or so, but it didn't.
(I planned to announce it after it is there)

I was a bit busy and didn't ask people why it is so.

Anyway, 1.4.1 is 1.4.0 plus these:

http://busybox.net/downloads/fixes-1.4.0/

--
vda


From vda.linux at googlemail.com  Thu Feb  1 22:21:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:21:40 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
Message-ID: <200702012321.40884.vda.linux@googlemail.com>

On Thursday 01 February 2007 07:26, Brion Finlay wrote:
> This seems like it should be a simple question that other people have had
> problems with, but I cannot get Busybox to build.  I have tried google-ing
> for similar problems, searching the mail archives, and reading the FAQs and
> all of the documentation, but I cannot figure out what is going on.
> 
> I am using a fairly fresh install of Ubuntu 6.1, and I have installed enough
> of the development packages to build a custom kernel.  (I mention this
> because Ubuntu does not preinstall many development packages, so it is
> possible I am still missing some, but I have installed quite a few.)
> 
> The GCC version is 4.1.2.
> sed is GNU Sed version 4.1.5
>
> Here are the compile problems that I get:
> 
> Busybox 1.4.1
> # make defconfig; make
> 
> ...
> include/bbconfigopts.h:1088: error: missing terminating " character
> (repeated for each line)
> include/bbconfigopts.h:1089: error: expected expression before ';' token
> make[1]: *** [miscutils/bbconfig.o] Error 1
> make: *** [miscutils] Error 2

gcc 4.1.1, glibc 2.4, gnu sed 4.1.5, bbox 1.4.1: 

# make defconfig; make
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/split-include
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  HOSTCC  scripts/kconfig/mconf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf -d Config.in
/.local/tmp/busybox-1.4.1/scripts/defconfig:351:warning: trying to assign nonexistent symbol E2FSCK
/.local/tmp/busybox-1.4.1/scripts/defconfig:354:warning: trying to assign nonexistent symbol MKE2FS
/.local/tmp/busybox-1.4.1/scripts/defconfig:355:warning: trying to assign nonexistent symbol TUNE2FS
/.local/tmp/busybox-1.4.1/scripts/defconfig:356:warning: trying to assign nonexistent symbol E2LABEL
/.local/tmp/busybox-1.4.1/scripts/defconfig:357:warning: trying to assign nonexistent symbol FINDFS
/.local/tmp/busybox-1.4.1/scripts/defconfig:635:warning: symbol value '' invalid for FEATURE_COMMAND_HISTORY
*
* Busybox Configuration
*
*
* Busybox Settings
*
*
* General Configuration
*
See lots more (probably unnecessary) configuration options. (NITPICK) [N/y/?] n
Enable options for full-blown desktop systems (DESKTOP) [N/y/?] n
...
envdir (ENVDIR) [Y/n/?] y
softlimit (SOFTLIMIT) [Y/n/?] y
  SPLIT   include/autoconf.h -> include/config/*
  GEN     include/bbconfigopts.h
  HOSTCC  applets/usage
  GEN     include/usage_compressed.h
  CC      applets/applets.o
  CC      applets/busybox.o
...
  CC      util-linux/switch_root.o
  CC      util-linux/umount.o
  AR      util-linux/lib.a
  LINK    busybox_unstripped

include/bbconfigopts.h from build tree is attached.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bbconfigopts.h
Type: text/x-chdr
Size: 16270 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/6425a36c/attachment-0002.h 

From vda.linux at googlemail.com  Thu Feb  1 22:22:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:22:56 +0100
Subject: Busybox build problem
In-Reply-To: <20070201002140.bfc52cea95091b0fffcb409eab6296ba.9cd207e1ee.wbe@email.secureserver.net>
References: <20070201002140.bfc52cea95091b0fffcb409eab6296ba.9cd207e1ee.wbe@email.secureserver.net>
Message-ID: <200702012322.56287.vda.linux@googlemail.com>

On Thursday 01 February 2007 08:21, akennedy at techmoninc.com wrote:
> 
> > I'm sure it is something wrong with my environment, but I do not know what.  Does anyone have any hints?
> Attempt the build with BuildRoot.  This will install uclibc and a gcc
> that will work with it to build BusyBox.  I've found it VERY difficult
> to build BusyBox with GLibC.

Really?! I do it all the time...

Please report what are the problems.
Provide gcc, glibc version, .config...
--
vda


From vda.linux at googlemail.com  Thu Feb  1 22:36:52 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:36:52 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <1170276931.18296.5.camel@studio>
References: <1170276931.18296.5.camel@studio>
Message-ID: <200702012336.52095.vda.linux@googlemail.com>

On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> The attatched patch adds support for option -user. The arg to -user can
> be either username or uid.
>
> Would be nice if it could be committed.
> Thanks!

+???????????????????????ap->uid = bb_strtoul(arg1, (char **)NULL, 10);

Why you use *strtoul* and then assign it to unsigned *int*?
Why cast?

Otherwise looks ok, applying...
--
vda


From vda.linux at googlemail.com  Thu Feb  1 22:57:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:57:03 +0100
Subject: CGI script and Content-type change in 1.4.0
In-Reply-To: <45C0533A.5000309@lkh-vil.or.at>
References: <45C0533A.5000309@lkh-vil.or.at>
Message-ID: <200702012357.03564.vda.linux@googlemail.com>

On Wednesday 31 January 2007 09:28, Alexander Griesser wrote:
> Hi folks!
> 
> Another thing that broke when upgrading to 1.4.0 is the management
> interface for my thinclients.
> 
> Previously, I used the following command to output a valid HTML header:
> 
> echo 'Content-type: text/html
> 
> 
> <html>
> <head>
> ...'
> 
> Now, with busybox 1.4.0, this doesn't work anymore.
> I get exactly the same output as written above in firefox (IE7 works
> fine).
> 
> I had a look at the changelog and found the following entry:
> 
> || httpd: stop adding our own "Content-type:" to CGI output
> 
> Additionally, I found a cgi-example (httpd_index_cgi_example) inside
> the busybox distribution that suggests do pipe all output generated
> through "dd bs=4k" with the following comment:
> 
> # Pipe thru dd (need to write header as single write(),
> # or else httpd doesn't see "Content-type: text/html"
> # in first read() and decides that it is not html)
> 
> Why is this needed with the current busybox release or are there any
> ways to work around this?

This piping not needed anymore, it has been fixed
after indexer example was addded.

Regarding your script: I must admit I am not a CGI expert,
but maybe you need to echo "HTTP/1.0 200 OK\r\n" first.

I just tested and cgi indexer works (also without piping thru dd),
so at least this cgi example is working.

If you definitely know that CGI should not print "200 OK"
(IOW: that https server process should add that instead),
please give me the URL so that I can educate myself too.

Thanks.
--
vda


From vapier at gentoo.org  Thu Feb  1 23:16:23 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Feb 2007 18:16:23 -0500
Subject: version 1.4.1
In-Reply-To: <200702012315.51620.vda.linux@googlemail.com>
References: <45C19F00.4060903@marcant.net>
	<200702012315.51620.vda.linux@googlemail.com>
Message-ID: <200702011816.24169.vapier@gentoo.org>

On Thursday 01 February 2007, Denis Vlasenko wrote:
> I was a bit busy and didn't ask people why it is so.

looks like svn locks got screwed up ... i cleared them and it should be OK now
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/66ae121a/attachment-0002.pgp 

From vda.linux at googlemail.com  Thu Feb  1 23:14:21 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 00:14:21 +0100
Subject: extra targets in busybox Makefile
In-Reply-To: <200702010312.34740.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
	<200702010312.34740.vapier@gentoo.org>
Message-ID: <200702020014.21335.vda.linux@googlemail.com>

On Thursday 01 February 2007 09:12, Mike Frysinger wrote:
> On Monday 29 January 2007, Denis Vlasenko wrote:
> > I propose to simply never define anything "modular"
> >
> > If people run "make modules",  well, that's their problems.
> 
> there are a bunch of env config settings which can cause problems ... what i'm 
> looking at is busybox gets integrated into a larger build system which 
> includes a kernel and next thing i know, busybox is failing because it's 
> trying to generate depmod and build modules

Huh, if this is really getting problematic,
then feel free to chainsaw "modular" support off.

Or just rename makefile targets ('modules' -> 'dont_use_me__modules')
if you don't want to spend too much time on things which
do not materially improve generated code.
--
vda


From strange at nsk.no-ip.org  Thu Feb  1 23:44:35 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Thu, 1 Feb 2007 23:44:35 +0000
Subject: CGI script and Content-type change in 1.4.0
In-Reply-To: <200702012357.03564.vda.linux@googlemail.com>
References: <45C0533A.5000309@lkh-vil.or.at>
	<200702012357.03564.vda.linux@googlemail.com>
Message-ID: <20070201234435.GA6908@nsk.no-ip.org>

On Thu, Feb 01, 2007 at 11:57:03PM +0100, Denis Vlasenko wrote:
> If you definitely know that CGI should not print "200 OK"
> (IOW: that https server process should add that instead),
> please give me the URL so that I can educate myself too.

Links with specs:
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html#7.0

Basically, there are two different types of CGI scripts (the method to
distinguish between the two types is implementation defined; the first
link defines cgi prefix of nph-):
1. non-parsed header (NPH) output (support not required)
  - all output is sent as is to the client (full HTTP response is
    created by the script)

2. parsed header output (support required)
  - one of the following headers must be present, and will be parsed by
    the server (not limited to one, but no repetitions are allowed):
    * Content-type: the Internet Media Type of the entity body,
       which is to be sent unmodified to the client.
    * Location: specify to the server that the script is
       returning a reference to a document rather than an actual
       document:
      - absolute uri: Location: http://.... -> 302 redirect (unless
        Status also defined);
      - or path: Location: /path/... -> server internally processes the
        redirect and the output is as if the new location was directly
        called (POST and other requests may lose the request body).
    * Status: indicates to the server what status code the server MUST
      use in the response message: Status: [0-9]{3} reason-phrase

  - output consists of header plus body (body may be null):
    * if body, Content-type is mandatory
    * else one of Location or Status is mandatory

  - headers are specified on a single line
  
Also, #8.1 on the second link, Requirements for Servers, should be of
interest.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070201/48863634/attachment-0002.pgp 

From vda.linux at googlemail.com  Fri Feb  2 01:14:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 02:14:33 +0100
Subject: busybox 1.4.1 build failure
In-Reply-To: <20070201140323.4dc138fa.aurel@gnuage.org>
References: <20070201140323.4dc138fa.aurel@gnuage.org>
Message-ID: <200702020214.33849.vda.linux@googlemail.com>

On Thursday 01 February 2007 14:03, Aurelien Jacobs wrote:
> Hi,
> 
> When upgrading from bb-1.4.0 to bb-1.4.1 I got the following error
> (gcc-4.1.1, uClibc for i386 target):
> 
>   CC      networking/interface.o
> cc1: warnings being treated as errors
> networking/interface.c: In function 'in_ether':
> networking/interface.c:853: warning: pointer targets in assignment differ in signedness
> make[1]: *** [networking/interface.o] Error 1
> make: *** [networking] Error 2
> 
> The attached patch fixes it.

thanks, applied
--
vda


From somlo at cmu.edu  Fri Feb  2 01:23:04 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 20:23:04 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702012308.20367.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
Message-ID: <20070202012303.GA23689@hedwig.net.cmu.edu>

On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> You can overflow existing->data[OPT_LEN].

Yes, by exactly 1 :)

>         /* add it to an existing option */

...

>                 if (existing->data[OPT_LEN] + length <= 255) {
>                         existing->data = xrealloc(existing->data,
>                                         existing->data[OPT_LEN] + length + 3);
>                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {
>                                 if (existing->data[OPT_LEN] + length >= 255)
>                                         return;

You already know that's never going to be more than 255 (see the if
statement at the beginning of the quote :) What you don't know is
whether the extra space I want to add will make it 256 instead of 255.
So, maybe do this:

>                               if (existing->data[OPT_LEN] + length + 1>= 255)
                                                                     ^^^^^
>                                         return;

The other choice would be to do this:

>                 if (existing->data[OPT_LEN] + length <= 254) {
                                                        ^^^^^^^
>                         existing->data = xrealloc(existing->data,
>                                         existing->data[OPT_LEN] + length + 3);
>                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {

and drop the second check entirely. I'd almost vote for this, but then
we'd be depriving non-string options of one potential byte. Makes the
code cleaner, though... I guess you're the decider :)

Otherwise, it compiles cleanly, and looks ok to me. Won't be able to
test it until some 15 hours from now, though, since I'll have to
physically hook up a dhcp client to the box which is in my office...

Cheers,
Gabriel


From vda.linux at googlemail.com  Fri Feb  2 01:55:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 02:55:13 +0100
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <20070202012303.GA23689@hedwig.net.cmu.edu>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
	<20070202012303.GA23689@hedwig.net.cmu.edu>
Message-ID: <200702020255.13687.vda.linux@googlemail.com>

On Friday 02 February 2007 02:23, Gabriel L. Somlo wrote:
> On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> > You can overflow existing->data[OPT_LEN].
> 
> Yes, by exactly 1 :)
> 
> >         /* add it to an existing option */
> 
> ...
> 
> >                 if (existing->data[OPT_LEN] + length <= 255) {
> >                         existing->data = xrealloc(existing->data,
> >                                         existing->data[OPT_LEN] + length + 3);
> >                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {
> >                                 if (existing->data[OPT_LEN] + length >= 255)
> >                                         return;
> 
> You already know that's never going to be more than 255 (see the if
> statement at the beginning of the quote :) What you don't know is
> whether the extra space I want to add will make it 256 instead of 255.
> So, maybe do this:
> 
> >                               if (existing->data[OPT_LEN] + length + 1>= 255)
>                                                                      ^^^^^
> >                                         return;

No. My check is really

		if (existing->data[OPT_LEN] + length == 255)

that is, "is it exactly 255? that wont fit because of +1!"
but I use >= because of sheer paranoia. ;)

--
vda


From somlo at cmu.edu  Fri Feb  2 03:21:42 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 22:21:42 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702020255.13687.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
	<20070202012303.GA23689@hedwig.net.cmu.edu>
	<200702020255.13687.vda.linux@googlemail.com>
Message-ID: <20070202032142.GA24474@hedwig.net.cmu.edu>

On Fri, Feb 02, 2007 at 02:55:13AM +0100, Denis Vlasenko wrote:
> 
> No. My check is really
> 
> 		if (existing->data[OPT_LEN] + length == 255)
> 
> that is, "is it exactly 255? that wont fit because of +1!"
> but I use >= because of sheer paranoia. ;)

Heh... You're right, of course...

That's why I like using computers -- you only have to get this
crap right once, and won't keep having to worry about spotting
that equal sign after the > sign... Or something... :) :)

Cheers,
Gabriel


From natanael.copa at gmail.com  Fri Feb  2 07:09:50 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 02 Feb 2007 08:09:50 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <200702012336.52095.vda.linux@googlemail.com>
References: <1170276931.18296.5.camel@studio>
	<200702012336.52095.vda.linux@googlemail.com>
Message-ID: <1170400190.28276.11.camel@localhost>

On Thu, 2007-02-01 at 23:36 +0100, Denis Vlasenko wrote:
> On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> > The attatched patch adds support for option -user. The arg to -user can
> > be either username or uid.
> >
> > Would be nice if it could be committed.
> > Thanks!
> 
> +                       ap->uid = bb_strtoul(arg1, (char **)NULL, 10);
> 
> Why you use *strtoul* and then assign it to unsigned *int*?

You are right. The uid type should ofcourse be uid_t and not int.

The xuname2uid() returns a long (why not uid_t?) so i think I could use
strtol() instead of bb_strtou().

> Why cast?

When I was looking for a atoi with error detection in libbb I found that
the atoi man-page states that the atoi behaviour is the same as

              strtol(nptr, (char **)NULL, 10);

The cast comes from there.

Sorry for the type confusion. New patch is attatched.

> Otherwise looks ok, applying...

Thanks!

> --
> vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-uid_t.patch
Type: text/x-patch
Size: 886 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070202/bddb1e2f/attachment-0002.bin 

From somlo at cmu.edu  Fri Feb  2 14:25:53 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Fri, 2 Feb 2007 09:25:53 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702012308.20367.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
Message-ID: <20070202142553.GA8714@hedwig.net.cmu.edu>

On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> The below version should fix that (and even mostly fit
> into 80 column displays). Can you try it?

Tried it, and it looks like it's working fine.

Thanks,
Gabriel


From natanael.copa at gmail.com  Fri Feb  2 15:01:30 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 02 Feb 2007 16:01:30 +0100
Subject: [PATCH] find ! ... (operator -not)
Message-ID: <1170428490.28276.35.camel@localhost>

Hi,

Attatched is a patch for support of the '!' operator for find.

I created another macro ALLOC_TEST for actions that can be inverted with
'!'. They are not really actions (like -print) but tests (like -name).

It should not touch anything unless you have enabled the
FEATURE_FIND_NOT config option.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-operator-not.patch
Type: text/x-patch
Size: 5665 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070202/a13eb967/attachment-0002.bin 

From mcross at irobot.com  Fri Feb  2 17:24:21 2007
From: mcross at irobot.com (Cross, Matthew)
Date: Fri, 2 Feb 2007 12:24:21 -0500
Subject: Revisiting an old losetup bug (bug 609)
Message-ID: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>

I have run into this old bug.  I'm using an old version of busybox
(1.1.3) on an i.MX21 embedded system (it's ARM based).  I understand
what's going on and how it could be fixed but I'm not sure if it's a
busybox bug or a problem with the toolchain.  Looking at the code, the
problem is still in the latest source.  Let me explain:
 
In my case, I'm using a "BSP" provided by Freescale for this chip.  They
provide a pre-built toolchain (binutils, gcc, glibc).  When the
toolchain was built, kernel headers from a 2.6.11 kernel were used by
glibc.  The kernel that is running on the board is a heavily patched
2.4.20 kernel.  Therefore, when libbb/loop.c is compiled it sees a 2.6
kernel, and so uses LOOP_GET_STATUS64 for BB_LOOP_GET_STATUS - note that
this is ioctl 0x4c05 (if you look in the strace output in the log of bug
609 you see this ioctl there, so it looks like the original submitter
had a similar problem).  However, the loop driver in 2.4 kernels does
not support the 64 bit variants of these ioctl's, only the 32 bit
LOOP_GET_STATUS (which is 0x4c03).  When I hack loop.c to use the 2.4
version of the code, it works on my system properly, so clearly the 2.4
kernel supports the loop device fine.
 
Busybox could be modified to work in this scenario by trying the 32 bit
version of the ioctl if the 64 bit version fails, but I don't know if
that goes against the low-bloat philosophy of busybox.  Does the busybox
dev team feel that this is a problem with the build system, or should a
busybox built with headers from a 2.6 kernel work with a 2.4 kernel?
The vendor I am working from has argued that userland applications
should not depend on kernel headers and that this toolchain has been
working for several years with this processor and kernel.
 
    -Matt
 
--
Matt Cross
Senior Lead Software Engineer
iRobot Corporation
63 South Avenue, Burlington, MA 01803
781-418-3373 (ph)
781-345-0201 (fax)
mcross at irobot.com
www.irobot.com <http://www.irobot.com/> 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070202/6186fc96/attachment-0001.htm 

From rob at landley.net  Fri Feb  2 19:58:58 2007
From: rob at landley.net (Rob Landley)
Date: Fri, 2 Feb 2007 14:58:58 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702010312.34740.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
	<200702010312.34740.vapier@gentoo.org>
Message-ID: <200702021458.59394.rob@landley.net>

On Thursday 01 February 2007 3:12 am, Mike Frysinger wrote:
> On Monday 29 January 2007, Denis Vlasenko wrote:
> > I propose to simply never define anything "modular"
> >
> > If people run "make modules",  well, that's their problems.
> 
> there are a bunch of env config settings which can cause problems ... what 
i'm 
> looking at is busybox gets integrated into a larger build system which 
> includes a kernel and next thing i know,

What do you mean by "integrated into a larger build system"?  Busybox's 
menuconfig is not the same as the kernel's (version skew among other things).  
If you write your own Config and use your own menuconfig infrastructure, you 
have to debug your new code as well, correct?

> busybox is failing because it's  
> trying to generate depmod and build modules

Because your "larger build system" (which we didn't write) is calling make 
modules on busybox?

What exactly is going on here?

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery


From vda.linux at googlemail.com  Fri Feb  2 20:17:30 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 21:17:30 +0100
Subject: Revisiting an old losetup bug (bug 609)
In-Reply-To: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>
References: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>
Message-ID: <200702022117.30601.vda.linux@googlemail.com>

On Friday 02 February 2007 18:24, Cross, Matthew wrote:
> In my case, I'm using a "BSP" provided by Freescale for this chip.  They
> provide a pre-built toolchain (binutils, gcc, glibc).  When the
> toolchain was built, kernel headers from a 2.6.11 kernel were used by
> glibc.  The kernel that is running on the board is a heavily patched
> 2.4.20 kernel.  Therefore, when libbb/loop.c is compiled it sees a 2.6
> kernel, and so uses LOOP_GET_STATUS64 for BB_LOOP_GET_STATUS - note that
> this is ioctl 0x4c05 (if you look in the strace output in the log of bug
> 609 you see this ioctl there, so it looks like the original submitter
> had a similar problem).  However, the loop driver in 2.4 kernels does
> not support the 64 bit variants of these ioctl's, only the 32 bit
> LOOP_GET_STATUS (which is 0x4c03).  When I hack loop.c to use the 2.4
> version of the code, it works on my system properly, so clearly the 2.4
> kernel supports the loop device fine.
>  
> Busybox could be modified to work in this scenario by trying the 32 bit
> version of the ioctl if the 64 bit version fails, but I don't know if
> that goes against the low-bloat philosophy of busybox.

It depents on the amount of bloat. If it is something like 32 bytes
it's ok. If significantly bigger, maybe create a CONFIG_xxx for it,
or sweep it under CONFIG_DESKTOP if you are lazy.

Please, by all means, send your patch to list. Thanks.
--
vda


From vda.linux at googlemail.com  Fri Feb  2 21:19:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 22:19:11 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <1170400190.28276.11.camel@localhost>
References: <1170276931.18296.5.camel@studio>
	<200702012336.52095.vda.linux@googlemail.com>
	<1170400190.28276.11.camel@localhost>
Message-ID: <200702022219.11973.vda.linux@googlemail.com>

On Friday 02 February 2007 08:09, Natanael Copa wrote:
> On Thu, 2007-02-01 at 23:36 +0100, Denis Vlasenko wrote:
> > On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> > > The attatched patch adds support for option -user. The arg to -user can
> > > be either username or uid.
> > >
> > > Would be nice if it could be committed.
> > > Thanks!
> > 
> > +                       ap->uid = bb_strtoul(arg1, (char **)NULL, 10);
> > 
> > Why you use *strtoul* and then assign it to unsigned *int*?
> 
> You are right. The uid type should ofcourse be uid_t and not int.

Ideally, yes.

> The xuname2uid() returns a long (why not uid_t?) so i think I could use
> strtol() instead of bb_strtou().

strtol treats really bizarre things like "      -" as 'numbers'.
That's why we have bb_strtoXXX.
--
vda


From vda.linux at googlemail.com  Fri Feb  2 21:43:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 22:43:56 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <1170428490.28276.35.camel@localhost>
References: <1170428490.28276.35.camel@localhost>
Message-ID: <200702022243.56100.vda.linux@googlemail.com>

On Friday 02 February 2007 16:01, Natanael Copa wrote:
> Hi,
> 
> Attatched is a patch for support of the '!' operator for find.
> 
> I created another macro ALLOC_TEST for actions that can be inverted with
> '!'. They are not really actions (like -print) but tests (like -name).
> 
> It should not touch anything unless you have enabled the
> FEATURE_FIND_NOT config option.

parse_params():
invert_flag is never reset to 0. This must be a bug -
"not" shouldn't be applied to the second -name here, I think
(did not check it versus GNU find, tho...):
find ! -name '*.a' -o -name '*.b'


Now, to more cosmetic matters:


+#define LOGIC_XOR(a, b) ( (!(a)) != (!(b)) )
                         ACTS(print)
                         ACTS(name,  const char *pattern;)
 USE_FEATURE_FIND_PRINT0(ACTS(print0))
@@ -120,7 +124,13 @@
                cur_action = -1;
                do {
                        ap = app[++cur_action];
-               } while (ap && (rc = ap->f(fileName, statbuf, ap)));
+               } while (ap &&
+#if ENABLE_FEATURE_FIND_NOT
+                       (rc = LOGIC_XOR(ap->f(fileName, statbuf, ap), ap->invert))
+#else
+                       (rc = ap->f(fileName, statbuf, ap))
+#endif
+               );


This is obscure. I propose to do this instead - much easier to read:


        while ((app = appp[++cur_group])) {
                cur_action = -1;
-               do {
+               while (1) {
                        ap = app[++cur_action];
-               } while (ap && (rc = ap->f(fileName, statbuf, ap)));
-               if (!ap) {
-                       /* all actions in group were successful */
-                       break;
+                       if (!ap) {
+                               /* all actions in group were successful */
+                               return rc;
+                       }
+                       rc = ap->f(fileName, statbuf, ap);
+#if ENABLE_FEATURE_FIND_NOT
+                       if (ap->invert) rc = !rc;
+#endif
+                       if (!rc) return rc;
                }
        }
        return rc;



+#if ENABLE_FEATURE_FIND_NOT
+               else if (strcmp(arg, "!") == 0
+                       USE_DESKTOP(|| strcmp(arg, "-not") == 0)
+               ) invert_flag = 1;
+#endif

Don't torture code reader please :) How about this?

+#if ENABLE_FEATURE_FIND_NOT
+               else if (strcmp(arg, "!") == 0
+                       USE_DESKTOP(|| strcmp(arg, "-not") == 0)
+               ) {
+                       invert_flag = 1;
+               }
+#endif



        action* alloc_action(int sizeof_struct, action_fp f
                USE_FEATURE_FIND_NOT(, int invert)
        )
        {
                action *ap;
                appp[cur_group] = xrealloc(appp[cur_group], (cur_action+2) * sizeof(*appp));
                appp[cur_group][cur_action++] = ap = xmalloc(sizeof_struct);
                appp[cur_group][cur_action] = NULL;
                ap->f = f;
                USE_FEATURE_FIND_NOT( ap->invert = invert; )
                return ap;
        }
#define ALLOC_ACTION(name) (action_##name*)alloc_action(sizeof(action_##name), (action_fp) func_##name USE_FEATURE_FIND_NOT(, 0))

#define ALLOC_TEST(name) (action_##name*)alloc_action(sizeof(action_##name), (action_fp) func_##name USE_FEATURE_FIND_NOT(, invert_flag))


You do not need to pass "int invert" to alloc_action. Just use invert_flag
in alloc_action body, and forcefully reset invert_flag = 0 whenever
you are about to do ALLOC_ACTION, like when you handle -print.
(GNU find doesn't error out on "find ! -print", it simply ignores "!").

Care to produce updated patch?
--
vda


From etzvetanov at xceedium.com  Fri Feb  2 23:05:08 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 18:05:08 -0500
Subject: "ls -l" Segmentation fault
Message-ID: <45C3C3A4.9050405@xceedium.com>

Hi all,

I have compiled version 1.4.1 of BusyBox and I have put it on a little 
system for testing.
It is running Linux kernel 2.6.18.1.

If I call "ls -l" in a directory with lots of files (say /dev or even 
/usr/bin) it is pulling Segmentation Fault.
What could be wrong or I am probably not on the same page with you guys...

I tried to search in the mailing list, but I could not find (or I was 
not able to find) any recent complains
-- 
*ET

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070202/1ad4838b/attachment-0001.htm 

From ddaney at avtrex.com  Fri Feb  2 23:18:40 2007
From: ddaney at avtrex.com (David Daney)
Date: Fri, 02 Feb 2007 15:18:40 -0800
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C3A4.9050405@xceedium.com>
References: <45C3C3A4.9050405@xceedium.com>
Message-ID: <45C3C6D0.8020209@avtrex.com>

Evgueni Tzvetanov wrote:
> Hi all,
> 
> I have compiled version 1.4.1 of BusyBox and I have put it on a little 
> system for testing.
> It is running Linux kernel 2.6.18.1.
> 
> If I call "ls -l" in a directory with lots of files (say /dev or even 
> /usr/bin) it is pulling Segmentation Fault.
> What could be wrong or I am probably not on the same page with you guys...
> 

What happens when you run it under gdb?


From etzvetanov at xceedium.com  Sat Feb  3 00:02:21 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 19:02:21 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C6D0.8020209@avtrex.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
Message-ID: <45C3D10D.8010006@xceedium.com>

David Daney wrote:
> Evgueni Tzvetanov wrote:
>> Hi all,
>>
>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>> little system for testing.
>> It is running Linux kernel 2.6.18.1.
>>
>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>> /usr/bin) it is pulling Segmentation Fault.
>> What could be wrong or I am probably not on the same page with you 
>> guys...
>>
>
> What happens when you run it under gdb?
It is a very small environment and I don't have a lot of stuff in the 
system.
But I think it must be a string boundary issue or something really 
small, because when I do "ls" or ls -1, it is not bombing.

I don't have ti time to look at the applet right now, but I may try next 
week. Though I think the owner should take a look at it...
Cheers.







From etzvetanov at xceedium.com  Sat Feb  3 00:49:17 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 19:49:17 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C6D0.8020209@avtrex.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
Message-ID: <45C3DC0D.900@xceedium.com>

David Daney wrote:
> Evgueni Tzvetanov wrote:
>> Hi all,
>>
>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>> little system for testing.
>> It is running Linux kernel 2.6.18.1.
>>
>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>> /usr/bin) it is pulling Segmentation Fault.
>> What could be wrong or I am probably not on the same page with you 
>> guys...
>>
>
> What happens when you run it under gdb?
Even stranger. When I call the command like (if this can help in anyway):
"busybox ls -l" it is not bombing. When I run it as "ls -l" it is bombing.



From questforhappiness at hotmail.com  Sat Feb  3 01:34:30 2007
From: questforhappiness at hotmail.com (none none)
Date: Fri, 02 Feb 2007 17:34:30 -0800
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
Message-ID: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>

Hi there,

My aventail appliances are using busybox as OS.  I checked and find that it 
is not using the new 2007 Daylight Saving Time schedule.  Does anyone know 
if there are patches or instructions to update busybox to accommodate the 
new 2007 Daylight Saving Time change?

Thank you,
Donald.

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline



From vda.linux at googlemail.com  Sat Feb  3 01:47:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 02:47:11 +0100
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>
References: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>
Message-ID: <200702030247.11080.vda.linux@googlemail.com>

On Saturday 03 February 2007 02:34, none none wrote:
> Hi there,
> 
> My aventail appliances are using busybox as OS.  I checked and find that it 
> is not using the new 2007 Daylight Saving Time schedule.  Does anyone know 
> if there are patches or instructions to update busybox to accommodate the 
> new 2007 Daylight Saving Time change?

This is done by libc routines. If it doesn't work for you,
you should update/fix your libc.
--
vda


From brion.finlay at gmail.com  Sat Feb  3 05:14:36 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Fri, 2 Feb 2007 23:14:36 -0600
Subject: Busybox build problem
In-Reply-To: <200702012321.40884.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
Message-ID: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>

Thanks for the responses.  It helped knowing that my gnu compiler/c library
configuration was correct.  It also helped knowing what the
bbconfigopts.hwas supposed to look like.

I did some digging into the problem and found the following.  The immediate
cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
/bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
construction for generating bbconfigopts.h.  This construction contains a
"\n" sequence, which the dash echo command interprets literally.  (See the
attached bbconfigopts.h production to see what happens.)

Linking /bin/sh to /bin/bash resolved this problem and allowed the build to
complete successfully.

The fix that could be made to scripts/mkconfigs in order to work more
generally, be less indirect, and avoid some of the backslash quoting would
be to eliminate the echo "`...`" construction and just execute the command
directly.  That is, change this:

echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
"\\"" $0 "\\\\n\\"";}'`"

to this:

sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
"\\n\"";}'

I tested this change under bash and dash and it works in both shells.


Alternatively, since awk is being invoked anyway, this line could be changed
to just a single line awk invocation to do away with the sed, the grep, and
the echo:

awk '/^#? ?CONFIG_/ {gsub(/\"/,"\\\\\"",$0); print "\"" $0 "\\n\"";}'
$config

I tested this change under bash and dash and it also works in both shells.

I have also attached a patch file to mkconfigs for the single line awk
version.


On 2/1/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Thursday 01 February 2007 07:26, Brion Finlay wrote:
> > This seems like it should be a simple question that other people have
> had
> > problems with, but I cannot get Busybox to build.  I have tried
> google-ing
> > for similar problems, searching the mail archives, and reading the FAQs
> and
> > all of the documentation, but I cannot figure out what is going on.
> >
> > I am using a fairly fresh install of Ubuntu 6.1, and I have installed
> enough
> > of the development packages to build a custom kernel.  (I mention this
> > because Ubuntu does not preinstall many development packages, so it is
> > possible I am still missing some, but I have installed quite a few.)
> >
> > The GCC version is 4.1.2.
> > sed is GNU Sed version 4.1.5
> >
> > Here are the compile problems that I get:
> >
> > Busybox 1.4.1
> > # make defconfig; make
> >
> > ...
> > include/bbconfigopts.h:1088: error: missing terminating " character
> > (repeated for each line)
> > include/bbconfigopts.h:1089: error: expected expression before ';' token
> > make[1]: *** [miscutils/bbconfig.o] Error 1
> > make: *** [miscutils] Error 2
>
> gcc 4.1.1, glibc 2.4, gnu sed 4.1.5, bbox 1.4.1:
>
> # make defconfig; make
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/basic/split-include
>   HOSTCC  scripts/basic/docproc
>   HOSTCC  scripts/kconfig/conf.o
>   HOSTCC  scripts/kconfig/kxgettext.o
>   HOSTCC  scripts/kconfig/mconf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/lex.zconf.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf -d Config.in
> /.local/tmp/busybox-1.4.1/scripts/defconfig:351:warning: trying to assign
> nonexistent symbol E2FSCK
> /.local/tmp/busybox-1.4.1/scripts/defconfig:354:warning: trying to assign
> nonexistent symbol MKE2FS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:355:warning: trying to assign
> nonexistent symbol TUNE2FS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:356:warning: trying to assign
> nonexistent symbol E2LABEL
> /.local/tmp/busybox-1.4.1/scripts/defconfig:357:warning: trying to assign
> nonexistent symbol FINDFS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:635:warning: symbol value ''
> invalid for FEATURE_COMMAND_HISTORY
> *
> * Busybox Configuration
> *
> *
> * Busybox Settings
> *
> *
> * General Configuration
> *
> See lots more (probably unnecessary) configuration options. (NITPICK)
> [N/y/?] n
> Enable options for full-blown desktop systems (DESKTOP) [N/y/?] n
> ...
> envdir (ENVDIR) [Y/n/?] y
> softlimit (SOFTLIMIT) [Y/n/?] y
>   SPLIT   include/autoconf.h -> include/config/*
>   GEN     include/bbconfigopts.h
>   HOSTCC  applets/usage
>   GEN     include/usage_compressed.h
>   CC      applets/applets.o
>   CC      applets/busybox.o
> ...
>   CC      util-linux/switch_root.o
>   CC      util-linux/umount.o
>   AR      util-linux/lib.a
>   LINK    busybox_unstripped
>
> include/bbconfigopts.h from build tree is attached.
> --
> vda
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070202/802bfa3b/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bbconfigopts.h
Type: text/x-chdr
Size: 20606 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070202/802bfa3b/attachment-0002.h 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkconfigs.patch
Type: text/x-patch
Size: 429 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070202/802bfa3b/attachment-0002.bin 

From vapier at gentoo.org  Sat Feb  3 07:41:38 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 3 Feb 2007 02:41:38 -0500
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702030241.41425.vapier@gentoo.org>

On Saturday 03 February 2007, Brion Finlay wrote:
> The fix that could be made to scripts/mkconfigs in order to work more
> generally

another fix would be to use a POSIX compliant shell ... then there wouldnt be 
problem
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070203/af9e409d/attachment-0002.pgp 

From vapier at gentoo.org  Sat Feb  3 07:44:07 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 3 Feb 2007 02:44:07 -0500
Subject: build system doesnt properly detect applet rebuild requirement
Message-ID: <200702030244.08150.vapier@gentoo.org>

$ make distclean
$ make allnoconfig
$ make menuconfig
-> enable dmesg, syslog, klogd, logger
$ make
$ nano .config
-> disable syslog, klogd, logger
$ make oldconfig
$ make
<link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070203/97fef1e6/attachment-0002.pgp 

From rep.dot.nop at gmail.com  Sat Feb  3 12:09:49 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:09:49 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702030244.08150.vapier@gentoo.org>
References: <200702030244.08150.vapier@gentoo.org>
Message-ID: <20070203120949.GB12488@aon.at>

On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
>$ make distclean
>$ make allnoconfig
>$ make menuconfig
>-> enable dmesg, syslog, klogd, logger
>$ make
>$ nano .config
>-> disable syslog, klogd, logger
>$ make oldconfig
>$ make
><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>-mike

Confirmed. See also vda's note that it's disfunctional:
http://busybox.net/lists/busybox/2007-January/025966.html

In the old buildsys we had a dependency like
applets.o: .config

Nowadays applets.o depends on usage_compressed.h alone.
Iff the problem turns out to be passing -include autoconf.h directly
(so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
#include "autoconf.h" into libbb.h would perhaps change that
misbehaviour. Any takers?


From vda.linux at googlemail.com  Sat Feb  3 12:07:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:07:45 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702030244.08150.vapier@gentoo.org>
References: <200702030244.08150.vapier@gentoo.org>
Message-ID: <200702031307.45497.vda.linux@googlemail.com>

On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> $ make distclean
> $ make allnoconfig
> $ make menuconfig
> -> enable dmesg, syslog, klogd, logger
> $ make
> $ nano .config
> -> disable syslog, klogd, logger
> $ make oldconfig
> $ make
> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> -mike

Does this patch help?
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 1914 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070203/2ad8d42b/attachment-0002.bin 

From rep.dot.nop at gmail.com  Sat Feb  3 12:21:31 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:21:31 +0100
Subject: sigset_t [was: Re: svn commit: trunk/busybox/runit]
In-Reply-To: <20070203014756.DD8AE48641@busybox.net>
References: <20070203014756.DD8AE48641@busybox.net>
Message-ID: <20070203122131.GD12488@aon.at>

On Fri, Feb 02, 2007 at 05:47:56PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-02 17:47:56 -0800 (Fri, 02 Feb 2007)
>New Revision: 17732
>
>Log:
>sigset_t blocked_sigset is too big for static (128 bytes)

and what about
$ svngrep -rl sigset_t * 
init/init.c
loginutils/vlock.c
mk.check.log
networking/inetd.c
networking/arping.c
runit/runit_lib.c
runit/svlogd.c



From rep.dot.nop at gmail.com  Sat Feb  3 12:41:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:41:21 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702031307.45497.vda.linux@googlemail.com>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
Message-ID: <20070203124121.GF12488@aon.at>

On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
>On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
>> $ make distclean
>> $ make allnoconfig
>> $ make menuconfig
>> -> enable dmesg, syslog, klogd, logger
>> $ make
>> $ nano .config
>> -> disable syslog, klogd, logger
>> $ make oldconfig
>> $ make
>> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>> -mike
>
>Does this patch help?

An IMHO cleaner approach would be the attached.

Comments?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.fix-autoconf-dep.00.diff
Type: text/x-diff
Size: 1564 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070203/74944a0c/attachment-0002.bin 

From vda.linux at googlemail.com  Sat Feb  3 12:39:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:39:51 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203120949.GB12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<20070203120949.GB12488@aon.at>
Message-ID: <200702031339.51374.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:09, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
> >$ make distclean
> >$ make allnoconfig
> >$ make menuconfig
> >-> enable dmesg, syslog, klogd, logger
> >$ make
> >$ nano .config
> >-> disable syslog, klogd, logger
> >$ make oldconfig
> >$ make
> ><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >-mike
> 
> Confirmed. See also vda's note that it's disfunctional:
> http://busybox.net/lists/busybox/2007-January/025966.html
> 
> In the old buildsys we had a dependency like
> applets.o: .config
> 
> Nowadays applets.o depends on usage_compressed.h alone.
> Iff the problem turns out to be passing -include autoconf.h directly
> (so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
> #include "autoconf.h" into libbb.h would perhaps change that
> misbehaviour. Any takers?

Attached patch should fix it. Works for me.
Can someone else confirm?

Will need big dumb patch with lots of

+int ar_main(int argc, char **argv);
 int ar_main(int argc, char **argv)

in order to suppress warnings.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 1914 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070203/aeffe6ef/attachment-0002.bin 

From rep.dot.nop at gmail.com  Sat Feb  3 12:43:59 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:43:59 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702031339.51374.vda.linux@googlemail.com>
References: <200702030244.08150.vapier@gentoo.org>
	<20070203120949.GB12488@aon.at>
	<200702031339.51374.vda.linux@googlemail.com>
Message-ID: <20070203124359.GG12488@aon.at>

On Sat, Feb 03, 2007 at 01:39:51PM +0100, Denis Vlasenko wrote:
>On Saturday 03 February 2007 13:09, Bernhard Fischer wrote:
>> On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
>> >$ make distclean
>> >$ make allnoconfig
>> >$ make menuconfig
>> >-> enable dmesg, syslog, klogd, logger
>> >$ make
>> >$ nano .config
>> >-> disable syslog, klogd, logger
>> >$ make oldconfig
>> >$ make
>> ><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>> >-mike
>> 
>> Confirmed. See also vda's note that it's disfunctional:
>> http://busybox.net/lists/busybox/2007-January/025966.html
>> 
>> In the old buildsys we had a dependency like
>> applets.o: .config
>> 
>> Nowadays applets.o depends on usage_compressed.h alone.
>> Iff the problem turns out to be passing -include autoconf.h directly
>> (so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
>> #include "autoconf.h" into libbb.h would perhaps change that
>> misbehaviour. Any takers?
>
>Attached patch should fix it. Works for me.
>Can someone else confirm?
>
>Will need big dumb patch with lots of
>
>+int ar_main(int argc, char **argv);
> int ar_main(int argc, char **argv)
>
>in order to suppress warnings.

I don't like that approach, personally.
Seen my counter-proposal that i sent a minute ago?


From vda.linux at googlemail.com  Sat Feb  3 12:49:47 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:49:47 +0100
Subject: sigset_t [was: Re: svn commit: trunk/busybox/runit]
In-Reply-To: <20070203122131.GD12488@aon.at>
References: <20070203014756.DD8AE48641@busybox.net>
	<20070203122131.GD12488@aon.at>
Message-ID: <200702031349.47336.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:21, Bernhard Fischer wrote:
> On Fri, Feb 02, 2007 at 05:47:56PM -0800, vda at busybox.net wrote:
> >Author: vda
> >Date: 2007-02-02 17:47:56 -0800 (Fri, 02 Feb 2007)
> >New Revision: 17732
> >
> >Log:
> >sigset_t blocked_sigset is too big for static (128 bytes)
> 
> and what about
> $ svngrep -rl sigset_t * 
> init/init.c
> loginutils/vlock.c
> mk.check.log
> networking/inetd.c
> networking/arping.c
> runit/runit_lib.c
> runit/svlogd.c

None of them is static (all are auto variables)
--
vda


From vda.linux at googlemail.com  Sat Feb  3 12:51:44 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:51:44 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702031351.44512.vda.linux@googlemail.com>

On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> Thanks for the responses.  It helped knowing that my gnu compiler/c library
> configuration was correct.  It also helped knowing what the
> bbconfigopts.hwas supposed to look like.
> 
> I did some digging into the problem and found the following.  The immediate
> cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
> /bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
> construction for generating bbconfigopts.h.  This construction contains a
> "\n" sequence, which the dash echo command interprets literally.  (See the
> attached bbconfigopts.h production to see what happens.)
> 
> Linking /bin/sh to /bin/bash resolved this problem and allowed the build to
> complete successfully.
> 
> The fix that could be made to scripts/mkconfigs in order to work more
> generally, be less indirect, and avoid some of the backslash quoting would
> be to eliminate the echo "`...`" construction and just execute the command
> directly.  That is, change this:
> 
> echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> "\\"" $0 "\\\\n\\"";}'`"
> 
> to this:
> 
> sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
> "\\n\"";}'
> 
> I tested this change under bash and dash and it works in both shells.

There is presumably a reason why it is done that way. Is bbconfig.h different?

Another question, does it (unmodified version, that is) work with bbox ash?
--
vda


From vda.linux at googlemail.com  Sat Feb  3 12:57:17 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:57:17 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203124121.GF12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
	<20070203124121.GF12488@aon.at>
Message-ID: <200702031357.17715.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:41, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
> >On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> >> $ make distclean
> >> $ make allnoconfig
> >> $ make menuconfig
> >> -> enable dmesg, syslog, klogd, logger
> >> $ make
> >> $ nano .config
> >> -> disable syslog, klogd, logger
> >> $ make oldconfig
> >> $ make
> >> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >> -mike
> >
> >Does this patch help?
> 
> An IMHO cleaner approach would be the attached.
> 
> Comments?

--- busybox_trunk/include/libbb.h???????(revision 17735)
+++ busybox_trunk/include/libbb.h???????(working copy)

+#include "autoconf.h"
?#include "platform.h"

This will make every .c file depend on .config. Change just one
CONFIG_xxx and watch make rebuild everything.

-include/usage_compressed.h: $(srctree)/include/usage.h applets/usage
+include/usage_compressed.h: include/autoconf.h $(srctree)/include/usage.h applets/usage

Maybe this is needed. Or just .config instead of include/autoconf.h?
I admit I'm not good in Makefile hacking...

--
vda


From vda.linux at googlemail.com  Sat Feb  3 13:19:10 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 14:19:10 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203124121.GF12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
	<20070203124121.GF12488@aon.at>
Message-ID: <200702031419.10898.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:41, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
> >On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> >> $ make distclean
> >> $ make allnoconfig
> >> $ make menuconfig
> >> -> enable dmesg, syslog, klogd, logger
> >> $ make
> >> $ nano .config
> >> -> disable syslog, klogd, logger
> >> $ make oldconfig
> >> $ make
> >> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >> -mike
> >
> >Does this patch help?
> 
> An IMHO cleaner approach would be the attached.

Why is it 'cleaner'? I checked my change: it muchly
reduces false dependencies. Isn't it nice?
--
vda


From pgf at brightstareng.com  Sat Feb  3 13:41:00 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Sat, 03 Feb 2007 08:41:00 -0500
Subject: Busybox build problem 
In-Reply-To: vapier's message of Sat, 03 Feb 2007 02:41:38 -0500.
	<200702030241.41425.vapier@gentoo.org> 
Message-ID: <28616.1170510060@brightstareng.com>

vapier wrote:
 > On Saturday 03 February 2007, Brion Finlay wrote:
 > > The fix that could be made to scripts/mkconfigs in order to work more
 > > generally
 > 
 > another fix would be to use a POSIX compliant shell ... then there wouldnt
 > be problem
 > -mike
 > 

we had the same problem with a different build system when we
moved it to ubuntu.  i did some googling at the time, but
couldn't find a definitive answer -- i expected to find a lot of
discussion on it somewhere in ubuntu-land, since it's a pretty
big change, but i didn't.  it's not clear to me that dash isn't
posix compliant, at least with regard to echo's expanding '\n'. 
but it might not be.  is there a "dash is/isn't POSIX" discussion
page out there anywhere?

in our case it was expedient (and safe) to simply replace
"#!/bin/sh" with "#!/bin/bash", but that's probably not
appropriate for busybox.

paul
=---------------------
 paul fox, pgf at brightstareng.com


From brion.finlay at gmail.com  Sat Feb  3 19:15:22 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 13:15:22 -0600
Subject: Busybox build problem
In-Reply-To: <200702031351.44512.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
	<200702031351.44512.vda.linux@googlemail.com>
Message-ID: <aa1451e00702031115l292e2079seb2d37257c051ec2@mail.gmail.com>

bbconfig.h: Yes, it seems to be a different file that is not generated by
scripts/mkconfigs.  include/config/bbconfig.h looks to be only a single
line, and it does not have quotes or "\n" in the file like
include/bbconfigopts.h.  Whether built with dash or bash using the
unmodified mkconfigs, both include/config/bbconfig.h files look like this:

#define CONFIG_BBCONFIG 1

I don't think scripts/mkconfigs generates include/config/bbconfig.h, I think
it only generates bbconfigopts.h, despite the comment in the header.  The
main evidence for this is that the include define for the .h file it
generates is always "_BBCONFIGOPTS_H", and is always generated.
include/config/bbconfig.h does not contain any of the text that is always
generated.

To be honest, though, I am not sure what IS generating the
include/config/bbconfig.h file.  Some quick greps through the source tree do
not turn anything up, but I know that this file gets replaced with a #undef
CONFIG_BBCONFIG when that option is turned off.

I could also clean up the comments and submit another patch if you are
interested.  There is another error in the comments where it refers to
scripts/config/mkconfigs instead of scripts/mkconfigs, which is propogated
to the generated bbconfigopts.h.

ash:  I just tested with ash.  The unmodified version does work with the
bbox ash.  The unmodified version also works with bash, in case that wasn't
clear from my other email.  The modified version also works with ash, bash,
and dash.

I agree, presumably there was a reason.  Maybe someone can shed some light.
I will share some of my thoughts.

It might be that the reason for using the echo "` ... `" construction is
simply to make the script look nicer, since the other lines in the script
are all echo statements.

The only difference that I see using an echo "` ... `" versus direct
execution of the command is that the echo statement could process escape
characters from the output of the backquote command.   If it isn't the
intent to process escape characters, then it seems like it might as well
execute the command directly.  In this case, the echo command of "dash" IS
processing the escape characters, and this causes a problem, so it
certainly doesn't seem like the intent is to use echo to process escape
characters (which seems like a dubious intent, anyway.)

The mkconfigs script appears to be simple.  As the comments state, it is
pulling lines from .config which start with "CONFIG_" or "# CONFIG_",
replacing " with \", and prints each line as "<string>\n".


On 2/3/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> > Thanks for the responses.  It helped knowing that my gnu compiler/c
> library
> > configuration was correct.  It also helped knowing what the
> > bbconfigopts.hwas supposed to look like.
> >
> > I did some digging into the problem and found the following.  The
> immediate
> > cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
> > /bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
> > construction for generating bbconfigopts.h.  This construction contains
> a
> > "\n" sequence, which the dash echo command interprets literally.  (See
> the
> > attached bbconfigopts.h production to see what happens.)
> >
> > Linking /bin/sh to /bin/bash resolved this problem and allowed the build
> to
> > complete successfully.
> >
> > The fix that could be made to scripts/mkconfigs in order to work more
> > generally, be less indirect, and avoid some of the backslash quoting
> would
> > be to eliminate the echo "`...`" construction and just execute the
> command
> > directly.  That is, change this:
> >
> > echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
>
> > "\\"" $0 "\\\\n\\"";}'`"
> >
> > to this:
> >
> > sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\""
> $0
> > "\\n\"";}'
> >
> > I tested this change under bash and dash and it works in both shells.
>
> There is presumably a reason why it is done that way. Is bbconfig.hdifferent?
>
> Another question, does it (unmodified version, that is) work with bbox
> ash?
> --
> vda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070203/2f8b8a35/attachment.htm 

From brion.finlay at gmail.com  Sat Feb  3 20:02:41 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 14:02:41 -0600
Subject: Busybox build problem
In-Reply-To: <28616.1170510060@brightstareng.com>
References: <200702030241.41425.vapier@gentoo.org>
	<28616.1170510060@brightstareng.com>
Message-ID: <aa1451e00702031202l2e85adffuf8c45864b272bf74@mail.gmail.com>

I agree Paul, I wasn't sure that dash was/wasn't compliant.  It is the
default with the latest Ubuntu for /bin/sh, which means busybox builds don't
work on Ubuntu by default.

Since the question was raised about posix compliance, I decided to go look
it up.  Here is what I found:

Here are the posix specs:
(free registration required)

Here is the main link:
http://www.unix.org/single_unix_specification/

here are some direct links:
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_02
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_03
http://www.opengroup.org/onlinepubs/000095399/utilities/echo.html

Here are some excerpts for consideration:

2.6.3 Command Substitution
"Within the backquoted style of command substitution, backslash shall retain
its literal meaning, except when followed by: '$', '`', or '\' (dollar sign,
backquote, backslash).
...
A single-quoted or double-quoted string that begins, but does not end,
within the "`...`" sequence produces undefined results."

so a single " or ' is undefined behavior within a backquote command
substitution and cannot be escaped with a backslash.

echo:
"It is not possible to use *echo* portably across all POSIX systems unless
both *-n* (as the first argument) and escape sequences are omitted."

"The following operands shall be supported:
*string*A string to be written to standard output. If the first operand is *
-n*, or if any of the operands contain a backslash ( '\' ) character, the
results are implementation-defined....
    \nWrite a <newline>....
"

So in the POSIX specs, the echo operand is not necessarily quoted, and a
"\n" is SUPPOSED to be printed as a newline, unless the "-n" option is used
(in which case backslash escapes are implementation specific), so according
to the spec technically bash and bbox ash are non-compliant because they
print the \n instead of the newline.

"New applications are encouraged to use
*printf*<http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html>instead
of
*echo*."
"

The *echo* utility has not been made obsolescent because of its extremely
widespread use in historical applications. Conforming applications that wish
to do prompting without <newline>s or that could possibly be expecting to
echo a *-n*, should use the
*printf*<http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html>utility
derived from the Ninth Edition system.

As specified, *echo* writes its arguments in the simplest of ways. The two
different historical versions of *echo* vary in fatally incompatible ways.

The BSD *echo* checks the first argument for the string *-n* which causes it
to suppress the <newline> that would otherwise follow the final argument in
the output.

The System V *echo* does not support any options, but allows escape
sequences within its operands, as described for XSI implementations in the
OPERANDS section.

The *echo* utility does not support Utility Syntax Guideline 10 because
historical applications depend on *echo* to echo *all* of its arguments,
except for the *-n* option in the BSD version.

"
Regardless of all of this (or perhaps this is a good demonstration) -
quoting is complicated and it is probably a good idea to avoid it when
possible.  An echo "`...`" command substitution seems a little like calling
"a = strtofloat(floattostr(b));" instead of directly "a=b;"


On 2/3/07, Paul Fox <pgf at brightstareng.com> wrote:
>
> vapier wrote:
> > On Saturday 03 February 2007, Brion Finlay wrote:
> > > The fix that could be made to scripts/mkconfigs in order to work more
> > > generally
> >
> > another fix would be to use a POSIX compliant shell ... then there
> wouldn't
> > be problem
> > -mike
> >
>
> we had the same problem with a different build system when we
> moved it to ubuntu.  i did some googling at the time, but
> couldn't find a definitive answer -- i expected to find a lot of
> discussion on it somewhere in ubuntu-land, since it's a pretty
> big change, but i didn't.  it's not clear to me that dash isn't
> posix compliant, at least with regard to echo's expanding '\n'.
> but it might not be.  is there a "dash is/isn't POSIX" discussion
> page out there anywhere?
>
> in our case it was expedient (and safe) to simply replace
> "#!/bin/sh" with "#!/bin/bash", but that's probably not
> appropriate for busybox.
>
> paul
> =---------------------
> paul fox, pgf at brightstareng.com
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070203/e179b110/attachment-0001.htm 

From vda.linux at googlemail.com  Sat Feb  3 23:34:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 00:34:32 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702040034.32257.vda.linux@googlemail.com>

On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> The fix that could be made to scripts/mkconfigs in order to work more
> generally, be less indirect, and avoid some of the backslash quoting would
> be to eliminate the echo "`...`" construction and just execute the command
> directly.  That is, change this:
> 
> echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> "\\"" $0 "\\\\n\\"";}'`"
> 
> to this:
> 
> sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
> "\\n\"";}'
> 
> I tested this change under bash and dash and it works in both shells.

But it doesn't work for me. ;) Your sed should have three \\\ instead of five.

Can you try the attached patch? Will apply if it also works for you.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 1349 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070204/3103bfbe/attachment-0002.bin 

From somlo at cmu.edu  Sat Feb  3 23:58:43 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sat, 3 Feb 2007 18:58:43 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
Message-ID: <20070203235843.GA4059@hedwig.net.cmu.edu>

Denis & All,

The first part of this patch fixes BB_EXECLP in libbb.h, (it
accidentally calls execvp instead of execlp).

The rest replaces execlp and execvp calls with BB_EXECLP and
BB_EXECVP, respectively (except in the shells, where we use
STANDALONE_SHELL to accomplish this).

Once this is in, we should be able to remove hardcoded paths from
anywhere else they might still be used.

Cheers,
Gabriel

diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
--- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
@@ -559,11 +559,11 @@
 	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
 #define BB_EXECLP(prog,cmd,...) \
 	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
 #else
 #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
-#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
+#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
 #endif
 
 USE_DESKTOP(long long) int uncompress(int fd_in, int fd_out);
 int inflate(int in, int out);
 
diff -NarU5 busybox-svn-17746.orig/archival/tar.c busybox-svn-17746/archival/tar.c
--- busybox-svn-17746.orig/archival/tar.c	2007-02-03 18:17:52.000000000 -0500
+++ busybox-svn-17746/archival/tar.c	2007-02-03 18:48:50.000000000 -0500
@@ -527,11 +527,11 @@
 			dup2(tbInfo.tarFd, 1);
 
 			close(gzipStatusPipe[0]);
 			fcntl(gzipStatusPipe[1], F_SETFD, FD_CLOEXEC);	/* close on exec shows success */
 
-			execlp(zip_exec, zip_exec, "-f", NULL);
+			BB_EXECLP(zip_exec, zip_exec, "-f", NULL);
 			vfork_exec_errno = errno;
 
 			close(gzipStatusPipe[1]);
 			exit(-1);
 		} else if (gzipPid > 0) {
diff -NarU5 busybox-svn-17746.orig/console-tools/openvt.c busybox-svn-17746/console-tools/openvt.c
--- busybox-svn-17746.orig/console-tools/openvt.c	2007-02-03 18:17:52.000000000 -0500
+++ busybox-svn-17746/console-tools/openvt.c	2007-02-03 18:31:02.000000000 -0500
@@ -34,10 +34,10 @@
 		dup2(fd, STDIN_FILENO);
 		dup2(fd, STDOUT_FILENO);
 		dup2(fd, STDERR_FILENO);
 		while (fd > 2) close(fd--);
 
-		execvp(argv[2], &argv[2]);
+		BB_EXECVP(argv[2], &argv[2]);
 		_exit(1);
 	}
 	return EXIT_SUCCESS;
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/chroot.c busybox-svn-17746/coreutils/chroot.c
--- busybox-svn-17746.orig/coreutils/chroot.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/chroot.c	2007-02-03 18:32:55.000000000 -0500
@@ -31,8 +31,8 @@
 			*argv = (char *) DEFAULT_SHELL;
 		}
 		argv[1] = (char *) "-i";
 	}
 
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("cannot execute %s", *argv);
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/env.c busybox-svn-17746/coreutils/env.c
--- busybox-svn-17746.orig/coreutils/env.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/env.c	2007-02-03 18:33:53.000000000 -0500
@@ -79,11 +79,11 @@
 		}
 		++argv;
 	}
 
 	if (*argv) {
-		execvp(*argv, argv);
+		BB_EXECVP(*argv, argv);
 		/* SUSv3-mandated exit codes. */
 		xfunc_error_retval = (errno == ENOENT) ? 127 : 126;
 		bb_perror_msg_and_die("%s", *argv);
 	}
 
diff -NarU5 busybox-svn-17746.orig/coreutils/install.c busybox-svn-17746/coreutils/install.c
--- busybox-svn-17746.orig/coreutils/install.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/install.c	2007-02-03 18:49:11.000000000 -0500
@@ -124,11 +124,11 @@
 		) {
 			bb_perror_msg("cannot change ownership of %s", dest);
 			ret = EXIT_FAILURE;
 		}
 		if (flags & OPT_STRIP) {
-			if (execlp("strip", "strip", dest, NULL) == -1) {
+			if (BB_EXECLP("strip", "strip", dest, NULL) == -1) {
 				bb_perror_msg("strip");
 				ret = EXIT_FAILURE;
 			}
 		}
 		if (ENABLE_FEATURE_CLEAN_UP && isdir) free(dest);
diff -NarU5 busybox-svn-17746.orig/coreutils/nice.c busybox-svn-17746/coreutils/nice.c
--- busybox-svn-17746.orig/coreutils/nice.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/nice.c	2007-02-03 18:34:17.000000000 -0500
@@ -45,11 +45,11 @@
 		if (setpriority(PRIO_PROCESS, 0, prio) < 0) {
 			bb_perror_msg_and_die("setpriority(%d)", prio);
 		}
 	}
 
-	execvp(*argv, argv);		/* Now exec the desired program. */
+	BB_EXECVP(*argv, argv);		/* Now exec the desired program. */
 
 	/* The exec failed... */
 	xfunc_error_retval = (errno == ENOENT) ? 127 : 126; /* SUSv3 */
 	bb_perror_msg_and_die("%s", *argv);
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/nohup.c busybox-svn-17746/coreutils/nohup.c
--- busybox-svn-17746.orig/coreutils/nohup.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/nohup.c	2007-02-03 18:34:07.000000000 -0500
@@ -51,10 +51,10 @@
 
 	if (nullfd > 2)
 		close(nullfd);
 	signal(SIGHUP, SIG_IGN);
 
-	execvp(argv[1], argv+1);
+	BB_EXECVP(argv[1], argv+1);
 	if (ENABLE_FEATURE_CLEAN_UP && home)
 		free((char*)nohupout);
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17746.orig/e2fsprogs/fsck.c busybox-svn-17746/e2fsprogs/fsck.c
--- busybox-svn-17746.orig/e2fsprogs/fsck.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/e2fsprogs/fsck.c	2007-02-03 18:34:40.000000000 -0500
@@ -675,11 +675,11 @@
 			if (!interactive) {
 				/* NB: e2fsck will complain because of this!
 				 * Use "fsck -s" to avoid... */
 				close(0);
 			}
-			execvp(argv[0], argv);
+			BB_EXECVP(argv[0], argv);
 			bb_perror_msg_and_die("%s", argv[0]);
 		}
 	}
 
 	for (i = num_args+1; i < argc; i++)
diff -NarU5 busybox-svn-17746.orig/findutils/xargs.c busybox-svn-17746/findutils/xargs.c
--- busybox-svn-17746.orig/findutils/xargs.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/findutils/xargs.c	2007-02-03 18:35:23.000000000 -0500
@@ -58,11 +58,11 @@
 	if (p < 0)
 		bb_perror_msg_and_die("vfork");
 
 	if (p == 0) {
 		/* vfork -- child */
-		execvp(args[0], args);
+		BB_EXECVP(args[0], args);
 		exec_errno = errno;     /* set error to shared stack */
 		_exit(1);
 	}
 
 	/* vfork -- parent */
diff -NarU5 busybox-svn-17746.orig/loginutils/adduser.c busybox-svn-17746/loginutils/adduser.c
--- busybox-svn-17746.orig/loginutils/adduser.c	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/loginutils/adduser.c	2007-02-03 18:49:30.000000000 -0500
@@ -78,11 +78,11 @@
 static void passwd_wrapper(const char *login) ATTRIBUTE_NORETURN;
 
 static void passwd_wrapper(const char *login)
 {
 	static const char prog[] = "passwd";
-	execlp(prog, prog, login, NULL);
+	BB_EXECLP(prog, prog, login, NULL);
 	bb_error_msg_and_die("failed to execute '%s', you must set the password for '%s' manually", prog, login);
 }
 
 /* putpwent(3) remix */
 static int adduser(struct passwd *p, unsigned long flags)
diff -NarU5 busybox-svn-17746.orig/loginutils/login.c busybox-svn-17746/loginutils/login.c
--- busybox-svn-17746.orig/loginutils/login.c	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/loginutils/login.c	2007-02-03 18:36:35.000000000 -0500
@@ -355,11 +355,11 @@
 				setenv("LOGIN_TTY", full_tty, 1);
 				setenv("LOGIN_USER", pw->pw_name, 1);
 				setenv("LOGIN_UID", utoa(pw->pw_uid), 1);
 				setenv("LOGIN_GID", utoa(pw->pw_gid), 1);
 				setenv("LOGIN_SHELL", pw->pw_shell, 1);
-				execvp(script, t_argv);
+				BB_EXECVP(script, t_argv);
 				exit(1);
 			default: /* parent */
 				wait(NULL);
 			}
 		}
diff -NarU5 busybox-svn-17746.orig/miscutils/devfsd.c busybox-svn-17746/miscutils/devfsd.c
--- busybox-svn-17746.orig/miscutils/devfsd.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/devfsd.c	2007-02-03 18:38:06.000000000 -0500
@@ -376,11 +376,11 @@
 		exit (EXIT_SUCCESS);
 	}
 	 /* Child : if arg0 != NULL do execvp */
 	if(arg0 != NULL )
 	{
-		execvp (arg0, arg);
+		BB_EXECVP(arg0, arg);
 		msg_logger_and_die(LOG_ERR, "execvp");
 	}
 }
 
 static void safe_memcpy( char *dest, const char *src, int len)
diff -NarU5 busybox-svn-17746.orig/miscutils/setsid.c busybox-svn-17746/miscutils/setsid.c
--- busybox-svn-17746.orig/miscutils/setsid.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/setsid.c	2007-02-03 18:39:23.000000000 -0500
@@ -34,9 +34,9 @@
 	}
 	/* child */
 
 	setsid();  /* no error possible */
 
-	execvp(argv[1], argv + 1);
+	BB_EXECVP(argv[1], argv + 1);
 
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17746.orig/miscutils/taskset.c busybox-svn-17746/miscutils/taskset.c
--- busybox-svn-17746.orig/miscutils/taskset.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/taskset.c	2007-02-03 18:39:02.000000000 -0500
@@ -89,11 +89,11 @@
 		state += 8;
 		++argv;
 		goto print_aff;
 	}
 	++argv;
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("%s", *argv);
 }
 #undef OPT_p
 #undef TASKSET_PRINTF_MASK
 #undef from_cpuset
diff -NarU5 busybox-svn-17746.orig/miscutils/time.c busybox-svn-17746/miscutils/time.c
--- busybox-svn-17746.orig/miscutils/time.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/time.c	2007-02-03 18:38:33.000000000 -0500
@@ -408,11 +408,11 @@
 	if (pid < 0)
 		bb_error_msg_and_die("cannot fork");
 	else if (pid == 0) {	/* If child.  */
 		/* Don't cast execvp arguments; that causes errors on some systems,
 		   versus merely warnings if the cast is left off.  */
-		execvp(cmd[0], cmd);
+		BB_EXECVP(cmd[0], cmd);
 		bb_error_msg("cannot run %s", cmd[0]);
 		_exit(errno == ENOENT ? 127 : 126);
 	}
 
 	/* Have signals kill the child but not self (if possible).  */
diff -NarU5 busybox-svn-17746.orig/networking/ifupdown.c busybox-svn-17746/networking/ifupdown.c
--- busybox-svn-17746.orig/networking/ifupdown.c	2007-02-03 18:17:50.000000000 -0500
+++ busybox-svn-17746/networking/ifupdown.c	2007-02-03 18:40:21.000000000 -0500
@@ -1002,11 +1002,11 @@
 		dup2(outfd[1], 1);
 		close(infd[0]);
 		close(infd[1]);
 		close(outfd[0]);
 		close(outfd[1]);
-		execvp(command, argv);
+		BB_EXECVP(command, argv);
 		exit(127);
 	default:			/* parent */
 		*in = fdopen(infd[1], "w");
 		*out = fdopen(outfd[0], "r");
 		close(infd[0]);
diff -NarU5 busybox-svn-17746.orig/networking/nc.c busybox-svn-17746/networking/nc.c
--- busybox-svn-17746.orig/networking/nc.c	2007-02-03 18:17:50.000000000 -0500
+++ busybox-svn-17746/networking/nc.c	2007-02-03 18:42:22.000000000 -0500
@@ -147,11 +147,11 @@
 			dup2(cfd, 0);
 			close(cfd);
 		}
 		dup2(0, 1);
 		dup2(0, 2);
-		USE_NC_EXTRA(execvp(execparam[0], execparam);)
+		USE_NC_EXTRA(BB_EXECVP(execparam[0], execparam);)
 		/* Don't print stuff or it will go over the wire.... */
 		_exit(127);
 	}
 
 	// Select loop copying stdin to cfd, and cfd to stdout.
diff -NarU5 busybox-svn-17746.orig/runit/chpst.c busybox-svn-17746/runit/chpst.c
--- busybox-svn-17746.orig/runit/chpst.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/runit/chpst.c	2007-02-03 18:42:47.000000000 -0500
@@ -308,11 +308,11 @@
 	if (env_user) euidgid(env_user);
 	if (set_user) suidgid(set_user);
 	if (OPT_nostdin) close(0);
 	if (OPT_nostdout) close(1);
 	if (OPT_nostderr) close(2);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void setuidgid(int argc, char **argv)
 {
@@ -320,11 +320,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	suidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envuidgid(int argc, char **argv)
 {
@@ -332,11 +332,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	euidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envdir(int argc, char **argv)
 {
@@ -344,11 +344,11 @@
 
 	dir = *++argv;
 	if (!dir) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	edir(dir);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void softlimit(int argc, char **argv)
 {
@@ -367,8 +367,8 @@
 	if (option_mask32 & 0x200) limits = xatoul(s); // -s
 	if (option_mask32 & 0x400) limitt = xatoul(t); // -t
 	argv += optind;
 	if (!argv[0]) bb_show_usage();
 	slimit();
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
diff -NarU5 busybox-svn-17746.orig/runit/runsvdir.c busybox-svn-17746/runit/runsvdir.c
--- busybox-svn-17746.orig/runit/runsvdir.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/runit/runsvdir.c	2007-02-03 18:43:10.000000000 -0500
@@ -71,11 +71,11 @@
 		prog[1] = (char*)name;
 		prog[2] = NULL;
 		sig_uncatch(SIGHUP);
 		sig_uncatch(SIGTERM);
 		if (pgrp) setsid();
-		execvp(prog[0], prog);
+		BB_EXECVP(prog[0], prog);
 		//pathexec_run(*prog, prog, (char* const*)environ);
 		fatal2_cannot("start runsv ", name);
 	}
 	sv[no].pid = pid;
 }
diff -NarU5 busybox-svn-17746.orig/util-linux/setarch.c busybox-svn-17746/util-linux/setarch.c
--- busybox-svn-17746.orig/util-linux/setarch.c	2007-02-03 18:17:59.000000000 -0500
+++ busybox-svn-17746/util-linux/setarch.c	2007-02-03 18:45:38.000000000 -0500
@@ -44,10 +44,10 @@
 
 	/* Try to set personality */
 	if (personality(pers) >= 0) {
 
 		/* Try to execute the program */
-		execvp(argv[0], argv);
+		BB_EXECVP(argv[0], argv);
 	}
 
 	bb_perror_msg_and_die("%s", argv[0]);
 }


From vda.linux at googlemail.com  Sun Feb  4 00:08:05 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 01:08:05 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070203235843.GA4059@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
Message-ID: <200702040108.05723.vda.linux@googlemail.com>

On Sunday 04 February 2007 00:58, Gabriel L. Somlo wrote:
> Denis & All,
> 
> The first part of this patch fixes BB_EXECLP in libbb.h, (it
> accidentally calls execvp instead of execlp).

Thanks! Consider this already fixed.

> The rest replaces execlp and execvp calls with BB_EXECLP and
> BB_EXECVP, respectively (except in the shells, where we use
> STANDALONE_SHELL to accomplish this).
> 
> Once this is in, we should be able to remove hardcoded paths from
> anywhere else they might still be used.
> 
> Cheers,
> Gabriel
> 
> diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
> --- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
> +++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
> @@ -559,11 +559,11 @@
>  	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
>  #define BB_EXECLP(prog,cmd,...) \
>  	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
>  #else

Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
(which should be a function) to save space?

>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 

It's probably too messy to make BB_EXECLP a function because of varargs...

Otherwise looks ok.
--
vda


From brion.finlay at gmail.com  Sun Feb  4 03:54:33 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 21:54:33 -0600
Subject: Busybox build problem
In-Reply-To: <200702040034.32257.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
	<200702040034.32257.vda.linux@googlemail.com>
Message-ID: <aa1451e00702031954m171e377fw55fdedbbba6360aa@mail.gmail.com>

Whoops, you are absolutely right.  I did not do the ash testing correctly,
but I figured out why and retested.  The patch I gave you did not work under
ash, and that was because of the extra back slash quotes, just like you say.

I tested this new patch you sent under ash and I also tested it with dash -
it works there too.

I have one more change for your patch - the comment about
"scripts/config/mkconfigs" should be "scripts/mkconfigs".  This comment gets
put into bbconfigopts.h.  I regenerated the diff with this additional change
and attached it as "4.sed.patch".  I also fixed the awk-only version and
retested it under ash.  I attached it as "4.awk.patch".   I personally like
the awk-only version a little better because it is only one invocation vs.
three invocations and two pipes for the sed | grep  | awk version, and maybe
more because it is a slick awk one-liner - but its trivial, really.  It's
just a shell script that is part of the build process.  They both work to
get the job done so they both work for me.

Thanks

Brion

On 2/3/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> > The fix that could be made to scripts/mkconfigs in order to work more
> > generally, be less indirect, and avoid some of the backslash quoting
> would
> > be to eliminate the echo "`...`" construction and just execute the
> command
> > directly.  That is, change this:
> >
> > echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> > "\\"" $0 "\\\\n\\"";}'`"
> >
> > to this:
> >
> > sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\""
> $0
> > "\\n\"";}'
> >
> > I tested this change under bash and dash and it works in both shells.
>
> But it doesn't work for me. ;) Your sed should have three \\\ instead of
> five.
>
> Can you try the attached patch? Will apply if it also works for you.
> --
> vda
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070203/1a4813d7/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.sed.patch
Type: text/x-patch
Size: 1290 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070203/1a4813d7/attachment-0004.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.awk.patch
Type: text/x-patch
Size: 1287 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070203/1a4813d7/attachment-0005.bin 

From Alexander at Kriegisch.name  Sun Feb  4 05:25:29 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 06:25:29 +0100
Subject: httpd and form-based upload
Message-ID: <45C56E49.9030907@Kriegisch.name>

Hi!

I would like to know if httpd supports form-based uploads and how they
can be handled in plain shell scripts (/bin/sh). I would be glad to see
one or more sample script(s).

Kind regards
-- 
Alexander Kriegisch


From rep.dot.nop at gmail.com  Sun Feb  4 10:28:53 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 11:28:53 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702040108.05723.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
Message-ID: <20070204102853.GJ12488@aon.at>

On Sun, Feb 04, 2007 at 01:08:05AM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 00:58, Gabriel L. Somlo wrote:
>> Denis & All,
>> 
>> The first part of this patch fixes BB_EXECLP in libbb.h, (it
>> accidentally calls execvp instead of execlp).
>
>Thanks! Consider this already fixed.
>
>> The rest replaces execlp and execvp calls with BB_EXECLP and
>> BB_EXECVP, respectively (except in the shells, where we use
>> STANDALONE_SHELL to accomplish this).
>> 
>> Once this is in, we should be able to remove hardcoded paths from
>> anywhere else they might still be used.
>> 
>> Cheers,
>> Gabriel
>> 
>> diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
>> --- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
>> +++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
>> @@ -559,11 +559,11 @@
>>  	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
>>  #define BB_EXECLP(prog,cmd,...) \
>>  	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
>>  #else
>
>Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
>(which should be a function) to save space?

Yes, please put it into an bb_execvp
>
>>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
>> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
>> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
>
>It's probably too messy to make BB_EXECLP a function because of varargs...

Why so? We already have several functions with varargs (our print
helpers), so this is fine. I'll note that several uncommon compilers had
problems with __VA_ARGS__ in the preprocessor but work fine for varargs
for the compiler. I'd prefer to have bb_execlp as a function, too.


From rep.dot.nop at gmail.com  Sun Feb  4 10:32:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 11:32:21 +0100
Subject: svn commit: trunk/busybox: include libbb networking sysklogd
In-Reply-To: <20070204023908.12D5548601@busybox.net>
References: <20070204023908.12D5548601@busybox.net>
Message-ID: <20070204103221.GK12488@aon.at>

On Sat, Feb 03, 2007 at 06:39:08PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-03 18:39:08 -0800 (Sat, 03 Feb 2007)
>New Revision: 17749

>Modified: trunk/busybox/include/libbb.h
>===================================================================
>--- trunk/busybox/include/libbb.h	2007-02-04 02:38:21 UTC (rev 17748)
>+++ trunk/busybox/include/libbb.h	2007-02-04 02:39:08 UTC (rev 17749)
>@@ -317,13 +317,13 @@
>  * Currently will return IPv4 or IPv6 sockaddrs only
>  * (depending on host), but in theory nothing prevents e.g.
>  * UNIX socket address being returned, IPX sockaddr etc... */
>-len_and_sockaddr* host2sockaddr(const char *host, int port);
>+len_and_sockaddr* xhost2sockaddr(const char *host, int port);
> #if ENABLE_FEATURE_IPV6
> /* Same, useful if you want to force family (e.g. IPv6) */
>-len_and_sockaddr* host_and_af2sockaddr(const char *host, int port, sa_family_t af);
>+len_and_sockaddr* xhost_and_af2sockaddr(const char *host, int port, sa_family_t af);

Why don't you mark those extern, btw?
> #else



From vda.linux at googlemail.com  Sun Feb  4 10:50:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 11:50:51 +0100
Subject: svn commit: trunk/busybox: include libbb networking sysklogd
In-Reply-To: <20070204103221.GK12488@aon.at>
References: <20070204023908.12D5548601@busybox.net>
	<20070204103221.GK12488@aon.at>
Message-ID: <200702041150.51385.vda.linux@googlemail.com>

On Sunday 04 February 2007 11:32, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 06:39:08PM -0800, vda at busybox.net wrote:
> >Author: vda
> >Date: 2007-02-03 18:39:08 -0800 (Sat, 03 Feb 2007)
> >New Revision: 17749
> 
> >Modified: trunk/busybox/include/libbb.h
> >===================================================================
> >--- trunk/busybox/include/libbb.h	2007-02-04 02:38:21 UTC (rev 17748)
> >+++ trunk/busybox/include/libbb.h	2007-02-04 02:39:08 UTC (rev 17749)
> >@@ -317,13 +317,13 @@
> >  * Currently will return IPv4 or IPv6 sockaddrs only
> >  * (depending on host), but in theory nothing prevents e.g.
> >  * UNIX socket address being returned, IPX sockaddr etc... */
> >-len_and_sockaddr* host2sockaddr(const char *host, int port);
> >+len_and_sockaddr* xhost2sockaddr(const char *host, int port);
> > #if ENABLE_FEATURE_IPV6
> > /* Same, useful if you want to force family (e.g. IPv6) */
> >-len_and_sockaddr* host_and_af2sockaddr(const char *host, int port, sa_family_t af);
> >+len_and_sockaddr* xhost_and_af2sockaddr(const char *host, int port, sa_family_t af);
> 
> Why don't you mark those extern, btw?

Function declarations are externs even if you don't put
extern keyword there, I think. extern is a must only for
variable declarations.

If you know a reason why extern should be there, please let me know.
--
vda


From vda.linux at googlemail.com  Sun Feb  4 11:03:28 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 12:03:28 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204102853.GJ12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
Message-ID: <200702041203.28506.vda.linux@googlemail.com>

On Sunday 04 February 2007 11:28, Bernhard Fischer wrote:
> >>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
> >> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
> >> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
> >
> >It's probably too messy to make BB_EXECLP a function because of varargs...
> 
> Why so? We already have several functions with varargs (our print
> helpers), so this is fine. I'll note that several uncommon compilers had
> problems with __VA_ARGS__ in the preprocessor but work fine for varargs
> for the compiler. I'd prefer to have bb_execlp as a function, too.

I have difficulty imagining how to _implement_ it.

int bb_execlp(char *prog, ...)
{
        va_list p;
	int n;
        va_start(p, prog);
        n = vexec(prog, p); ???? libc doesn't have vexec! ???
        va_end(p);
	return n;
}

Maybe it is doable with dirty tricks like calling execvp
with address of a parameter and hope that on your architecture
it will work.

But it doesn't worth the effort/complexity.
We have only four callsites of execlp.
--
vda


From rep.dot.nop at gmail.com  Sun Feb  4 11:51:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 12:51:21 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041203.28506.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
	<200702041203.28506.vda.linux@googlemail.com>
Message-ID: <20070204115117.GM12488@aon.at>

On Sun, Feb 04, 2007 at 12:03:28PM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 11:28, Bernhard Fischer wrote:
>> >>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
>> >> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
>> >> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
>> >
>> >It's probably too messy to make BB_EXECLP a function because of varargs...
>> 
>> Why so? We already have several functions with varargs (our print
>> helpers), so this is fine. I'll note that several uncommon compilers had
>> problems with __VA_ARGS__ in the preprocessor but work fine for varargs
>> for the compiler. I'd prefer to have bb_execlp as a function, too.
>
>I have difficulty imagining how to _implement_ it.

>But it doesn't worth the effort/complexity.
>We have only four callsites of execlp.

I see. Well if it's only four callsite, then a define is fine.

cheers,


From Alexander at Kriegisch.name  Sun Feb  4 13:44:40 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 14:44:40 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5E348.2050602@Kriegisch.name>

I wrote earlier:
>> I would like to know if httpd supports form-based uploads and how
>> they can be handled in plain shell scripts (/bin/sh). I would be glad
>> to see one or more sample script(s).

Some more background info: An HTML page for form-based upload could look like this:

<html>
<body>
  <form action="/cgi-bin/do_upload.cgi" method=post enctype="multipart/form-data">
    <input type=file size=50 maxlength=100000 name="File"><br>
    <input type=submit value="Submit">
  </form>
</body>
</html>

A server-side script receiving the upload could look like this:

#!/bin/sh
echo -n -e 'HTTP/1.0 200 OK\r\n'
echo -n -e 'Content-type: text/html\r\n\r\n'

cat > /var/tmp/upload.bin
cat << EOF
<html>
<body>
  <h2>Upload finished</h2>
</body>
</html>
EOF

And this would be the content of upload.bin:

-----------------------------7d72033ac0372
Content-Disposition: form-data; name="File"; filename="I:\install\sample_upload.tar.gz"
Content-Type: application/x-gzip

(...) unencoded binary stuff (...)
-----------------------------7d72033ac0372--

So, basically, I would need a shell script which could
cut away the MIME header and footer, so as to only save 
the "unencoded binary stuff" section to disk. This may 
not be a very busybox-specific question, but anyway, 
probably I should use the limited means provided by 
busybox's shell (ash) and toolset (sed, awk, maybe others) 
to achieve. I was also hoping for an httpd  configuration
option to help me achieve my goal without having to code
a CGI upload handler in C. BTW: My busybox is running on
a DSL router.
--
Alexander Kriegisch



From somlo at cmu.edu  Sun Feb  4 13:47:37 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sun, 4 Feb 2007 08:47:37 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204102853.GJ12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
Message-ID: <20070204134737.GA10874@hedwig.net.cmu.edu>

On Sun, Feb 04, 2007 at 11:28:53AM +0100, Bernhard Fischer wrote:
> >Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
> >(which should be a function) to save space?
> 
> Yes, please put it into an bb_execvp

OK, will do that. Now, about the specifics: I could simply do what the
macro now does, i.e., check for the existance of a busybox applet and
then call execvp. Or, I could "unwind" execvp, and check for the
presence of a '/' in the program name first, then for the presence of
an applet, and last search PATH the way the real execvp does, and end
up by calling execve(), the way the real execvp does.

Do we want to keep it simple more than we care about speed (avoiding
work when the progname contains a '/') ?

Cheers,
Gabriel


From wharms at bfs.de  Sun Feb  4 14:12:02 2007
From: wharms at bfs.de (walter harms)
Date: Sun, 04 Feb 2007 15:12:02 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5E9B2.70800@bfs.de>

hi Alexander
you would like to use httpd for uploading files ? (rfc1867)
the problem is already solved and called 'ftp'. there are several
examples how to script ftp. http has a totally different target
and misuse are mostly to be punished with serve problems.

Why do you need this ?

re,
 wh


Alexander Kriegisch wrote:
> Hi!
> 
> I would like to know if httpd supports form-based uploads and how they
> can be handled in plain shell scripts (/bin/sh). I would be glad to see
> one or more sample script(s).
> 
> Kind regards


From Alexander at Kriegisch.name  Sun Feb  4 14:21:22 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 15:21:22 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C5E9B2.70800@bfs.de>
References: <45C56E49.9030907@Kriegisch.name> <45C5E9B2.70800@bfs.de>
Message-ID: <45C5EBE2.1050203@Kriegisch.name>

> you would like to use httpd for uploading files ? (rfc1867) the
> problem is already solved and called 'ftp'. there are several 
> examples how to script ftp. http has a totally different target and
> misuse are mostly to be punished with serve problems.
> 
> Why do you need this ?

Dear Walter,

I want to extend my router's web configuration interface, so it would be
natural to use form based upload and not open a second data transmission
channel. As you wrote, there is an RFC for form-based upload, and MIME
multiparts are known much longer than that anyway. So this should nort
be regarded a misuse, it is a standard.
--
Alexander

> Alexander Kriegisch wrote:
>> I would like to know if httpd supports form-based uploads and how
>> they can be handled in plain shell scripts (/bin/sh). I would be
>> glad to see one or more sample script(s).



From rep.dot.nop at gmail.com  Sun Feb  4 15:01:57 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 16:01:57 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204134737.GA10874@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
Message-ID: <20070204150157.GN12488@aon.at>

On Sun, Feb 04, 2007 at 08:47:37AM -0500, Gabriel L. Somlo wrote:
>On Sun, Feb 04, 2007 at 11:28:53AM +0100, Bernhard Fischer wrote:
>> >Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
>> >(which should be a function) to save space?
>> 
>> Yes, please put it into an bb_execvp
>
>OK, will do that. Now, about the specifics: I could simply do what the
>macro now does, i.e., check for the existance of a busybox applet and
>then call execvp. Or, I could "unwind" execvp, and check for the
>presence of a '/' in the program name first, then for the presence of
>an applet, and last search PATH the way the real execvp does, and end
>up by calling execve(), the way the real execvp does.
>
>Do we want to keep it simple more than we care about speed (avoiding
>work when the progname contains a '/') ?

I don't think that spawning a subprogram is _that_ performance critical,
so i'd go for the simple case of looking if we've got an applet (like
the macro did) only. Also, i'd expect this to me smaller, which is the
ultimate reason there.


From nangel at nothome.org  Sun Feb  4 14:32:50 2007
From: nangel at nothome.org (Nathan Anglacos)
Date: Sun, 04 Feb 2007 09:32:50 -0500
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5EE92.80307@nothome.org>

[reposting to the busybox list]


Alexander Kriegisch wrote:
> Hi!
> 
> I would like to know if httpd supports form-based uploads and how they
> can be handled in plain shell scripts (/bin/sh). I would be glad to see
> one or more sample script(s).
> 
> Kind regards

Hi Alexander,

haserl (haserl.sourceforge.net) does what you are asking for.    haserl 
is a C cgi script, and works with busybox httpd.



From vda.linux at googlemail.com  Sun Feb  4 16:07:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 17:07:33 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204150157.GN12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
Message-ID: <200702041707.33774.vda.linux@googlemail.com>

On Sunday 04 February 2007 16:01, Bernhard Fischer wrote:
> >OK, will do that. Now, about the specifics: I could simply do what the
> >macro now does, i.e., check for the existance of a busybox applet and
> >then call execvp. Or, I could "unwind" execvp, and check for the
> >presence of a '/' in the program name first, then for the presence of
> >an applet, and last search PATH the way the real execvp does, and end
> >up by calling execve(), the way the real execvp does.
> >
> >Do we want to keep it simple more than we care about speed (avoiding
> >work when the progname contains a '/') ?
> 
> I don't think that spawning a subprogram is _that_ performance critical,

Yes. PATH search is completely dwarfed by fork+exec time anyway
(on current x86 processors and kernels, fork+exec flushes entire
L1 data cache (too many pages copied/zeroed out)).
--
vda


From vda.linux at googlemail.com  Sun Feb  4 17:10:57 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 18:10:57 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <200702022243.56100.vda.linux@googlemail.com>
References: <1170428490.28276.35.camel@localhost>
	<200702022243.56100.vda.linux@googlemail.com>
Message-ID: <200702041810.57851.vda.linux@googlemail.com>

On Friday 02 February 2007 22:43, Denis Vlasenko wrote:
> On Friday 02 February 2007 16:01, Natanael Copa wrote:
> > Hi,
> > 
> > Attatched is a patch for support of the '!' operator for find.
> > 
> > I created another macro ALLOC_TEST for actions that can be inverted with
> > '!'. They are not really actions (like -print) but tests (like -name).
> > 
> > It should not touch anything unless you have enabled the
> > FEATURE_FIND_NOT config option.
> 
> parse_params():
> invert_flag is never reset to 0. This must be a bug -
> "not" shouldn't be applied to the second -name here, I think
> (did not check it versus GNU find, tho...):
> find ! -name '*.a' -o -name '*.b'

I did it myself. find ! support is in svn. Please test.
--
vda


From wharms at bfs.de  Sun Feb  4 17:44:14 2007
From: wharms at bfs.de (walter harms)
Date: Sun, 04 Feb 2007 18:44:14 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C5EE92.80307@nothome.org>
References: <45C56E49.9030907@Kriegisch.name> <45C5EE92.80307@nothome.org>
Message-ID: <45C61B6E.4010705@bfs.de>



hi nathan,
i could not find any security stuff (like preventing an rm -r /).
did you try check it out ?

maybe this is something that should go to the webpage.

re,
 wh


Nathan Anglacos wrote:
> [reposting to the busybox list]
> 
> 
> Alexander Kriegisch wrote:
>> Hi!
>>
>> I would like to know if httpd supports form-based uploads and how they
>> can be handled in plain shell scripts (/bin/sh). I would be glad to see
>> one or more sample script(s).
>>
>> Kind regards
> 
> Hi Alexander,
> 
> haserl (haserl.sourceforge.net) does what you are asking for.    haserl 
> is a C cgi script, and works with busybox httpd.
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
> 
> 


From pgf at brightstareng.com  Sun Feb  4 17:51:04 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Sun, 04 Feb 2007 12:51:04 -0500
Subject: Busybox build problem 
In-Reply-To: brion.finlay's message of Sat, 03 Feb 2007 14:02:41 -0600.
	<aa1451e00702031202l2e85adffuf8c45864b272bf74@mail.gmail.com> 
Message-ID: <10826.1170611464@brightstareng.com>

 > 
 > "New applications are encouraged to use
 > *printf* ... instead of *echo*."

perhaps busybox should start moving in this direction in its
build scripts?  (i've never tried this sort of conversion myself,
and don't know whether other portability issues would emerge
as a result...)

paul
=---------------------
 paul fox, pgf at brightstareng.com


From vda.linux at googlemail.com  Sun Feb  4 21:17:09 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 22:17:09 +0100
Subject: svn commit: trunk/busybox/libbb
In-Reply-To: <20070204203239.23E9B48657@busybox.net>
References: <20070204203239.23E9B48657@busybox.net>
Message-ID: <200702042217.09589.vda.linux@googlemail.com>

On Sunday 04 February 2007 21:32, aldot at busybox.net wrote:
> -void llist_add_to(llist_t **old_head, void *data)
> +void llist_add_to(llist_t ** old_head, void *data)

Why different style for llist_t* and void*?

I think than this particular aspect of style should
be left unspecified.
--
vda


From rep.dot.nop at gmail.com  Sun Feb  4 21:50:40 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 22:50:40 +0100
Subject: svn commit: trunk/busybox/libbb
In-Reply-To: <200702042217.09589.vda.linux@googlemail.com>
References: <20070204203239.23E9B48657@busybox.net>
	<200702042217.09589.vda.linux@googlemail.com>
Message-ID: <20070204215040.GQ12488@aon.at>

On Sun, Feb 04, 2007 at 10:17:09PM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 21:32, aldot at busybox.net wrote:
>> -void llist_add_to(llist_t **old_head, void *data)
>> +void llist_add_to(llist_t ** old_head, void *data)
>
>Why different style for llist_t* and void*?
>
>I think than this particular aspect of style should
>be left unspecified.

I remember that i once looked to make indent not treat them differently,
but didn't find how to specify that. If you -- or anybody else for that
matter -- spot which setting this is, then please adjust it or send a
patch.

TIA,


From somlo at cmu.edu  Sun Feb  4 23:22:17 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sun, 4 Feb 2007 18:22:17 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041707.33774.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
	<200702041707.33774.vda.linux@googlemail.com>
Message-ID: <20070204232217.GA16952@hedwig.net.cmu.edu>

Denis, Bernhard,

Here's the patch that adds bb_execvp(). I compiled it
with static and dynamic linking (against glibc, I know static there is
buggy, but I just wanted to see how the binary size was affected :) ).
Here's the results (I'm building all but maybe two of the applets that
call execvp()):

arch.   linking         standalone      macro calls     bytes   
                        macro           bb_execvp()     saved


        static          1257820         1257820         0 
i386
        dynamic          512136          512136         0 


        static          1677276         1676860         416 
ppc
        dynamic          659600          659600         0 

No clue how much (if anything) we'd save on other architectures. Also,
not clear why dynamically linked binaries aren't affected (maybe
there's some padding/alignment thing, but I'm not an expert on the ELF
format :)

Also, if you *want* a bb_execlp(), we could do the following,
(shamelessly ripped from glibc):

int bb_execlp (const char *file, const char *arg, ...)
{
#define INITIAL_ARGV_MAX 1024
  size_t argv_max = INITIAL_ARGV_MAX;
  const char *initial_argv[INITIAL_ARGV_MAX];
  const char **argv = initial_argv;
  va_list args;

  argv[0] = arg;

  va_start (args, arg);
  unsigned int i = 0;
  while (argv[i++] != NULL)
    {
      if (i == argv_max)
        {
          argv_max *= 2;
          const char **nptr = xrealloc (argv == initial_argv ? NULL : argv,
                                       argv_max * sizeof (const char *));
          if (nptr == NULL)
            {
              if (argv != initial_argv)
                free (argv);
              return -1;
            }
          if (argv == initial_argv)
            /* We have to copy the already filled-in data ourselves.  */
            memcpy (nptr, argv, i * sizeof (const char *));

          argv = nptr;
        }

      argv[i] = va_arg (args, const char *);
    }
  va_end (args);

  int ret = bb_execvp (file, (char *const *) argv);
  if (argv != initial_argv)
    free (argv);

  return ret;
}

But given how few the places it's being called from, we'd end up maybe
increasing the size slightly instead of saving a few bytes.

(now, I don't know how many places call execl() with hardcoded paths
that should really be calling BB_EXECLP(), but that's something I'll
be looking into next :) )

OK, so given the meager space savings, do you guys still want this, or
should we stick with standalone macros ?

Here goes the patch.
Cheers,
--Gabriel

diff -NarU5 busybox-svn-17770.orig/libbb/execable.c busybox-svn-17770/libbb/execable.c
--- busybox-svn-17770.orig/libbb/execable.c	2007-02-04 16:25:51.000000000 -0500
+++ busybox-svn-17770/libbb/execable.c	2007-02-04 17:43:13.000000000 -0500
@@ -57,5 +57,15 @@
 		free(ret);
 		return 1;
 	}
 	return 0;
 }
+
+#ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
+/* just like the real execvp, but try to launch an applet named 'file' first
+ */
+int bb_execvp(const char *file, char *const argv[])
+{
+	return execvp(find_applet_by_name(file) ? CONFIG_BUSYBOX_EXEC_PATH : file,
+					argv);
+}
+#endif
diff -NarU5 busybox-svn-17770.orig/include/libbb.h busybox-svn-17770/include/libbb.h
--- busybox-svn-17770.orig/include/libbb.h	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/include/libbb.h	2007-02-04 17:42:54.000000000 -0500
@@ -560,12 +560,12 @@
 int execable_file(const char *name);
 char *find_execable(const char *filename);
 int exists_execable(const char *filename);
 
 #ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
-#define BB_EXECVP(prog,cmd) \
-	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
+int bb_execvp(const char *file, char *const argv[]);
+#define BB_EXECVP(prog,cmd) bb_execvp(prog,cmd)
 #define BB_EXECLP(prog,cmd,...) \
 	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
 #else
 #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
 #define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 


From somlo at cmu.edu  Sun Feb  4 23:23:55 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sun, 4 Feb 2007 18:23:55 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041707.33774.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
	<200702041707.33774.vda.linux@googlemail.com>
Message-ID: <20070204232355.GB16952@hedwig.net.cmu.edu>

... And here's the rest of it again -- converting exec*p to BB_EXEC*P.

Either way you decide to go with bb_exec*p(), this should be applied
regardless... :)

Thanks,
Gabriel


diff -NarU5 busybox-svn-17770.orig/archival/tar.c busybox-svn-17770/archival/tar.c
--- busybox-svn-17770.orig/archival/tar.c	2007-02-04 16:25:47.000000000 -0500
+++ busybox-svn-17770/archival/tar.c	2007-02-04 16:30:04.000000000 -0500
@@ -527,11 +527,11 @@
 			dup2(tbInfo.tarFd, 1);
 
 			close(gzipStatusPipe[0]);
 			fcntl(gzipStatusPipe[1], F_SETFD, FD_CLOEXEC);	/* close on exec shows success */
 
-			execlp(zip_exec, zip_exec, "-f", NULL);
+			BB_EXECLP(zip_exec, zip_exec, "-f", NULL);
 			vfork_exec_errno = errno;
 
 			close(gzipStatusPipe[1]);
 			exit(-1);
 		} else if (gzipPid > 0) {
diff -NarU5 busybox-svn-17770.orig/console-tools/openvt.c busybox-svn-17770/console-tools/openvt.c
--- busybox-svn-17770.orig/console-tools/openvt.c	2007-02-04 16:25:47.000000000 -0500
+++ busybox-svn-17770/console-tools/openvt.c	2007-02-04 16:30:04.000000000 -0500
@@ -34,10 +34,10 @@
 		dup2(fd, STDIN_FILENO);
 		dup2(fd, STDOUT_FILENO);
 		dup2(fd, STDERR_FILENO);
 		while (fd > 2) close(fd--);
 
-		execvp(argv[2], &argv[2]);
+		BB_EXECVP(argv[2], &argv[2]);
 		_exit(1);
 	}
 	return EXIT_SUCCESS;
 }
diff -NarU5 busybox-svn-17770.orig/coreutils/chroot.c busybox-svn-17770/coreutils/chroot.c
--- busybox-svn-17770.orig/coreutils/chroot.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/chroot.c	2007-02-04 16:30:04.000000000 -0500
@@ -31,8 +31,8 @@
 			*argv = (char *) DEFAULT_SHELL;
 		}
 		argv[1] = (char *) "-i";
 	}
 
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("cannot execute %s", *argv);
 }
diff -NarU5 busybox-svn-17770.orig/coreutils/env.c busybox-svn-17770/coreutils/env.c
--- busybox-svn-17770.orig/coreutils/env.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/env.c	2007-02-04 16:30:04.000000000 -0500
@@ -79,11 +79,11 @@
 		}
 		++argv;
 	}
 
 	if (*argv) {
-		execvp(*argv, argv);
+		BB_EXECVP(*argv, argv);
 		/* SUSv3-mandated exit codes. */
 		xfunc_error_retval = (errno == ENOENT) ? 127 : 126;
 		bb_perror_msg_and_die("%s", *argv);
 	}
 
diff -NarU5 busybox-svn-17770.orig/coreutils/install.c busybox-svn-17770/coreutils/install.c
--- busybox-svn-17770.orig/coreutils/install.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/install.c	2007-02-04 16:30:04.000000000 -0500
@@ -124,11 +124,11 @@
 		) {
 			bb_perror_msg("cannot change ownership of %s", dest);
 			ret = EXIT_FAILURE;
 		}
 		if (flags & OPT_STRIP) {
-			if (execlp("strip", "strip", dest, NULL) == -1) {
+			if (BB_EXECLP("strip", "strip", dest, NULL) == -1) {
 				bb_perror_msg("strip");
 				ret = EXIT_FAILURE;
 			}
 		}
 		if (ENABLE_FEATURE_CLEAN_UP && isdir) free(dest);
diff -NarU5 busybox-svn-17770.orig/coreutils/nice.c busybox-svn-17770/coreutils/nice.c
--- busybox-svn-17770.orig/coreutils/nice.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/nice.c	2007-02-04 16:30:04.000000000 -0500
@@ -45,11 +45,11 @@
 		if (setpriority(PRIO_PROCESS, 0, prio) < 0) {
 			bb_perror_msg_and_die("setpriority(%d)", prio);
 		}
 	}
 
-	execvp(*argv, argv);		/* Now exec the desired program. */
+	BB_EXECVP(*argv, argv);		/* Now exec the desired program. */
 
 	/* The exec failed... */
 	xfunc_error_retval = (errno == ENOENT) ? 127 : 126; /* SUSv3 */
 	bb_perror_msg_and_die("%s", *argv);
 }
diff -NarU5 busybox-svn-17770.orig/coreutils/nohup.c busybox-svn-17770/coreutils/nohup.c
--- busybox-svn-17770.orig/coreutils/nohup.c	2007-02-04 16:25:49.000000000 -0500
+++ busybox-svn-17770/coreutils/nohup.c	2007-02-04 16:30:04.000000000 -0500
@@ -51,10 +51,10 @@
 
 	if (nullfd > 2)
 		close(nullfd);
 	signal(SIGHUP, SIG_IGN);
 
-	execvp(argv[1], argv+1);
+	BB_EXECVP(argv[1], argv+1);
 	if (ENABLE_FEATURE_CLEAN_UP && home)
 		free((char*)nohupout);
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17770.orig/e2fsprogs/fsck.c busybox-svn-17770/e2fsprogs/fsck.c
--- busybox-svn-17770.orig/e2fsprogs/fsck.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/e2fsprogs/fsck.c	2007-02-04 16:30:04.000000000 -0500
@@ -675,11 +675,11 @@
 			if (!interactive) {
 				/* NB: e2fsck will complain because of this!
 				 * Use "fsck -s" to avoid... */
 				close(0);
 			}
-			execvp(argv[0], argv);
+			BB_EXECVP(argv[0], argv);
 			bb_perror_msg_and_die("%s", argv[0]);
 		}
 	}
 
 	for (i = num_args+1; i < argc; i++)
diff -NarU5 busybox-svn-17770.orig/findutils/xargs.c busybox-svn-17770/findutils/xargs.c
--- busybox-svn-17770.orig/findutils/xargs.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/findutils/xargs.c	2007-02-04 16:30:04.000000000 -0500
@@ -58,11 +58,11 @@
 	if (p < 0)
 		bb_perror_msg_and_die("vfork");
 
 	if (p == 0) {
 		/* vfork -- child */
-		execvp(args[0], args);
+		BB_EXECVP(args[0], args);
 		exec_errno = errno;     /* set error to shared stack */
 		_exit(1);
 	}
 
 	/* vfork -- parent */
diff -NarU5 busybox-svn-17770.orig/loginutils/adduser.c busybox-svn-17770/loginutils/adduser.c
--- busybox-svn-17770.orig/loginutils/adduser.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/loginutils/adduser.c	2007-02-04 16:30:04.000000000 -0500
@@ -78,11 +78,11 @@
 static void passwd_wrapper(const char *login) ATTRIBUTE_NORETURN;
 
 static void passwd_wrapper(const char *login)
 {
 	static const char prog[] = "passwd";
-	execlp(prog, prog, login, NULL);
+	BB_EXECLP(prog, prog, login, NULL);
 	bb_error_msg_and_die("failed to execute '%s', you must set the password for '%s' manually", prog, login);
 }
 
 /* putpwent(3) remix */
 static int adduser(struct passwd *p, unsigned long flags)
diff -NarU5 busybox-svn-17770.orig/loginutils/login.c busybox-svn-17770/loginutils/login.c
--- busybox-svn-17770.orig/loginutils/login.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/loginutils/login.c	2007-02-04 16:30:04.000000000 -0500
@@ -355,11 +355,11 @@
 				setenv("LOGIN_TTY", full_tty, 1);
 				setenv("LOGIN_USER", pw->pw_name, 1);
 				setenv("LOGIN_UID", utoa(pw->pw_uid), 1);
 				setenv("LOGIN_GID", utoa(pw->pw_gid), 1);
 				setenv("LOGIN_SHELL", pw->pw_shell, 1);
-				execvp(script, t_argv);
+				BB_EXECVP(script, t_argv);
 				exit(1);
 			default: /* parent */
 				wait(NULL);
 			}
 		}
diff -NarU5 busybox-svn-17770.orig/miscutils/devfsd.c busybox-svn-17770/miscutils/devfsd.c
--- busybox-svn-17770.orig/miscutils/devfsd.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/devfsd.c	2007-02-04 16:30:04.000000000 -0500
@@ -376,11 +376,11 @@
 		exit (EXIT_SUCCESS);
 	}
 	 /* Child : if arg0 != NULL do execvp */
 	if(arg0 != NULL )
 	{
-		execvp (arg0, arg);
+		BB_EXECVP(arg0, arg);
 		msg_logger_and_die(LOG_ERR, "execvp");
 	}
 }
 
 static void safe_memcpy( char *dest, const char *src, int len)
diff -NarU5 busybox-svn-17770.orig/miscutils/setsid.c busybox-svn-17770/miscutils/setsid.c
--- busybox-svn-17770.orig/miscutils/setsid.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/setsid.c	2007-02-04 16:30:04.000000000 -0500
@@ -34,9 +34,9 @@
 	}
 	/* child */
 
 	setsid();  /* no error possible */
 
-	execvp(argv[1], argv + 1);
+	BB_EXECVP(argv[1], argv + 1);
 
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17770.orig/miscutils/taskset.c busybox-svn-17770/miscutils/taskset.c
--- busybox-svn-17770.orig/miscutils/taskset.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/taskset.c	2007-02-04 16:30:04.000000000 -0500
@@ -89,11 +89,11 @@
 		state += 8;
 		++argv;
 		goto print_aff;
 	}
 	++argv;
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("%s", *argv);
 }
 #undef OPT_p
 #undef TASKSET_PRINTF_MASK
 #undef from_cpuset
diff -NarU5 busybox-svn-17770.orig/miscutils/time.c busybox-svn-17770/miscutils/time.c
--- busybox-svn-17770.orig/miscutils/time.c	2007-02-04 16:25:52.000000000 -0500
+++ busybox-svn-17770/miscutils/time.c	2007-02-04 16:30:04.000000000 -0500
@@ -408,11 +408,11 @@
 	if (pid < 0)
 		bb_error_msg_and_die("cannot fork");
 	else if (pid == 0) {	/* If child.  */
 		/* Don't cast execvp arguments; that causes errors on some systems,
 		   versus merely warnings if the cast is left off.  */
-		execvp(cmd[0], cmd);
+		BB_EXECVP(cmd[0], cmd);
 		bb_error_msg("cannot run %s", cmd[0]);
 		_exit(errno == ENOENT ? 127 : 126);
 	}
 
 	/* Have signals kill the child but not self (if possible).  */
diff -NarU5 busybox-svn-17770.orig/networking/ifupdown.c busybox-svn-17770/networking/ifupdown.c
--- busybox-svn-17770.orig/networking/ifupdown.c	2007-02-04 16:25:44.000000000 -0500
+++ busybox-svn-17770/networking/ifupdown.c	2007-02-04 16:30:04.000000000 -0500
@@ -1002,11 +1002,11 @@
 		dup2(outfd[1], 1);
 		close(infd[0]);
 		close(infd[1]);
 		close(outfd[0]);
 		close(outfd[1]);
-		execvp(command, argv);
+		BB_EXECVP(command, argv);
 		exit(127);
 	default:			/* parent */
 		*in = fdopen(infd[1], "w");
 		*out = fdopen(outfd[0], "r");
 		close(infd[0]);
diff -NarU5 busybox-svn-17770.orig/networking/nc.c busybox-svn-17770/networking/nc.c
--- busybox-svn-17770.orig/networking/nc.c	2007-02-04 16:25:44.000000000 -0500
+++ busybox-svn-17770/networking/nc.c	2007-02-04 16:30:04.000000000 -0500
@@ -147,11 +147,11 @@
 			dup2(cfd, 0);
 			close(cfd);
 		}
 		dup2(0, 1);
 		dup2(0, 2);
-		USE_NC_EXTRA(execvp(execparam[0], execparam);)
+		USE_NC_EXTRA(BB_EXECVP(execparam[0], execparam);)
 		/* Don't print stuff or it will go over the wire.... */
 		_exit(127);
 	}
 
 	// Select loop copying stdin to cfd, and cfd to stdout.
diff -NarU5 busybox-svn-17770.orig/runit/chpst.c busybox-svn-17770/runit/chpst.c
--- busybox-svn-17770.orig/runit/chpst.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/runit/chpst.c	2007-02-04 16:30:04.000000000 -0500
@@ -308,11 +308,11 @@
 	if (env_user) euidgid(env_user);
 	if (set_user) suidgid(set_user);
 	if (OPT_nostdin) close(0);
 	if (OPT_nostdout) close(1);
 	if (OPT_nostderr) close(2);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void setuidgid(int argc, char **argv)
 {
@@ -320,11 +320,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	suidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envuidgid(int argc, char **argv)
 {
@@ -332,11 +332,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	euidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envdir(int argc, char **argv)
 {
@@ -344,11 +344,11 @@
 
 	dir = *++argv;
 	if (!dir) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	edir(dir);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void softlimit(int argc, char **argv)
 {
@@ -367,8 +367,8 @@
 	if (option_mask32 & 0x200) limits = xatoul(s); // -s
 	if (option_mask32 & 0x400) limitt = xatoul(t); // -t
 	argv += optind;
 	if (!argv[0]) bb_show_usage();
 	slimit();
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
diff -NarU5 busybox-svn-17770.orig/runit/runsvdir.c busybox-svn-17770/runit/runsvdir.c
--- busybox-svn-17770.orig/runit/runsvdir.c	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/runit/runsvdir.c	2007-02-04 16:30:04.000000000 -0500
@@ -71,11 +71,11 @@
 		prog[1] = (char*)name;
 		prog[2] = NULL;
 		sig_uncatch(SIGHUP);
 		sig_uncatch(SIGTERM);
 		if (pgrp) setsid();
-		execvp(prog[0], prog);
+		BB_EXECVP(prog[0], prog);
 		//pathexec_run(*prog, prog, (char* const*)environ);
 		fatal2_cannot("start runsv ", name);
 	}
 	sv[no].pid = pid;
 }
diff -NarU5 busybox-svn-17770.orig/util-linux/setarch.c busybox-svn-17770/util-linux/setarch.c
--- busybox-svn-17770.orig/util-linux/setarch.c	2007-02-04 16:25:54.000000000 -0500
+++ busybox-svn-17770/util-linux/setarch.c	2007-02-04 16:30:04.000000000 -0500
@@ -44,10 +44,10 @@
 
 	/* Try to set personality */
 	if (personality(pers) >= 0) {
 
 		/* Try to execute the program */
-		execvp(argv[0], argv);
+		BB_EXECVP(argv[0], argv);
 	}
 
 	bb_perror_msg_and_die("%s", argv[0]);
 }


From nangel at nothome.org  Mon Feb  5 01:00:22 2007
From: nangel at nothome.org (Nathan Angelacos)
Date: Mon, 05 Feb 2007 01:00:22 +0000
Subject: httpd and form-based upload
In-Reply-To: <45C61B6E.4010705@bfs.de>
References: <45C56E49.9030907@Kriegisch.name> <45C5EE92.80307@nothome.org>
	<45C61B6E.4010705@bfs.de>
Message-ID: <45C681A6.1090409@nothome.org>

walter harms wrote:
> 
> hi nathan,
> i could not find any security stuff (like preventing an rm -r /).
> did you try check it out ?
> 
> maybe this is something that should go to the webpage.
> 
> re,
>  wh
> 
Hi walter,

I'm not sure I understand your question.

haserl does the parsing of http GET/POST and mime-encoded http requests.
 That's what Alexander was asking about.  Its is a tool, like busybox or
netcat is a tool.

If someone really wants to make a web page that does "rm -rf /" - I
guess its a self-limiting problem. ;-)




From Alexander at Kriegisch.name  Mon Feb  5 01:33:04 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Mon, 05 Feb 2007 02:33:04 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C681A6.1090409@nothome.org>
References: <45C56E49.9030907@Kriegisch.name>
	<45C5EE92.80307@nothome.org>	<45C61B6E.4010705@bfs.de>
	<45C681A6.1090409@nothome.org>
Message-ID: <45C68950.20007@Kriegisch.name>

@Walter: I agree with Nathan. Besides, in my special case the router's
config web interface is not accessible from "outside" anyway. Haserl is
a tool facilitating what I want.

@Nathan: Maybe Walter speaks of code injection. Anyway, Haserl's man
page even mentions an example showing how to filter the content of HTML
form fields. That should be a starter for those who need or want to
provide their web pages with more security.

For me it works brilliantly, thank you. I guess Haserl will make its way
into our standard firmware mod for the AVM Fritz!Box router series.

Regards
--
Alexander Kriegisch



Nathan Angelacos wrote:
> walter harms wrote:
>> hi nathan,
>> i could not find any security stuff (like preventing an rm -r /).
>> did you try check it out ?
>
> Hi walter,
> 
> I'm not sure I understand your question.
> 
> haserl does the parsing of http GET/POST and mime-encoded http
> requests. That's what Alexander was asking about. Its is a tool, like
> busybox or netcat is a tool.
> 
> If someone really wants to make a web page that does "rm -rf /" - I 
> guess its a self-limiting problem. ;-)>



From farmatito at tiscali.it  Mon Feb  5 06:20:54 2007
From: farmatito at tiscali.it (Tito)
Date: Mon, 5 Feb 2007 07:20:54 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204232355.GB16952@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
Message-ID: <200702050720.54286.farmatito@tiscali.it>

On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> +???????BB_EXECVP(*argv, argv);
> ????????bb_perror_msg_and_die("cannot execute %s", *argv);

Hi,
shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
be moved inside  BB_EXECVP(*argv, argv); ?
This would probably save some space.

Ciao,
Tito 


From rep.dot.nop at gmail.com  Mon Feb  5 08:49:00 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Mon, 5 Feb 2007 09:49:00 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702050720.54286.farmatito@tiscali.it>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
	<200702050720.54286.farmatito@tiscali.it>
Message-ID: <20070205084900.GB5399@aon.at>

On Mon, Feb 05, 2007 at 07:20:54AM +0100, Tito wrote:
>On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
>> +???????BB_EXECVP(*argv, argv);
>> ????????bb_perror_msg_and_die("cannot execute %s", *argv);
>
>Hi,
>shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
>be moved inside  BB_EXECVP(*argv, argv); ?
>This would probably save some space.

seconded :)

Also, i'd add a bb_msg_exec_failed
and fixup svngrep -ri "exec.*%s" *  to use that msg instead of growing
a dozend of separate messages for this very same error, but maybe that's
just me :P


From rupesh_gujare at rediffmail.com  Mon Feb  5 09:21:13 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 5 Feb 2007 09:21:13 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070205092113.603.qmail@webmail8.rediffmail.com>

  
Hello all,
 I am a newbie to busybox.. Dont know whether it is right place to ask..
  I am building embedded linux.. and using initrd image to boot linux at the start. I am booting from USB pen drive.
  But problem is after booting from pen drive, i am unable to remove initrd image. and mount my real filesystem.
  My initrd image includes busybox links and rcS script. I am using busybox 1.3.1

My /etc/init.d/rcS file is as follow:-
 
#!/bin/sh
# Remount the root filesystem in read-write (requires /etc/fstab)
mount -n -o remount,rw /
# Mount /proc filesystem
mount /proc

/etc/inittab:----

::sysinit:/etc/init.d/rcS
::restart:/sbin/init
::shutdown:/bin/umount -a -r
::respawn:/bin/sh 

fstab:----
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/sda1 / ext2 defaults,errors=remount-ro 0 1

After booting system still i gets initrd image as a root file system.
Can anyone tell me what i am doing wrong?
 Thanks in advance 
 Rupesh..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070205/e3a9336e/attachment.htm 

From vapier at gentoo.org  Mon Feb  5 09:38:54 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 5 Feb 2007 04:38:54 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702021458.59394.rob@landley.net>
References: <200701282116.46840.vapier@gentoo.org>
	<200702010312.34740.vapier@gentoo.org>
	<200702021458.59394.rob@landley.net>
Message-ID: <200702050438.55998.vapier@gentoo.org>

On Friday 02 February 2007, Rob Landley wrote:
> On Thursday 01 February 2007 3:12 am, Mike Frysinger wrote:
> > busybox is failing because it's
> > trying to generate depmod and build modules
>
> Because your "larger build system" (which we didn't write) is calling make
> modules on busybox?

incorrect ... the busybox system changes the default all dependencies based 
upon the environment it is run in

so if the host env has the same defines that the kernel uses, then busybox 
will incorrectly try and generate modules (since it is really just using the 
kernel build)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070205/532c53e6/attachment-0002.pgp 

From vapier at gentoo.org  Mon Feb  5 09:41:55 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 5 Feb 2007 04:41:55 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702020014.21335.vda.linux@googlemail.com>
References: <200701282116.46840.vapier@gentoo.org>
	<200702010312.34740.vapier@gentoo.org>
	<200702020014.21335.vda.linux@googlemail.com>
Message-ID: <200702050441.56413.vapier@gentoo.org>

On Thursday 01 February 2007, Denis Vlasenko wrote:
> Huh, if this is really getting problematic,
> then feel free to chainsaw "modular" support off.
>
> Or just rename makefile targets ('modules' -> 'dont_use_me__modules')

i'm referring to the env checking ... change things like so:
-ifdef CONFIG_MODULES
+ifdef CONFIG_MODULES____BUSYBOX_DOES_NOT_USE_THIS

that way doing diffs between the build systems should show up pretty clearly 
as to what is a local change and what should be updated

> if you don't want to spend too much time on things which
> do not materially improve generated code.

really dont know what you're referring to here
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070205/44c032ea/attachment-0002.pgp 

From somlo at cmu.edu  Mon Feb  5 13:13:48 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Mon, 5 Feb 2007 08:13:48 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070205084900.GB5399@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
	<200702050720.54286.farmatito@tiscali.it>
	<20070205084900.GB5399@aon.at>
Message-ID: <20070205131348.GA22190@hedwig.net.cmu.edu>

On Mon, Feb 05, 2007 at 09:49:00AM +0100, Bernhard Fischer wrote:
> On Mon, Feb 05, 2007 at 07:20:54AM +0100, Tito wrote:
> >On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> >> +???????BB_EXECVP(*argv, argv);
> >> ????????bb_perror_msg_and_die("cannot execute %s", *argv);
> >
> >Hi,
> >shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
> >be moved inside  BB_EXECVP(*argv, argv); ?
> >This would probably save some space.
> 
> seconded :)

I too noticed that a lot of the code surrounding execvp/BB_EXECVP
looks similar in a lot of the places it happens. However, BB_EXECVP
was meant as strictly a drop-in replacement for the execvp function
call. Maybe what we want to do is find a way to replace a lot of the
boilerplate code with a call to spawn() (in libbb/xfuncs.c) instead...

Cheers,
Gabriel

> 
> Also, i'd add a bb_msg_exec_failed
> and fixup svngrep -ri "exec.*%s" *  to use that msg instead of growing
> a dozend of separate messages for this very same error, but maybe that's
> just me :P
> 


From floydpink at gmail.com  Mon Feb  5 13:40:15 2007
From: floydpink at gmail.com (Jason Schoon)
Date: Mon, 5 Feb 2007 07:40:15 -0600
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070205092113.603.qmail@webmail8.rediffmail.com>
References: <20070205092113.603.qmail@webmail8.rediffmail.com>
Message-ID: <78a54e1b0702050540t13dee290jc0e9b542b27843c9@mail.gmail.com>

On 5 Feb 2007 09:21:13 -0000, Rupesh Gujare <rupesh_gujare at rediffmail.com>
wrote:
>
>
> After booting system still i gets initrd image as a root file system.
> Can anyone tell me what i am doing wrong?
> Thanks in advance
> Rupesh..
>

man pivot_root

If you are on a 2.6 kernel though, you should do some google searching on
initramfs and switch_root (provided by Busybox).  There is a good starting
point regarding initramfs in the Linux kernel Documentation directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070205/9c1775c5/attachment-0002.htm 

From rupesh_gujare at rediffmail.com  Mon Feb  5 14:11:36 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 5 Feb 2007 14:11:36 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070205141136.5944.qmail@webmail81.rediffmail.com>

  
I had tried with pivot_root:
 I entered 
/bin/sh  in /etc/rcS
and after mounting /proc tried to do pivot_root
 it gives me 
pivot_root:pivot_root: Device or resource busy.
 any clue why it is like this?

 Regarding initramfs.. i am not aware of it by too much.. i will try to find out more about it.. Is it more easier than ramdisk image?

 Your suggestions are greatly appreciated
 Thanks in advance 
Rupesh
 


On Mon, 05 Feb 2007 Jason Schoon wrote :
>On 5 Feb 2007 09:21:13 -0000, Rupesh Gujare <rupesh_gujare at rediffmail.com>
>wrote:
>>
>>
>>After booting system still i gets initrd image as a root file system.
>>Can anyone tell me what i am doing wrong?
>>Thanks in advance
>>Rupesh..
>>
>
>man pivot_root
>
>If you are on a 2.6 kernel though, you should do some google searching on
>initramfs and switch_root (provided by Busybox).  There is a good starting
>point regarding initramfs in the Linux kernel Documentation directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070205/5d3d2ba7/attachment.htm 

From rupesh_gujare at rediffmail.com  Mon Feb  5 14:11:53 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 5 Feb 2007 14:11:53 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070205141153.21424.qmail@webmail100.rediffmail.com>

  
I had tried with pivot_root:
 I entered 
/bin/sh  in /etc/rcS
and after mounting /proc tried to do pivot_root
 it gives me 
pivot_root:pivot_root: Device or resource busy.
 any clue why it is like this?

 Regarding initramfs.. i am not aware of it by too much.. i will try to find out more about it.. Is it more easier than ramdisk image?

 Your suggestions are greatly appreciated
 Thanks in advance 
Rupesh
 


On Mon, 05 Feb 2007 Jason Schoon wrote :
>On 5 Feb 2007 09:21:13 -0000, Rupesh Gujare <rupesh_gujare at rediffmail.com>
>wrote:
>>
>>
>>After booting system still i gets initrd image as a root file system.
>>Can anyone tell me what i am doing wrong?
>>Thanks in advance
>>Rupesh..
>>
>
>man pivot_root
>
>If you are on a 2.6 kernel though, you should do some google searching on
>initramfs and switch_root (provided by Busybox).  There is a good starting
>point regarding initramfs in the Linux kernel Documentation directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070205/f15223e1/attachment-0002.htm 

From rob at landley.net  Mon Feb  5 16:10:59 2007
From: rob at landley.net (Rob Landley)
Date: Mon, 5 Feb 2007 11:10:59 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702050438.55998.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200702021458.59394.rob@landley.net>
	<200702050438.55998.vapier@gentoo.org>
Message-ID: <200702051111.00383.rob@landley.net>

On Monday 05 February 2007 4:38 am, Mike Frysinger wrote:
> On Friday 02 February 2007, Rob Landley wrote:
> > On Thursday 01 February 2007 3:12 am, Mike Frysinger wrote:
> > > busybox is failing because it's
> > > trying to generate depmod and build modules
> >
> > Because your "larger build system" (which we didn't write) is calling make
> > modules on busybox?
> 
> incorrect ... the busybox system changes the default all dependencies based 
> upon the environment it is run in

What's the "default all dependencies"?  You mean the default behavior of "make 
all"?  (I don't think you mean "make depend" because that's not there 
anymore...)

> so if the host env has the same defines that the kernel uses, then busybox  
> will incorrectly try and generate modules (since it is really just using the 
> kernel build)

Ok, once again guessing at your meaning, I take it this isn't "#defines" but 
environment variables you're talking about?

Changing behavior based on random environment variables is bad, but the Linux 
From Scratch project goes out of its way to tell you to blank certain 
environment variables because they've been known to screw things up if you 
don't.  That's a known problem and a "don't do that".

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery


From somlo at cmu.edu  Mon Feb  5 16:40:26 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Mon, 5 Feb 2007 11:40:26 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041707.33774.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
	<200702041707.33774.vda.linux@googlemail.com>
Message-ID: <20070205164026.GB23779@hedwig.net.cmu.edu>


Denis, Bernhard,

Here's a version that provides both a bb_execvp() and a bb_execlp()
function. The latter is a simplified version of the glibc one, but
returns E2BIG when more than 16 arguments are passed into it, and does
have the code that would grow the argv array dynamically while reading
its varargs. That should not be a problem, as all execlp calls I've
seen so far in busybox have maybe four arguments max...

Cheers,
Gabriel



diff -NarU5 busybox-svn-17770.orig/include/libbb.h busybox-svn-17770/include/libbb.h
--- busybox-svn-17770.orig/include/libbb.h	2007-02-04 16:25:53.000000000 -0500
+++ busybox-svn-17770/include/libbb.h	2007-02-05 11:33:12.000000000 -0500
@@ -560,14 +560,14 @@
 int execable_file(const char *name);
 char *find_execable(const char *filename);
 int exists_execable(const char *filename);
 
 #ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
-#define BB_EXECVP(prog,cmd) \
-	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
-#define BB_EXECLP(prog,cmd,...) \
-	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
+int bb_execvp(const char *file, char *const argv[]);
+int bb_execlp(const char *file, const char *arg, ...);
+#define BB_EXECVP(prog,cmd) bb_execvp(prog,cmd)
+#define BB_EXECLP(prog,cmd,...) bb_execlp(prog,cmd, __VA_ARGS__) 
 #else
 #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
 #define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
 #endif
 
diff -NarU5 busybox-svn-17770.orig/libbb/execable.c busybox-svn-17770/libbb/execable.c
--- busybox-svn-17770.orig/libbb/execable.c	2007-02-04 16:25:51.000000000 -0500
+++ busybox-svn-17770/libbb/execable.c	2007-02-05 11:30:55.000000000 -0500
@@ -57,5 +57,42 @@
 		free(ret);
 		return 1;
 	}
 	return 0;
 }
+
+#ifdef ENABLE_FEATURE_EXEC_PREFER_APPLETS
+/* just like the real execvp, but try to launch an applet named 'file' first
+ */
+int bb_execvp(const char *file, char *const argv[])
+{
+	return execvp(find_applet_by_name(file) ? CONFIG_BUSYBOX_EXEC_PATH : file,
+					argv);
+}
+
+/* just like the real execlp, but try to launch an applet named 'file' first
+ * (since there's no good way to handle varargs here, we unroll execlp and
+ *  replace the execvp call with a bb_execvp call :)
+ */
+int bb_execlp (const char *file, const char *arg, ...)
+{
+	#define ARGV_MAX 16
+	const char *argv[ARGV_MAX];
+	unsigned int i = 0;
+	va_list args;
+
+	argv[0] = arg;
+
+	va_start(args, arg);
+	while (argv[i++] != NULL && i < ARGV_MAX) {
+		argv[i] = va_arg(args, const char *);
+	}
+	va_end(args);
+
+	if (i >= ARGV_MAX) {
+		errno = E2BIG;
+		return -1;
+	}
+
+	return bb_execvp(file, (char *const *)argv);
+}
+#endif


From sortiz at olivetti-engineering.com  Mon Feb  5 16:33:06 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Mon, 05 Feb 2007 17:33:06 +0100
Subject: [PATCH] udhcp: infinite retries
Message-ID: <45C75C42.8040302@olivetti-engineering.com>

Hi All,

It may be useful (at least it is for us) to keep on sending DHCP request 
and renewals for ever until we actually get an answer. For that purpose 
udhcpc -t 0 could do the job.
Attached you will find the corresponding patch, please let me know if 
you'd consider it for inclusion.

Cheers,
Samuel.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_udhcpc_retries
Url: http://lists.busybox.net/pipermail/busybox/attachments/20070205/6dc82d9e/attachment.diff 

From akennedy at techmoninc.com  Mon Feb  5 18:25:49 2007
From: akennedy at techmoninc.com (Andy Kennedy)
Date: Mon, 05 Feb 2007 12:25:49 -0600
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <20070201005758.GA19486@nsk.no-ip.org>
References: <45C0EA70.4080508@techmoninc.com> <45C0EBB2.1090604@seiner.com>
	<45C0F180.4000904@techmoninc.com> <45C11D80.20906@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
Message-ID: <45C776AD.5090602@techmoninc.com>

Luciano Miguel Ferreira Rocha wrote:
> On Wed, Jan 31, 2007 at 04:51:44PM -0600, Andy Kennedy wrote:
>   
>> Anyone have ANY idea about this???  Anyone else have a buildroot/busybox 
>> setup that uses a serial console?
>>     
> 3. boot scripts set serial speed:
> for d in /dev/ttyS* /dev/ttyAM* /dev/ttyUSB*; do
>     [ -e "$d" ] && stty -F $d ospeed 57600
> done
Attempted this.  Didn't help.  To restate my problem (in case some kind 
developer decides to help me):

When I have the kernel command line parameter "console=ttyS0,115200n8" I 
get nice neat output on the serial line up until the init runs.  As soon 
as init runs, I get missing chars.  So, I replace the BusyBox init with 
minit, compiled from source and using the uCLibC gcc that I let 
buildroot make for me.  Same problem.  For some reason, when the system 
initializes -- after the kernel has reported all of its output, my 
serial console goes splat.  When I initialize the console using BusyBox 
(/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is {'i', 'g', 
's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  One of these 
letters will appear each time I send enter.

I have tried everything I can think of.  There is no script setting any 
of the line speeds -- in fact, I have even attempted to remove the 
scripts and still get the same thing.  Removing the 
console=ttyS0,115200n8 (or attempting any variant of it) has no affect, 
except without the console= I get no good output on the line.  The only 
thing I haven't attempted yet is to replace the getty with an equivalent 
to see if that makes a difference.  I have also tried 9600, 38400, 
19200, with E8, O8, 2 stop bits, and 1 stop bit in just about every 
combination, but I still cannot get a serial console.

Can anyone offer a suggestion as to how I might fix this -- or some 
other place to start?

Thanks in advance for any help you can offer,
Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: akennedy.vcf
Type: text/x-vcard
Size: 256 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070205/43f16d7e/attachment-0002.vcf 

From vda.linux at googlemail.com  Tue Feb  6 00:48:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 01:48:45 +0100
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070205141136.5944.qmail@webmail81.rediffmail.com>
References: <20070205141136.5944.qmail@webmail81.rediffmail.com>
Message-ID: <200702060148.45448.vda.linux@googlemail.com>

On Monday 05 February 2007 15:11, Rupesh Gujare wrote:
> 
> I had tried with pivot_root:
>  I entered 
> /bin/sh  in /etc/rcS
> and after mounting /proc tried to do pivot_root
>  it gives me 
> pivot_root:pivot_root: Device or resource busy.
>  any clue why it is like this?

Oh, wonderful problem report. No solid info on what exactly
you did (params to pivot_root etc...).

Anyway, a part of my homemade initrd whcu does pivot_root
(bu this time "new" rootfs is mounted on /new_root):


# Clean up
#umount /sys
umount /proc

echo "# Chrooting into root fs"
# we expect that /dev/console and /dev/null exist in /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc || {
    echo "pivot_root failed. Fatal, cannot continue booting"
    while true; do sleep 32000; done
}

exec \
chroot . \
sh -c '\
umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
exec /bin/env - /sbin/init
'

echo "chroot . sh failed. Fatal, cannot continue booting"
while true; do sleep 32000; done


Hope this helps
--
vda


From vda.linux at googlemail.com  Tue Feb  6 00:58:21 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 01:58:21 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070205131348.GA22190@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070205084900.GB5399@aon.at>
	<20070205131348.GA22190@hedwig.net.cmu.edu>
Message-ID: <200702060158.21461.vda.linux@googlemail.com>

On Monday 05 February 2007 14:13, Gabriel L. Somlo wrote:
> On Mon, Feb 05, 2007 at 09:49:00AM +0100, Bernhard Fischer wrote:
> > On Mon, Feb 05, 2007 at 07:20:54AM +0100, Tito wrote:
> > >On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> > >> +???????BB_EXECVP(*argv, argv);
> > >> ????????bb_perror_msg_and_die("cannot execute %s", *argv);
> > >
> > >Hi,
> > >shouldn't the    bb_perror_msg_and_die("cannot execute %s", *argv)
> > >be moved inside  BB_EXECVP(*argv, argv); ?
> > >This would probably save some space.
> > 
> > seconded :)
> 
> I too noticed that a lot of the code surrounding execvp/BB_EXECVP
> looks similar in a lot of the places it happens. However, BB_EXECVP
> was meant as strictly a drop-in replacement for the execvp function
> call.

I prefer it to stay that way. Dying variety should be called
xexecvp() according to our usual conventions.
--
vda


From vda.linux at googlemail.com  Tue Feb  6 01:20:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 02:20:11 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C75C42.8040302@olivetti-engineering.com>
References: <45C75C42.8040302@olivetti-engineering.com>
Message-ID: <200702060220.11391.vda.linux@googlemail.com>

On Monday 05 February 2007 17:33, Samuel Ortiz wrote:
> Hi All,
> 
> It may be useful (at least it is for us) to keep on sending DHCP request 
> and renewals for ever until we actually get an answer. For that purpose 
> udhcpc -t 0 could do the job.

I guess udhcpc -t 999999999 will be the same in practice.

> Attached you will find the corresponding patch, please let me know if 
> you'd consider it for inclusion.

Well, and if for some obscure reason someone wants zero retries?
--
vda


From vda.linux at googlemail.com  Tue Feb  6 01:40:35 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 02:40:35 +0100
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45C776AD.5090602@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com>
Message-ID: <200702060240.35806.vda.linux@googlemail.com>

On Monday 05 February 2007 19:25, Andy Kennedy wrote:
> Luciano Miguel Ferreira Rocha wrote:
> > On Wed, Jan 31, 2007 at 04:51:44PM -0600, Andy Kennedy wrote:
> >   
> >> Anyone have ANY idea about this???  Anyone else have a buildroot/busybox 
> >> setup that uses a serial console?
> >>     
> > 3. boot scripts set serial speed:
> > for d in /dev/ttyS* /dev/ttyAM* /dev/ttyUSB*; do
> >     [ -e "$d" ] && stty -F $d ospeed 57600
> > done
>
> Attempted this.  Didn't help.  To restate my problem (in case some kind 
> developer decides to help me):
> 
> When I have the kernel command line parameter "console=ttyS0,115200n8" I 
> get nice neat output on the serial line up until the init runs.  As soon 
> as init runs, I get missing chars.  So, I replace the BusyBox init with 
> minit, compiled from source and using the uCLibC gcc that I let 
> buildroot make for me.  Same problem.  For some reason, when the system 
> initializes -- after the kernel has reported all of its output, my 
> serial console goes splat.  When I initialize the console using BusyBox 
> (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is {'i', 'g', 
> 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  One of these 
> letters will appear each time I send enter.
> 
> I have tried everything I can think of.  There is no script setting any 
> of the line speeds -- in fact, I have even attempted to remove the 
> scripts and still get the same thing.  Removing the 
> console=ttyS0,115200n8 (or attempting any variant of it) has no affect, 
> except without the console= I get no good output on the line.  The only 
> thing I haven't attempted yet is to replace the getty with an equivalent 
> to see if that makes a difference.  I have also tried 9600, 38400, 
> 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about every 
> combination, but I still cannot get a serial console.
> 
> Can anyone offer a suggestion as to how I might fix this -- or some 
> other place to start?

Does booting with init=/bin/sh work? If yes, then try to run with
init=/a/shell/script, where script is:

#!/bin/sh
# ...stty, setserial, whatever else you want to experiment with...
getty -L ttyS0 115200
echo "Getty exited..."
# So that we can continue experimenting...
sh

or even

#!/bin/sh
# This is the "debug shell"
sh </dev/tty12 >/dev/tty12 2>&1 &
exec /sbin/init

then debug stuff using that shell on vt #12 (strace, kernel logs, etc)

Also, using console=ttyS0 is not very commot, so you may want to tap
much wider userbase by posting to lkml.
--
vda


From larry.brigman at gmail.com  Tue Feb  6 01:40:26 2007
From: larry.brigman at gmail.com (Larry Brigman)
Date: Mon, 5 Feb 2007 17:40:26 -0800
Subject: troubleshooting mklibs
Message-ID: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>

This might be a little off topic but it is a problem I am having with busybox
and glibc.
I know, too many problems linking to glibc but right now I have to fix
the problem.

The problem,  running mklibs to produce a small sub-set of libraries that are
needed on the target system, doesn't always include all the functions that
are needed.

Other applications change and the mix of functions that are needed changes and
the ones that are necessary for busybox to run are missed.

The other day it missed __r_debug from GLIBC_2.0.  Today it is missing
crypt in GLIBC_2.0 for busybox login.

My question:  How do I go about troubleshooting this problem?
If someone could hit me with a clue stick it would be much appreciated.


From vda.linux at googlemail.com  Tue Feb  6 01:21:15 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 02:21:15 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204232355.GB16952@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702041707.33774.vda.linux@googlemail.com>
	<20070204232355.GB16952@hedwig.net.cmu.edu>
Message-ID: <200702060221.15515.vda.linux@googlemail.com>

On Monday 05 February 2007 00:23, Gabriel L. Somlo wrote:
> ... And here's the rest of it again -- converting exec*p to BB_EXEC*P.

Applied both (sans bb_execlp), Thanks!
--
vda


From vda.linux at googlemail.com  Tue Feb  6 02:36:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 03:36:20 +0100
Subject: troubleshooting mklibs
In-Reply-To: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>
References: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>
Message-ID: <200702060336.20899.vda.linux@googlemail.com>

On Tuesday 06 February 2007 02:40, Larry Brigman wrote:
> This might be a little off topic but it is a problem I am having with busybox
> and glibc.
> I know, too many problems linking to glibc but right now I have to fix
> the problem.
> 
> The problem,  running mklibs to produce a small sub-set of libraries that are
> needed on the target system, doesn't always include all the functions that
> are needed.

What is mklibs?
--
vda


From ddaney at avtrex.com  Tue Feb  6 04:46:32 2007
From: ddaney at avtrex.com (David Daney)
Date: Mon, 05 Feb 2007 20:46:32 -0800
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45C776AD.5090602@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com>
	<45C0EBB2.1090604@seiner.com>	<45C0F180.4000904@techmoninc.com>
	<45C11D80.20906@techmoninc.com>	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com>
Message-ID: <45C80828.6050507@avtrex.com>

Andy Kennedy wrote:
> Luciano Miguel Ferreira Rocha wrote:
>> On Wed, Jan 31, 2007 at 04:51:44PM -0600, Andy Kennedy wrote:
>>  
>>> Anyone have ANY idea about this???  Anyone else have a 
>>> buildroot/busybox setup that uses a serial console?
>>>     
>> 3. boot scripts set serial speed:
>> for d in /dev/ttyS* /dev/ttyAM* /dev/ttyUSB*; do
>>     [ -e "$d" ] && stty -F $d ospeed 57600
>> done
> Attempted this.  Didn't help.  To restate my problem (in case some 
> kind developer decides to help me):
>
> When I have the kernel command line parameter "console=ttyS0,115200n8" 
> I get nice neat output on the serial line up

I think I always use "console=ttyS0,115200,n,8,1"

Try it with commas between the all the comm parameters and see what happens.

Setting init=/bin/sh might help track it down also.

> until the init runs.  As soon as init runs, I get missing chars.  So, 
> I replace the BusyBox init with minit, compiled from source and using 
> the uCLibC gcc that I let buildroot make for me.  Same problem.  For 
> some reason, when the system initializes -- after the kernel has 
> reported all of its output, my serial console goes splat.  When I 
> initialize the console using BusyBox (/sbin/getty -L ttyS0 115200 
> vt100) I get "X n", where X is {'i', 'g', 's', 'o', 'l', 'm'}, but I 
> cannot find a pattern in it.  One of these letters will appear each 
> time I send enter.
>
> I have tried everything I can think of.  There is no script setting 
> any of the line speeds -- in fact, I have even attempted to remove the 
> scripts and still get the same thing.  Removing the 
> console=ttyS0,115200n8 (or attempting any variant of it) has no 
> affect, except without the console= I get no good output on the line.  
> The only thing I haven't attempted yet is to replace the getty with an 
> equivalent to see if that makes a difference.  I have also tried 9600, 
> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
> every combination, but I still cannot get a serial console.
>
> Can anyone offer a suggestion as to how I might fix this -- or some 
> other place to start?
>
> Thanks in advance for any help you can offer,
> Andy
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox




From larry.brigman at gmail.com  Tue Feb  6 06:08:34 2007
From: larry.brigman at gmail.com (Larry Brigman)
Date: Mon, 5 Feb 2007 22:08:34 -0800
Subject: troubleshooting mklibs
In-Reply-To: <200702060336.20899.vda.linux@googlemail.com>
References: <ca5165530702051740g48f65f83o678d8bc7435cb545@mail.gmail.com>
	<200702060336.20899.vda.linux@googlemail.com>
Message-ID: <ca5165530702052208k2308e7eibac2fce7bc95863c@mail.gmail.com>

On 2/5/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Tuesday 06 February 2007 02:40, Larry Brigman wrote:
> > This might be a little off topic but it is a problem I am having with busybox
> > and glibc.
> > I know, too many problems linking to glibc but right now I have to fix
> > the problem.
> >
> > The problem,  running mklibs to produce a small sub-set of libraries that are
> > needed on the target system, doesn't always include all the functions that
> > are needed.
>
> What is mklibs?

It is a shell or python script that takes a list of executable to make
small(er) optimized
shared libraries using only the info that the libraries and executables provide.
The python version is a debian package, is used in buildroot and other
systems to
make boot floppies.  I have used it before on other projects and know
that it misses
libnss_files and libnss_dns because of the privated internal link
between glibc and
these libraries but I haven't seen this behavior before.


From sortiz at olivetti-engineering.com  Tue Feb  6 09:36:12 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Tue, 06 Feb 2007 10:36:12 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <200702060220.11391.vda.linux@googlemail.com>
References: <45C75C42.8040302@olivetti-engineering.com>
	<200702060220.11391.vda.linux@googlemail.com>
Message-ID: <45C84C0C.5040703@olivetti-engineering.com>

Hi Denis,

Denis Vlasenko wrote:
> On Monday 05 February 2007 17:33, Samuel Ortiz wrote:
>> Hi All,
>>
>> It may be useful (at least it is for us) to keep on sending DHCP request 
>> and renewals for ever until we actually get an answer. For that purpose 
>> udhcpc -t 0 could do the job.
> 
> I guess udhcpc -t 999999999 will be the same in practice.

Almost, but not exactly.
We have machines that can be powered up without being connected to any 
network for weeks. However, we need them to fetch an IP if they ever get 
plugged to some network.


>> Attached you will find the corresponding patch, please let me know if 
>> you'd consider it for inclusion.
> 
> Well, and if for some obscure reason someone wants zero retries?

0 retries would be one try, and that would be -t 1.
With the current code, running udhcpc with -t 0 is quite useless since 
it will not send _any_ DHCP frame since packet_num will never be lower
than client_config.retries. I don't see the point of doing that unless 
you're expecting a DHCP offer or ACK without having sent a discovery or 
request previously.
That's why I assumed -t 0 was semantically available, and proposed to 
use it for infinite retries.

Cheers,
Samuel.


From rep.dot.nop at gmail.com  Tue Feb  6 09:55:54 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Tue, 6 Feb 2007 10:55:54 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C84C0C.5040703@olivetti-engineering.com>
References: <45C75C42.8040302@olivetti-engineering.com>
	<200702060220.11391.vda.linux@googlemail.com>
	<45C84C0C.5040703@olivetti-engineering.com>
Message-ID: <20070206095554.GA17279@aon.at>

On Tue, Feb 06, 2007 at 10:36:12AM +0100, Samuel Ortiz wrote:
>Hi Denis,
>
>Denis Vlasenko wrote:
>> On Monday 05 February 2007 17:33, Samuel Ortiz wrote:
>>> Hi All,
>>>
>>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>> and renewals for ever until we actually get an answer. For that purpose 
>>> udhcpc -t 0 could do the job.
>> 
>> I guess udhcpc -t 999999999 will be the same in practice.
>
>Almost, but not exactly.
>We have machines that can be powered up without being connected to any 
>network for weeks. However, we need them to fetch an IP if they ever get 
>plugged to some network.
>
>
>>> Attached you will find the corresponding patch, please let me know if 
>>> you'd consider it for inclusion.
>> 
>> Well, and if for some obscure reason someone wants zero retries?
>
>0 retries would be one try, and that would be -t 1.
>With the current code, running udhcpc with -t 0 is quite useless since 
>it will not send _any_ DHCP frame since packet_num will never be lower
>than client_config.retries. I don't see the point of doing that unless 
>you're expecting a DHCP offer or ACK without having sent a discovery or 
>request previously.
>That's why I assumed -t 0 was semantically available, and proposed to 
>use it for infinite retries.

I think that the proposal to provide means to infinitely query makes
sense. Can zcip take care of this even now, perhaps?


From rupesh_gujare at rediffmail.com  Tue Feb  6 13:02:16 2007
From: rupesh_gujare at rediffmail.com (Rupesh Gujare)
Date: 6 Feb 2007 13:02:16 -0000
Subject: Need help to umount initrd and mount real file system
Message-ID: <20070206130216.14246.qmail@webmail72.rediffmail.com>

hello all,
 thanks for help..  and sorry for not stating my problem clearly
so finally i was able to change rootfs.. Here is what i did at interactive shell by adding /bin/sh at start in /etc/init.d/rcS:--

 mount -t proc none /proc
 mount -t ext2 /dev/sda1 /tmp
 cd /tmp
 umount /proc
 pivot_root . tmp   #tmp exist on new-root
 mount -t proc none /proc
 exec chroot . /bin/ash <dev/console > dev/console 2>&1
 exec chroot . /sbin/init <dev/console > dev/console 2>&1
 umount /tmp
 
BUT HERE I GET ERROR AS:--
Device or resource busy
 
 Where I am going wrong?
I am compiling busybox with shared library as a dynamically linked.
 Is it problem with /dev/sda1? ie. i am referencing to /dev/sda1 on old   root FS(if it's like that, then how to overcome it?). or with shared libraries on old FS?
 your help is greatly appreciated..
 Thanks in advance..

Rupesh Gujare.




On Tue, 06 Feb 2007 Denis Vlasenko wrote :
>On Monday 05 February 2007 15:11, Rupesh Gujare wrote:
> >
> > I had tried with pivot_root:
> >  I entered
> > /bin/sh  in /etc/rcS
> > and after mounting /proc tried to do pivot_root
> >  it gives me
> > pivot_root:pivot_root: Device or resource busy.
> >  any clue why it is like this?
>
>Oh, wonderful problem report. No solid info on what exactly
>you did (params to pivot_root etc...).
>
>Anyway, a part of my homemade initrd whcu does pivot_root
>(bu this time "new" rootfs is mounted on /new_root):
>
>
># Clean up
>#umount /sys
>umount /proc
>
>echo "# Chrooting into root fs"
># we expect that /dev/console and /dev/null exist in /new_root/dev
>cd /new_root
># making sure we dont keep /dev busy
>exec <dev/console >dev/console 2>&1
># proc/ in new root is used here as a temp mountpoint for old root
>pivot_root . proc || {
>     echo "pivot_root failed. Fatal, cannot continue booting"
>     while true; do sleep 32000; done
>}
>
>exec \
>chroot . \
>sh -c '\
>umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
>exec /bin/env - /sbin/init
>'
>
>echo "chroot . sh failed. Fatal, cannot continue booting"
>while true; do sleep 32000; done
>
>
>Hope this helps
>--
>vda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070206/b2767cc4/attachment-0001.htm 

From strange at nsk.no-ip.org  Tue Feb  6 14:07:17 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 6 Feb 2007 14:07:17 +0000
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070206130216.14246.qmail@webmail72.rediffmail.com>
References: <20070206130216.14246.qmail@webmail72.rediffmail.com>
Message-ID: <20070206140717.GA21057@nsk.no-ip.org>

On Tue, Feb 06, 2007 at 01:02:16PM -0000, Rupesh Gujare wrote:
> hello all,
>  thanks for help..  and sorry for not stating my problem clearly
> so finally i was able to change rootfs.. Here is what i did at interactive shell by adding /bin/sh at start in /etc/init.d/rcS:--
> 
>  mount -t proc none /proc
>  mount -t ext2 /dev/sda1 /tmp
>  cd /tmp
>  umount /proc
>  pivot_root . tmp   #tmp exist on new-root
>  mount -t proc none /proc
>  exec chroot . /bin/ash <dev/console > dev/console 2>&1
>  exec chroot . /sbin/init <dev/console > dev/console 2>&1
>  umount /tmp
>  
> BUT HERE I GET ERROR AS:--
> Device or resource busy
>  
>  Where I am going wrong?

That script *has* to be init, not run from init. Try booting with
init=/etc/init.d/rcS and if it works replace /sbin/init with that
script.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070206/a89eee6e/attachment-0002.pgp 

From steven.scholz at imc-berlin.de  Tue Feb  6 13:44:47 2007
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 06 Feb 2007 14:44:47 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C84C0C.5040703@olivetti-engineering.com>
References: <45C75C42.8040302@olivetti-engineering.com>	<200702060220.11391.vda.linux@googlemail.com>
	<45C84C0C.5040703@olivetti-engineering.com>
Message-ID: <45C8864F.1020005@imc-berlin.de>

Samuel,

>>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>> and renewals for ever until we actually get an answer. For that purpose 
>>> udhcpc -t 0 could do the job.
>> I guess udhcpc -t 999999999 will be the same in practice.
> 
> Almost, but not exactly.
> We have machines that can be powered up without being connected to any 
> network for weeks. However, we need them to fetch an IP if they ever get 
> plugged to some network.

Then maybe you want to use something like netplugd ot ifplugd ...

--
Steven




From pgf at brightstareng.com  Tue Feb  6 14:17:44 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Tue, 06 Feb 2007 09:17:44 -0500
Subject: [PATCH] udhcp: infinite retries 
In-Reply-To: steven.scholz's message of Tue, 06 Feb 2007 14:44:47 +0100.
	<45C8864F.1020005@imc-berlin.de> 
Message-ID: <16105.1170771464@brightstareng.com>

 > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
 > >>> and renewals for ever until we actually get an answer. For that purpose 
 > >>> udhcpc -t 0 could do the job.
 > >> I guess udhcpc -t 999999999 will be the same in practice.
 > > 
 > > Almost, but not exactly.
 > > We have machines that can be powered up without being connected to any 
 > > network for weeks. However, we need them to fetch an IP if they ever get 
 > > plugged to some network.
 > 
 > Then maybe you want to use something like netplugd ot ifplugd ...

of course that takes care of the locally connected problem, but
not the "connected to a switch which is itself disconnected"
problem.  but i agree -- if it were me, i'd probably use a
combination of the mechanisms.

dhcp should be using netlink itself, to track interface connectivity.  (i.e.,
needing ifplugd is a bug, in my opinion.)

paul
=---------------------
 paul fox, pgf at brightstareng.com


From sortiz at olivetti-engineering.com  Tue Feb  6 14:54:52 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Tue, 06 Feb 2007 15:54:52 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <16105.1170771464@brightstareng.com>
References: <16105.1170771464@brightstareng.com>
Message-ID: <45C896BC.505@olivetti-engineering.com>

Paul Fox wrote:
>  > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
>  > >>> and renewals for ever until we actually get an answer. For that purpose 
>  > >>> udhcpc -t 0 could do the job.
>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>  > > 
>  > > Almost, but not exactly.
>  > > We have machines that can be powered up without being connected to any 
>  > > network for weeks. However, we need them to fetch an IP if they ever get 
>  > > plugged to some network.
>  > 
>  > Then maybe you want to use something like netplugd ot ifplugd ...
> 
> of course that takes care of the locally connected problem, but
> not the "connected to a switch which is itself disconnected"
> problem.  but i agree -- if it were me, i'd probably use a
> combination of the mechanisms.
well, with the infinite retries option, we can live without netplugd.
However, I agree that it would be nicer to have netplugd firing up 
udhcpc with infinite retries whenever we actually are plugged/associated 
(we do have machines with both ethernet and 802.11 interfaces).

Cheers,
Samuel.


> dhcp should be using netlink itself, to track interface connectivity.  (i.e.,
> needing ifplugd is a bug, in my opinion.)
> 
> paul
> =---------------------
>  paul fox, pgf at brightstareng.com
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 



From natanael.copa at gmail.com  Tue Feb  6 15:50:33 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Tue, 06 Feb 2007 16:50:33 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <200702041810.57851.vda.linux@googlemail.com>
References: <1170428490.28276.35.camel@localhost>
	<200702022243.56100.vda.linux@googlemail.com>
	<200702041810.57851.vda.linux@googlemail.com>
Message-ID: <1170777033.6604.13.camel@localhost>

vda,

Sorry for the delayed reply. I was sick since friday.

Thank for you comments. They were appreciated.

On Sun, 2007-02-04 at 18:10 +0100, Denis Vlasenko wrote:
> On Friday 02 February 2007 22:43, Denis Vlasenko wrote:
> > On Friday 02 February 2007 16:01, Natanael Copa wrote:
> > > Hi,
> > > 
> > > Attatched is a patch for support of the '!' operator for find.
> > > 
> > > I created another macro ALLOC_TEST for actions that can be inverted with
> > > '!'. They are not really actions (like -print) but tests (like -name).
> > > 
> > > It should not touch anything unless you have enabled the
> > > FEATURE_FIND_NOT config option.
> > 
> > parse_params():
> > invert_flag is never reset to 0. This must be a bug -
> > "not" shouldn't be applied to the second -name here, I think
> > (did not check it versus GNU find, tho...):
> > find ! -name '*.a' -o -name '*.b'

Correct. It was a bug.

> I did it myself. find ! support is in svn. Please test.

The bug is still there.

./busybox find ! -name '*.c' -name 'f*'

Should give you a lists of files starting with 'f' and with all .c files
excluded.

The attatched patch should fix it.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-not-fix.patch
Type: text/x-patch
Size: 1280 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070206/8442e1fc/attachment-0002.bin 

From natanael.copa at gmail.com  Tue Feb  6 15:56:43 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Tue, 06 Feb 2007 16:56:43 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <1170777033.6604.13.camel@localhost>
References: <1170428490.28276.35.camel@localhost>
	<200702022243.56100.vda.linux@googlemail.com>
	<200702041810.57851.vda.linux@googlemail.com>
	<1170777033.6604.13.camel@localhost>
Message-ID: <1170777403.6604.18.camel@localhost>

On Tue, 2007-02-06 at 16:50 +0100, Natanael Copa wrote:

> > > parse_params():
> > > invert_flag is never reset to 0. This must be a bug -
> > > "not" shouldn't be applied to the second -name here, I think
> > > (did not check it versus GNU find, tho...):
> > > find ! -name '*.a' -o -name '*.b'
> 
> Correct. It was a bug.
> 
> > I did it myself. find ! support is in svn. Please test.
> 
> The bug is still there.
> 
> ./busybox find ! -name '*.c' -name 'f*'
> 
> Should give you a lists of files starting with 'f' and with all .c files
> excluded.
> 
> The attatched patch should fix it.

I'm sorry. I posted it a few seconds to early. The following chunk
should not be there:
@@ -342,7 +342,7 @@
 	action*** appp;
 	unsigned cur_group = 0;
 	unsigned cur_action = 0;
-	USE_FEATURE_FIND_NOT( smallint invert_flag = 0; )
+	USE_FEATURE_FIND_NOT( smallint invert_flag; )
 
 	action* alloc_action(int sizeof_struct, action_fp f)
 	{


The invert_flag should be initialized.




From steven.scholz at imc-berlin.de  Tue Feb  6 16:21:00 2007
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 06 Feb 2007 17:21:00 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <16105.1170771464@brightstareng.com>
References: <16105.1170771464@brightstareng.com>
Message-ID: <45C8AAEC.1090307@imc-berlin.de>

Paul Fox wrote:
>  > >>> It may be useful (at least it is for us) to keep on sending DHCP
request
>  > >>> and renewals for ever until we actually get an answer. For that
purpose
>  > >>> udhcpc -t 0 could do the job.
>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>  > >
>  > > Almost, but not exactly.
>  > > We have machines that can be powered up without being connected to any
>  > > network for weeks. However, we need them to fetch an IP if they ever get
>  > > plugged to some network.
>  >
>  > Then maybe you want to use something like netplugd ot ifplugd ...
>
> of course that takes care of the locally connected problem, but
> not the "connected to a switch which is itself disconnected"
> problem.

But udhcpc in background mode takes care of this situation by trying toi get
a lease every 5 minutes or so ... Right?

> dhcp should be using netlink itself, to track interface connectivity.  (i.e.,
> needing ifplugd is a bug, in my opinion.)
Not realy. We're using netplugd with static IP adresses as well. No need for
eth0 to be up and running if there's no network...

--
Steven


From steven.scholz at imc-berlin.de  Tue Feb  6 16:22:13 2007
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 06 Feb 2007 17:22:13 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C896BC.505@olivetti-engineering.com>
References: <16105.1170771464@brightstareng.com>
	<45C896BC.505@olivetti-engineering.com>
Message-ID: <45C8AB35.8050505@imc-berlin.de>

Samuel Ortiz wrote:
> Paul Fox wrote:
>>  > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>  > >>> and renewals for ever until we actually get an answer. For that purpose 
>>  > >>> udhcpc -t 0 could do the job.
>>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>>  > > 
>>  > > Almost, but not exactly.
>>  > > We have machines that can be powered up without being connected to any 
>>  > > network for weeks. However, we need them to fetch an IP if they ever get 
>>  > > plugged to some network.
>>  > 
>>  > Then maybe you want to use something like netplugd ot ifplugd ...
>>
>> of course that takes care of the locally connected problem, but
>> not the "connected to a switch which is itself disconnected"
>> problem.  but i agree -- if it were me, i'd probably use a
>> combination of the mechanisms.
> well, with the infinite retries option, we can live without netplugd.
How about using

-b,     --background
	Fork to background if lease cannot be immediately negotiated.

???

Steven


From sortiz at olivetti-engineering.com  Tue Feb  6 16:33:02 2007
From: sortiz at olivetti-engineering.com (Samuel Ortiz)
Date: Tue, 06 Feb 2007 17:33:02 +0100
Subject: [PATCH] udhcp: infinite retries
In-Reply-To: <45C8AB35.8050505@imc-berlin.de>
References: <16105.1170771464@brightstareng.com>
	<45C896BC.505@olivetti-engineering.com>
	<45C8AB35.8050505@imc-berlin.de>
Message-ID: <45C8ADBE.5060603@olivetti-engineering.com>

Steven Scholz wrote:
> Samuel Ortiz wrote:
>> Paul Fox wrote:
>>>  > >>> It may be useful (at least it is for us) to keep on sending DHCP request 
>>>  > >>> and renewals for ever until we actually get an answer. For that purpose 
>>>  > >>> udhcpc -t 0 could do the job.
>>>  > >> I guess udhcpc -t 999999999 will be the same in practice.
>>>  > > 
>>>  > > Almost, but not exactly.
>>>  > > We have machines that can be powered up without being connected to any 
>>>  > > network for weeks. However, we need them to fetch an IP if they ever get 
>>>  > > plugged to some network.
>>>  > 
>>>  > Then maybe you want to use something like netplugd ot ifplugd ...
>>>
>>> of course that takes care of the locally connected problem, but
>>> not the "connected to a switch which is itself disconnected"
>>> problem.  but i agree -- if it were me, i'd probably use a
>>> combination of the mechanisms.
>> well, with the infinite retries option, we can live without netplugd.
> How about using
> 
> -b,     --background
> 	Fork to background if lease cannot be immediately negotiated.
> 
> ???

I didn't check this option, but it seems that it will wakeup after 60
seconds, and try again, so this could be a solution, yes.

Cheers,
Samuel.


> Steven
> 



From vda.linux at googlemail.com  Tue Feb  6 17:14:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 18:14:20 +0100
Subject: Need help to umount initrd and mount real file system
In-Reply-To: <20070206130216.14246.qmail@webmail72.rediffmail.com>
References: <20070206130216.14246.qmail@webmail72.rediffmail.com>
Message-ID: <200702061814.20154.vda.linux@googlemail.com>

On Tuesday 06 February 2007 14:02, Rupesh Gujare wrote:
> hello all,
>  thanks for help..  and sorry for not stating my problem clearly
> so finally i was able to change rootfs.. Here is what i did at interactive shell by adding /bin/sh at start in /etc/init.d/rcS:--
> 
>  mount -t proc none /proc
>  mount -t ext2 /dev/sda1 /tmp
>  cd /tmp
>  umount /proc
>  pivot_root . tmp   #tmp exist on new-root
>  mount -t proc none /proc
>  exec chroot . /bin/ash <dev/console > dev/console 2>&1
>  exec chroot . /sbin/init <dev/console > dev/console 2>&1
>  umount /tmp
>  
> BUT HERE I GET ERROR AS:--
> Device or resource busy

Because your current directory is still "old" /
(== "new" /tmp)

>  Where I am going wrong?

Example that I posted:

echo "# Chrooting into root fs"
# we expect that /dev/console and /dev/null exist in /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc

avoided that by changing to /new_root, detaching stdio from lod /dev
and doing pivot_root while sitting in /new_root.

Why you are not following the example?
--
vda


From vda.linux at googlemail.com  Tue Feb  6 17:36:29 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 18:36:29 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <1170777403.6604.18.camel@localhost>
References: <1170428490.28276.35.camel@localhost>
	<1170777033.6604.13.camel@localhost>
	<1170777403.6604.18.camel@localhost>
Message-ID: <200702061836.29931.vda.linux@googlemail.com>

On Tuesday 06 February 2007 16:56, Natanael Copa wrote:
> On Tue, 2007-02-06 at 16:50 +0100, Natanael Copa wrote:
> 
> > > > parse_params():
> > > > invert_flag is never reset to 0. This must be a bug -
> > > > "not" shouldn't be applied to the second -name here, I think
> > > > (did not check it versus GNU find, tho...):
> > > > find ! -name '*.a' -o -name '*.b'
> > 
> > Correct. It was a bug.
> > 
> > > I did it myself. find ! support is in svn. Please test.
> > 
> > The bug is still there.
> > 
> > ./busybox find ! -name '*.c' -name 'f*'
> > 
> > Should give you a lists of files starting with 'f' and with all .c files
> > excluded.
> > 
> > The attatched patch should fix it.
> 
> I'm sorry. I posted it a few seconds to early. The following chunk
> should not be there:
> @@ -342,7 +342,7 @@
>  	action*** appp;
>  	unsigned cur_group = 0;
>  	unsigned cur_action = 0;
> -	USE_FEATURE_FIND_NOT( smallint invert_flag = 0; )
> +	USE_FEATURE_FIND_NOT( smallint invert_flag; )
>  
>  	action* alloc_action(int sizeof_struct, action_fp f)
>  	{
> 
> 
> The invert_flag should be initialized.

Applied, thanks.
--
vda


From questforhappiness at hotmail.com  Tue Feb  6 19:34:25 2007
From: questforhappiness at hotmail.com (none none)
Date: Tue, 06 Feb 2007 11:34:25 -0800
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <200702030247.11080.vda.linux@googlemail.com>
Message-ID: <BAY123-F85F6D80EA409D2C95FC4BB99F0@phx.gbl>




>From: Denis Vlasenko <vda.linux at googlemail.com>
>To: busybox at busybox.net
>CC: "none none" <questforhappiness at hotmail.com>
>Subject: Re: Patch to accommodate 2007 Daylight Saving Time change 
>(busybox)
>Date: Sat, 3 Feb 2007 02:47:11 +0100
>
>On Saturday 03 February 2007 02:34, none none wrote:
> > Hi there,
> >
> > My aventail appliances are using busybox as OS.  I checked and find that 
>it
> > is not using the new 2007 Daylight Saving Time schedule.  Does anyone 
>know
> > if there are patches or instructions to update busybox to accommodate 
>the
> > new 2007 Daylight Saving Time change?
>
>This is done by libc routines. If it doesn't work for you,
>you should update/fix your libc.
>--
>vda


I am new to busybox although I have some background in linux.  How do you 
usually update packages like libc in busybox?  In Linux, we use either yum 
or up2date.  It is the same for busybox?  Is there a link where I can find 
the correct libc for 2007 Daylight Saving Time?

Thank you,
Donald.

_________________________________________________________________
Search for grocery stores. Find gratitude. Turn a simple search into 
something more. 
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_gratitude&FORM=WLMTAG



From vda.linux at googlemail.com  Tue Feb  6 19:29:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 20:29:32 +0100
Subject: libselinux utilities applets - please test
Message-ID: <200702062029.33013.vda.linux@googlemail.com>

int getsebool_main(int argc, char **argv)
{
...
        if (!len) {
                if (argc < 2)
                        bb_show_usage();
                len = argc - 1;
                names = xmalloc(sizeof(char *) * len);
                for (i = 0; i < len; i++)
                        names[i] = xstrdup(argv[i + 1]);
        }

Is it necessary to allocate names and xstrdup argv[i]?
Maybe just do "names = argv + 1"?


bb_perror_msg_and_die("error while processing %s: ", prefix);

bb_perror prints: "<applet>: message: <strerror>" - that thrailing
": " in your code is not needed.


+#define matchpathcon_trivial_usage \
+       "[-n] [-N] [-f file_contexts_file] [-p prefix] [-V]"
+#define matchpathcon_full_usage \
+       "\t-n\tDo not display path.\n" \
+       "\t-N\tDo not use translations.\n" \
+       "\t-f\tfile_context_file Use alternate file_context file\n" \
+       "\t-p\tprefix Use prefix to speed translations\n" \
+       "\t-V\tVerify file context on disk matches defaults"

Ehhh.... usage.h has such a nice comment at the top:

/*
 * This file suffers from chronically incorrect tabification
 * of messages. Before editing this file:
 * 1. Switch you editor to 8-space tab mode.
 * 2. Do not use \t in messages, use real tab character.
 * 3. Start each source line with message as follows:
 *    |<7 spaces>"text with tabs"....
 */


Okay. I applied your patch to svn and did some changes.
Please review & test - I can't run-test it at the moment
(my kernel and userspace is not selinux-enabled).

Patch is attached for easy review. Thanks.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sl.patch
Type: text/x-diff
Size: 12760 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070206/cee881f2/attachment-0002.bin 

From vda.linux at googlemail.com  Tue Feb  6 19:42:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 6 Feb 2007 20:42:40 +0100
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <BAY123-F85F6D80EA409D2C95FC4BB99F0@phx.gbl>
References: <BAY123-F85F6D80EA409D2C95FC4BB99F0@phx.gbl>
Message-ID: <200702062042.40194.vda.linux@googlemail.com>

On Tuesday 06 February 2007 20:34, none none wrote:
> I am new to busybox although I have some background in linux.  How do you 
> usually update packages like libc in busybox?

You seem to confuse busybox with linux distributions.
It isn't a distro. It is just a collection of programs.

You question is similar to "how do you usually update
apache in samba?". My reaction is "what??!".

> In Linux, we use either yum  
> or up2date.  It is the same for busybox?

In "my" Linux, it's wget && read_docs_carefully && make. ;)

> Is there a link where I can find  
> the correct libc for 2007 Daylight Saving Time?

I doubt you need to update libc.

If you have problems with incorrect time zone setup,
on "desktop" (i.e., glibc-based) distro check your
/etc/localtime (should be a symlink, something like
/etc/localtime -> /usr/share/zoneinfo/Europe/Kiev).

On uclibc, check /etc/TZ and/or TZ environment variable.
Example: /etc/TZ contents for Eastern Europe is
just one line:

EET-2EEST-3

It says "Normal time is called 'EET' and is GMT + 2:00,
summer time is called 'EEST' and is GMT + 3".

More complex example specifies _when_ to do transition:

EET-2EEST-3,M3.5.0/03:00:00,M10.5.0/04:00:00

--
vda


From pgf at brightstareng.com  Tue Feb  6 20:21:11 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Tue, 06 Feb 2007 15:21:11 -0500
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox) 
In-Reply-To: vda.linux's message of Tue, 06 Feb 2007 20:42:40 +0100.
	<200702062042.40194.vda.linux@googlemail.com> 
Message-ID: <26843.1170793271@brightstareng.com>

 > On Tuesday 06 February 2007 20:34, none none wrote:
 > > I am new to busybox although I have some background in linux.  How do you 
 > > usually update packages like libc in busybox?
 > 
...
 > I doubt you need to update libc.
 > 
 > If you have problems with incorrect time zone setup,
 > on "desktop" (i.e., glibc-based) distro check your
 > /etc/localtime (should be a symlink, something like
 > /etc/localtime -> /usr/share/zoneinfo/Europe/Kiev).

i suspect the original poster is concerned with the USA's
change of daylight savings time start/end dates.  the law
requiring the change was passed in 2005, and takes effect
this year.  many vendors are only now scrambling to implement
the change, which is pretty late, since DST starts on march
11th this year.  :-)

so:  what needs to change is not just a symlink or a reference, but the
contents of the tz database.

but, to echo vda's comment:  this isn't a busybox issue.

paul
=---------------------
 paul fox, pgf at brightstareng.com


From questforhappiness at hotmail.com  Tue Feb  6 21:50:51 2007
From: questforhappiness at hotmail.com (none none)
Date: Tue, 06 Feb 2007 13:50:51 -0800
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <26843.1170793271@brightstareng.com>
Message-ID: <BAY123-F200BA655A818D835020FAEB99F0@phx.gbl>


>i suspect the original poster is concerned with the USA's
>change of daylight savings time start/end dates.  the law
>requiring the change was passed in 2005, and takes effect
>this year.  many vendors are only now scrambling to implement
>the change, which is pretty late, since DST starts on march
>11th this year.  :-)

Yes, that is exactly right.

>so:  what needs to change is not just a symlink or a reference, but the
>contents of the tz database.
>
>but, to echo vda's comment:  this isn't a busybox issue.

Yes, nothing is wrong with busybox.  I do need to change the content of the 
tz database.  I don't know how to do that in busybox.  Please help give some 
directions.

thank you,
Donald.

_________________________________________________________________
FREE online classifieds from Windows Live Expo ? buy and sell with people 
you know 
http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06



From psmith at netezza.com  Tue Feb  6 22:01:55 2007
From: psmith at netezza.com (Paul Smith)
Date: Tue, 06 Feb 2007 17:01:55 -0500
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <BAY123-F200BA655A818D835020FAEB99F0@phx.gbl>
References: <BAY123-F200BA655A818D835020FAEB99F0@phx.gbl>
Message-ID: <1170799315.32495.12.camel@psmithub>

On Tue, 2007-02-06 at 13:50 -0800, none none wrote:

> Yes, nothing is wrong with busybox.  I do need to change the content of the 
> tz database.  I don't know how to do that in busybox.  Please help give some 
> directions.

The tz database is not part of busybox: it (typically) is part of your C
runtime library.  You need to check with the folks who maintain whatever
C library you use: probably either GNU libc (glibc) or UClib.


Cheers!

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <psmith at netezza.com>                       http://netezza.com
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
-----------------------------------------------------------------------------
      These are my opinions--Netezza takes no responsibility for them.


From pgf at brightstareng.com  Tue Feb  6 22:04:34 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Tue, 06 Feb 2007 17:04:34 -0500
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox) 
In-Reply-To: questforhappiness's message of Tue, 06 Feb 2007 13:50:51 -0800.
	<BAY123-F200BA655A818D835020FAEB99F0@phx.gbl> 
Message-ID: <26244.1170799474@brightstareng.com>

 > Yes, nothing is wrong with busybox.  I do need to change the content of the 
 > tz database.  I don't know how to do that in busybox.  Please help give some 
 > directions.

download the latest tz database, and compile it:
    http://www.twinsun.com/tz/tz-link.htm

paul
=---------------------
 paul fox, pgf at brightstareng.com


From education.sina at gmail.com  Wed Feb  7 05:02:16 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Wed, 7 Feb 2007 14:02:16 +0900
Subject: Busybox compilation error
Message-ID: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>

Hi,
I am trying to compile busybox for ARM cpu...Am using arm bese toolchain...
I am getting this error at the end...
LINK    busybox_unstripped
applets/built-in.o:(.rodata.applets+0x664): undefined reference to
`readahead_main'
applets/built-in.o:(.rodata.applets+0x868): undefined reference to
`taskset_main'
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1

BTD I am keeping off two line  at /miscutils/Kbuild
#lib-$(CONFIG_READAHEAD)   += readahead.o
#lib-$(CONFIG_TASKSET)     += taskset.o

as if i keeping this two line then i am also geting some errors...
Can anybody tell what should i do now..to solve this problem...

Thanks
Sina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070207/0ea51218/attachment-0001.htm 

From natanael.copa at gmail.com  Wed Feb  7 09:33:09 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Wed, 07 Feb 2007 10:33:09 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
Message-ID: <1170840789.6604.48.camel@localhost>

Hi,

I just discovered that busybox wget segfaults in my
gentoo/hardened/uclibc environment.

strace shows this:

open("/etc/services", O_RDONLY)         = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
(Inappropriate ioctl for device)
brk(0x10e57000)                         = 0x10e57000
read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
close(3)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 15366 detached

Does anybody know anything about it?




From kaigai at kaigai.gr.jp  Wed Feb  7 15:28:07 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Thu, 08 Feb 2007 00:28:07 +0900
Subject: libselinux utilities applets - please test
In-Reply-To: <200702062029.33013.vda.linux@googlemail.com>
References: <200702062029.33013.vda.linux@googlemail.com>
Message-ID: <45C9F007.40706@kaigai.gr.jp>

Denis, Thanks for merging the series of patches.

> Okay. I applied your patch to svn and did some changes.
> Please review & test - I can't run-test it at the moment
> (my kernel and userspace is not selinux-enabled).
> 
> Patch is attached for easy review. Thanks.
> --
> vda

I found some problems on building SELinux related applets.
The attached patch will fix them.

> diff -urpN busybox.5/selinux/matchpathcon.c busybox.6/selinux/matchpathcon.c
> --- busybox.5/selinux/matchpathcon.c	1970-01-01 01:00:00.000000000 +0100
> +++ busybox.6/selinux/matchpathcon.c	2007-02-06 20:23:46.000000000 +0100

- snip -

Compiler generated a warning message due to missing a prototype definition.
So, I put a prototype definition such as other applets.

> +int matchpathcon_main(int argc, char **argv)
> +{
> +	int error = 0;
> +	unsigned opts;
> +	char *fcontext, *prefix, *path;
> +
> +	opt_complementary = "-1:" /* at least one param reqd */
> +		"f--p:p--f"; /* mutually exclusive */
> +	opts = getopt32(argc, argv, "nNf:p:V", &fcontext, &prefix);
> +	argv += optind;
> +
> +	if (opts & OPT_NOT_TRANS) {
> +		set_matchpathcon_flags(NOTRANS);
                                       ^^^^^^^
It should be MATCHPATHCON_NOTRANS which is defined in selinux/selinux.h.
It's not a constant value to represent a command line option.

> +	}
> +	if (opts & OPT_FCONTEXT) {
> +		if (matchpathcon_init(fcontext))
> +			bb_perror_msg_and_die("error while processing %s", fcontext);
> +	}
> +	if (opts & OPT_PREFIX) {
> +		if (matchpathcon_init_prefix(NULL, prefix))
> +			bb_perror_msg_and_die("error while processing %s", prefix);
> +	}
> +
> +	while((path = *argv++) != NULL) {
> +		security_context_t con;
> +		int rc;
> +
> +		if (!(opts & OPT_VERIFY)) {
> +			error += print_matchpathcon(path, opt & OPT_NOT_PRINT);
It should be 'opts', not 'opt'.

> +			continue;
> +		}
> +
> +		if (selinux_file_context_verify(path, 0)) {
> +			printf("%s verified\n", path);
> +			continue;
> +		}
> +
> +		if (opts & OPT_NOT_TRANS)
> +			rc = lgetfilecon_raw(path, &con);
> +		else
> +			rc = lgetfilecon(path, &con);
> +
> +		if (rc >= 0) {
> +			printf("%s has context %s, should be ", path, con);
> +			error += print_matchpathcon(path, 1);
> +			freecon(con);
> +			continue;
> +		}
> +		printf("actual context unknown: %s, should be ", strerror(errno));
> +		error += print_matchpathcon(path, 1);
> +	}
> +	matchpathcon_fini();
> +	return error;
> +}

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-selinux-fix-build.patch
Type: text/x-patch
Size: 2191 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/1acdae87/attachment-0002.bin 

From marc.leeman at gmail.com  Wed Feb  7 16:15:25 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Wed, 7 Feb 2007 17:15:25 +0100
Subject: syslogd +realpath
Message-ID: <20070207161525.GQ15523@scorpius.homelinux.org>

I seem to have stumbled on another problem with syslogd in 1.4.0/1.4.1.
I did not notice it at first since I was developing on an NFS system and
not yet on a squashfs system with a ro /

The problem occurs when syslogd unlinks /dev/log and creates a socket in
/dev/log; on a RO fs, it cannot do that and will segfault all the time.

On a virgin NFS system; the following happens:

[mleeman at gemini target.scu.jodw]$ ls -al dev/log
lrwxrwxrwx 1 root root 10 Feb  7 17:04 dev/log -> ../tmp/log
[mleeman at gemini target.scu.jodw]$ ls -al dev/log
lrwxrwxrwx 1 root root 10 Feb  7 17:04 dev/log -> ../tmp/log
[mleeman at gemini target.scu.jodw]$ ls -al dev/log
srw-rw-rw- 1 root root 0 Feb  7 17:05 dev/log

The link is replaced with a socket (/ fs is RW).

-- 
  greetz, marc
Come on out, Chiana. Look, I don't have time to play this game. Durka's
gone Hannibal Lector on us.
	Crichton - Durka Returns
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070207/9351ae79/attachment-0002.pgp 

From marc.leeman at gmail.com  Wed Feb  7 16:35:07 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Wed, 7 Feb 2007 17:35:07 +0100
Subject: [gmail] syslogd +realpath
In-Reply-To: <20070207161525.GQ15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
Message-ID: <20070207163507.GR15523@scorpius.homelinux.org>

> The link is replaced with a socket (/ fs is RW).

Forgot to mention that I am using uclibc on powerpc.:

-- 
  greetz, marc
I may be small but allow me to remind you that only serves to put me
at castration level.
	Rygel - Relativity
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070207/7ce1cc6f/attachment-0002.pgp 

From marc.leeman at gmail.com  Wed Feb  7 16:58:34 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Wed, 7 Feb 2007 17:58:34 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070207163507.GR15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207163507.GR15523@scorpius.homelinux.org>
Message-ID: <20070207165834.GT15523@scorpius.homelinux.org>

On Wed, Feb 07, 2007 at 05:35:07PM +0100, Marc Leeman wrote:
> > The link is replaced with a socket (/ fs is RW).
> 
> Forgot to mention that I am using uclibc on powerpc.:


adding:

char *xmalloc_realpath(const char *path)
{
#if defined(__GLIBC__) && !defined(__UCLIBC__)
    /* glibc provides a non-standard extension */
    return realpath(path, NULL);
#else
    char buf[PATH_MAX+1];

    fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
    fprintf(stdout,"realpath buf is %s\n",buf);
    /* on error returns NULL (xstrdup(NULL) ==NULL) */
    return xstrdup(realpath(path, buf));
#endif
}

results in:

$ /sbin/syslogd -n -m 0 -C16
realpath returns (null)
realpath buf is /tmp/log
syslogd: bind: Address already in use

oeps!

let's blatantly ignore the comment about "on error":

char *xmalloc_realpath(const char *path)
{
#if defined(__GLIBC__) && !defined(__UCLIBC__)
    /* glibc provides a non-standard extension */
    return realpath(path, NULL);
#else
    char buf[PATH_MAX+1];

    fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
    fprintf(stdout,"realpath buf is %s\n",buf);
    /* on error returns NULL (xstrdup(NULL) ==NULL) */
    return xstrdup(buf);
#endif
}

$ ls -al /tmp/log
srw-rw-rw-    1 0        0               0 Jan  1 00:00 /tmp/log

this seems to give us what we expect :)

cf. att'd patch

-- 
  Marc Leeman
  R&D Firmware Engineer
  Security & Monitoring Division
  
  Barco N.V.
  Noordlaan 5, 
  B-8520 Kuurne
  Tel. +32 (0)56 368 428
  Tel. +32 (0)56 368 605
  mailto:marc.leeman at barco.com
  http://www.barco.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmalloc_realpath.diff
Type: text/x-diff
Size: 459 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070207/35980f6c/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070207/35980f6c/attachment-0002.pgp 

From vda.linux at googlemail.com  Wed Feb  7 20:25:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 21:25:43 +0100
Subject: Busybox compilation error
In-Reply-To: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
Message-ID: <200702072125.43257.vda.linux@googlemail.com>

On Wednesday 07 February 2007 06:02, Sina Mallick wrote:
> Hi,
> I am trying to compile busybox for ARM cpu...Am using arm bese toolchain...
> I am getting this error at the end...
> LINK    busybox_unstripped
> applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> `readahead_main'
> applets/built-in.o:(.rodata.applets+0x868): undefined reference to
> `taskset_main'
> collect2: ld returned 1 exit status
> make: *** [busybox_unstripped] Error 1
> 
> BTD I am keeping off two line  at /miscutils/Kbuild
> #lib-$(CONFIG_READAHEAD)   += readahead.o
> #lib-$(CONFIG_TASKSET)     += taskset.o
> 
> as if i keeping this two line then i am also geting some errors...
> Can anybody tell what should i do now..to solve this problem...

Please post your .comfig
--
vda


From vda.linux at googlemail.com  Wed Feb  7 21:26:49 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 22:26:49 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170840789.6604.48.camel@localhost>
References: <1170840789.6604.48.camel@localhost>
Message-ID: <200702072226.49159.vda.linux@googlemail.com>

On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> Hi,
> 
> I just discovered that busybox wget segfaults in my
> gentoo/hardened/uclibc environment.
> 
> strace shows this:
> 
> open("/etc/services", O_RDONLY)         = 3
> ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> (Inappropriate ioctl for device)
> brk(0x10e57000)                         = 0x10e57000
> read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> close(3)                                = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 15366 detached
> 
> Does anybody know anything about it?

What is your bbox version and .config? uclibc version and .config?
--
vda


From vda.linux at googlemail.com  Wed Feb  7 22:07:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:07:45 +0100
Subject: libselinux utilities applets - please test
In-Reply-To: <45C9F007.40706@kaigai.gr.jp>
References: <200702062029.33013.vda.linux@googlemail.com>
	<45C9F007.40706@kaigai.gr.jp>
Message-ID: <200702072307.45400.vda.linux@googlemail.com>

On Wednesday 07 February 2007 16:28, KaiGai Kohei wrote:
> Denis, Thanks for merging the series of patches.
> 
> > Okay. I applied your patch to svn and did some changes.
> > Please review & test - I can't run-test it at the moment
> > (my kernel and userspace is not selinux-enabled).
> > 
> > Patch is attached for easy review. Thanks.
> > --
> > vda
> 
> I found some problems on building SELinux related applets.
> The attached patch will fix them.

Thanks! Applied to svn. I also noticed one small optimization.

See the patch.

Consider testing it (just in case I messed something up).
--
vda

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.patch
Type: text/x-diff
Size: 3180 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070207/441ace4a/attachment-0002.bin 

From vda.linux at googlemail.com  Wed Feb  7 22:19:04 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:19:04 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070207165834.GT15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207163507.GR15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
Message-ID: <200702072319.04728.vda.linux@googlemail.com>

On Wednesday 07 February 2007 17:58, Marc Leeman wrote:
> On Wed, Feb 07, 2007 at 05:35:07PM +0100, Marc Leeman wrote:
> > > The link is replaced with a socket (/ fs is RW).
> > 
> > Forgot to mention that I am using uclibc on powerpc.:
> 
> 
> adding:
> 
> char *xmalloc_realpath(const char *path)
> {
> #if defined(__GLIBC__) && !defined(__UCLIBC__)
>     /* glibc provides a non-standard extension */
>     return realpath(path, NULL);
> #else
>     char buf[PATH_MAX+1];
> 
>     fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
>     fprintf(stdout,"realpath buf is %s\n",buf);
>     /* on error returns NULL (xstrdup(NULL) ==NULL) */
>     return xstrdup(realpath(path, buf));
> #endif
> }
> 
> results in:
> 
> $ /sbin/syslogd -n -m 0 -C16
> realpath returns (null)
> realpath buf is /tmp/log
> syslogd: bind: Address already in use
> 
> oeps!
> 
> let's blatantly ignore the comment about "on error":
> 
> char *xmalloc_realpath(const char *path)
> {
> #if defined(__GLIBC__) && !defined(__UCLIBC__)
>     /* glibc provides a non-standard extension */
>     return realpath(path, NULL);
> #else
>     char buf[PATH_MAX+1];
> 
>     fprintf(stdout,"realpath returns %s\n",realpath(path,buf));
>     fprintf(stdout,"realpath buf is %s\n",buf);
>     /* on error returns NULL (xstrdup(NULL) ==NULL) */
>     return xstrdup(buf);
> #endif
> }
> 
> $ ls -al /tmp/log
> srw-rw-rw-    1 0        0               0 Jan  1 00:00 /tmp/log
> 
> this seems to give us what we expect :)

Yeah, strange... but think about what will happen when realpath REALLY
will fail. We will xstrdup and return... something bogus?

Maybe you should look into uclibc. Why it returned NULL?
My manpage says:

RETURN VALUE
       If there is no error, realpath() returns a pointer to the
       resolved_path.
       Otherwise  it  returns a NULL pointer, and the contents
       of the array resolved_path are undefined. The global
       variable errno is set to indicate the error.

Yet another question is why syslogd even bothers to do this
remove/recreate cycle? What will happen if it will just
bind to /dev/log? (the code will be smaller too)
--
vda


From vda.linux at googlemail.com  Wed Feb  7 22:25:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:25:20 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702072319.04728.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
Message-ID: <200702072325.20231.vda.linux@googlemail.com>

On Wednesday 07 February 2007 23:19, Denis Vlasenko wrote:
> Yet another question is why syslogd even bothers to do this
> remove/recreate cycle? What will happen if it will just
> bind to /dev/log? (the code will be smaller too)

This is what will happen:

./busybox syslogd -n -O zz_syslog
syslogd: bind: Address already in use

I like it. Do you? I mean, let's kill realpath'ing entirely!

But don't forget to file uclibc bug report regarding realpath
at http://bugs.uclibc.org/
--
vda


From vda.linux at googlemail.com  Wed Feb  7 22:29:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 7 Feb 2007 23:29:20 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <200702072226.49159.vda.linux@googlemail.com>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
Message-ID: <200702072329.20826.vda.linux@googlemail.com>

On Wednesday 07 February 2007 22:26, Denis Vlasenko wrote:
> On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.
> > 
> > strace shows this:
> > 
> > open("/etc/services", O_RDONLY)         = 3
> > ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> > (Inappropriate ioctl for device)
> > brk(0x10e57000)                         = 0x10e57000
> > read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> > read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> > close(3)                                = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> > Process 15366 detached
> > 
> > Does anybody know anything about it?
> 
> What is your bbox version and .config? uclibc version and .config?

Oh, and of course, what is wget's commandline?
--
vda


From solar at gentoo.org  Wed Feb  7 22:39:14 2007
From: solar at gentoo.org (Ned Ludd)
Date: Wed, 07 Feb 2007 14:39:14 -0800
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170840789.6604.48.camel@localhost>
References: <1170840789.6604.48.camel@localhost>
Message-ID: <1170887954.14435.33.camel@onyx.private.gni.com>

On Wed, 2007-02-07 at 10:33 +0100, Natanael Copa wrote:
> Hi,
> 
> I just discovered that busybox wget segfaults in my
> gentoo/hardened/uclibc environment.

I more or less have a tinderbox setup with the same setup.

uClibc-0.9.28.1
busybox-1.4.1

gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2, HTB-3.4.4-1.00,
ssp-3.4.6-1.0, pie-8.7.9)

wget does not segfault here.

Unless your /etc/services matches the following checksum
bd6b457cdce64b7932a4db4d4a251265 can you post that also?

> 
> strace shows this:
> 
> open("/etc/services", O_RDONLY)         = 3
> ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> (Inappropriate ioctl for device)
> brk(0x10e57000)                         = 0x10e57000
> read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> close(3)                                = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 15366 detached
> 
> Does anybody know anything about it?
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
-- 
Ned Ludd <solar at gentoo.org>
Gentoo Linux



From education.sina at gmail.com  Thu Feb  8 00:47:30 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Thu, 8 Feb 2007 09:47:30 +0900
Subject: Busybox compilation error
In-Reply-To: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
Message-ID: <1ff320400702071647x1b64de12m10bef0c1c59fccd8@mail.gmail.com>

Hi,
> I am trying to compile busybox for ARM cpu...Am using arm bese
> toolchain...
> I am getting this error at the end...
> LINK    busybox_unstripped
> applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> `readahead_main'
> applets/built-in.o: (.rodata.applets+0x868): undefined reference to
> `taskset_main'
> collect2: ld returned 1 exit status
> make: *** [busybox_unstripped] Error 1
>
> BTD I am keeping off two line  at /miscutils/Kbuild
> #lib-$(CONFIG_READAHEAD)   += readahead.o
> #lib-$(CONFIG_TASKSET)     += taskset.o
>
> as if i keeping this two line then i am also geting some errors...
> Can anybody tell what should i do now..to solve this problem...
>
> Thanks
> Sina

I am attaching .config file at this mail...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070208/eecffe45/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busyconfig
Type: application/octet-stream
Size: 15741 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/eecffe45/attachment-0002.obj 

From education.sina at gmail.com  Thu Feb  8 00:41:17 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Thu, 8 Feb 2007 09:41:17 +0900
Subject: Busybox compilation error
In-Reply-To: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
Message-ID: <1ff320400702071641x362f2494j5b0604c435c4cea4@mail.gmail.com>

Hi,
> I am trying to compile busybox for ARM cpu...Am using arm bese
> toolchain...
> I am getting this error at the end...
> LINK    busybox_unstripped
> applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> `readahead_main'
> applets/built-in.o: (.rodata.applets+0x868): undefined reference to
> `taskset_main'
> collect2: ld returned 1 exit status
> make: *** [busybox_unstripped] Error 1
>
> BTD I am keeping off two line  at /miscutils/Kbuild
> #lib-$(CONFIG_READAHEAD)   += readahead.o
> #lib-$(CONFIG_TASKSET)     += taskset.o
>
> as if i keeping this two line then i am also geting some errors...
> Can anybody tell what should i do now..to solve this problem...
>
> Thanks
> Sina
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070208/45ba084c/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Config.in
Type: application/octet-stream
Size: 15800 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/45ba084c/attachment-0002.obj 

From natanael.copa at gmail.com  Thu Feb  8 08:14:45 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Thu, 08 Feb 2007 09:14:45 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170887954.14435.33.camel@onyx.private.gni.com>
References: <1170840789.6604.48.camel@localhost>
	<1170887954.14435.33.camel@onyx.private.gni.com>
Message-ID: <1170922485.14212.10.camel@localhost>

On Wed, 2007-02-07 at 14:39 -0800, Ned Ludd wrote:
> On Wed, 2007-02-07 at 10:33 +0100, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.
> 
> I more or less have a tinderbox setup with the same setup.
> 
> uClibc-0.9.28.1

same here.

> busybox-1.4.1

same here but with backported find from svn.

> gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2, HTB-3.4.4-1.00,
> ssp-3.4.6-1.0, pie-8.7.9)

gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)

> 
> wget does not segfault here.
> 
> Unless your /etc/services matches the following checksum
> bd6b457cdce64b7932a4db4d4a251265 can you post that also?

bd6b457cdce64b7932a4db4d4a251265  /etc/services
yup... same.


The config is attatched.

> > 
> > strace shows this:
> > 
> > open("/etc/services", O_RDONLY)         = 3
> > ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5fc7f8d8) = -1 ENOTTY
> > (Inappropriate ioctl for device)
> > brk(0x10e57000)                         = 0x10e57000
> > read(3, "# /etc/services\n#\n# Network serv"..., 4096) = 4096
> > read(3, "E service\n# private\t77/udp\nvettc"..., 4096) = 4096
> > close(3)                                = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> > Process 15366 detached
> > 
> > Does anybody know anything about it?
> > 
> > 
> > _______________________________________________
> > busybox mailing list
> > busybox at busybox.net
> > http://busybox.net/cgi-bin/mailman/listinfo/busybox
> > 
-------------- next part --------------
#
# Automatically generated make config: don't edit
# Busybox version: 1.4.1
# Tue Feb  6 16:59:42 2007
#
CONFIG_HAVE_DOT_CONFIG=y

#
# Busybox Settings
#

#
# General Configuration
#
CONFIG_NITPICK=y
CONFIG_DESKTOP=y
CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
# CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set
# CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set
CONFIG_SHOW_USAGE=y
CONFIG_FEATURE_VERBOSE_USAGE=y
CONFIG_FEATURE_COMPRESS_USAGE=y
CONFIG_FEATURE_INSTALLER=y
# CONFIG_LOCALE_SUPPORT is not set
CONFIG_GETOPT_LONG=y
CONFIG_FEATURE_DEVPTS=y
# CONFIG_FEATURE_CLEAN_UP is not set
CONFIG_FEATURE_SUID=y
CONFIG_FEATURE_SYSLOG=y
# CONFIG_FEATURE_SUID_CONFIG is not set
# CONFIG_FEATURE_SUID_CONFIG_QUIET is not set
CONFIG_FEATURE_HAVE_RPC=y
# CONFIG_SELINUX is not set
CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe"

#
# Build Options
#
# CONFIG_STATIC is not set
# CONFIG_BUILD_LIBBUSYBOX is not set
# CONFIG_FEATURE_FULL_LIBBUSYBOX is not set
# CONFIG_FEATURE_SHARED_BUSYBOX is not set
CONFIG_LFS=y
# CONFIG_BUILD_AT_ONCE is not set

#
# Debugging Options
#
# CONFIG_DEBUG is not set
# CONFIG_DEBUG_PESSIMIZE is not set
# CONFIG_NO_DEBUG_LIB is not set
# CONFIG_DMALLOC is not set
# CONFIG_EFENCE is not set
# CONFIG_INCLUDE_SUSv2 is not set

#
# Installation Options
#
# CONFIG_INSTALL_NO_USR is not set
CONFIG_INSTALL_APPLET_SYMLINKS=y
# CONFIG_INSTALL_APPLET_HARDLINKS is not set
# CONFIG_INSTALL_APPLET_DONT is not set
CONFIG_PREFIX="./_install"

#
# Busybox Library Tuning
#
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SIZE_VS_SPEED=0

#
# Applets
#

#
# Archival Utilities
#
CONFIG_AR=y
CONFIG_FEATURE_AR_LONG_FILENAMES=y
CONFIG_BUNZIP2=y
CONFIG_CPIO=y
# CONFIG_DPKG is not set
# CONFIG_DPKG_DEB is not set
# CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set
CONFIG_GUNZIP=y
CONFIG_FEATURE_GUNZIP_UNCOMPRESS=y
CONFIG_GZIP=y
# CONFIG_RPM2CPIO is not set
# CONFIG_RPM is not set
CONFIG_TAR=y
CONFIG_FEATURE_TAR_CREATE=y
CONFIG_FEATURE_TAR_BZIP2=y
CONFIG_FEATURE_TAR_LZMA=y
CONFIG_FEATURE_TAR_FROM=y
CONFIG_FEATURE_TAR_GZIP=y
CONFIG_FEATURE_TAR_COMPRESS=y
CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y
# CONFIG_FEATURE_TAR_LONG_OPTIONS is not set
CONFIG_UNCOMPRESS=y
CONFIG_UNLZMA=y
CONFIG_FEATURE_LZMA_FAST=y
CONFIG_UNZIP=y

#
# Common options for cpio and tar
#
CONFIG_FEATURE_UNARCHIVE_TAPE=y
# CONFIG_FEATURE_DEB_TAR_GZ is not set
# CONFIG_FEATURE_DEB_TAR_BZ2 is not set
# CONFIG_FEATURE_DEB_TAR_LZMA is not set

#
# Coreutils
#
CONFIG_BASENAME=y
CONFIG_CAL=y
CONFIG_CAT=y
CONFIG_CATV=y
CONFIG_CHGRP=y
CONFIG_CHMOD=y
CONFIG_CHOWN=y
CONFIG_CHROOT=y
CONFIG_CKSUM=y
CONFIG_CMP=y
CONFIG_COMM=y
CONFIG_CP=y
CONFIG_CUT=y
CONFIG_DATE=y
CONFIG_FEATURE_DATE_ISOFMT=y
CONFIG_DD=y
CONFIG_FEATURE_DD_SIGNAL_HANDLING=y
CONFIG_FEATURE_DD_IBS_OBS=y
CONFIG_DF=y
CONFIG_DIFF=y
CONFIG_FEATURE_DIFF_BINARY=y
CONFIG_FEATURE_DIFF_DIR=y
CONFIG_FEATURE_DIFF_MINIMAL=y
CONFIG_DIRNAME=y
CONFIG_DOS2UNIX=y
CONFIG_UNIX2DOS=y
CONFIG_DU=y
CONFIG_FEATURE_DU_DEFAULT_BLOCKSIZE_1K=y
CONFIG_ECHO=y
CONFIG_FEATURE_FANCY_ECHO=y
CONFIG_ENV=y
# CONFIG_FEATURE_ENV_LONG_OPTIONS is not set
CONFIG_EXPR=y
CONFIG_EXPR_MATH_SUPPORT_64=y
CONFIG_FALSE=y
CONFIG_FOLD=y
CONFIG_HEAD=y
CONFIG_FEATURE_FANCY_HEAD=y
CONFIG_HOSTID=y
CONFIG_ID=y
CONFIG_INSTALL=y
# CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set
CONFIG_LENGTH=y
CONFIG_LN=y
# CONFIG_LOGNAME is not set
CONFIG_LS=y
CONFIG_FEATURE_LS_FILETYPES=y
CONFIG_FEATURE_LS_FOLLOWLINKS=y
CONFIG_FEATURE_LS_RECURSIVE=y
CONFIG_FEATURE_LS_SORTFILES=y
CONFIG_FEATURE_LS_TIMESTAMPS=y
CONFIG_FEATURE_LS_USERNAME=y
CONFIG_FEATURE_LS_COLOR=y
CONFIG_FEATURE_LS_COLOR_IS_DEFAULT=y
CONFIG_MD5SUM=y
CONFIG_MKDIR=y
# CONFIG_FEATURE_MKDIR_LONG_OPTIONS is not set
CONFIG_MKFIFO=y
CONFIG_MKNOD=y
CONFIG_MV=y
# CONFIG_FEATURE_MV_LONG_OPTIONS is not set
CONFIG_NICE=y
CONFIG_NOHUP=y
# CONFIG_OD is not set
CONFIG_PRINTENV=y
CONFIG_PRINTF=y
CONFIG_PWD=y
CONFIG_REALPATH=y
CONFIG_RM=y
CONFIG_RMDIR=y
CONFIG_SEQ=y
CONFIG_SHA1SUM=y
CONFIG_SLEEP=y
CONFIG_FEATURE_FANCY_SLEEP=y
CONFIG_SORT=y
CONFIG_FEATURE_SORT_BIG=y
CONFIG_STAT=y
CONFIG_FEATURE_STAT_FORMAT=y
CONFIG_STTY=y
CONFIG_SUM=y
CONFIG_SYNC=y
CONFIG_TAIL=y
CONFIG_FEATURE_FANCY_TAIL=y
CONFIG_TEE=y
CONFIG_FEATURE_TEE_USE_BLOCK_IO=y
CONFIG_TEST=y
CONFIG_FEATURE_TEST_64=y
CONFIG_TOUCH=y
CONFIG_TR=y
CONFIG_FEATURE_TR_CLASSES=y
CONFIG_FEATURE_TR_EQUIV=y
CONFIG_TRUE=y
CONFIG_TTY=y
CONFIG_UNAME=y
CONFIG_UNIQ=y
CONFIG_USLEEP=y
# CONFIG_UUDECODE is not set
CONFIG_UUENCODE=y
CONFIG_WATCH=y
CONFIG_WC=y
# CONFIG_FEATURE_WC_LARGE is not set
CONFIG_WHO=y
CONFIG_WHOAMI=y
CONFIG_YES=y

#
# Common options for cp and mv
#
CONFIG_FEATURE_PRESERVE_HARDLINKS=y

#
# Common options for ls, more and telnet
#
CONFIG_FEATURE_AUTOWIDTH=y

#
# Common options for df, du, ls
#
CONFIG_FEATURE_HUMAN_READABLE=y

#
# Common options for md5sum, sha1sum
#
CONFIG_FEATURE_MD5_SHA1_SUM_CHECK=y

#
# Console Utilities
#
CONFIG_CHVT=y
CONFIG_CLEAR=y
CONFIG_DEALLOCVT=y
CONFIG_DUMPKMAP=y
CONFIG_LOADFONT=y
CONFIG_LOADKMAP=y
CONFIG_OPENVT=y
CONFIG_RESET=y
CONFIG_RESIZE=y
CONFIG_FEATURE_RESIZE_PRINT=y
CONFIG_SETCONSOLE=y
# CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS is not set
CONFIG_SETKEYCODES=y
CONFIG_SETLOGCONS=y

#
# Debian Utilities
#
CONFIG_MKTEMP=y
CONFIG_PIPE_PROGRESS=y
CONFIG_READLINK=y
CONFIG_FEATURE_READLINK_FOLLOW=y
CONFIG_RUN_PARTS=y
CONFIG_FEATURE_RUN_PARTS_LONG_OPTIONS=y
CONFIG_START_STOP_DAEMON=y
CONFIG_FEATURE_START_STOP_DAEMON_FANCY=y
CONFIG_FEATURE_START_STOP_DAEMON_LONG_OPTIONS=y
CONFIG_WHICH=y

#
# Editors
#
CONFIG_AWK=y
CONFIG_FEATURE_AWK_MATH=y
# CONFIG_ED is not set
CONFIG_PATCH=y
CONFIG_SED=y
CONFIG_VI=y
CONFIG_FEATURE_VI_COLON=y
CONFIG_FEATURE_VI_YANKMARK=y
CONFIG_FEATURE_VI_SEARCH=y
CONFIG_FEATURE_VI_USE_SIGNALS=y
CONFIG_FEATURE_VI_DOT_CMD=y
CONFIG_FEATURE_VI_READONLY=y
CONFIG_FEATURE_VI_SETOPTS=y
CONFIG_FEATURE_VI_SET=y
CONFIG_FEATURE_VI_WIN_RESIZE=y
CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
CONFIG_FEATURE_ALLOW_EXEC=y

#
# Finding Utilities
#
CONFIG_FIND=y
CONFIG_FEATURE_FIND_PRINT0=y
CONFIG_FEATURE_FIND_MTIME=y
CONFIG_FEATURE_FIND_MMIN=y
CONFIG_FEATURE_FIND_PERM=y
CONFIG_FEATURE_FIND_TYPE=y
CONFIG_FEATURE_FIND_XDEV=y
CONFIG_FEATURE_FIND_NEWER=y
CONFIG_FEATURE_FIND_INUM=y
CONFIG_FEATURE_FIND_EXEC=y
CONFIG_FEATURE_FIND_USER=y
CONFIG_FEATURE_FIND_NOT=y
CONFIG_GREP=y
CONFIG_FEATURE_GREP_EGREP_ALIAS=y
CONFIG_FEATURE_GREP_FGREP_ALIAS=y
CONFIG_FEATURE_GREP_CONTEXT=y
CONFIG_XARGS=y
CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION=y
CONFIG_FEATURE_XARGS_SUPPORT_QUOTES=y
CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT=y
CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM=y

#
# Init Utilities
#
CONFIG_INIT=y
# CONFIG_DEBUG_INIT is not set
CONFIG_FEATURE_USE_INITTAB=y
CONFIG_FEATURE_INIT_SCTTY=y
CONFIG_FEATURE_EXTRA_QUIET=y
# CONFIG_FEATURE_INIT_COREDUMPS is not set
CONFIG_FEATURE_INITRD=y
CONFIG_HALT=y
CONFIG_MESG=y

#
# Login/Password Management Utilities
#
CONFIG_FEATURE_SHADOWPASSWDS=y
CONFIG_USE_BB_SHADOW=y
CONFIG_USE_BB_PWD_GRP=y
CONFIG_ADDGROUP=y
CONFIG_DELGROUP=y
CONFIG_ADDUSER=y
CONFIG_DELUSER=y
CONFIG_GETTY=y
CONFIG_FEATURE_UTMP=y
CONFIG_FEATURE_WTMP=y
CONFIG_LOGIN=y
CONFIG_LOGIN_SCRIPTS=y
CONFIG_FEATURE_SECURETTY=y
CONFIG_PASSWD=y
CONFIG_FEATURE_PASSWD_WEAK_CHECK=y
CONFIG_SU=y
CONFIG_FEATURE_SU_SYSLOG=y
CONFIG_FEATURE_SU_CHECKS_SHELLS=y
# CONFIG_SULOGIN is not set
CONFIG_VLOCK=y

#
# Linux Ext2 FS Progs
#
# CONFIG_CHATTR is not set
# CONFIG_FSCK is not set
# CONFIG_LSATTR is not set

#
# Linux Module Utilities
#
CONFIG_INSMOD=y
# CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set
# CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS is not set
# CONFIG_FEATURE_INSMOD_LOADINKMEM is not set
# CONFIG_FEATURE_INSMOD_LOAD_MAP is not set
# CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set
CONFIG_RMMOD=y
CONFIG_LSMOD=y
CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT=y
CONFIG_MODPROBE=y
CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS=y
CONFIG_FEATURE_MODPROBE_FANCY_ALIAS=y

#
# Options common to multiple modutils
#
CONFIG_FEATURE_CHECK_TAINTED_MODULE=y
# CONFIG_FEATURE_2_4_MODULES is not set
CONFIG_FEATURE_2_6_MODULES=y
# CONFIG_FEATURE_QUERY_MODULE_INTERFACE is not set

#
# Linux System Utilities
#
CONFIG_DMESG=y
CONFIG_FEATURE_DMESG_PRETTY=y
CONFIG_FBSET=y
CONFIG_FEATURE_FBSET_FANCY=y
CONFIG_FEATURE_FBSET_READMODE=y
CONFIG_FDFLUSH=y
CONFIG_FDFORMAT=y
CONFIG_FDISK=y
CONFIG_FDISK_SUPPORT_LARGE_DISKS=y
CONFIG_FEATURE_FDISK_WRITABLE=y
CONFIG_FEATURE_AIX_LABEL=y
CONFIG_FEATURE_SGI_LABEL=y
CONFIG_FEATURE_SUN_LABEL=y
CONFIG_FEATURE_OSF_LABEL=y
CONFIG_FEATURE_FDISK_ADVANCED=y
CONFIG_FREERAMDISK=y
# CONFIG_FSCK_MINIX is not set
# CONFIG_MKFS_MINIX is not set
# CONFIG_FEATURE_MINIX2 is not set
CONFIG_GETOPT=y
CONFIG_HEXDUMP=y
CONFIG_HWCLOCK=y
# CONFIG_FEATURE_HWCLOCK_LONG_OPTIONS is not set
CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y
CONFIG_IPCRM=y
CONFIG_IPCS=y
CONFIG_LOSETUP=y
CONFIG_MDEV=y
CONFIG_FEATURE_MDEV_CONF=y
CONFIG_FEATURE_MDEV_EXEC=y
CONFIG_MKSWAP=y
# CONFIG_FEATURE_MKSWAP_V0 is not set
CONFIG_MORE=y
CONFIG_FEATURE_USE_TERMIOS=y
CONFIG_MOUNT=y
CONFIG_FEATURE_MOUNT_NFS=y
CONFIG_FEATURE_MOUNT_CIFS=y
CONFIG_FEATURE_MOUNT_FLAGS=y
CONFIG_FEATURE_MOUNT_FSTAB=y
# CONFIG_PIVOT_ROOT is not set
CONFIG_RDATE=y
CONFIG_READPROFILE=y
# CONFIG_SETARCH is not set
CONFIG_SWAPONOFF=y
# CONFIG_SWITCH_ROOT is not set
CONFIG_UMOUNT=y
CONFIG_FEATURE_UMOUNT_ALL=y

#
# Common options for mount/umount
#
CONFIG_FEATURE_MOUNT_LOOP=y
# CONFIG_FEATURE_MTAB_SUPPORT is not set

#
# Miscellaneous Utilities
#
CONFIG_ADJTIMEX=y
CONFIG_BBCONFIG=y
CONFIG_CROND=y
# CONFIG_DEBUG_CROND_OPTION is not set
CONFIG_FEATURE_CROND_CALL_SENDMAIL=y
CONFIG_CRONTAB=y
CONFIG_DC=y
# CONFIG_DEVFSD is not set
# CONFIG_DEVFSD_MODLOAD is not set
# CONFIG_DEVFSD_FG_NP is not set
# CONFIG_DEVFSD_VERBOSE is not set
# CONFIG_FEATURE_DEVFS is not set
CONFIG_EJECT=y
CONFIG_LAST=y
CONFIG_LESS=y
CONFIG_FEATURE_LESS_MAXLINES=9999999
CONFIG_FEATURE_LESS_BRACKETS=y
CONFIG_FEATURE_LESS_FLAGS=y
CONFIG_FEATURE_LESS_FLAGCS=y
CONFIG_FEATURE_LESS_MARKS=y
CONFIG_FEATURE_LESS_REGEXP=y
# CONFIG_HDPARM is not set
# CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set
# CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set
# CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set
CONFIG_MAKEDEVS=y
# CONFIG_FEATURE_MAKEDEVS_LEAF is not set
CONFIG_FEATURE_MAKEDEVS_TABLE=y
CONFIG_MOUNTPOINT=y
CONFIG_MT=y
CONFIG_NMETER=y
CONFIG_RAIDAUTORUN=y
CONFIG_READAHEAD=y
CONFIG_RUNLEVEL=y
CONFIG_RX=y
CONFIG_STRINGS=y
CONFIG_SETSID=y
# CONFIG_TASKSET is not set
# CONFIG_FEATURE_TASKSET_FANCY is not set
CONFIG_TIME=y
CONFIG_WATCHDOG=y

#
# Networking Utilities
#
CONFIG_FEATURE_IPV6=y
CONFIG_ARP=y
CONFIG_ARPING=y
# CONFIG_DNSD is not set
CONFIG_ETHER_WAKE=y
CONFIG_FAKEIDENTD=y
# CONFIG_FTPGET is not set
# CONFIG_FTPPUT is not set
# CONFIG_FEATURE_FTPGETPUT_LONG_OPTIONS is not set
CONFIG_HOSTNAME=y
CONFIG_HTTPD=y
# CONFIG_FEATURE_HTTPD_RELOAD_CONFIG_SIGHUP is not set
CONFIG_FEATURE_HTTPD_SETUID=y
CONFIG_FEATURE_HTTPD_BASIC_AUTH=y
CONFIG_FEATURE_HTTPD_AUTH_MD5=y
CONFIG_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES=y
CONFIG_FEATURE_HTTPD_CGI=y
CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR=y
CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV=y
CONFIG_FEATURE_HTTPD_ENCODE_URL_STR=y
CONFIG_IFCONFIG=y
CONFIG_FEATURE_IFCONFIG_STATUS=y
CONFIG_FEATURE_IFCONFIG_SLIP=y
CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ=y
CONFIG_FEATURE_IFCONFIG_HW=y
CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS=y
CONFIG_IFUPDOWN=y
CONFIG_FEATURE_IFUPDOWN_IP=y
CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN=y
# CONFIG_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN is not set
CONFIG_FEATURE_IFUPDOWN_IPV4=y
CONFIG_FEATURE_IFUPDOWN_IPV6=y
# CONFIG_FEATURE_IFUPDOWN_IPX is not set
# CONFIG_FEATURE_IFUPDOWN_MAPPING is not set
CONFIG_INETD=y
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN is not set
# CONFIG_FEATURE_INETD_RPC is not set
CONFIG_IP=y
CONFIG_FEATURE_IP_ADDRESS=y
CONFIG_FEATURE_IP_LINK=y
CONFIG_FEATURE_IP_ROUTE=y
CONFIG_FEATURE_IP_TUNNEL=y
CONFIG_FEATURE_IP_RULE=y
CONFIG_FEATURE_IP_SHORT_FORMS=y
CONFIG_IPADDR=y
CONFIG_IPLINK=y
CONFIG_IPROUTE=y
CONFIG_IPTUNNEL=y
CONFIG_IPRULE=y
CONFIG_IPCALC=y
CONFIG_FEATURE_IPCALC_FANCY=y
# CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set
CONFIG_NAMEIF=y
CONFIG_NC=y
CONFIG_NC_SERVER=y
CONFIG_NC_EXTRA=y
CONFIG_NETSTAT=y
CONFIG_NSLOOKUP=y
CONFIG_PING=y
CONFIG_FEATURE_FANCY_PING=y
CONFIG_PING6=y
CONFIG_FEATURE_FANCY_PING6=y
CONFIG_ROUTE=y
CONFIG_TELNET=y
CONFIG_FEATURE_TELNET_TTYPE=y
CONFIG_FEATURE_TELNET_AUTOLOGIN=y
# CONFIG_TELNETD is not set
# CONFIG_FEATURE_TELNETD_STANDALONE is not set
# CONFIG_TFTP is not set
# CONFIG_FEATURE_TFTP_GET is not set
# CONFIG_FEATURE_TFTP_PUT is not set
# CONFIG_FEATURE_TFTP_BLOCKSIZE is not set
# CONFIG_DEBUG_TFTP is not set
CONFIG_TRACEROUTE=y
CONFIG_FEATURE_TRACEROUTE_VERBOSE=y
CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE=y
CONFIG_FEATURE_TRACEROUTE_USE_ICMP=y
CONFIG_APP_UDHCPD=y
CONFIG_APP_DHCPRELAY=y
CONFIG_APP_DUMPLEASES=y
CONFIG_APP_UDHCPC=y
CONFIG_FEATURE_UDHCP_SYSLOG=y
# CONFIG_FEATURE_UDHCP_DEBUG is not set
CONFIG_VCONFIG=y
CONFIG_WGET=y
CONFIG_FEATURE_WGET_STATUSBAR=y
CONFIG_FEATURE_WGET_AUTHENTICATION=y
CONFIG_FEATURE_WGET_IP6_LITERAL=y
# CONFIG_FEATURE_WGET_LONG_OPTIONS is not set
CONFIG_ZCIP=y

#
# Process Utilities
#
CONFIG_FREE=y
CONFIG_FUSER=y
CONFIG_KILL=y
CONFIG_KILLALL=y
CONFIG_KILLALL5=y
CONFIG_PIDOF=y
CONFIG_FEATURE_PIDOF_SINGLE=y
CONFIG_FEATURE_PIDOF_OMIT=y
CONFIG_PS=y
CONFIG_FEATURE_PS_WIDE=y
CONFIG_RENICE=y
CONFIG_BB_SYSCTL=y
CONFIG_TOP=y
CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE=y
CONFIG_UPTIME=y

#
# Shells
#
CONFIG_FEATURE_SH_IS_ASH=y
# CONFIG_FEATURE_SH_IS_HUSH is not set
# CONFIG_FEATURE_SH_IS_LASH is not set
# CONFIG_FEATURE_SH_IS_MSH is not set
# CONFIG_FEATURE_SH_IS_NONE is not set
CONFIG_ASH=y

#
# Ash Shell Options
#
CONFIG_ASH_JOB_CONTROL=y
CONFIG_ASH_READ_NCHARS=y
CONFIG_ASH_READ_TIMEOUT=y
CONFIG_ASH_ALIAS=y
CONFIG_ASH_MATH_SUPPORT=y
CONFIG_ASH_MATH_SUPPORT_64=y
CONFIG_ASH_GETOPTS=y
CONFIG_ASH_BUILTIN_ECHO=y
CONFIG_ASH_BUILTIN_TEST=y
CONFIG_ASH_CMDCMD=y
CONFIG_ASH_MAIL=y
CONFIG_ASH_OPTIMIZE_FOR_SIZE=y
CONFIG_ASH_RANDOM_SUPPORT=y
CONFIG_ASH_EXPAND_PRMT=y
# CONFIG_HUSH is not set
# CONFIG_LASH is not set
# CONFIG_MSH is not set

#
# Bourne Shell Options
#
CONFIG_FEATURE_SH_EXTRA_QUIET=y
# CONFIG_FEATURE_SH_STANDALONE_SHELL is not set
CONFIG_FEATURE_COMMAND_EDITING=y
CONFIG_FEATURE_COMMAND_EDITING_VI=y
CONFIG_FEATURE_COMMAND_HISTORY=31
CONFIG_FEATURE_COMMAND_SAVEHISTORY=y
CONFIG_FEATURE_COMMAND_TAB_COMPLETION=y
CONFIG_FEATURE_COMMAND_USERNAME_COMPLETION=y
CONFIG_FEATURE_SH_FANCY_PROMPT=y

#
# System Logging Utilities
#
CONFIG_SYSLOGD=y
CONFIG_FEATURE_ROTATE_LOGFILE=y
CONFIG_FEATURE_REMOTE_LOG=y
CONFIG_FEATURE_IPC_SYSLOG=y
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16
CONFIG_LOGREAD=y
CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
CONFIG_KLOGD=y
CONFIG_LOGGER=y

#
# Runit Utilities
#
# CONFIG_RUNSV is not set
# CONFIG_RUNSVDIR is not set
# CONFIG_SV is not set
# CONFIG_SVLOGD is not set
# CONFIG_CHPST is not set
# CONFIG_SETUIDGID is not set
# CONFIG_ENVUIDGID is not set
# CONFIG_ENVDIR is not set
# CONFIG_SOFTLIMIT is not set

From rep.dot.nop at gmail.com  Thu Feb  8 08:15:57 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 8 Feb 2007 09:15:57 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702072325.20231.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
	<200702072325.20231.vda.linux@googlemail.com>
Message-ID: <20070208081557.GA5301@aon.at>

On Wed, Feb 07, 2007 at 11:25:20PM +0100, Denis Vlasenko wrote:
>On Wednesday 07 February 2007 23:19, Denis Vlasenko wrote:
>> Yet another question is why syslogd even bothers to do this
>> remove/recreate cycle? What will happen if it will just
>> bind to /dev/log? (the code will be smaller too)
>
>This is what will happen:
>
>./busybox syslogd -n -O zz_syslog
>syslogd: bind: Address already in use
>
>I like it. Do you? I mean, let's kill realpath'ing entirely!
>
>But don't forget to file uclibc bug report regarding realpath
>at http://bugs.uclibc.org/

IIRC there is already a proposed fix for this. Yep:
http://busybox.net/lists/uclibc/2007-February/017284.html


From marc.leeman at gmail.com  Thu Feb  8 09:09:39 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Thu, 8 Feb 2007 10:09:39 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702072319.04728.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<20070207163507.GR15523@scorpius.homelinux.org>
	<20070207165834.GT15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
Message-ID: <20070208090939.GW15523@scorpius.homelinux.org>

> Maybe you should look into uclibc. Why it returned NULL?

I was planning to do so, but I just isolated and fixed the problem
around 18h, I'm going to see of something like that is already reported
in uclibc today.

> My manpage says:
> 
> RETURN VALUE
>        If there is no error, realpath() returns a pointer to the
>        resolved_path.
>        Otherwise  it  returns a NULL pointer, and the contents
>        of the array resolved_path are undefined. The global
>        variable errno is set to indicate the error.

I could not agree with you more on this: it really is uclibc that is not
following the manpage and I also noticed that the "resolved_path are
undefined" is not really something to cherish.

But the issue is that the re-write of syslogd triggered an underlying
problem in uclibc, making the current busybox not compatible with 0.9.28
based toolchains.

So the real question is: should busybox include a workaround for a,
hopefully, temporary problem in uclibc or not.

> Yet another question is why syslogd even bothers to do this
> remove/recreate cycle? What will happen if it will just
> bind to /dev/log? (the code will be smaller too)

Probably there is some reason that they did it like this in the past. It
could be that changing this breaks several crosscompilation
(buildroot/uclibc) systems. But this is just guessing on my part.

-- 
  greetz, marc
If he should ask for it, what body part are you willing to offer for
it, your Eminence?
	Pilot - DNA Mad Scientist
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/b04eed92/attachment-0002.pgp 

From natanael.copa at gmail.com  Thu Feb  8 09:28:20 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Thu, 08 Feb 2007 10:28:20 +0100
Subject: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <200702072226.49159.vda.linux@googlemail.com>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
Message-ID: <1170926900.14212.23.camel@localhost>

On Wed, 2007-02-07 at 22:26 +0100, Denis Vlasenko wrote:
> On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.

more info, from gdb:

al-1.5 busybox-1.4.1 # gdb ./busybox_unstripped
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-gentoo-linux-uclibc"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set args wget http://
(gdb) run
Starting program: /var/tmp/portage/busybox-1.4.1-r1/work/busybox-1.4.1/busybox_unstripped wget http://
warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4

Program received signal SIGSEGV, Segmentation fault.
bb_get_last_path_component (path=0x811074d "")
    at libbb/get_last_path_component.c:29
29              last[1] = 0;
(gdb) bt
#0  bb_get_last_path_component (path=0x811074d "")
    at libbb/get_last_path_component.c:29
#1  0x08096d39 in wget_main (argc=2, argv=0x810649d) at networking/wget.c:193
#2  0x080484ad in run_applet_by_name (name=0x8116a28 "F\035\017\b?k\t\b\003", 
    argc=134514459, argv=0xffab2c98) at applets/applets.c:489
#3  0x0804871b in busybox_main (argc=3, argv=0xffab2c94)
    at applets/busybox.c:143
#4  0x08048415 in run_applet_by_name (name=0xffab3b49 "busybox_unstripped", 
    argc=134513955, argv=0xffab2c94) at applets/applets.c:480
#5  0x08048523 in main (argc=-5559148, argv=0xffab2c94) at applets/busybox.c:72
(gdb) 





From natanael.copa at gmail.com  Thu Feb  8 10:18:58 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Thu, 08 Feb 2007 11:18:58 +0100
Subject: [RESOLVED] Re: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <200702072226.49159.vda.linux@googlemail.com>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
Message-ID: <1170929938.14212.37.camel@localhost>

On Wed, 2007-02-07 at 22:26 +0100, Denis Vlasenko wrote:
> On Wednesday 07 February 2007 10:33, Natanael Copa wrote:
> > Hi,
> > 
> > I just discovered that busybox wget segfaults in my
> > gentoo/hardened/uclibc environment.

Here is the explanation:

When url is "http://a/b" evertyhing works. When url is "http://a" then
the following happens:

parse_url sets target.path = ""

later, when guessing the out file name

 fname_out = bb_get_last_path_component(target.path);

bb_get_last_path_component() will write to target.path.

Looks like its fixed in svn. Would be nice to have it fixed for 1.4.2.

Attached is a patch for 1.4.1.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bb-wget-path.patch
Type: text/x-patch
Size: 457 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/3fe517bc/attachment-0002.bin 

From vda.linux at googlemail.com  Thu Feb  8 19:12:38 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 20:12:38 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070208090939.GW15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
	<20070208090939.GW15523@scorpius.homelinux.org>
Message-ID: <200702082012.38814.vda.linux@googlemail.com>

On Thursday 08 February 2007 10:09, Marc Leeman wrote:
> > Yet another question is why syslogd even bothers to do this
> > remove/recreate cycle? What will happen if it will just
> > bind to /dev/log? (the code will be smaller too)
> 
> Probably there is some reason that they did it like this in the past. It
> could be that changing this breaks several crosscompilation
> (buildroot/uclibc) systems. But this is just guessing on my part.

I tried. /dev/log is created by bind() of AF_UNIX.
If it exists, bind() will fail, even if no other process did bind().
That's why removing /dev/log is really needed.
--
vda


From ynakam at hitachisoft.jp  Thu Feb  8 06:54:48 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:48 +0900
Subject: [PATCH 5/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155448.961743fb.ynakam@hitachisoft.jp>


[5/6]  busybox-coreutils-05-ls.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-ls-05.patch
Type: application/octet-stream
Size: 592 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/f6149c3e/attachment-0002.obj 

From ynakam at hitachisoft.jp  Thu Feb  8 06:54:17 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:17 +0900
Subject: [PATCH 0/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155417.8d62937f.ynakam@hitachisoft.jp>

Hi.

The following patches provide SELinux options(like -Z) to coreutils 
We imported SELinux options from coreutils 5.97(included in Fedora Core6).
You have to enable CONFIG_SELINUX to use following feature.
Any of them are fundamental one to use SELinux.
We are welcoming any comment, and hope to merge it into busybox.


[1/6] busybox-coreutils-common-01.patch
 - usage.h for SELinux options

[2/6] busybox-coreutils-02-copy.patch
  - cp: -Z,-c option support. 
      -c option: security context is preserved during file copy.
      -Z option: security context can be set during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.

[3/6] busybox-coreutils-03-mk.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.

[4/6] busybox-coreutils-04-stat.patch
 - -Z option support for stat. Security context of file is shown by -Z option.

[5/6]  busybox-coreutils-05-ls.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.

[6/6] busybox-coreutils-06-id.patch
 - -Z option support for id. Security context of process is shown by -Z option.


This project is originated from some of JPSEUG(Japan SELinux User Group). 
Now, we are preparing to submit more patches to support SELinux commands/options.

Regards,

Yuichi Nakamura
Hitachi Software
SELinux Policy Editor: http://seedit.sourceforge.net/


From ynakam at hitachisoft.jp  Thu Feb  8 06:54:38 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:38 +0900
Subject: [PATCH 3/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>

[3/6] busybox-coreutils-03-mk.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.


Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-mk-03.patch
Type: application/octet-stream
Size: 2211 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/b4148715/attachment-0002.obj 

From ynakam at hitachisoft.jp  Thu Feb  8 06:54:56 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:56 +0900
Subject: [PATCH 6/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155456.2d016051.ynakam@hitachisoft.jp>

[6/6] busybox-coreutils-06-id.patch
 - -Z option support for id. Security context of process is shown by -Z option.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-id-06.patch
Type: application/octet-stream
Size: 2641 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/7813d8f6/attachment-0002.obj 

From ynakam at hitachisoft.jp  Thu Feb  8 06:54:26 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:26 +0900
Subject: [PATCH 1/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>


[1/6] busybox-coreutils-common-01.patch
 - usage.h for SELinux options

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.patch
Type: application/octet-stream
Size: 4206 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/282af443/attachment-0002.obj 

From ynakam at hitachisoft.jp  Thu Feb  8 06:54:32 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:32 +0900
Subject: [PATCH 2/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155432.e8234d84.ynakam@hitachisoft.jp>

[2/6] busybox-coreutils-02-copy.patch
  - cp: -Z,-c option support. 
      -c option: security context is preserved during file copy.
      -Z option: security context can be set during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.patch
Type: application/octet-stream
Size: 6414 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/96a1fb65/attachment-0002.obj 

From ynakam at hitachisoft.jp  Thu Feb  8 06:54:42 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 8 Feb 2007 15:54:42 +0900
Subject: [PATCH 4/6] busybox -- SELinux option support for coreutils
Message-ID: <20070208155442.045b052b.ynakam@hitachisoft.jp>

[4/6] busybox-coreutils-04-stat.patch
 - -Z option support for stat. Security context of file is shown by -Z option.

Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-stat-04.patch
Type: application/octet-stream
Size: 10382 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/92c89f09/attachment-0002.obj 

From marc.leeman at gmail.com  Thu Feb  8 19:39:12 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Thu, 8 Feb 2007 20:39:12 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <200702082012.38814.vda.linux@googlemail.com>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<200702072319.04728.vda.linux@googlemail.com>
	<20070208090939.GW15523@scorpius.homelinux.org>
	<200702082012.38814.vda.linux@googlemail.com>
Message-ID: <20070208193912.GC15523@scorpius.homelinux.org>

> I tried. /dev/log is created by bind() of AF_UNIX.

doh, on a RO fs?

> If it exists, bind() will fail, even if no other process did bind().
> That's why removing /dev/log is really needed.

No, /dev/ is not normally mounted on a rw filesystem (tmpfs). That's
probably why a symlink was used in the firsts place (to /tmp/log)


-- 
  greetz, marc
It's not Kansas, and you're way too homely to be Auntie Em, but... Come
here, Toto.
	Crichton - That Old Black Magic
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/54949273/attachment-0002.pgp 

From vda.linux at googlemail.com  Thu Feb  8 20:51:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 21:51:33 +0100
Subject: [PATCH] syslogd +realpath
In-Reply-To: <20070208193912.GC15523@scorpius.homelinux.org>
References: <20070207161525.GQ15523@scorpius.homelinux.org>
	<200702082012.38814.vda.linux@googlemail.com>
	<20070208193912.GC15523@scorpius.homelinux.org>
Message-ID: <200702082151.33326.vda.linux@googlemail.com>

On Thursday 08 February 2007 20:39, Marc Leeman wrote:
> > I tried. /dev/log is created by bind() of AF_UNIX.
> 
> doh, on a RO fs?

It is indeed created with bind(), but on RO fs it fails.

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
int main(int argc, char **argv)
{
        struct sockaddr_un sunx;
        socklen_t addr_len;
        int sock_fd;
//      unlink(argv[1]);
        memset(&sunx, 0, sizeof(sunx));
        sunx.sun_family = AF_UNIX;
        strncpy(sunx.sun_path, argv[1], sizeof(sunx.sun_path));
        sock_fd = socket(AF_UNIX, SOCK_DGRAM, 0);
        if (sock_fd < 0) return 1;
        addr_len = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
        bind(sock_fd, (struct sockaddr *) &sunx, addr_len);
        return 0;
}

Testing by stracing "testprog /dev/log2"

...
socket(PF_FILE, SOCK_DGRAM, 0)          = 4
bind(4, {sa_family=AF_FILE, path="/dev/log2"}, 11) = 0
exit_group(0)

and also now I see /dev/log2 socket.

Running that again:

...
socket(PF_FILE, SOCK_DGRAM, 0)          = 4
bind(4, {sa_family=AF_FILE, path="/dev/log2"}, 11) = -1 EADDRINUSE (Address already in use)
exit_group(0)


On RO fs (my / in RO, so I just do "testprog /bin/log2")

socket(PF_FILE, SOCK_DGRAM, 0)          = 4
bind(4, {sa_family=AF_FILE, path="/bin/log2"}, 11) = -1 EROFS (Read-only file system)
exit_group(0)  


> > If it exists, bind() will fail, even if no other process did bind().
> > That's why removing /dev/log is really needed.
> 
> No, /dev/ is not normally mounted on a rw filesystem (tmpfs). That's
> probably why a symlink was used in the firsts place (to /tmp/log)

Of sourse you may want to symlink /dev/log, and that's exactly why syslogd
tries to resolve the symlink - it needs to remove the socket, or else
it won't be able to bind to it.
--
vda


From vda.linux at googlemail.com  Fri Feb  9 00:10:27 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 9 Feb 2007 01:10:27 +0100
Subject: file descriptors
In-Reply-To: <20061215233441.CD5014855E@busybox.net>
References: <20061215233441.CD5014855E@busybox.net>
Message-ID: <200702090110.27682.vda.linux@googlemail.com>

On Saturday 16 December 2006 00:26, Eric Perraud wrote:
> Hello,
> 
> My application, running on busy box, potentially needs more than 1024 file
> descriptors available to it.
> 
> I have tried "ulimit -n 2048" on the command line and also tried adding the
> same line to the end of /etc/profile.
> 
> Either way, doing a "ulimit -a" shows nofiles  2048, however my application
> is still no longer able to open a file descriptor once it reaches 1024
> (verified by doing a ls | wc -w in /proc/<pid>/fs).
> 
> Additionally, I have verifed that the entire system is not running out of
> fd's by examining the values in /proc/sys/fs/file-nr
> 
> Any ideas on how to raise the "per process " file descriptor limit would
> much appreciated.

Google said me that I maybe need:
echo 32768 > /proc/sys/fs/file-max
increases the system limit on open files, and
ulimit -n 32768
increases the current process' limit.

On yet another page I read about increasing
/proc/sys/fs/inode-nr
too

I suggest you use Google too.
--
vda


From carl at matrixstream.com  Thu Feb  8 21:42:05 2007
From: carl at matrixstream.com (Carl Stewart)
Date: Thu, 8 Feb 2007 13:42:05 -0800
Subject: busybox 1.4.1 and rules.mak
Message-ID: <FDEIKJLBDHGMFFMHEKPGIENPDPAA.carl@matrixstream.com>

In busybox 1.2.2.1 and earlier, it used the rules.mak file to compile it.
But the compiling process seems to have changed now and that makefile is no
longer their.  The reason I'm asking is because the embedded system's SDK,
which is uclinux based, references that rules.mak file when adding and
compiling busybox to the rootfs folder.  And I want to be able to use
busybox 1.4.1 instead of 1.2.2.1 because 1.4.1 has the ability to mount smb
shares.

Anyone know how to do this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070208/297755b0/attachment.htm 

From vda.linux at googlemail.com  Thu Feb  8 22:29:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:29:37 +0100
Subject: [PATCH 1/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
References: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
Message-ID: <200702082329.37316.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> 
> [1/6] busybox-coreutils-common-01.patch
>  - usage.h for SELinux options
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>


@@ -1299,9 +1301,8 @@
 #define id_full_usage \
        "Print information for USERNAME or the current user" \
        "\n\nOptions:\n" \
-	USE_SELINUX( \
-       "	-c	Prints only the security context\n") \
-       "	-g	Prints only the group ID\n" \
+	   USAGE_SELINUX("	-Z	prints only the security context\n")	\
+	   "	-g	Prints only the group ID\n"						\

Well I can fix occasional problems but this is a bitt too much.
I would prefer more careful formatting, like:



        "	-u	Prints only the user ID\n" \
        "	-n	Print a name instead of a number\n" \
        "	-r	Prints the real user ID instead of the effective ID"
@@ -1519,7 +1520,9 @@
        "	-m	Set permission modes\n" \
        "	-o	Set ownership\n" \
        "	-p	Preserve date\n" \
-       "	-s	Strip symbol tables"
+       "    -s  Strip symbol tables\n" \
+	USAGE_SELINUX("	-P	preserve security context\n") \
+	USAGE_SELINUX("	Z	CONTEXT  set security context of copy to CONTEXT")
 
 #define ip_trivial_usage \
        "[OPTIONS] {address | link | route | tunnel | rule} {COMMAND}"
@@ -1829,7 +1832,9 @@
 	USE_SELINUX( \
        "\n	-k	Print security context") \
 	USE_SELINUX( \
-       "\n	-K	Print security context in long format")
+       "\n	-K	Print security context in long format") \
+	USE_SELINUX( \
+	"\n	-Z	Print security context and permission")
 
 #define lsattr_trivial_usage \
        "[-Radlv] [files...]"
@@ -1974,7 +1979,9 @@
        "Create the DIRECTORY(ies) if they do not already exist" \
        "\n\nOptions:\n" \
        "	-m	Set permission mode (as in chmod), not rwxrwxrwx - umask\n" \
-       "	-p	No error if existing, make parent directories as needed"
+       "	-p	No error if existing, make parent directories as needed\n"	\
+       USAGE_SELINUX("	-Z	set security context")
+
 #define mkdir_example_usage \
        "$ mkdir /tmp/foo\n" \
        "$ mkdir /tmp/foo\n" \
@@ -2019,7 +2026,8 @@
 #define mkfifo_full_usage \
        "Create a named pipe (identical to 'mknod name p')" \
        "\n\nOptions:\n" \
-       "	-m	Create the pipe using the specified mode (default a=rw)"
+       "	-m	Create the pipe using the specified mode (default a=rw)\n" \
+	USAGE_SELINUX("	-Z	set security context")
 
 #define mkfs_minix_trivial_usage \
        "[-c | -l filename] [-nXX] [-iXX] /dev/name [blocks]"
@@ -2041,7 +2049,9 @@
        "\n\nTYPEs include:\n" \
        "	b:	Make a block (buffered) device\n" \
        "	c or u:	Make a character (un-buffered) device\n" \
-       "	p:	Make a named pipe. MAJOR and MINOR are ignored for named pipes"
+       "	p:	Make a named pipe. MAJOR and MINOR are ignored for named pipes\n" \
+	USAGE_SELINUX("	-Z	set security context")
+
 #define mknod_example_usage \
        "$ mknod /dev/fd0 b 2 0\n" \
        "$ mknod -m 644 /tmp/pipe p\n"
@@ -2901,6 +2911,7 @@
        "	-f	Display filesystem status\n" \
        "	-L,-l	Dereference links\n" \
        "	-t	Display info in terse form" \
+	USAGE_SELINUX("	-Z	print security context\n") \
 	USE_FEATURE_STAT_FORMAT( \
        "\n\nValid format sequences for files:\n" \
        " %a	Access rights in octal\n" \
@@ -2935,6 +2946,7 @@
        " %c	Total file nodes in file system\n" \
        " %d	Free file nodes in file system\n" \
        " %f	Free blocks in file system\n" \
+	USAGE_SELINUX("	%C	Security context in SELinux\n")	\
        " %i	File System ID in hex\n" \
        " %l	Maximum length of filenames\n" \
        " %n	File name\n" \


From vda.linux at googlemail.com  Thu Feb  8 22:32:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:32:43 +0100
Subject: [PATCH 1/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
References: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
Message-ID: <200702082332.43175.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> 
> [1/6] busybox-coreutils-common-01.patch
>  - usage.h for SELinux options
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>


@@ -1299,9 +1301,8 @@
 #define id_full_usage \
        "Print information for USERNAME or the current user" \
        "\n\nOptions:\n" \
-	USE_SELINUX( \
-       "	-c	Prints only the security context\n") \
-       "	-g	Prints only the group ID\n" \
+	   USAGE_SELINUX("	-Z	prints only the security context\n")	\
+	   "	-g	Prints only the group ID\n"						\

Well I can fix occasional problems but this is a bitt too much.
I would prefer more careful formatting, like

	USAGE_SELINUX( \
       "	-Z	prints only the security context\n" \
	) \
       "	-g	Prints only the group ID\n" \

This helps to avoid misformatting in help texts.

The rest of this patch needs similar reformatting.
--
vda


From vda.linux at googlemail.com  Thu Feb  8 22:49:08 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:49:08 +0100
Subject: [PATCH 2/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155432.e8234d84.ynakam@hitachisoft.jp>
References: <20070208155432.e8234d84.ynakam@hitachisoft.jp>
Message-ID: <200702082349.08804.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> [2/6] busybox-coreutils-02-copy.patch
>   - cp: -Z,-c option support. 
>       -c option: security context is preserved during file copy.
>       -Z option: security context can be set during file copy.
>   - mv 
>     In SELinux, it is recommended to preserve security context 
>     when file is moved. By this patch, file context is preserved 
>     during file move.
>   - install
>     When file is copied by install, security context of installed file 
>     becomes different from value configured in file_contexts file.
>     By this patch, security context is set according to file_contexts file.
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>


Index: include/libbb.h
===================================================================
--- include/libbb.h	(revision 17803)
+++ include/libbb.h	(working copy)
@@ -743,9 +743,15 @@
 	FILEUTILS_INTERACTIVE = 0x10,
 	FILEUTILS_MAKE_HARDLINK = 0x20,
 	FILEUTILS_MAKE_SOFTLINK = 0x40,
+#if ENABLE_SELINUX
+	FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
+	FILEUTILS_SET_SECURITY_CONTEXT = 0x100
+#endif
+
 };

This empty line after #endif - why?

+#if ENABLE_SELINUX 
+	if (flags & FILEUTILS_SET_SECURITY_CONTEXT) {
+		if(is_selinux_enabled() == 0) {
+			fprintf( stderr, "Warning:  ignoring --context (-Z). "
+					 "It requires a SELinux enabled kernel.\n" );
+		}else{
+			if ( setfscreatecon(context_str) < 0 ) {
+				bb_error_msg_and_die("cannot set default security context %s\n", context_str);
+			}
+		}
+	}
+#endif

The style is not consistent. Should be "if ()", "} else {".
"Warning:  ignoring" has extra space for no reason.
fprintf(stderr) can be probably replaced by bb_error_msg:
bb_error_msg("warning: ignoring --context (-Z), it requires a SELinux enabled kernel");


+static int use_default_selinux_context = 1;

You never change it, it is always 1.  - ?!
--
vda


From vda.linux at googlemail.com  Thu Feb  8 22:53:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 8 Feb 2007 23:53:43 +0100
Subject: [PATCH 3/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>
References: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>
Message-ID: <200702082353.43667.vda.linux@googlemail.com>

On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> [3/6] busybox-coreutils-03-mk.patch
>  - -Z option support for mkdir, mkfifo, mknod. 
>     By -Z, security context for created file can be set.
> 
> Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>


+#if ENABLE_SELINUX
+	security_context_t scontext = NULL;
+#endif
 
 #if ENABLE_FEATURE_MKDIR_LONG_OPTIONS
 	applet_long_options = mkdir_long_options;
 #endif
-	opt = getopt32(argc, argv, "m:p", &smode);
+	opt = getopt32(argc, argv, "m:p" USE_SELINUX("Z:"), &smode USE_SELINUX(,&scontext));
 	if (opt & 1) {
 		mode = 0777;
 		if (!bb_parse_mode(smode, &mode)) {
@@ -50,6 +61,15 @@
 	}
 	if (opt & 2)
 		flags |= FILEUTILS_RECUR;
+#if ENABLE_SELINUX
+	if(opt & 4) {
+		selinux_or_die();
+		if (setfscreatecon(scontext)) {
+			bb_error_msg_and_die ("Sorry, cannot set default context "
+					      "to %s.\n", scontext);

Initializing scontext to NULL is useless code. bb_error_msg_and_die
has useless "Sorry" (with wrong capitalization: "mkdir: Sorry...")
and useless ".\n" at the end.

Sorry guys, I would be really happy if these patches get
a little bit prettier...
--
vda


From education.sina at gmail.com  Fri Feb  9 02:04:23 2007
From: education.sina at gmail.com (Sina Mallick)
Date: Fri, 9 Feb 2007 11:04:23 +0900
Subject: Busybox compilation error(for ARM CPU)
Message-ID: <1ff320400702081804x750ce909na2f0ec26f3e85ea@mail.gmail.com>

Hello ,

I am trying to compile busy box for ARM CPU....
Busybox version is 1.4.0...
I am fecing this problem when i am trying to run this command
#make ARCH=arm CROSS_COMPILE=/cross/arm-unknown-linux-gnu-
I am geting this error at the end....
 LINK    busybox_unstripped
applets/built-in.o:(.rodata.applets+0x664): undefined reference to
`readahead_main'
applets/built-in.o:(.rodata.applets+0x868): undefined reference to
`taskset_main'
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1

I am attaching my config with this email...

If anybody knows about this problem please help  me out ....

Thanks
Sina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070209/b8cf9225/attachment-0002.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busyconfig
Type: application/octet-stream
Size: 15741 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070209/b8cf9225/attachment-0002.obj 

From ddaney at avtrex.com  Fri Feb  9 02:04:31 2007
From: ddaney at avtrex.com (David Daney)
Date: Thu, 08 Feb 2007 18:04:31 -0800
Subject: Detecting link state in dhcpc...
Message-ID: <45CBD6AF.7060407@avtrex.com>

I recall reading on the list recently that someone was thinking about 
modifying dhcpc to do nice things when the link state changes.

Has this been done?

If not, I think I will be doing it very soon.

David Daney


From vapier at gentoo.org  Fri Feb  9 04:56:51 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 8 Feb 2007 23:56:51 -0500
Subject: busybox 1.4.1 and rules.mak
In-Reply-To: <FDEIKJLBDHGMFFMHEKPGIENPDPAA.carl@matrixstream.com>
References: <FDEIKJLBDHGMFFMHEKPGIENPDPAA.carl@matrixstream.com>
Message-ID: <200702082356.52557.vapier@gentoo.org>

On Thursday 08 February 2007, Carl Stewart wrote:
> In busybox 1.2.2.1 and earlier, it used the rules.mak file to compile it.
> But the compiling process seems to have changed now and that makefile is no
> longer their.  The reason I'm asking is because the embedded system's SDK,
> which is uclinux based, references that rules.mak file when adding and
> compiling busybox to the rootfs folder.  And I want to be able to use
> busybox 1.4.1 instead of 1.2.2.1 because 1.4.1 has the ability to mount smb
> shares.
>
> Anyone know how to do this?

what's wrong with `$(MAKE) -C busybox` ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070208/ba9a649f/attachment-0002.pgp 

From marc.leeman at gmail.com  Fri Feb  9 08:36:05 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Fri, 9 Feb 2007 09:36:05 +0100
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702090021.35590.vapier@gentoo.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702081409.43111.vapier@gentoo.org>
	<20070208193704.GB15523@scorpius.homelinux.org>
	<200702090021.35590.vapier@gentoo.org>
Message-ID: <20070209083605.GF15523@scorpius.homelinux.org>

Cc to busybox ML.

> > > could you be more specific as to what is breaking ?  "syslogd breaks on
> > > read only filesystems" does not translate well into actual test cases for
> > > inclusion into uClibc testsuite ...
> >
> > cf. busybox discussion of yesterday:
> >
> > http://www.busybox.net/lists/busybox/2007-February/026252.html
> 
> ok, looking again and i see your setup is:
>  - /dev is mounted RO
>  - /tmp is mounted RW
>  - /dev/log is a symlink to ../tmp/log
> 
> busybox launches sysklogd which does:
>  - dev_log_name = xmalloc_realpath(/dev/log)
>  - unlink(dev_log_name)
> 
> on your system, dev_log_name should be resolving to /tmp/log but it seems to 
> return NULL ... on my system, it works:
> # ls -l /dev/log /tmp/log 
> lrwxrwxrwx 1 root root 10 2007-02-08 23:58 /dev/log -> ../tmp/log
> -rw-r--r-- 1 root root  0 2007-02-08 23:58 /tmp/log
> # ./busybox syslogd -n
> running xmalloc_realpath(/dev/log)
> got back /tmp/log
> dev_log_name is now /tmp/log
> unlinking(/tmp/log)
> exiting now
> # ./busybox syslogd -n
> running xmalloc_realpath(/dev/log)
> got back (null)
> dev_log_name is now /dev/log
> unlinking(/dev/log)
> exiting now
> 
> this behavior is correct ... since /tmp/log was removed in the first run, the 
> second run should actually return NULL ...

The system is using an empty /tmp fs (tmpfs), so the socket or any other
file is not present in /tmp when xmallok_realpath("/dev/log") is called.

The old syslogd implementation correctly de-referenced the pointer in
/dev/log to /tmp/log and created a /tmp/log socket. the new syslogd
implementation tries to delete /dev/log on the RO filesystem and tries
to create the log socket there, what obviously fails on a RO fs.

So since uclibc's implementation of realpath matches glibc's; we should
re-store the relevant parts of the older syslogd code again instead of
fixing it in xmalloc_realpath()?

-- 
  greetz, marc
My dear, I've kicked more ass than you've sat on.
	Zhaan - Through the Looking Glass
scorpius.homelinux.org 2.6.19 #1 Tue Dec 5 16:35:02 CET 2006 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070209/e3e8d3ed/attachment-0002.pgp 

From develop at cle-mens.de  Fri Feb  9 16:15:18 2007
From: develop at cle-mens.de (Dirk Clemens)
Date: Fri, 09 Feb 2007 17:15:18 +0100
Subject: Bug in bb 1.3.1, httpd with POST
Message-ID: <45CC9E16.9010407@cle-mens.de>

I thing I have found a post bug in busybosy 1.3.1/mips.

If I want to take the POST input from stdin,
I get the following error message:

.../cgi-bin/test: line 3: read: read error: 0: Bad file descriptor

I will get this message in all cgi scripts and also if I do simply:
cat >/tmp/out

The vars REQUEST_METHOD and CONTENT_LENGTH are correct.

Dirk


From parmarsatpal at gmail.com  Fri Feb  9 16:56:38 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Fri, 9 Feb 2007 22:26:38 +0530
Subject: udhcp client not working
Message-ID: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>

Hi all;

   I am trying to make udchpc (UDHCP clinet from busybox) work on my kernel
(linux 2.6.11.12, linux 2.6.18 and linux 2.6.19 ).
 poted on arm9 board.I am getting following output


/ # udhcpc
udhcpc (v1.2.0-svn) started
eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:37

Sending discover...
Sending discover...
Sending discover...
eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:37

NETDEV WATCHDOG: eth0: transmit timed out
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

I have a linux machine which works as dhcp server at ip adress
192.168.0.1and I am able to concet to another windows machine with
adress
192.168.0.20

Tcpdump on linux machine reflect no packet received from board.

my dmesg log:

 139too Fast Ethernet driver 0.9.28
PCI: enabling device 0000:00:0b.0 (0140 -> 0143)
eth0: RealTek RTL8139 at 0x44800000, 00:40:f4:39:6a:61, IRQ 37
eth0:  Identified 8139 chip type 'RTL-8139C'
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing init memory: 80K
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008003c. (queue head)
eth0:  Tx descriptor 1 is 0008003c.
eth0:  Tx descriptor 2 is 0008003c.
eth0:  Tx descriptor 3 is 0008003c.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008024e. (queue head)
eth0:  Tx descriptor 1 is 0008024e.
eth0:  Tx descriptor 2 is 0008024e.
eth0:  Tx descriptor 3 is 0008024e.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008024e. (queue head)
eth0:  Tx descriptor 1 is 0008024e.
eth0:  Tx descriptor 2 is 0008024e.
eth0:  Tx descriptor 3 is 0008024e.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0d 0000 c07f media 00.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008024e. (queue head)
eth0:  Tx descriptor 1 is 0008024e.
eth0:  Tx descriptor 2 is 0008024e.
eth0:  Tx descriptor 3 is 0008024e.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

I would also like to know what configuration in networking are MUST for dhcp
clinet to work.

Thanks in advance.

satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070209/8d88c43e/attachment-0002.htm 

From rep.dot.nop at gmail.com  Fri Feb  9 17:18:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 18:18:21 +0100
Subject: udhcp client not working
In-Reply-To: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
References: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
Message-ID: <20070209171821.GS12488@aon.at>

On Fri, Feb 09, 2007 at 10:26:38PM +0530, satpal parmar wrote:
>Hi all;
>
>  I am trying to make udchpc (UDHCP clinet from busybox) work on my kernel

(1) Can you reproduce this with the current release? See
   http://busybox.net/
(2) Can you reproduce this with current trunk?
(3) does the HW and the driver work if you manually up the eth0 and ping
   some other host?

>(linux 2.6.11.12, linux 2.6.18 and linux 2.6.19 ).
>poted on arm9 board.I am getting following output
>
>
>/ # udhcpc
>udhcpc (v1.2.0-svn) started
>eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>         collisions:0 txqueuelen:1000
>         RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>         Interrupt:37
>
>Sending discover...
>Sending discover...
>Sending discover...
>eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>         collisions:0 txqueuelen:1000
>         RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>         Interrupt:37

grep eth /proc/interrupts if you happen to have /proc support in your
kernel. Short of that verify that your HW works as suggested in (3)

If no irq fires off, then drop the busybox list off.

HTH,
Bernhard


From ynakam at hitachisoft.jp  Fri Feb  9 07:44:09 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 16:44:09 +0900
Subject: [PATCH 0/6] busybox -- SELinux option support for coreutils
In-Reply-To: <1170941165.11912.208.camel@moss-spartans.epoch.ncsc.mil>
References: <20070208155417.8d62937f.ynakam@hitachisoft.jp>
	<1170941165.11912.208.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <20070209164409.3b302e35.ynakam@hitachisoft.jp>


On Thu, 08 Feb 2007 08:26:04 -0500
Stephen Smalley wrote:
> On Thu, 2007-02-08 at 15:54 +0900, Yuichi Nakamura wrote:
> > Hi.
> > 
> > The following patches provide SELinux options(like -Z) to coreutils 
> > We imported SELinux options from coreutils 5.97(included in Fedora Core6).
> > You have to enable CONFIG_SELINUX to use following feature.
> > Any of them are fundamental one to use SELinux.
> > We are welcoming any comment, and hope to merge it into busybox.
> 
> I'd suggest looking at the upstream coreutils selinux branch (see Jim
> Meyering's prior announcement of it on selinux list) and make sure you
> are consistent with it rather than Fedora Core 6, as I believe some
> aspects have changed (e.g. cp -a handling).
Thanks for information.
I've looked at upstream coreutils, and found some changes in cp and install.
I will fix them later.

> 
> > 
> > 
> > [1/6] busybox-coreutils-common-01.patch
> >  - usage.h for SELinux options
> > 
> > [2/6] busybox-coreutils-02-copy.patch
> >   - cp: -Z,-c option support. 
> >       -c option: security context is preserved during file copy.
> >       -Z option: security context can be set during file copy.
> >   - mv 
> >     In SELinux, it is recommended to preserve security context 
> >     when file is moved. By this patch, file context is preserved 
> >     during file move.
> >   - install
> >     When file is copied by install, security context of installed file 
> >     becomes different from value configured in file_contexts file.
> >     By this patch, security context is set according to file_contexts file.
> > 
> > [3/6] busybox-coreutils-03-mk.patch
> >  - -Z option support for mkdir, mkfifo, mknod. 
> >     By -Z, security context for created file can be set.
> > 
> > [4/6] busybox-coreutils-04-stat.patch
> >  - -Z option support for stat. Security context of file is shown by -Z option.
> > 
> > [5/6]  busybox-coreutils-05-ls.patch
> >  - -Z option support for ls. Security context of file is shown by -Z option.
> >    In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.
> > 
> > [6/6] busybox-coreutils-06-id.patch
> >  - -Z option support for id. Security context of process is shown by -Z option.
> > 
> > 
> > This project is originated from some of JPSEUG(Japan SELinux User Group). 
> > Now, we are preparing to submit more patches to support SELinux commands/options.
> > 
> > Regards,
> > 
> > Yuichi Nakamura
> > Hitachi Software
> > SELinux Policy Editor: http://seedit.sourceforge.net/
> > 
> > --
> > This message was distributed to subscribers of the selinux mailing list.
> > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with
> > the words "unsubscribe selinux" without quotes as the message.
> -- 
> Stephen Smalley
> National Security Agency
> 


From ynakam at hitachisoft.jp  Fri Feb  9 09:47:41 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 18:47:41 +0900
Subject: [busybox:00365] Re: [PATCH 1/6] busybox -- SELinux option
	support for coreutils
In-Reply-To: <200702082332.43175.vda.linux@googlemail.com>
References: <20070208155426.7e9ca113.ynakam@hitachisoft.jp>
	<200702082332.43175.vda.linux@googlemail.com>
Message-ID: <20070209184741.dcbef9a9.ynakam@hitachisoft.jp>

Thank you for comments.

On Thu, 8 Feb 2007 23:32:43 +0100
Denis Vlasenko  wrote:
> On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> > 
> > [1/6] busybox-coreutils-common-01.patch
> >  - usage.h for SELinux options
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> 
> @@ -1299,9 +1301,8 @@
>  #define id_full_usage \
>         "Print information for USERNAME or the current user" \
>         "\n\nOptions:\n" \
> -	USE_SELINUX( \
> -       "	-c	Prints only the security context\n") \
> -       "	-g	Prints only the group ID\n" \
> +	   USAGE_SELINUX("	-Z	prints only the security context\n")	\
> +	   "	-g	Prints only the group ID\n"						\
> 
> Well I can fix occasional problems but this is a bitt too much.
> I would prefer more careful formatting, like
> 
> 	USAGE_SELINUX( \
>        "	-Z	prints only the security context\n" \
> 	) \
>        "	-g	Prints only the group ID\n" \
> 
> This helps to avoid misformatting in help texts.
> 
> The rest of this patch needs similar reformatting.
Fixed.

> --
> vda
> 

We were porting SELinux option based on coreutils in Fedora Core6, 
but Stephen recommended to check upstream coreutils.
So I have checked upstream coreutils and found some SELinux option has been changed.
I have changed following:
* Removed -Z option from cp
* Added -Z and --preserve-context option to install

About cp,  -c option is dropped in upstream and "--preserve=context" is used instead.
However, cp in BusyBox does not have long options, so our patch still has -c option.

Yuichi Nakamura


-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v2.patch
Type: application/octet-stream
Size: 4171 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070209/89431eb2/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb  9 09:48:17 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 18:48:17 +0900
Subject: [busybox:00366] Re: [PATCH 2/6] busybox -- SELinux option
	support for coreutils
In-Reply-To: <200702082349.08804.vda.linux@googlemail.com>
References: <20070208155432.e8234d84.ynakam@hitachisoft.jp>
	<200702082349.08804.vda.linux@googlemail.com>
Message-ID: <20070209184817.3384ed07.ynakam@hitachisoft.jp>

On Thu, 8 Feb 2007 23:49:08 +0100
Denis Vlasenko wrote:
> On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> > [2/6] busybox-coreutils-02-copy.patch
> >   - cp: -Z,-c option support. 
> >       -c option: security context is preserved during file copy.
> >       -Z option: security context can be set during file copy.
> >   - mv 
> >     In SELinux, it is recommended to preserve security context 
> >     when file is moved. By this patch, file context is preserved 
> >     during file move.
> >   - install
> >     When file is copied by install, security context of installed file 
> >     becomes different from value configured in file_contexts file.
> >     By this patch, security context is set according to file_contexts file.
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> 
> Index: include/libbb.h
> ===================================================================
> --- include/libbb.h	(revision 17803)
> +++ include/libbb.h	(working copy)
> @@ -743,9 +743,15 @@
>  	FILEUTILS_INTERACTIVE = 0x10,
>  	FILEUTILS_MAKE_HARDLINK = 0x20,
>  	FILEUTILS_MAKE_SOFTLINK = 0x40,
> +#if ENABLE_SELINUX
> +	FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
> +	FILEUTILS_SET_SECURITY_CONTEXT = 0x100
> +#endif
> +
>  };
> 
> This empty line after #endif - why?

removed this empty line.

> 
> +#if ENABLE_SELINUX 
> +	if (flags & FILEUTILS_SET_SECURITY_CONTEXT) {
> +		if(is_selinux_enabled() == 0) {
> +			fprintf( stderr, "Warning:  ignoring --context (-Z). "
> +					 "It requires a SELinux enabled kernel.\n" );
> +		}else{
> +			if ( setfscreatecon(context_str) < 0 ) {
> +				bb_error_msg_and_die("cannot set default security context %s\n", context_str);
> +			}
> +		}
> +	}
> +#endif
This part is removed because upstream coreutils does not have -Z option for cp.

> 
> The style is not consistent. Should be "if ()", "} else {".
> "Warning:  ignoring" has extra space for no reason.
> fprintf(stderr) can be probably replaced by bb_error_msg:
> bb_error_msg("warning: ignoring --context (-Z), it requires a SELinux enabled kernel");
fixed.

> 
> 
> +static int use_default_selinux_context = 1;
> 
> You never change it, it is always 1.  - ?!
It is used in current patch.

> --
> vda
> 

Other changes are following:
* Removed -Z option from cp
* Added --preserve-context, -Z options to install


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.v2.patch
Type: application/octet-stream
Size: 7808 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070209/205fedc0/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb  9 09:48:53 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 9 Feb 2007 18:48:53 +0900
Subject: [busybox:00367] Re: [PATCH 3/6] busybox -- SELinux option
	support for coreutils
In-Reply-To: <200702082353.43667.vda.linux@googlemail.com>
References: <20070208155438.6cf3ebf3.ynakam@hitachisoft.jp>
	<200702082353.43667.vda.linux@googlemail.com>
Message-ID: <20070209184853.0671d4c9.ynakam@hitachisoft.jp>

On Thu, 8 Feb 2007 23:53:43 +0100
Denis Vlasenko wrote:
> On Thursday 08 February 2007 07:54, Yuichi Nakamura wrote:
> > [3/6] busybox-coreutils-03-mk.patch
> >  - -Z option support for mkdir, mkfifo, mknod. 
> >     By -Z, security context for created file can be set.
> > 
> > Signed-off-by: Yoshinori Sato <ysato at users.sourceforge.jp>
> 
> 
> +#if ENABLE_SELINUX
> +	security_context_t scontext = NULL;
> +#endif
>  
>  #if ENABLE_FEATURE_MKDIR_LONG_OPTIONS
>  	applet_long_options = mkdir_long_options;
>  #endif
> -	opt = getopt32(argc, argv, "m:p", &smode);
> +	opt = getopt32(argc, argv, "m:p" USE_SELINUX("Z:"), &smode USE_SELINUX(,&scontext));
>  	if (opt & 1) {
>  		mode = 0777;
>  		if (!bb_parse_mode(smode, &mode)) {
> @@ -50,6 +61,15 @@
>  	}
>  	if (opt & 2)
>  		flags |= FILEUTILS_RECUR;
> +#if ENABLE_SELINUX
> +	if(opt & 4) {
> +		selinux_or_die();
> +		if (setfscreatecon(scontext)) {
> +			bb_error_msg_and_die ("Sorry, cannot set default context "
> +					      "to %s.\n", scontext);
> 
> Initializing scontext to NULL is useless code. bb_error_msg_and_die
> has useless "Sorry" (with wrong capitalization: "mkdir: Sorry...")
> and useless ".\n" at the end.
Fixed.

> 
> Sorry guys, I would be really happy if these patches get
> a little bit prettier...
Thank you :-)

> --
> vda
> 


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-mk-03.v2.patch
Type: application/octet-stream
Size: 2213 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070209/292c4424/attachment-0002.obj 

From rep.dot.nop at gmail.com  Fri Feb  9 17:59:41 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 18:59:41 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CC9E16.9010407@cle-mens.de>
References: <45CC9E16.9010407@cle-mens.de>
Message-ID: <20070209175941.GT12488@aon.at>

On Fri, Feb 09, 2007 at 05:15:18PM +0100, Dirk Clemens wrote:
>I thing I have found a post bug in busybosy 1.3.1/mips.

Can you reproduce this with the current 1.4.1 (?) release or with trunk?
Please attach an strace for the cat > /tmp/out  case.
What toolchain did you use to build busybox?


From rep.dot.nop at gmail.com  Fri Feb  9 18:49:44 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 19:49:44 +0100
Subject: svn commit: trunk/busybox: include libbb networking
In-Reply-To: <20070209173217.8C217486DE@busybox.net>
References: <20070209173217.8C217486DE@busybox.net>
Message-ID: <20070209184944.GV12488@aon.at>

On Fri, Feb 09, 2007 at 09:32:17AM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-09 09:32:16 -0800 (Fri, 09 Feb 2007)
>New Revision: 17842
>
>Log:
>ping: support -I addr in family neutral manner; reuse a bit of common code

>Modified: trunk/busybox/include/usage.h
>===================================================================
>--- trunk/busybox/include/usage.h	2007-02-09 17:30:14 UTC (rev 17841)
>+++ trunk/busybox/include/usage.h	2007-02-09 17:32:16 UTC (rev 17842)
>@@ -2428,20 +2428,22 @@
> #define ping_full_usage \
>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>        "\n\nOptions:\n" \
>-       "	-c CNT	Send only CNT pings\n" \
>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>-       "	-I IP	Use IP as source address\n" \
>-       "	-q	Quiet mode, only displays output at start\n" \
>-       "		and when finished"
>+       "	-4, -6		Force IPv4 or IPv6 hostname resolution\n" \

s/resolution/resolving/g

btw (re: usage.h)
let me suggest the attached stripping of redundant information in
busybox_main.
Furthermore, That helptext should really be moved to usage.h to be able
to compress it, just as a sidenote ;)


>+       "	-c CNT		Send only CNT pings\n" \
>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>+       "	-I iface/IP	Use interface or IP address as source\n" \
>+       "	-q		Quiet mode, only displays output at start\n" \
>+       "			and when finished"
> #define ping6_trivial_usage \
>        "[OPTION]... host"
> #define ping6_full_usage \
>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>        "\n\nOptions:\n" \
>-       "	-c CNT	Send only CNT pings\n" \
>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>-       "	-q	Quiet mode, only displays output at start\n" \
>-       "		and when finished"

"Be quiet."
should suffice, really

>+       "	-c CNT		Send only CNT pings\n" \
>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>+       "	-I iface/IP	Use interface or IP address as source\n" \
>+       "	-q		Quiet mode, only displays output at start\n" \
>+       "			and when finished"

ditto

>Modified: trunk/busybox/networking/ping.c
>===================================================================
>--- trunk/busybox/networking/ping.c	2007-02-09 17:30:14 UTC (rev 17841)
>+++ trunk/busybox/networking/ping.c	2007-02-09 17:32:16 UTC (rev 17842)
>@@ -254,7 +254,7 @@
> 	struct sockaddr_in6 sin6;
> #endif
> } pingaddr;
>-static struct sockaddr_in sourceaddr;
>+static len_and_sockaddr *source_lsa;
> static int pingsock = -1;
> static unsigned datalen; /* intentionally uninitialized to work around gcc bug */
/* huh? what bug, exactly? */
 
>@@ -561,9 +561,8 @@
> 
> 	pingsock = create_icmp_socket();
> 	pingaddr.sin = lsa->sin;
>-	if (sourceaddr.sin_addr.s_addr) {
>-		xbind(pingsock, (struct sockaddr*)&sourceaddr, sizeof(sourceaddr));
>-	}
>+	if (source_lsa)
>+		xbind(pingsock, &lsa->sa, lsa->len);

Didn't look, but are there any users that can't rely on xbind using
#parm2->len so we could drop that explicit len parm?
 
> 	/* enable broadcast pings */
> 	setsockopt_broadcast(pingsock);

>@@ -695,25 +685,21 @@
> }
> #endif
> 
>-/* TODO: consolidate ether-wake.c, dnsd.c, ifupdown.c, nslookup.c
>- * versions of below thing. BTW we have far too many "%u.%u.%u.%u" too...
>-*/
>-static int parse_nipquad(const char *str, struct sockaddr_in* addr)
>+static void ping(len_and_sockaddr *lsa)

const len_and_sockaddr * const lsa , perhaps?

>@@ -732,9 +718,11 @@
> 	if (option_mask32 & OPT_s) datalen = xatou16(opt_s); // -s
> 	if (option_mask32 & OPT_I) { // -I
> 		if_index = if_nametoindex(opt_I);
>-		if (!if_index)
>-			if (parse_nipquad(opt_I, &sourceaddr))
>-				bb_show_usage();
>+		if (!if_index) {
>+			/* TODO: I'm not sure it takes IPv6 unless in [XX:XX..] format */

I'm unsure whether the decision to require that [XX:XX..] format was a
good idea since it sounds to be non-standard to me

cheers,


From etzvetanov at xceedium.com  Fri Feb  9 18:53:16 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 09 Feb 2007 13:53:16 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3DC0D.900@xceedium.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
	<45C3DC0D.900@xceedium.com>
Message-ID: <45CCC31C.1010300@xceedium.com>

I still can't make this work for me... When it comes to processing a lot 
of file listing information not only "ls -s" causes a segmentation 
fault, but also any attempt to use the file system functions does the 
same...
---
*ET*
**

Evgueni Tzvetanov wrote:
> David Daney wrote:
>   
>> Evgueni Tzvetanov wrote:
>>     
>>> Hi all,
>>>
>>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>>> little system for testing.
>>> It is running Linux kernel 2.6.18.1.
>>>
>>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>>> /usr/bin) it is pulling Segmentation Fault.
>>> What could be wrong or I am probably not on the same page with you 
>>> guys...
>>>
>>>       
>> What happens when you run it under gdb?
>>     
> Even stranger. When I call the command like (if this can help in anyway):
> "busybox ls -l" it is not bombing. When I run it as "ls -l" it is bombing.
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070209/9aa12b7e/attachment-0001.htm 

From rep.dot.nop at gmail.com  Fri Feb  9 19:14:07 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 20:14:07 +0100
Subject: svn commit: trunk/busybox: include libbb networking
In-Reply-To: <20070209184944.GV12488@aon.at>
References: <20070209173217.8C217486DE@busybox.net>
	<20070209184944.GV12488@aon.at>
Message-ID: <20070209191407.GW12488@aon.at>

On Fri, Feb 09, 2007 at 07:49:44PM +0100, Bernhard Fischer wrote:
>On Fri, Feb 09, 2007 at 09:32:17AM -0800, vda at busybox.net wrote:
>>Author: vda
>>Date: 2007-02-09 09:32:16 -0800 (Fri, 09 Feb 2007)
>>New Revision: 17842
>>
>>Log:
>>ping: support -I addr in family neutral manner; reuse a bit of common code
>
>>Modified: trunk/busybox/include/usage.h
>>===================================================================
>>--- trunk/busybox/include/usage.h	2007-02-09 17:30:14 UTC (rev 17841)
>>+++ trunk/busybox/include/usage.h	2007-02-09 17:32:16 UTC (rev 17842)
>>@@ -2428,20 +2428,22 @@
>> #define ping_full_usage \
>>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>>        "\n\nOptions:\n" \
>>-       "	-c CNT	Send only CNT pings\n" \
>>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>>-       "	-I IP	Use IP as source address\n" \
>>-       "	-q	Quiet mode, only displays output at start\n" \
>>-       "		and when finished"
>>+       "	-4, -6		Force IPv4 or IPv6 hostname resolution\n" \
>
>s/resolution/resolving/g
>
>btw (re: usage.h)
>let me suggest the attached stripping of redundant information in
>busybox_main.

And embarassingly enough i forgot to attach said hunks..
Attached now, sorry for the noise. <skip rest>

>Furthermore, That helptext should really be moved to usage.h to be able
>to compress it, just as a sidenote ;)
>
>
>>+       "	-c CNT		Send only CNT pings\n" \
>>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>>+       "	-I iface/IP	Use interface or IP address as source\n" \
>>+       "	-q		Quiet mode, only displays output at start\n" \
>>+       "			and when finished"
>> #define ping6_trivial_usage \
>>        "[OPTION]... host"
>> #define ping6_full_usage \
>>        "Send ICMP ECHO_REQUEST packets to network hosts" \
>>        "\n\nOptions:\n" \
>>-       "	-c CNT	Send only CNT pings\n" \
>>-       "	-s SIZE	Send SIZE data bytes in packets (default=56)\n" \
>>-       "	-q	Quiet mode, only displays output at start\n" \
>>-       "		and when finished"
>
>"Be quiet."
>should suffice, really
>
>>+       "	-c CNT		Send only CNT pings\n" \
>>+       "	-s SIZE		Send SIZE data bytes in packets (default=56)\n" \
>>+       "	-I iface/IP	Use interface or IP address as source\n" \
>>+       "	-q		Quiet mode, only displays output at start\n" \
>>+       "			and when finished"
>
>ditto
>
>>Modified: trunk/busybox/networking/ping.c
>>===================================================================
>>--- trunk/busybox/networking/ping.c	2007-02-09 17:30:14 UTC (rev 17841)
>>+++ trunk/busybox/networking/ping.c	2007-02-09 17:32:16 UTC (rev 17842)
>>@@ -254,7 +254,7 @@
>> 	struct sockaddr_in6 sin6;
>> #endif
>> } pingaddr;
>>-static struct sockaddr_in sourceaddr;
>>+static len_and_sockaddr *source_lsa;
>> static int pingsock = -1;
>> static unsigned datalen; /* intentionally uninitialized to work around gcc bug */
>/* huh? what bug, exactly? */
> 
>>@@ -561,9 +561,8 @@
>> 
>> 	pingsock = create_icmp_socket();
>> 	pingaddr.sin = lsa->sin;
>>-	if (sourceaddr.sin_addr.s_addr) {
>>-		xbind(pingsock, (struct sockaddr*)&sourceaddr, sizeof(sourceaddr));
>>-	}
>>+	if (source_lsa)
>>+		xbind(pingsock, &lsa->sa, lsa->len);
>
>Didn't look, but are there any users that can't rely on xbind using
>#parm2->len so we could drop that explicit len parm?
> 
>> 	/* enable broadcast pings */
>> 	setsockopt_broadcast(pingsock);
>
>>@@ -695,25 +685,21 @@
>> }
>> #endif
>> 
>>-/* TODO: consolidate ether-wake.c, dnsd.c, ifupdown.c, nslookup.c
>>- * versions of below thing. BTW we have far too many "%u.%u.%u.%u" too...
>>-*/
>>-static int parse_nipquad(const char *str, struct sockaddr_in* addr)
>>+static void ping(len_and_sockaddr *lsa)
>
>const len_and_sockaddr * const lsa , perhaps?
>
>>@@ -732,9 +718,11 @@
>> 	if (option_mask32 & OPT_s) datalen = xatou16(opt_s); // -s
>> 	if (option_mask32 & OPT_I) { // -I
>> 		if_index = if_nametoindex(opt_I);
>>-		if (!if_index)
>>-			if (parse_nipquad(opt_I, &sourceaddr))
>>-				bb_show_usage();
>>+		if (!if_index) {
>>+			/* TODO: I'm not sure it takes IPv6 unless in [XX:XX..] format */
>
>I'm unsure whether the decision to require that [XX:XX..] format was a
>good idea since it sounds to be non-standard to me
>
>cheers,
>_______________________________________________
>busybox mailing list
>busybox at busybox.net
>http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.shring-bare-helptext.00.diff
Type: text/x-diff
Size: 1002 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070209/785b565f/attachment-0002.bin 

From akennedy at techmoninc.com  Fri Feb  9 19:45:33 2007
From: akennedy at techmoninc.com (Andy Kennedy)
Date: Fri, 09 Feb 2007 13:45:33 -0600
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45C776AD.5090602@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com>
	<45C0EBB2.1090604@seiner.com>	<45C0F180.4000904@techmoninc.com>
	<45C11D80.20906@techmoninc.com>	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com>
Message-ID: <45CCCF5D.6040203@techmoninc.com>

Andy Kennedy wrote:
> To restate my problem (in case some kind developer decides to help me):
>
> When I have the kernel command line parameter "console=ttyS0,115200n8" 
> I get nice neat output on the serial line up until the init runs.  As 
> soon as init runs, I get missing chars.  So, I replace the BusyBox 
> init with minit, compiled from source and using the uCLibC gcc that I 
> let buildroot make for me.  Same problem.  For some reason, when the 
> system initializes -- after the kernel has reported all of its output, 
> my serial console goes splat.  When I initialize the console using 
> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
> One of these letters will appear each time I send enter.
>
> I have tried everything I can think of.  There is no script setting 
> any of the line speeds -- in fact, I have even attempted to remove the 
> scripts and still get the same thing.  Removing the 
> console=ttyS0,115200n8 (or attempting any variant of it) has no 
> affect, except without the console= I get no good output on the line.  
> The only thing I haven't attempted yet is to replace the getty with an 
> equivalent to see if that makes a difference.  I have also tried 9600, 
> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
> every combination, but I still cannot get a serial console.
>
> Can anyone offer a suggestion as to how I might fix this -- or some 
> other place to start?
>
> Thanks in advance for any help you can offer,
> Andy
Okay, now I'm really confused.  Here is what I have done so far:
Made my laptop boot with a console on ttyS0 and put a login shell on it 
(to verify that I can do it -- I was beginning to think maybe I needed 
to remove Linux from my computer and get rid of all of  it being to 
stupid to own a computer, much less program an embedded system) and I 
had no problems.  So, I took my syslinux disk and booted from it (the 
SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
everything comes up as you would expect.

Given that this test worked there is one of about three possibilities:
1) Cable issue.  Tested my serial cable on another embedded system (an 
Arcom Viper), checks out.  Replaced the break-out cable from the 
embedded system -- failed.  Tried a known good cable -- failed.  Tested 
a different VersaLogic board -- failed.  Now, here is the part that 
really yanked me around:

The last time I booted the machine I didn't have the keyboard connected 
to the break-out cable.  The boot went as it normally does except the 
keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
BusyBox init takes over the console and prints all kind of whack.  I 
plug in the keyboard and the keyboard driver prints a perfect string 
onto the serial console.

I've looked through the code to see what type of initialization init is 
doing to the console, but it doesn't look like it is re-initializing the 
sucker at all.  The only thing that I can think is that BusyBox is doing 
something that Linux doesn't do to interact with the ttyS0 so I'm not 
getting what I expect.

Perhaps this will click something in your head and you can help me fix this.

Thanks again for any help you can provide,
Andy Kennedy


From rep.dot.nop at gmail.com  Fri Feb  9 21:11:42 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 9 Feb 2007 22:11:42 +0100
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45CCCF5D.6040203@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com> <45C0EBB2.1090604@seiner.com>
	<45C0F180.4000904@techmoninc.com> <45C11D80.20906@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com> <45CCCF5D.6040203@techmoninc.com>
Message-ID: <20070209211142.GY12488@aon.at>

On Fri, Feb 09, 2007 at 01:45:33PM -0600, Andy Kennedy wrote:
>Andy Kennedy wrote:
>> To restate my problem (in case some kind developer decides to help me):
>>
>> When I have the kernel command line parameter "console=ttyS0,115200n8" 
>> I get nice neat output on the serial line up until the init runs.  As 
>> soon as init runs, I get missing chars.  So, I replace the BusyBox 
>> init with minit, compiled from source and using the uCLibC gcc that I 
>> let buildroot make for me.  Same problem.  For some reason, when the 
>> system initializes -- after the kernel has reported all of its output, 
>> my serial console goes splat.  When I initialize the console using 
>> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
>> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
>> One of these letters will appear each time I send enter.
>>
>> I have tried everything I can think of.  There is no script setting 
>> any of the line speeds -- in fact, I have even attempted to remove the 
>> scripts and still get the same thing.  Removing the 
>> console=ttyS0,115200n8 (or attempting any variant of it) has no 
>> affect, except without the console= I get no good output on the line.  
>> The only thing I haven't attempted yet is to replace the getty with an 
>> equivalent to see if that makes a difference.  I have also tried 9600, 
>> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
>> every combination, but I still cannot get a serial console.
>>
>> Can anyone offer a suggestion as to how I might fix this -- or some 
>> other place to start?
>>
>> Thanks in advance for any help you can offer,
>> Andy
>Okay, now I'm really confused.  Here is what I have done so far:
>Made my laptop boot with a console on ttyS0 and put a login shell on it 
>(to verify that I can do it -- I was beginning to think maybe I needed 
>to remove Linux from my computer and get rid of all of  it being to 
>stupid to own a computer, much less program an embedded system) and I 
>had no problems.  So, I took my syslinux disk and booted from it (the 
>SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
>everything comes up as you would expect.
>
>Given that this test worked there is one of about three possibilities:
>1) Cable issue.  Tested my serial cable on another embedded system (an 
>Arcom Viper), checks out.  Replaced the break-out cable from the 
>embedded system -- failed.  Tried a known good cable -- failed.  Tested 
>a different VersaLogic board -- failed.  Now, here is the part that 
>really yanked me around:
>
>The last time I booted the machine I didn't have the keyboard connected 
>to the break-out cable.  The boot went as it normally does except the 
>keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
>BusyBox init takes over the console and prints all kind of whack.  I 
>plug in the keyboard and the keyboard driver prints a perfect string 
>onto the serial console.
>
>I've looked through the code to see what type of initialization init is 
>doing to the console, but it doesn't look like it is re-initializing the 
>sucker at all.  The only thing that I can think is that BusyBox is doing 
>something that Linux doesn't do to interact with the ttyS0 so I'm not 
>getting what I expect.

IIRC busybox's init doesn't do anything special for serial lines.

As vda already suggested, better seek help on lkml or try to find
somebody to whom that <char><space><char>.. pattern sounds familiar.


From vapier at gentoo.org  Sat Feb 10 02:34:35 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 9 Feb 2007 21:34:35 -0500
Subject: realpath bug
In-Reply-To: <20070209083605.GF15523@scorpius.homelinux.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702090021.35590.vapier@gentoo.org>
	<20070209083605.GF15523@scorpius.homelinux.org>
Message-ID: <200702092134.35752.vapier@gentoo.org>

On Friday 09 February 2007, Marc Leeman wrote:
> The system is using an empty /tmp fs (tmpfs), so the socket or any other
> file is not present in /tmp when xmallok_realpath("/dev/log") is called.

then the behavior of realpath is correct ... it should return NULL on broken 
symlinks which is what it appears to be doing

> So since uclibc's implementation of realpath matches glibc's; we should
> re-store the relevant parts of the older syslogd code again instead of
> fixing it in xmalloc_realpath()?

that seems to be prudent i would think
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070209/d9d95fa7/attachment-0002.pgp 

From vda.linux at googlemail.com  Sat Feb 10 18:17:04 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:17:04 +0100
Subject: Busybox compilation error
In-Reply-To: <1ff320400702071647x1b64de12m10bef0c1c59fccd8@mail.gmail.com>
References: <1ff320400702062102n274a5a0bhb98db974230b4db9@mail.gmail.com>
	<1ff320400702071647x1b64de12m10bef0c1c59fccd8@mail.gmail.com>
Message-ID: <200702101917.04048.vda.linux@googlemail.com>

On Thursday 08 February 2007 01:47, Sina Mallick wrote:
> Hi,
> > I am trying to compile busybox for ARM cpu...Am using arm bese
> > toolchain...
> > I am getting this error at the end...
> > LINK    busybox_unstripped
> > applets/built-in.o:(.rodata.applets+0x664): undefined reference to
> > `readahead_main'
> > applets/built-in.o: (.rodata.applets+0x868): undefined reference to
> > `taskset_main'
> > collect2: ld returned 1 exit status
> > make: *** [busybox_unstripped] Error 1

I think you are getting these because your libc
does not have functions needed for readahead and taskset.

Apparently you disabled these applets and reran make, but
due to a bug in build system it is still trying to link in
newly-disabled applets. This bug was recently fixed.

"make clean; make" will work around the problem.
--
vda


From vda.linux at googlemail.com  Sat Feb 10 18:20:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:20:56 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <45CBD6AF.7060407@avtrex.com>
References: <45CBD6AF.7060407@avtrex.com>
Message-ID: <200702101920.56047.vda.linux@googlemail.com>

On Friday 09 February 2007 03:04, David Daney wrote:
> I recall reading on the list recently that someone was thinking about 
> modifying dhcpc to do nice things when the link state changes.
> 
> Has this been done?
> 
> If not, I think I will be doing it very soon.

Why do you need this?

Windows have such a behavior (of severing all TCP connections
whenever I need to unplug my network cable for 5 seconds)
and it is _awful_.

I hope you plan to implement something less annoying then this.
--
vda


From floydpink at gmail.com  Sat Feb 10 18:35:13 2007
From: floydpink at gmail.com (Jason Schoon)
Date: Sat, 10 Feb 2007 12:35:13 -0600
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702101920.56047.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
Message-ID: <78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>

On 2/10/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Friday 09 February 2007 03:04, David Daney wrote:
> > I recall reading on the list recently that someone was thinking about
> > modifying dhcpc to do nice things when the link state changes.
> >
> > Has this been done?
> >
> > If not, I think I will be doing it very soon.
>
> Why do you need this?
>
> Windows have such a behavior (of severing all TCP connections
> whenever I need to unplug my network cable for 5 seconds)
> and it is _awful_.
>
> I hope you plan to implement something less annoying then this.


Perhaps he is talking more along the lines of doing an automatic renewal
when a link is upped.  For example, plugging into a new network.  You want
to get a new address on that net, not keep using an old one.  I have
implemented that several times in different DHCP clients.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070210/4093efe9/attachment-0001.htm 

From vda.linux at googlemail.com  Sat Feb 10 18:35:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:35:37 +0100
Subject: [gmail] Re: realpath bug
In-Reply-To: <20070209083605.GF15523@scorpius.homelinux.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702090021.35590.vapier@gentoo.org>
	<20070209083605.GF15523@scorpius.homelinux.org>
Message-ID: <200702101935.37919.vda.linux@googlemail.com>

On Friday 09 February 2007 09:36, Marc Leeman wrote:
> Cc to busybox ML.
> 
> > > > could you be more specific as to what is breaking ?  "syslogd breaks on
> > > > read only filesystems" does not translate well into actual test cases for
> > > > inclusion into uClibc testsuite ...
> > >
> > > cf. busybox discussion of yesterday:
> > >
> > > http://www.busybox.net/lists/busybox/2007-February/026252.html
> > 
> > ok, looking again and i see your setup is:
> >  - /dev is mounted RO
> >  - /tmp is mounted RW
> >  - /dev/log is a symlink to ../tmp/log
> > 
> > busybox launches sysklogd which does:
> >  - dev_log_name = xmalloc_realpath(/dev/log)
> >  - unlink(dev_log_name)
> > 
> > on your system, dev_log_name should be resolving to /tmp/log but it seems to 
> > return NULL ... on my system, it works:
> > # ls -l /dev/log /tmp/log 
> > lrwxrwxrwx 1 root root 10 2007-02-08 23:58 /dev/log -> ../tmp/log
> > -rw-r--r-- 1 root root  0 2007-02-08 23:58 /tmp/log
> > # ./busybox syslogd -n
> > running xmalloc_realpath(/dev/log)
> > got back /tmp/log
> > dev_log_name is now /tmp/log
> > unlinking(/tmp/log)
> > exiting now
> > # ./busybox syslogd -n
> > running xmalloc_realpath(/dev/log)
> > got back (null)
> > dev_log_name is now /dev/log
> > unlinking(/dev/log)
> > exiting now
> > 
> > this behavior is correct ... since /tmp/log was removed in the first run, the 
> > second run should actually return NULL ...
> 
> The system is using an empty /tmp fs (tmpfs), so the socket or any other
> file is not present in /tmp when xmallok_realpath("/dev/log") is called.
> 
> The old syslogd implementation correctly de-referenced the pointer in
> /dev/log to /tmp/log and created a /tmp/log socket. the new syslogd
> implementation tries to delete /dev/log on the RO filesystem and tries
> to create the log socket there, what obviously fails on a RO fs.

rev 16000:

        /* Create the syslog file so realpath() can work. */
        if (realpath(_PATH_LOG, lfile) != NULL) {
                unlink(lfile);
        }

        memset(&sunx, 0, sizeof(sunx));
        sunx.sun_family = AF_UNIX;
        strncpy(sunx.sun_path, lfile, sizeof(sunx.sun_path));
        sock_fd = xsocket(AF_UNIX, SOCK_DGRAM, 0);
        addrLength = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
        if (bind(sock_fd, (struct sockaddr *) &sunx, addrLength) < 0) {
                bb_perror_msg_and_die("Could not connect to socket " _PATH_LOG);
        }

if realpath fails, lfile is undefined.
strncpy above will pass possibly bogus lfile as socket name to bind().
it happens so on glibc realpath() returns resolved link and
uclibc returns NULL but fills lfile with resolved link.

New code is:

        dev_log_name = xmalloc_realpath(_PATH_LOG);
        if (!dev_log_name)
                dev_log_name = _PATH_LOG;

        /* Unlink old /dev/log (or object it points to) */
        unlink(dev_log_name);

        memset(&sunx, 0, sizeof(sunx));
        sunx.sun_family = AF_UNIX;
        strncpy(sunx.sun_path, dev_log_name, sizeof(sunx.sun_path));
        sock_fd = xsocket(AF_UNIX, SOCK_DGRAM, 0);
        addr_len = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
        xbind(sock_fd, (struct sockaddr *) &sunx, addr_len);

which looks more sane to me.

Apparently the problem is that realpath may fail to resolve
dangling links (e.g. uclibc).

Patch which replaces realpath with readlink, anyone?
--
vda


From vda.linux at googlemail.com  Sat Feb 10 18:46:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 10 Feb 2007 19:46:11 +0100
Subject: udhcp client not working
In-Reply-To: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
References: <457d2dc30702090856l49e91661jd14621bc1a061bd5@mail.gmail.com>
Message-ID: <200702101946.11939.vda.linux@googlemail.com>

On Friday 09 February 2007 17:56, satpal parmar wrote:
> Hi all;
> 
>    I am trying to make udchpc (UDHCP clinet from busybox) work on my kernel
> (linux 2.6.11.12, linux 2.6.18 and linux 2.6.19 ).
>  poted on arm9 board.I am getting following output
> 
> 
> / # udhcpc
> udhcpc (v1.2.0-svn) started
> eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>           Interrupt:37
> 
> Sending discover...
> Sending discover...
> Sending discover...
> eth0      Link encap:Ethernet  HWaddr 00:40:F4:39:6A:61
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>           Interrupt:37
> 
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

This is a kernel message. Your network card is failing to send
packets.

Try assigning static ip address and pinging some other
machine on the network - does that work?
--
vda


From vda.linux at googlemail.com  Sun Feb 11 02:09:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 03:09:32 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
Message-ID: <200702110309.32856.vda.linux@googlemail.com>

On Saturday 10 February 2007 19:35, Jason Schoon wrote:
> > > I recall reading on the list recently that someone was thinking about
> > > modifying dhcpc to do nice things when the link state changes.
> > >
> > > Has this been done?
> > >
> > > If not, I think I will be doing it very soon.
> >
> > Why do you need this?
> >
> > Windows have such a behavior (of severing all TCP connections
> > whenever I need to unplug my network cable for 5 seconds)
> > and it is _awful_.
> >
> > I hope you plan to implement something less annoying then this.
> 
> Perhaps he is talking more along the lines of doing an automatic renewal
> when a link is upped.  For example, plugging into a new network.  You want
> to get a new address on that net, not keep using an old one.  I have
> implemented that several times in different DHCP clients.

Why? If I unplug my machine from network, it does NOT
automatically mean I should renew DHCP address.

It is needed sometimes, but other times (e.g. "I need to unplug
my machine for 10 seconds...") it will be utterly inconvenient.

If you really want it, perhaps kernel sends a hotplug event
or something like it on link down/link up,
so you can hook onto it and kill/restart udhcpc?
--
vda


From rogelio.serrano at gmail.com  Sun Feb 11 02:23:12 2007
From: rogelio.serrano at gmail.com (Rogelio Serrano)
Date: Sun, 11 Feb 2007 02:23:12 +0000
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702110309.32856.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
	<200702110309.32856.vda.linux@googlemail.com>
Message-ID: <a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>

On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Saturday 10 February 2007 19:35, Jason Schoon wrote:
> > > > I recall reading on the list recently that someone was thinking about
> > > > modifying dhcpc to do nice things when the link state changes.
> > > >
> > > > Has this been done?
> > > >
> > > > If not, I think I will be doing it very soon.
> > >
> > > Why do you need this?
> > >
> > > Windows have such a behavior (of severing all TCP connections
> > > whenever I need to unplug my network cable for 5 seconds)
> > > and it is _awful_.
> > >
> > > I hope you plan to implement something less annoying then this.
> >
> > Perhaps he is talking more along the lines of doing an automatic renewal
> > when a link is upped.  For example, plugging into a new network.  You want
> > to get a new address on that net, not keep using an old one.  I have
> > implemented that several times in different DHCP clients.
>
> Why? If I unplug my machine from network, it does NOT
> automatically mean I should renew DHCP address.
>
> It is needed sometimes, but other times (e.g. "I need to unplug
> my machine for 10 seconds...") it will be utterly inconvenient.
>
> If you really want it, perhaps kernel sends a hotplug event
> or something like it on link down/link up,
> so you can hook onto it and kill/restart udhcpc?
> --
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>

How does the machine find out by itself that you are "just "unplugging
for 10 seconds and dont want to renew your address?

I would rather have the adapter renew the address anytime the
interface goes up. And notify the system that the interface is down
when the link goes down.

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items


From floydpink at gmail.com  Sun Feb 11 02:52:50 2007
From: floydpink at gmail.com (Jason Schoon)
Date: Sat, 10 Feb 2007 20:52:50 -0600
Subject: Detecting link state in dhcpc...
In-Reply-To: <a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<200702101920.56047.vda.linux@googlemail.com>
	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>
	<200702110309.32856.vda.linux@googlemail.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
Message-ID: <78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>

On 2/10/07, Rogelio Serrano <rogelio.serrano at gmail.com> wrote:
>
> On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > On Saturday 10 February 2007 19:35, Jason Schoon wrote:
> > > > > I recall reading on the list recently that someone was thinking
> about
> > > > > modifying dhcpc to do nice things when the link state changes.
> > > > >
> > > > > Has this been done?
> > > > >
> > > > > If not, I think I will be doing it very soon.
> > > >
> > > > Why do you need this?
> > > >
> > > > Windows have such a behavior (of severing all TCP connections
> > > > whenever I need to unplug my network cable for 5 seconds)
> > > > and it is _awful_.
> > > >
> > > > I hope you plan to implement something less annoying then this.
> > >
> > > Perhaps he is talking more along the lines of doing an automatic
> renewal
> > > when a link is upped.  For example, plugging into a new network.  You
> want
> > > to get a new address on that net, not keep using an old one.  I have
> > > implemented that several times in different DHCP clients.
> >
> > Why? If I unplug my machine from network, it does NOT
> > automatically mean I should renew DHCP address.
> >
> > It is needed sometimes, but other times (e.g. "I need to unplug
> > my machine for 10 seconds...") it will be utterly inconvenient.
> >
> > If you really want it, perhaps kernel sends a hotplug event
> > or something like it on link down/link up,
> > so you can hook onto it and kill/restart udhcpc?
> > --
> > vda
> > _______________________________________________
> > busybox mailing list
> > busybox at busybox.net
> > http://busybox.net/cgi-bin/mailman/listinfo/busybox
> >
>
> How does the machine find out by itself that you are "just "unplugging
> for 10 seconds and dont want to renew your address?
>
> I would rather have the adapter renew the address anytime the
> interface goes up. And notify the system that the interface is down
> when the link goes down.
>

Agreed, I see nothing wrong with sending a renewal.  It's not like it will
break any of your existing connections.

In my case, I am talking about an embedded device that is essentially
useless if not on a network also, so I definitely want to be able to take
some action if the link goes down as well.  In my case it happens that I
need to do this in static IP case also, so I have a link monitoring daemon
that takes care of it, rather than adding it to DHCP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070210/2c5588be/attachment.htm 

From vda.linux at googlemail.com  Sun Feb 11 03:07:54 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 04:07:54 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
	<78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
Message-ID: <200702110407.54040.vda.linux@googlemail.com>

On Sunday 11 February 2007 03:52, Jason Schoon wrote:
> > > > to get a new address on that net, not keep using an old one.  I have
> > > > implemented that several times in different DHCP clients.
> > >
> > > Why? If I unplug my machine from network, it does NOT
> > > automatically mean I should renew DHCP address.
> > >
> > > It is needed sometimes, but other times (e.g. "I need to unplug
> > > my machine for 10 seconds...") it will be utterly inconvenient.
> > >
> > > If you really want it, perhaps kernel sends a hotplug event
> > > or something like it on link down/link up,
> > > so you can hook onto it and kill/restart udhcpc?
> >
> > How does the machine find out by itself that you are "just "unplugging
> > for 10 seconds and dont want to renew your address?
> >
> > I would rather have the adapter renew the address anytime the
> > interface goes up. And notify the system that the interface is down
> > when the link goes down.
> 
> Agreed, I see nothing wrong with sending a renewal.  It's not like it will
> break any of your existing connections.
> 
> In my case, I am talking about an embedded device that is essentially
> useless if not on a network also, so I definitely want to be able to take
> some action if the link goes down as well.  In my case it happens that I
> need to do this in static IP case also, so I have a link monitoring daemon
> that takes care of it, rather than adding it to DHCP.

Exactly what I am saying. Link state monitoring is a DIFFERENT thing,
not DHCP thing. I still think that this functionality should not
be added to udhcpc.
--
vda


From vda.linux at googlemail.com  Sun Feb 11 03:19:26 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 04:19:26 +0100
Subject: [PATCH] syslogd +realpath
Message-ID: <200702110419.26631.vda.linux@googlemail.com>

Hi,

Please test attached patch. For me it works correctly
for symlinked and non-symlinked /dev/log.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 2455 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070211/dfac7cf2/attachment-0002.bin 

From rogelio.serrano at gmail.com  Sun Feb 11 03:24:58 2007
From: rogelio.serrano at gmail.com (Rogelio Serrano)
Date: Sun, 11 Feb 2007 03:24:58 +0000
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702110407.54040.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
	<78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
	<200702110407.54040.vda.linux@googlemail.com>
Message-ID: <a9951d2a0702101924t4c9bfddjcfd24a413a079a36@mail.gmail.com>

On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Sunday 11 February 2007 03:52, Jason Schoon wrote:
> > > > > to get a new address on that net, not keep using an old one.  I have
> > > > > implemented that several times in different DHCP clients.
> > > >
> > > > Why? If I unplug my machine from network, it does NOT
> > > > automatically mean I should renew DHCP address.
> > > >
> > > > It is needed sometimes, but other times (e.g. "I need to unplug
> > > > my machine for 10 seconds...") it will be utterly inconvenient.
> > > >
> > > > If you really want it, perhaps kernel sends a hotplug event
> > > > or something like it on link down/link up,
> > > > so you can hook onto it and kill/restart udhcpc?
> > >
> > > How does the machine find out by itself that you are "just "unplugging
> > > for 10 seconds and dont want to renew your address?
> > >
> > > I would rather have the adapter renew the address anytime the
> > > interface goes up. And notify the system that the interface is down
> > > when the link goes down.
> >
> > Agreed, I see nothing wrong with sending a renewal.  It's not like it will
> > break any of your existing connections.
> >
> > In my case, I am talking about an embedded device that is essentially
> > useless if not on a network also, so I definitely want to be able to take
> > some action if the link goes down as well.  In my case it happens that I
> > need to do this in static IP case also, so I have a link monitoring daemon
> > that takes care of it, rather than adding it to DHCP.
>
> Exactly what I am saying. Link state monitoring is a DIFFERENT thing,
> not DHCP thing. I still think that this functionality should not
> be added to udhcpc.
> --
> vda
>

I agree too.

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items


From vapier at gentoo.org  Sun Feb 11 04:55:08 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 10 Feb 2007 23:55:08 -0500
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702101935.37919.vda.linux@googlemail.com>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<20070209083605.GF15523@scorpius.homelinux.org>
	<200702101935.37919.vda.linux@googlemail.com>
Message-ID: <200702102355.09483.vapier@gentoo.org>

On Saturday 10 February 2007, Denis Vlasenko wrote:
> it happens so on glibc realpath() returns resolved link and
> uclibc returns NULL but fills lfile with resolved link.

no ... glibc and uClibc both return NULL for broken symlinks

> Patch which replaces realpath with readlink, anyone?

this wont be terribly robust as what if /dev/ is readonly and /dev/log is a 
relative symlink ... you'd have to make sure you chroot(/dev/) first
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070210/7ab61e8c/attachment-0002.pgp 

From lists at zelow.no  Sun Feb 11 08:29:23 2007
From: lists at zelow.no (Thomas Lundquist)
Date: Sun, 11 Feb 2007 09:29:23 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702110407.54040.vda.linux@googlemail.com>
References: <45CBD6AF.7060407@avtrex.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
	<78a54e1b0702101852t4389fb01w6c23b11ae9875c1b@mail.gmail.com>
	<200702110407.54040.vda.linux@googlemail.com>
Message-ID: <20070211082923.GA14307@zelow.no>

On Sun, Feb 11, 2007 at 04:07:54AM +0100, Denis Vlasenko wrote:
> 
> Exactly what I am saying. Link state monitoring is a DIFFERENT thing,
> not DHCP thing. I still think that this functionality should not
> be added to udhcpc.

as long as the interface are controlled by DHCP, the dhcp client should
get notice on link events and act upon it.

a renewal is the logical action.


Thomas.


From alexander.griesser at lkh-vil.or.at  Sun Feb 11 13:25:05 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 14:25:05 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <20070209175941.GT12488@aon.at>
References: <45CC9E16.9010407@cle-mens.de> <20070209175941.GT12488@aon.at>
Message-ID: <45CF1931.3010807@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernhard Fischer wrote:
> On Fri, Feb 09, 2007 at 05:15:18PM +0100, Dirk Clemens wrote:
>> I thing I have found a post bug in busybosy 1.3.1/mips.
>
> Can you reproduce this with the current 1.4.1 (?) release or with trunk?

Well, I think I'm suffering from a similar bug.
I don't know when it started to not work anymore, but currently (1.4.1)
I'm not able to do the following:

if [ "$REQUEST_METHOD" = "POST" ]; then
  read QUERY_STRING
fi

This results in waiting endlessly for the webserver to complete,
as if there was nothing coming on stdin for read to complete.

I gave `cat` a shot and that worked:

if [ "$REQUEST_METHOD" = "POST" ]; then
  cat >/tmp/out
fi

> What toolchain did you use to build busybox?

I'm running on Debian 4.0, Linux kernel 2.6.20, gcc 4.1.2 and libc
2.3.6.ds1-11.

If I missed something to specify for my toolchain, please tell me
and I'll get you this information.

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFzxkx66HVD6KUm1oRAksdAJsFBB7GuTo+ZzQ+jJvAB/SEleGcEQCgqUbh
Se5QZYWqImzyItTTCtYaCxI=
=rhld
-----END PGP SIGNATURE-----


From vda.linux at googlemail.com  Sun Feb 11 14:30:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 15:30:45 +0100
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702102355.09483.vapier@gentoo.org>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702101935.37919.vda.linux@googlemail.com>
	<200702102355.09483.vapier@gentoo.org>
Message-ID: <200702111530.45440.vda.linux@googlemail.com>

On Sunday 11 February 2007 05:55, Mike Frysinger wrote:
> On Saturday 10 February 2007, Denis Vlasenko wrote:
> > it happens so on glibc realpath() returns resolved link and
> > uclibc returns NULL but fills lfile with resolved link.
> 
> no ... glibc and uClibc both return NULL for broken symlinks

I don't understand how rev 16000 managed to work ok
with dangling symlinks, then:

? ? ? ? /* Create the syslog file so realpath() can work. */
? ? ? ? if (realpath(_PATH_LOG, lfile) != NULL) {
? ? ? ? ? ? ? ? unlink(lfile);
? ? ? ? }

? ? ? ? memset(&sunx, 0, sizeof(sunx));
? ? ? ? sunx.sun_family = AF_UNIX;
? ? ? ? strncpy(sunx.sun_path, lfile, sizeof(sunx.sun_path));
? ? ? ? sock_fd = xsocket(AF_UNIX, SOCK_DGRAM, 0);
? ? ? ? addrLength = sizeof(sunx.sun_family) + strlen(sunx.sun_path);
? ? ? ? if (bind(sock_fd, (struct sockaddr *) &sunx, addrLength) < 0) {
? ? ? ? ? ? ? ? bb_perror_msg_and_die("Could not connect to socket " _PATH_LOG);
? ? ? ? }

unless glibc _also_ fills lfile, but returns NULL, just like uclibc.

Anyway, I am not very interested in realpath here,
I'm going to switch to readlink.

> > Patch which replaces realpath with readlink, anyone?
> 
> this wont be terribly robust as what if /dev/ is readonly and /dev/log is a 
> relative symlink ... you'd have to make sure you chroot(/dev/) first

I hope chdir("/dev") would suffice ;)
--
vda


From vda.linux at googlemail.com  Sun Feb 11 14:51:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 15:51:40 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CF1931.3010807@lkh-vil.or.at>
References: <45CC9E16.9010407@cle-mens.de> <20070209175941.GT12488@aon.at>
	<45CF1931.3010807@lkh-vil.or.at>
Message-ID: <200702111551.41002.vda.linux@googlemail.com>

On Sunday 11 February 2007 14:25, Alexander Griesser wrote:
> Bernhard Fischer wrote:
> > On Fri, Feb 09, 2007 at 05:15:18PM +0100, Dirk Clemens wrote:
> >> I thing I have found a post bug in busybosy 1.3.1/mips.
> >
> > Can you reproduce this with the current 1.4.1 (?) release or with trunk?
> 
> Well, I think I'm suffering from a similar bug.
> I don't know when it started to not work anymore, but currently (1.4.1)
> I'm not able to do the following:
> 
> if [ "$REQUEST_METHOD" = "POST" ]; then
>   read QUERY_STRING
> fi
> 
> This results in waiting endlessly for the webserver to complete,
> as if there was nothing coming on stdin for read to complete.
> 
> I gave `cat` a shot and that worked:
> 
> if [ "$REQUEST_METHOD" = "POST" ]; then
>   cat >/tmp/out
> fi

I would like to try it myself. Do you have a small testcase?
--
vda


From alexander.griesser at lkh-vil.or.at  Sun Feb 11 16:27:23 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 17:27:23 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702111551.41002.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de> <20070209175941.GT12488@aon.at>
	<45CF1931.3010807@lkh-vil.or.at>
	<200702111551.41002.vda.linux@googlemail.com>
Message-ID: <45CF43EB.8090103@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Vlasenko wrote:
> I would like to try it myself. Do you have a small testcase?

Well, I have this cgi-script that I built to try it out.

test.cgi:
- ------------------- 8< -------------------
#!/bin/sh

echo "<html>
<body>
<form method="post" action="/cgi-bin/test.cgi">
<input type="text" name="test">
<input type="submit" name="submit">
</form>"

if [ "$REQUEST_METHOD" = "POST" ]; then
  # This doesn't work at all, it hangs with this
  read QUERY_STRING
  echo $QUERY_STRING

  # This does only work, if the destination file has
  # already been created before, don't know why, but
  # I debugged this fact yesterday and it is reproducible
  # If the file is not available when cat tries to write
  # the data to it, it hangs as `read` does in the above
  # lines
  cat >/tmp/query
  cat /tmp/query
fi

echo "</body>
</html>"
- ------------------- 8< -------------------

I hope, this is what you meant with "testcase". If not, please tell
me what I need to provide so that you can reproduce it.

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFz0Pr66HVD6KUm1oRAkn4AKCjovrAqECmb73a2ts1KE8RiKPVZgCfZBSd
WKUmDKwPnm/riOcFFbOqUV0=
=hai/
-----END PGP SIGNATURE-----


From vda.linux at googlemail.com  Sun Feb 11 16:23:59 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 17:23:59 +0100
Subject: [RESOLVED] Re: wget segfaults (busybox-1.4.1/uclibc)
In-Reply-To: <1170929938.14212.37.camel@localhost>
References: <1170840789.6604.48.camel@localhost>
	<200702072226.49159.vda.linux@googlemail.com>
	<1170929938.14212.37.camel@localhost>
Message-ID: <200702111723.59599.vda.linux@googlemail.com>

On Thursday 08 February 2007 11:18, Natanael Copa wrote:
> parse_url sets target.path = ""
> 
> later, when guessing the out file name
> 
>  fname_out = bb_get_last_path_component(target.path);
> 
> bb_get_last_path_component() will write to target.path.

bb_get_last_component is a bad API, yes...
 
> Looks like its fixed in svn. Would be nice to have it fixed for 1.4.2.
> 
> Attached is a patch for 1.4.1.

Thanks, added to post 1.4.1 fixes
--
vda


From vda.linux at googlemail.com  Sun Feb 11 18:34:01 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 19:34:01 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CF43EB.8090103@lkh-vil.or.at>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111551.41002.vda.linux@googlemail.com>
	<45CF43EB.8090103@lkh-vil.or.at>
Message-ID: <200702111934.01919.vda.linux@googlemail.com>

On Sunday 11 February 2007 17:27, Alexander Griesser wrote:
> Denis Vlasenko wrote:
> > I would like to try it myself. Do you have a small testcase?
> 
> Well, I have this cgi-script that I built to try it out.
> 
> test.cgi:
> ------------------- 8< -------------------
> #!/bin/sh
> 
> echo "<html>
> <body>
> <form method="post" action="/cgi-bin/test.cgi">
> <input type="text" name="test">
> <input type="submit" name="submit">
> </form>"
> 
> if [ "$REQUEST_METHOD" = "POST" ]; then
>   # This doesn't work at all, it hangs with this
>   read QUERY_STRING
>   echo $QUERY_STRING
> 
>   # This does only work, if the destination file has
>   # already been created before, don't know why, but
>   # I debugged this fact yesterday and it is reproducible
>   # If the file is not available when cat tries to write
>   # the data to it, it hangs as `read` does in the above
>   # lines
>   cat >/tmp/query
>   cat /tmp/query
> fi
> 
> echo "</body>
> </html>"
> ------------------- 8< -------------------
> 
> I hope, this is what you meant with "testcase". If not, please tell
> me what I need to provide so that you can reproduce it.

Yes. Generally it's always better to explain problems
with exact details, not with somewhat vague descriptions.

I think I know where is the problem.

networking/httpd.c: replace

                close(config->accepted_socket);
                close(config->server_socket);

with

                if (config->accepted_socket > 1)
                        close(config->accepted_socket);
                if (config->server_socket > 1)
                        close(config->server_socket);

Does it work now?
--
vda


From alexander.griesser at lkh-vil.or.at  Sun Feb 11 18:54:28 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 19:54:28 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702111934.01919.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111551.41002.vda.linux@googlemail.com>
	<45CF43EB.8090103@lkh-vil.or.at>
	<200702111934.01919.vda.linux@googlemail.com>
Message-ID: <45CF6664.1060407@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Vlasenko wrote:
> I think I know where is the problem.
> 
> networking/httpd.c: replace
> 
>                 close(config->accepted_socket);
>                 close(config->server_socket);
> 
> with
> 
>                 if (config->accepted_socket > 1)
>                         close(config->accepted_socket);
>                 if (config->server_socket > 1)
>                         close(config->server_socket);
> 
> Does it work now?

No, unfortunately, the symptoms stay the same after this change.

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFz2Zk66HVD6KUm1oRApleAJ9AF7dDk6wckY9n1qmSf+LK8RvrygCbBPIi
szirOghA95JvjW+Xiu1jO/U=
=Hv9/
-----END PGP SIGNATURE-----


From vda.linux at googlemail.com  Sun Feb 11 19:08:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 20:08:25 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <45CF6664.1060407@lkh-vil.or.at>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111934.01919.vda.linux@googlemail.com>
	<45CF6664.1060407@lkh-vil.or.at>
Message-ID: <200702112008.25916.vda.linux@googlemail.com>

On Sunday 11 February 2007 19:54, Alexander Griesser wrote:
> Denis Vlasenko wrote:
> > I think I know where is the problem.
> >
> > networking/httpd.c: replace
> >
> >                 close(config->accepted_socket);
> >                 close(config->server_socket);
> >
> > with
> >
> >                 if (config->accepted_socket > 1)
> >                         close(config->accepted_socket);
> >                 if (config->server_socket > 1)
> >                         close(config->server_socket);
> >
> > Does it work now?
> 
> No, unfortunately, the symptoms stay the same after this change.

Make sure you killed/restarted httpd (so that you
don't use old version).

I noticed another problem - httpd may wait forever for
cgi output while cgi waits for httpd's output!

Attached patch fixes it too.
Please test it (patch is against current svn).
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 3499 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070211/650854cb/attachment-0002.bin 

From alexander.griesser at lkh-vil.or.at  Sun Feb 11 19:31:04 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Sun, 11 Feb 2007 20:31:04 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702112008.25916.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111934.01919.vda.linux@googlemail.com>
	<45CF6664.1060407@lkh-vil.or.at>
	<200702112008.25916.vda.linux@googlemail.com>
Message-ID: <45CF6EF8.4040701@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denis Vlasenko wrote:
>>> Does it work now?
>> No, unfortunately, the symptoms stay the same after this change.
> 
> Make sure you killed/restarted httpd (so that you
> don't use old version).

I did, don't worry :)

> I noticed another problem - httpd may wait forever for
> cgi output while cgi waits for httpd's output!

That sounds good...

> Attached patch fixes it too.

... and that one helped! Great, now it's working again :)

ciao,
- --
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFz27466HVD6KUm1oRAmcEAJ0WAcrrUbhe+YX2aFuN55cW+f2CjwCcCcje
5u2LHECPSUJqM0oEj2Yyy/s=
=uRxx
-----END PGP SIGNATURE-----


From rep.dot.nop at gmail.com  Sun Feb 11 19:42:32 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 11 Feb 2007 20:42:32 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <200702112008.25916.vda.linux@googlemail.com>
References: <45CC9E16.9010407@cle-mens.de>
	<200702111934.01919.vda.linux@googlemail.com>
	<45CF6664.1060407@lkh-vil.or.at>
	<200702112008.25916.vda.linux@googlemail.com>
Message-ID: <20070211194232.GE12488@aon.at>

On Sun, Feb 11, 2007 at 08:08:25PM +0100, Denis Vlasenko wrote:
>On Sunday 11 February 2007 19:54, Alexander Griesser wrote:

>-		dup2(inFd, 0);  // replace stdin with the pipe
>-		dup2(outFd, 1);  // replace stdout with the pipe
>+		if (config->accepted_socket > 1)
>+			close(config->accepted_socket);

Didn't we have an close_nonstdin?


From hias at horus.com  Sun Feb 11 19:38:13 2007
From: hias at horus.com (Matthias Reichl)
Date: Sun, 11 Feb 2007 20:38:13 +0100
Subject: [PATCH] fix httpd lockup in cgi POSTs
Message-ID: <20070211193813.GA29704@horus.com>

While debugging some lockup problems with the openwrt webif^2 firmware
upload page I discovered a bug in httpd.c:

In line 1216 it must really be safe_read(), not full_read().
Otherwise httpd may lock up in the case where the cgi-script
has sent some data before fully receiving all POSTed data.

httpd.c multiplexes fine using select() and only calls safe_read()
if data is available, whereas full_read() loops over safe_read()
without checking if data is available. In this case read() will
block...

so long,

Hias

--- busybox-1.4.1.orig/networking/httpd.c	2007-01-24 22:34:34.000000000 +0100
+++ busybox-1.4.1/networking/httpd.c	2007-02-11 20:37:01.000000000 +0100
@@ -1211,9 +1211,10 @@
 #if PIPESIZE >= MAX_MEMORY_BUFF
 # error "PIPESIZE >= MAX_MEMORY_BUFF"
 #endif
-			/* NB: was safe_read. If it *has to be* safe_read, */
-			/* please explain why in this comment... */
-			count = full_read(inFd, rbuf, PIPESIZE);
+			/* reverted back to safe_read, otherwise httpd may */
+			/* block if the cgi-script outputs page date before */
+			/* it has fully received all (POST) data */
+			count = safe_read(inFd, rbuf, PIPESIZE);
 			if (count == 0)
 				break;  /* closed */
 			if (count < 0)


From vda.linux at googlemail.com  Sun Feb 11 19:46:29 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 20:46:29 +0100
Subject: Bug in bb 1.3.1, httpd with POST
In-Reply-To: <20070211194232.GE12488@aon.at>
References: <45CC9E16.9010407@cle-mens.de>
	<200702112008.25916.vda.linux@googlemail.com>
	<20070211194232.GE12488@aon.at>
Message-ID: <200702112046.29354.vda.linux@googlemail.com>

On Sunday 11 February 2007 20:42, Bernhard Fischer wrote:
> On Sun, Feb 11, 2007 at 08:08:25PM +0100, Denis Vlasenko wrote:
> >On Sunday 11 February 2007 19:54, Alexander Griesser wrote:
> 
> >-		dup2(inFd, 0);  // replace stdin with the pipe
> >-		dup2(outFd, 1);  // replace stdout with the pipe
> >+		if (config->accepted_socket > 1)
> >+			close(config->accepted_socket);
> 
> Didn't we have an close_nonstdin?

That one is for stdio (it's fclose, not close) and it
basically does "if (fp != stdin) fclose(fp);"

Not applicable here.
--
vda


From vda.linux at googlemail.com  Sun Feb 11 21:07:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 11 Feb 2007 22:07:25 +0100
Subject: [PATCH] fix httpd lockup in cgi POSTs
In-Reply-To: <20070211193813.GA29704@horus.com>
References: <20070211193813.GA29704@horus.com>
Message-ID: <200702112207.25857.vda.linux@googlemail.com>

On Sunday 11 February 2007 20:38, Matthias Reichl wrote:
> While debugging some lockup problems with the openwrt webif^2 firmware
> upload page I discovered a bug in httpd.c:
> 
> In line 1216 it must really be safe_read(), not full_read().
> Otherwise httpd may lock up in the case where the cgi-script
> has sent some data before fully receiving all POSTed data.
> 
> httpd.c multiplexes fine using select() and only calls safe_read()
> if data is available, whereas full_read() loops over safe_read()
> without checking if data is available. In this case read() will
> block...

Thanks, this was fixed just minutes ago. Please test whether
current svn works for you.
--
vda


From stephane.billiart at gmail.com  Sun Feb 11 22:24:19 2007
From: stephane.billiart at gmail.com (Stephane Billiart)
Date: Sun, 11 Feb 2007 17:24:19 -0500
Subject: tar no longer extracting with setuid bits
Message-ID: <20070211222418.GA4818@tleilax.gmail.com>

While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
setuid files in tar files are no longer created with the setuid bit
while running as root.

The attached patch (which partially reverts r15775 of
archival/libunarchive/data_extract_all.c) fixes the problem.

Any idea why the chmod call was removed?

-- 
St?phane Billiart                      http://perso.orange.fr/billiart/
-------------- next part --------------
--- archival/libunarchive/data_extract_all.c.orig	2007-01-24 16:34:38.000000000 -0500
+++ archival/libunarchive/data_extract_all.c	2007-02-11 17:22:14.000000000 -0500
@@ -111,6 +111,12 @@
 		lchown(file_header->name, file_header->uid, file_header->gid);
 	}
 
+	if (!(archive_handle->flags & ARCHIVE_NOPRESERVE_PERM) &&
+		 (file_header->mode & S_IFMT) != S_IFLNK)
+	{
+		chmod(file_header->name, file_header->mode);
+	}
+
 	if (archive_handle->flags & ARCHIVE_PRESERVE_DATE) {
 		struct utimbuf t;
 		t.actime = t.modtime = file_header->mtime;

From hias at horus.com  Sun Feb 11 23:49:51 2007
From: hias at horus.com (Matthias Reichl)
Date: Mon, 12 Feb 2007 00:49:51 +0100
Subject: [PATCH] fix httpd lockup in cgi POSTs
In-Reply-To: <200702112207.25857.vda.linux@googlemail.com>
References: <20070211193813.GA29704@horus.com>
	<200702112207.25857.vda.linux@googlemail.com>
Message-ID: <20070211234951.GA893@horus.com>

On Sun, Feb 11, 2007 at 10:07:25PM +0100, Denis Vlasenko wrote:
> Thanks, this was fixed just minutes ago. Please test whether
> current svn works for you.

Seems like I wasn't the only one fighting with this bug :-)

I just ran a quick test with the current svn (httpd only) and
it works fine!

so long,

Hias


From ddaney at avtrex.com  Mon Feb 12 07:23:45 2007
From: ddaney at avtrex.com (David Daney)
Date: Sun, 11 Feb 2007 23:23:45 -0800
Subject: Detecting link state in dhcpc...
In-Reply-To: <a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
References: <45CBD6AF.7060407@avtrex.com>	<200702101920.56047.vda.linux@googlemail.com>	<78a54e1b0702101035p2ae337f0w3a1099b58fbd92af@mail.gmail.com>	<200702110309.32856.vda.linux@googlemail.com>
	<a9951d2a0702101823m62465e5ar780c263d7d651d8b@mail.gmail.com>
Message-ID: <45D01601.1080501@avtrex.com>

Rogelio Serrano wrote:
> On 2/11/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>   
>> On Saturday 10 February 2007 19:35, Jason Schoon wrote:
>>     
>>>>> I recall reading on the list recently that someone was thinking about
>>>>> modifying dhcpc to do nice things when the link state changes.
>>>>>
>>>>> Has this been done?
>>>>>
>>>>> If not, I think I will be doing it very soon.
>>>>>           
>>>> Why do you need this?
>>>>
>>>> Windows have such a behavior (of severing all TCP connections
>>>> whenever I need to unplug my network cable for 5 seconds)
>>>> and it is _awful_.
>>>>
>>>> I hope you plan to implement something less annoying then this.
>>>>         

I am testing my patch now.  The behavior is optional in two ways:  The 
link state support is be enabled/disabled at configure time, and then if 
it is present, it is only used if a command line flag is specified.

Linux seems to be nicer than Windows in at least this respect.  A TCP 
connection is only lost if you are assigned a *different* address when 
you re-connect.  Really it is not lost per se, it just never receives 
any more incoming packets, and thus will die if you try to send data 
over it.

>>> Perhaps he is talking more along the lines of doing an automatic renewal
>>> when a link is upped.  For example, plugging into a new network.  You want
>>> to get a new address on that net, not keep using an old one.  I have
>>> implemented that several times in different DHCP clients.
>>>       
>> Why? If I unplug my machine from network, it does NOT
>> automatically mean I should renew DHCP address.
>>
>> It is needed sometimes, but other times (e.g. "I need to unplug
>> my machine for 10 seconds...") it will be utterly inconvenient.
>>
>> If you really want it, perhaps kernel sends a hotplug event
>> or something like it on link down/link up,
>> so you can hook onto it and kill/restart udhcpc?
>> --
>> vda
>> _______________________________________________
>> busybox mailing list
>> busybox at busybox.net
>> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>>
>>     
>
> How does the machine find out by itself that you are "just "unplugging
> for 10 seconds and dont want to renew your address?
>
> I would rather have the adapter renew the address anytime the
> interface goes up. And notify the system that the interface is down
> when the link goes down.
>
>   
For desktop systems it may be debatable if you would want to enable link 
state tracking.  However for some types of embedded systems it can be 
useful.  Since there will be zero runtime overhead when the support for 
link state tracking is disabled, I hope the patch will be acceptable 
(when and if I finish testing it and send it in)

David Daney


From natanael.copa at gmail.com  Mon Feb 12 15:56:21 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 12 Feb 2007 16:56:21 +0100
Subject: tar no longer extracting with setuid bits
In-Reply-To: <20070211222418.GA4818@tleilax.gmail.com>
References: <20070211222418.GA4818@tleilax.gmail.com>
Message-ID: <1171295781.2696.52.camel@localhost>

On Sun, 2007-02-11 at 17:24 -0500, Stephane Billiart wrote:
> While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
> setuid files in tar files are no longer created with the setuid bit
> while running as root.
> 
> The attached patch (which partially reverts r15775 of
> archival/libunarchive/data_extract_all.c) fixes the problem.

aww... this is a problem for me. (just verified, the sudo package on my
alpinelinux distro is broken) Could this please be fixed for 1.4.2 (+ in
trunk ofcourse)

> 
> Any idea why the chmod call was removed?
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox



From albrecht at rdi1.com  Mon Feb 12 15:25:09 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 10:25:09 -0500
Subject: Must really be safe_read(), not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
Message-ID: <1171293909.3280.0.camel@albrecht.rdi1.com>


Reverting the code back to using safe_read doesn't work if you don't fix
the way the first line is handled because you're not guaranteed a full
line with the safe_read.

You can verify this by writing a cgi program which redirects to another
location.

It will intermittently fail. This has nothing to do with how the cgi
program writes to standard output. It's a consequence of the fact that
the server doesn't buffer standard input so it has no right to expect a
full line with its first read of cgi output.

An expedient way to fix the problem is to do the full_read, that is,
receive all the cgi output before handling the first line.

If this is not sufficient then busybox httpd should line buffer standard
input so that it always handles the status line correctly. 

Paul Albrecht


From MatthewLCreech at eaton.com  Mon Feb 12 17:00:47 2007
From: MatthewLCreech at eaton.com (MatthewLCreech at eaton.com)
Date: Mon, 12 Feb 2007 12:00:47 -0500
Subject: Detecting link state in dhcpc...
Message-ID: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>

busybox-bounces at busybox.net wrote:
> 
> In my case, I am talking about an embedded device that is
> essentially useless if not on a network also, so I definitely
> want to be able to take some action if the link goes down as
> well.  In my case it happens that I need to do this in static
> IP case also, so I have a link monitoring daemon that takes
> care of it, rather than adding it to DHCP.

FWIW, I also have an embedded device which needs this kind of behavior,
so I used netplugd:

http://www.red-bean.com/~bos/

The netplugd script that gets run when the carrier state changes either
starts/kills udhcpc, or it runs the appropriate ifconfig commands,
depending on how the device is configured.  It's an easy alternative to
modifying BusyBox, and also keeps things consistent when you're not
using DHCP.  (Which sounds like it might be similar to what you've
already done for the static case)

-- 
Matthew L. Creech


From hias at horus.com  Mon Feb 12 17:09:59 2007
From: hias at horus.com (Matthias Reichl)
Date: Mon, 12 Feb 2007 18:09:59 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171293909.3280.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
Message-ID: <20070212170958.GA17291@horus.com>

On Mon, Feb 12, 2007 at 10:25:09AM -0500, Paul Albrecht wrote:
> Reverting the code back to using safe_read doesn't work if you don't fix
> the way the first line is handled because you're not guaranteed a full
> line with the safe_read.

ACK, you are right.

> An expedient way to fix the problem is to do the full_read, that is,
> receive all the cgi output before handling the first line.
> 
> If this is not sufficient then busybox httpd should line buffer standard
> input so that it always handles the status line correctly. 

If I understand the code correctly, it would be sufficient to do
something like

if (firstline)
    count = full_read(inFd, rbuf, 4);
    /* read 4 bytes so we can check if the line begins with "HTTP" */
} else {
    count = safe_read(inFd, rbuf, PIPESIZE);
}

Better yet, do a full line read for the first line or completely
switch to line buffered input, as you suggested.

so long,

Hias


From vda.linux at googlemail.com  Mon Feb 12 20:52:29 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 21:52:29 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171293909.3280.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
Message-ID: <200702122152.29070.vda.linux@googlemail.com>

On Monday 12 February 2007 16:25, Paul Albrecht wrote:
> 
> Reverting the code back to using safe_read doesn't work if you don't fix
> the way the first line is handled because you're not guaranteed a full
> line with the safe_read.
> 
> You can verify this by writing a cgi program which redirects to another
> location.

Testcase, please?

> It will intermittently fail. This has nothing to do with how the cgi
> program writes to standard output. It's a consequence of the fact that
> the server doesn't buffer standard input so it has no right to expect a
> full line with its first read of cgi output.

We don't care about first line. We care about first four charachers only,
I think.

> An expedient way to fix the problem is to do the full_read, that is,
> receive all the cgi output before handling the first line.
> 
> If this is not sufficient then busybox httpd should line buffer standard
> input so that it always handles the status line correctly. 

Yes, this will even handle the case when CGI writes "HTT" and
"P/1.0 200 OK" separately.
--
vda


From vda.linux at googlemail.com  Mon Feb 12 21:01:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 22:01:13 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <20070212170958.GA17291@horus.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<20070212170958.GA17291@horus.com>
Message-ID: <200702122201.13865.vda.linux@googlemail.com>

On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > If this is not sufficient then busybox httpd should line buffer standard
> > input so that it always handles the status line correctly. 
> 
> If I understand the code correctly, it would be sufficient to do
> something like
> 
> if (firstline)
>     count = full_read(inFd, rbuf, 4);
>     /* read 4 bytes so we can check if the line begins with "HTTP" */

So far I am happy with "bbox httpd doesn't support insane cgis
which split their HTTP response" way.

> } else {
>     count = safe_read(inFd, rbuf, PIPESIZE);
> }
> 
> Better yet, do a full line read for the first line or completely
> switch to line buffered input, as you suggested.

Are you suggesting using stdio?
Can't do that, or POSTDATA will break again.

You basically need to _open-code_ buffering here. Than will work.
--
vda


From vda.linux at googlemail.com  Mon Feb 12 21:03:58 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 22:03:58 +0100
Subject: Detecting link state in dhcpc...
In-Reply-To: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>
References: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>
Message-ID: <200702122203.58972.vda.linux@googlemail.com>

On Monday 12 February 2007 18:00, MatthewLCreech at eaton.com wrote:
> busybox-bounces at busybox.net wrote:
> > 
> > In my case, I am talking about an embedded device that is
> > essentially useless if not on a network also, so I definitely
> > want to be able to take some action if the link goes down as
> > well.  In my case it happens that I need to do this in static
> > IP case also, so I have a link monitoring daemon that takes
> > care of it, rather than adding it to DHCP.
> 
> FWIW, I also have an embedded device which needs this kind of behavior,
> so I used netplugd:
> 
> http://www.red-bean.com/~bos/
> 
> The netplugd script that gets run when the carrier state changes either
> starts/kills udhcpc, or it runs the appropriate ifconfig commands,
> depending on how the device is configured.  It's an easy alternative to
> modifying BusyBox, and also keeps things consistent when you're not
> using DHCP.  (Which sounds like it might be similar to what you've
> already done for the static case)

That's a good solution: add netplugd to bbox as a new applet.
--
vda


From albrecht at rdi1.com  Mon Feb 12 20:38:16 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 15:38:16 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171304015.3598.1.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171304015.3598.1.camel@albrecht.rdi1.com>
Message-ID: <1171312696.3800.8.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 18:09 +0100, Matthias Reichl wrote:
> On Mon, Feb 12, 2007 at 10:25:09AM -0500, Paul Albrecht wrote:
> > Reverting the code back to using safe_read doesn't work if you don't fix
> > the way the first line is handled because you're not guaranteed a full
> > line with the safe_read.
> 
> ACK, you are right.
> 
> > An expedient way to fix the problem is to do the full_read, that is,
> > receive all the cgi output before handling the first line.
> > 
> > If this is not sufficient then busybox httpd should line buffer standard
> > input so that it always handles the status line correctly. 
> 
> If I understand the code correctly, it would be sufficient to do
> something like
> 
> if (firstline)
>     count = full_read(inFd, rbuf, 4);
>     /* read 4 bytes so we can check if the line begins with "HTTP" */
> } else {
>     count = safe_read(inFd, rbuf, PIPESIZE);
> }
> 

Yes, I think that's probably sufficient. The busybox httpd cgi program
interaction is obviously idiosyncratic in that it doesn't parse headers
and expects the cgi program to write the status line if it wants to
return something other than OK status. I think this is usually handled
by using the status header, but I guess I don't really care. As they
say, "When in Rome ..."

:)


> Better yet, do a full line read for the first line or completely
> switch to line buffered input, as you suggested.
> 
> so long,
> 
> Hias
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox


From ddaney at avtrex.com  Mon Feb 12 21:36:10 2007
From: ddaney at avtrex.com (David Daney)
Date: Mon, 12 Feb 2007 13:36:10 -0800
Subject: Detecting link state in dhcpc...
In-Reply-To: <200702122203.58972.vda.linux@googlemail.com>
References: <AB6A1BB47C4EEC42AA92468A0A5CC8990322D373@ra1ncsmb01.nasa.ad.etn.com>
	<200702122203.58972.vda.linux@googlemail.com>
Message-ID: <45D0DDCA.1060808@avtrex.com>

Denis Vlasenko wrote:
> On Monday 12 February 2007 18:00, MatthewLCreech at eaton.com wrote:
>> busybox-bounces at busybox.net wrote:
>>> In my case, I am talking about an embedded device that is
>>> essentially useless if not on a network also, so I definitely
>>> want to be able to take some action if the link goes down as
>>> well.  In my case it happens that I need to do this in static
>>> IP case also, so I have a link monitoring daemon that takes
>>> care of it, rather than adding it to DHCP.
>> FWIW, I also have an embedded device which needs this kind of behavior,
>> so I used netplugd:
>>
>> http://www.red-bean.com/~bos/
>>
>> The netplugd script that gets run when the carrier state changes either
>> starts/kills udhcpc, or it runs the appropriate ifconfig commands,
>> depending on how the device is configured.  It's an easy alternative to
>> modifying BusyBox, and also keeps things consistent when you're not
>> using DHCP.  (Which sounds like it might be similar to what you've
>> already done for the static case)
> 
> That's a good solution: add netplugd to bbox as a new applet.

I am abandoning my patch to add it to udhcpd.

Currently I am looking at running ifplugd to see how that works.  If it 
looks OK, I will add it or netplugd to busybox.

Thanks,
David Daney


From vda.linux at googlemail.com  Mon Feb 12 22:05:00 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:05:00 +0100
Subject: tar no longer extracting with setuid bits
In-Reply-To: <20070211222418.GA4818@tleilax.gmail.com>
References: <20070211222418.GA4818@tleilax.gmail.com>
Message-ID: <200702122305.00198.vda.linux@googlemail.com>

On Sunday 11 February 2007 23:24, Stephane Billiart wrote:
> While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
> setuid files in tar files are no longer created with the setuid bit
> while running as root.
> 
> The attached patch (which partially reverts r15775 of
> archival/libunarchive/data_extract_all.c) fixes the problem.

Applied, thanks!

> Any idea why the chmod call was removed?

Probably because open is creating file with correct mode.
But setuid bits can be lost later.
--
vda


From albrecht at rdi1.com  Mon Feb 12 21:17:23 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 16:17:23 -0500
Subject: Must really be safe_read(), not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <200702122152.29070.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122152.29070.vda.linux@googlemail.com>
Message-ID: <1171315043.3897.33.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 21:52 +0100, Denis Vlasenko wrote: 
> On Monday 12 February 2007 16:25, Paul Albrecht wrote:
> > 
> > Reverting the code back to using safe_read doesn't work if you don't fix
> > the way the first line is handled because you're not guaranteed a full
> > line with the safe_read.
> > 
> > You can verify this by writing a cgi program which redirects to another
> > location.
> 
> Testcase, please?

I have already given you an example in a previous message, but here it
is again: 

echo -en "HTTP/1.0 302 Found\r\n"
echo -en "Location: http://www.busybox.net\r\n"
echo -en "\r\n"

> 
> > It will intermittently fail. This has nothing to do with how the cgi
> > program writes to standard output. It's a consequence of the fact that
> > the server doesn't buffer standard input so it has no right to expect a
> > full line with its first read of cgi output.
> 
> We don't care about first line. We care about first four charachers only,
> I think.
> 

I think the busybox httpd server cgi program interaction is obviously
idiosyncratic in that the server doesn't parse returned headers and
mucks with the status line.

I'm not really complaining, but however you expect the httpd server and
cgi program to interact to get a valid http response back to a user
should work. 

If you're going to write the status line if you don't get one back from
the cgi program you should do that and you're not doing that because
you're using an unbuffered read to get at least four characters of the
first line of cgi output and that doesn't always work.

> > An expedient way to fix the problem is to do the full_read, that is,
> > receive all the cgi output before handling the first line.
> > 
> > If this is not sufficient then busybox httpd should line buffer standard
> > input so that it always handles the status line correctly. 
> 
> Yes, this will even handle the case when CGI writes "HTT" and
> "P/1.0 200 OK" separately.

That's not the problem. For example, if a cgi program writes:

echo -en "HTTP/1.0 302 Found\r\n"

The busybox httpd server has no right to assume it's got more than a
byte of data when a safe_read completes with good status because its
input isn't buffered. 

> --
> 
> vda


From albrecht at rdi1.com  Mon Feb 12 21:33:02 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Mon, 12 Feb 2007 16:33:02 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171312135.3800.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<20070212170958.GA17291@horus.com>
	<1171312135.3800.0.camel@albrecht.rdi1.com>
Message-ID: <1171315982.3897.49.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 22:01 +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > > If this is not sufficient then busybox httpd should line buffer standard
> > > input so that it always handles the status line correctly. 
> > 
> > If I understand the code correctly, it would be sufficient to do
> > something like
> > 
> > if (firstline)
> >     count = full_read(inFd, rbuf, 4);
> >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> 
> So far I am happy with "bbox httpd doesn't support insane cgis
> which split their HTTP response" way.
> 

A cgi program doesn't have to "split" its output for the problem to
occur because the data is read over a socket over a network and is not
buffered. There's simply no guarantee an unbuffered read gets a full
line of output from a cgi program however the data gets output.

If, for example, this is the first line of cgi program output:

echo -en "HTTP/1.0 302 Found\r\n

then when the busybox httpd server does its safe_read it can only count
on one byte with good status. It's a fact that usually the read will get
most of if not the entire line but that's not guaranteed because the
read isn't buffered.

> > } else {
> >     count = safe_read(inFd, rbuf, PIPESIZE);
> > }
> > 
> > Better yet, do a full line read for the first line or completely
> > switch to line buffered input, as you suggested.
> 
> Are you suggesting using stdio?
> Can't do that, or POSTDATA will break again.
> 
> You basically need to _open-code_ buffering here. Than will work.
> --
> 
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox


From hias at horus.com  Mon Feb 12 22:21:55 2007
From: hias at horus.com (Matthias Reichl)
Date: Mon, 12 Feb 2007 23:21:55 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <200702122201.13865.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<20070212170958.GA17291@horus.com>
	<200702122201.13865.vda.linux@googlemail.com>
Message-ID: <20070212222155.GB17291@horus.com>

On Mon, Feb 12, 2007 at 10:01:13PM +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > if (firstline)
> >     count = full_read(inFd, rbuf, 4);
> >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> 
> So far I am happy with "bbox httpd doesn't support insane cgis
> which split their HTTP response" way.

Would be OK for me, too. OTOH: it's a simple patch and it assures
that the current httpd could also deal with insane cgis.

> > Better yet, do a full line read for the first line or completely
> > switch to line buffered input, as you suggested.
> 
> Are you suggesting using stdio?
4> Can't do that, or POSTDATA will break again.
> 
> You basically need to _open-code_ buffering here. Than will work.

No, I was thinking about using a function like getLine() when
reading the first line from the cgi. But that's not needed ATM
and would only be useful for future versions of httpd if they'd like
to parse the full first line.

To clean up the patch a little bit more, I'd suggest something like
this:

static const char HTTP_200[] = "HTTP/1.0 200 OK\r\n\r\n";
/* httpd only checks for a response beginning with "HTTP" */
/* in the first line of cgi output */
#define HTTP_200_check_len 4
if (firstline)
	count = full_read(inFd, rbuf, HTTP_200_check_len);
} else {
	count = safe_read(inFd, rbuf, PIPESIZE);
}
...
	if (memcmp(rbuf, HTTP_200, HTTP_200_check_len) != 0) {
...
#undef HTTP_200_check_len

AFAICT this should work fine and it's clear for other developers.

The only thing that may go wrong is a cgi that outputs only
something like "hi\n" and then waits for POST data. Also insane,
and can only be handled with a getLine()-like approach.

so long,

Hias


From vda.linux at googlemail.com  Mon Feb 12 22:25:17 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:25:17 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171315043.3897.33.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122152.29070.vda.linux@googlemail.com>
	<1171315043.3897.33.camel@albrecht.rdi1.com>
Message-ID: <200702122325.17826.vda.linux@googlemail.com>

On Monday 12 February 2007 22:17, Paul Albrecht wrote:
> On Mon, 2007-02-12 at 21:52 +0100, Denis Vlasenko wrote: 
> > On Monday 12 February 2007 16:25, Paul Albrecht wrote:
> > > 
> > > Reverting the code back to using safe_read doesn't work if you don't fix
> > > the way the first line is handled because you're not guaranteed a full
> > > line with the safe_read.
> > > 
> > > You can verify this by writing a cgi program which redirects to another
> > > location.
> > 
> > Testcase, please?
> 
> I have already given you an example in a previous message, but here it
> is again: 
> 
> echo -en "HTTP/1.0 302 Found\r\n"
> echo -en "Location: http://www.busybox.net\r\n"
> echo -en "\r\n"

#!/bin/sh
echo -en "HTTP/1.0 302 Found\r\n"
echo -en "Location: http://www.busybox.net\r\n"
echo -en "\r\n"

Works for me 

> I think the busybox httpd server cgi program interaction is obviously
> idiosyncratic in that the server doesn't parse returned headers and
> mucks with the status line.
> 
> I'm not really complaining, but however you expect the httpd server and
> cgi program to interact to get a valid http response back to a user
> should work.

bbox applets usually start small and then add features / fix bugs
in the order of severity.

> If you're going to write the status line if you don't get one back from
> the cgi program you should do that and you're not doing that because
> you're using an unbuffered read to get at least four characters of the
> first line of cgi output and that doesn't always work.

I will gladly take good patch which does said buffering.

> > Yes, this will even handle the case when CGI writes "HTT" and
> > "P/1.0 200 OK" separately.
> 
> That's not the problem. For example, if a cgi program writes:
> 
> echo -en "HTTP/1.0 302 Found\r\n"
> 
> The busybox httpd server has no right to assume it's got more than a
> byte of data when a safe_read completes with good status because its
> input isn't buffered. 

Sorry, I don't understand this part. If cgi writes "HTTP/1.0 302 Found\r\n"
using one write syscall, httpd will read the same number of bytes (not less).
--
vda


From vda.linux at googlemail.com  Mon Feb 12 22:28:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:28:33 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171315982.3897.49.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171312135.3800.0.camel@albrecht.rdi1.com>
	<1171315982.3897.49.camel@albrecht.rdi1.com>
Message-ID: <200702122328.33155.vda.linux@googlemail.com>

On Monday 12 February 2007 22:33, Paul Albrecht wrote:
> > So far I am happy with "bbox httpd doesn't support insane cgis
> > which split their HTTP response" way.
> > 
> 
> A cgi program doesn't have to "split" its output for the problem to
> occur because the data is read over a socket over a network and is not
> buffered. There's simply no guarantee an unbuffered read gets a full
> line of output from a cgi program however the data gets output.

No, data is written thru the local pipe from cgi to httpd process.
--
vda


From vda.linux at googlemail.com  Mon Feb 12 22:34:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 12 Feb 2007 23:34:03 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <20070212222155.GB17291@horus.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122201.13865.vda.linux@googlemail.com>
	<20070212222155.GB17291@horus.com>
Message-ID: <200702122334.03094.vda.linux@googlemail.com>

On Monday 12 February 2007 23:21, Matthias Reichl wrote:
> On Mon, Feb 12, 2007 at 10:01:13PM +0100, Denis Vlasenko wrote:
> > On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > > if (firstline)
> > >     count = full_read(inFd, rbuf, 4);
> > >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> > 
> > So far I am happy with "bbox httpd doesn't support insane cgis
> > which split their HTTP response" way.
> 
> Would be OK for me, too. OTOH: it's a simple patch and it assures
> that the current httpd could also deal with insane cgis.

NO, IT CAN'T.

If cgi will output "HTT" and then block in read() from fd#0
while httpd is also blocked in full_read() trying to get at least
four bytes, we will deadlock.

> > > Better yet, do a full line read for the first line or completely
> > > switch to line buffered input, as you suggested.
> > 
> > Are you suggesting using stdio?
> 4> Can't do that, or POSTDATA will break again.
> > 
> > You basically need to _open-code_ buffering here. Than will work.
> 
> No, I was thinking about using a function like getLine() when
> reading the first line from the cgi. But that's not needed ATM
> and would only be useful for future versions of httpd if they'd like
> to parse the full first line.
--
vda


From hias at horus.com  Tue Feb 13 00:42:51 2007
From: hias at horus.com (Matthias Reichl)
Date: Tue, 13 Feb 2007 01:42:51 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <200702122334.03094.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122201.13865.vda.linux@googlemail.com>
	<20070212222155.GB17291@horus.com>
	<200702122334.03094.vda.linux@googlemail.com>
Message-ID: <20070213004251.GA26535@horus.com>

On Mon, Feb 12, 2007 at 11:34:03PM +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 23:21, Matthias Reichl wrote:
> > Would be OK for me, too. OTOH: it's a simple patch and it assures
> > that the current httpd could also deal with insane cgis.
> 
> NO, IT CAN'T.
> 
> If cgi will output "HTT" and then block in read() from fd#0
> while httpd is also blocked in full_read() trying to get at least
> four bytes, we will deadlock.

OK, you are right. We have to avoid deadlock situations,

Here's a new patch. It delays the header check against "HTTP" until
enough bytes are read from the CGI. All this is done non-blocking.
In case of a premature EOF (eg CGI only writing "hi\n") a
"HTTP/1.0 200 OK" plus the data is sent. The rest of the code is
as before.

I hope this fixes the issues (at the moment :-)

so long,

Hias
-------------- next part --------------
--- busybox-svn.orig/networking/httpd.c	2007-02-11 23:29:09.000000000 +0100
+++ busybox-svn/networking/httpd.c	2007-02-13 01:36:58.000000000 +0100
@@ -1137,6 +1137,14 @@
 		fd_set readSet;
 		fd_set writeSet;
 		char wbuf[128];
+		/* default response if not set by cgi */
+		static const char HTTP_200[] = "HTTP/1.0 200 OK\r\n\r\n";
+		/* only check the first 4 bytes of cgi response (for "HTTP") */
+#define HTTP_200_CHECK_LEN 4
+#if HTTP_200_CHECK_LEN >= MAX_MEMORY_BUFF
+# error "HTTP_200_CHECK_LEN >= MAX_MEMORY_BUFF"
+#endif
+		int fcount = 0; /* byte counter for first line */
 		int nfound;
 		int count;
 
@@ -1206,41 +1214,59 @@
 			/* There is something to read from CGI */
 			int s = config->accepted_socket;
 			char *rbuf = config->buf;
+			if (firstLine) {
+				/* try to read the first bytes of the CGI response so we can
+				 * check if it contained a HTTP/x.y ... response
+				 * note: do it non-blocking, otherwise httpd might deadlock! */
+				count = safe_read(inFd, rbuf + fcount, HTTP_200_CHECK_LEN - fcount);
+				if (count == 0) {
+					/* eof and we couldn't check for a valid HTTP/... header,
+					 * so add one and write out the received data */
+					if (fcount) {
+							full_write(s, HTTP_200, sizeof(HTTP_200)-1);
+							full_write(s, rbuf, fcount);
+					}
+					break;  /* closed */
+				}
+				if (count < 0)
+					continue; /* huh, error, why continue?? */
+
+				fcount += count;
+
+				if (fcount == HTTP_200_CHECK_LEN) {
+					rbuf[fcount] = '\0';
+					/* check to see if the user script added headers */
+					/* (NB: buggy wrt cgi splitting "HTTP OK") */
+					if (memcmp(rbuf, HTTP_200, HTTP_200_CHECK_LEN) != 0) {
+						/* there is no "HTTP", do it ourself */
+						if (full_write(s, HTTP_200, sizeof(HTTP_200)-1) != sizeof(HTTP_200)-1)
+							break;
+					}
+					/* Example of valid GCI without "Content-type:"
+					 * echo -en "HTTP/1.0 302 Found\r\n"
+					 * echo -en "Location: http://www.busybox.net\r\n"
+					 * echo -en "\r\n"
+					if (!strstr(rbuf, "ontent-")) {
+						full_write(s, "Content-type: text/plain\r\n\r\n", 28);
+					}
+					 */
+					if (full_write(s, rbuf, fcount) != fcount)
+						break;
+					firstLine = 0;
+				}
+			} else {
 #define PIPESIZE PIPE_BUF
 #if PIPESIZE >= MAX_MEMORY_BUFF
 # error "PIPESIZE >= MAX_MEMORY_BUFF"
 #endif
-			/* Must use safe_read, not full_read, because
-			 * cgi may output a few first lines and then wait
-			 * for POSTDATA without closing stdout.
-			 * With full_read we may wait here forever. */
-			count = safe_read(inFd, rbuf, PIPESIZE);
-			if (count == 0)
-				break;  /* closed */
-			if (count < 0)
-				continue; /* huh, error, why continue?? */
-
-			if (firstLine) {
-				static const char HTTP_200[] = "HTTP/1.0 200 OK\r\n\r\n";
-				rbuf[count] = '\0';
-				/* check to see if the user script added headers */
-				/* (NB: buggy wrt cgi splitting "HTTP OK") */
-				if (memcmp(rbuf, HTTP_200, 4) != 0) {
-					/* there is no "HTTP", do it ourself */
-					full_write(s, HTTP_200, sizeof(HTTP_200)-1);
-				}
-				/* Example of valid GCI without "Content-type:"
-				 * echo -en "HTTP/1.0 302 Found\r\n"
-				 * echo -en "Location: http://www.busybox.net\r\n"
-				 * echo -en "\r\n"
-				if (!strstr(rbuf, "ontent-")) {
-					full_write(s, "Content-type: text/plain\r\n\r\n", 28);
-				}
-				 */
-				firstLine = 0;
+				count = safe_read(inFd, rbuf, PIPESIZE);
+				if (count == 0)
+					break;  /* closed */
+				if (count < 0)
+					continue; /* huh, error, why continue?? */
+				if (full_write(s, rbuf, count) != count)
+					break;
 			}
-			if (full_write(s, rbuf, count) != count)
-				break;
 			if (DEBUG)
 				fprintf(stderr, "cgi read %d bytes: '%.*s'\n", count, count, rbuf);
 		} /* if (FD_ISSET(inFd)) */

From vapier at gentoo.org  Tue Feb 13 00:56:25 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 12 Feb 2007 19:56:25 -0500
Subject: [gmail] Re: realpath bug
In-Reply-To: <200702111530.45440.vda.linux@googlemail.com>
References: <2ccd6e3c0702070222w57d7cfbdlebb3566928faf880@mail.gmail.com>
	<200702102355.09483.vapier@gentoo.org>
	<200702111530.45440.vda.linux@googlemail.com>
Message-ID: <200702121956.26551.vapier@gentoo.org>

On Sunday 11 February 2007, Denis Vlasenko wrote:
> On Sunday 11 February 2007 05:55, Mike Frysinger wrote:
> > this wont be terribly robust as what if /dev/ is readonly and /dev/log is
> > a relative symlink ... you'd have to make sure you chroot(/dev/) first
>
> I hope chdir("/dev") would suffice ;)

err, sorry ... you are correct of course, i meant chdir() ... i seem to typo 
those quite frequently :/
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070212/728f0a25/attachment-0002.pgp 

From gcohn at optusnet.com.au  Tue Feb 13 06:58:26 2007
From: gcohn at optusnet.com.au (Gerry Cohn)
Date: Tue, 13 Feb 2007 17:58:26 +1100
Subject: Udhcpc problem
Message-ID: <001301c74f3c$5bfd7dc0$0914a8c0@glap>

Hi all,
 
I am using BusyBox v1.00 (2005.08.15-23:44+0000) multi-call binary as part
of an embedded system based on the PXA270 processor.
Recently I have discovered a problem that has me baffled.
 
Up until a few days ago, no matter what dhcp server was used, I could
successfully obtain a lease.
I am now trying to use a Thomson Speedtouch 536 v6 Modem/Router and am
finding that the DHCPOFFER messages are being rejected.
I have also found that exactly the same thing happens with a Dynalink
RTA1320 modem/router.
Both of these units are based on Broadcom chips.
 
I am now at my wits end with this.
 
If anyone can offer any advice regarding a fix for this problem, I would be
forever grateful.
 
Regards,
 
Gerry Cohn
>From the land down under
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070213/15a08442/attachment-0001.htm 

From natanael.copa at gmail.com  Tue Feb 13 08:31:47 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Tue, 13 Feb 2007 09:31:47 +0100
Subject: tar no longer extracting with setuid bits
In-Reply-To: <200702122305.00198.vda.linux@googlemail.com>
References: <20070211222418.GA4818@tleilax.gmail.com>
	<200702122305.00198.vda.linux@googlemail.com>
Message-ID: <1171355507.2696.109.camel@localhost>

On Mon, 2007-02-12 at 23:05 +0100, Denis Vlasenko wrote:
> On Sunday 11 February 2007 23:24, Stephane Billiart wrote:
> > While trying to upgrade from busybox 1.2.2.1 to 1.4.1, I noticed that
> > setuid files in tar files are no longer created with the setuid bit
> > while running as root.
> > 
> > The attached patch (which partially reverts r15775 of
> > archival/libunarchive/data_extract_all.c) fixes the problem.
> 
> Applied, thanks!

Could this also be added to fixes-1.4.1, please?

Thanks!

Natanael Copa



From albrecht at rdi1.com  Tue Feb 13 13:34:40 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Tue, 13 Feb 2007 08:34:40 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171316917.4039.3.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122201.13865.vda.linux@googlemail.com>
	<20070212222155.GB17291@horus .com>
	<1171316917.4039.3.camel@albrecht.rdi1.com>
Message-ID: <1171373680.2437.13.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 23:34 +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 23:21, Matthias Reichl wrote:
> > On Mon, Feb 12, 2007 at 10:01:13PM +0100, Denis Vlasenko wrote:
> > > On Monday 12 February 2007 18:09, Matthias Reichl wrote:
> > > > if (firstline)
> > > >     count = full_read(inFd, rbuf, 4);
> > > >     /* read 4 bytes so we can check if the line begins with "HTTP" */
> > > 
> > > So far I am happy with "bbox httpd doesn't support insane cgis
> > > which split their HTTP response" way.
> > 
> > Would be OK for me, too. OTOH: it's a simple patch and it assures
> > that the current httpd could also deal with insane cgis.
> 
> NO, IT CAN'T.
> 
> If cgi will output "HTT" and then block in read() from fd#0
> while httpd is also blocked in full_read() trying to get at least
> four bytes, we will deadlock.
> 

This scenario seems far fetched because http is a request/response
protocol.  It doesn't make a lot of sense for a cgi program to start
producing output--the http response--before it has read and processed
request.

> > > > Better yet, do a full line read for the first line or completely
> > > > switch to line buffered input, as you suggested.
> > > 
> > > Are you suggesting using stdio?
> > 4> Can't do that, or POSTDATA will break again.
> > > 
> > > You basically need to _open-code_ buffering here. Than will work.
> > 
> > No, I was thinking about using a function like getLine() when
> > reading the first line from the cgi. But that's not needed ATM
> > and would only be useful for future versions of httpd if they'd like
> > to parse the full first line.
> --
> 
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox


From albrecht at rdi1.com  Tue Feb 13 13:58:50 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Tue, 13 Feb 2007 08:58:50 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <200702122328.33155.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171312135.3800.0.camel@albrecht.rdi1.com>
	<1171315982.3897.49.camel@albrecht.rdi1.com>
	<200702122328.33155.vda.linux@googlemail.com>
Message-ID: <1171375130.2437.36.camel@albrecht.rdi1.com>

On Mon, 2007-02-12 at 23:28 +0100, Denis Vlasenko wrote:
> On Monday 12 February 2007 22:33, Paul Albrecht wrote:
> > > So far I am happy with "bbox httpd doesn't support insane cgis
> > > which split their HTTP response" way.
> > > 
> > 
> > A cgi program doesn't have to "split" its output for the problem to
> > occur because the data is read over a socket over a network and is not
> > buffered. There's simply no guarantee an unbuffered read gets a full
> > line of output from a cgi program however the data gets output.
> 
> No, data is written thru the local pipe from cgi to httpd process.

Yes, of course, the cgi program and busybox httpd server communicate
over a pipe, not a tcp socket.

However, I still think that because the read syscall is unbuffered you
can't assume that if you write x bytes to one end of the pipe you're
guaranteed x bytes on the *first* read on the other end of the pipe.

I think you're supposed to check the number of bytes read and continue
doing reads until you get as much data as you're expecting or get end of
file.

Finally, whether you accept this explanation or not it's a fact that the
simple cgi program I posted in my previous message fails intermittently.


From ddaney at avtrex.com  Tue Feb 13 18:28:13 2007
From: ddaney at avtrex.com (David Daney)
Date: Tue, 13 Feb 2007 10:28:13 -0800
Subject: bb_sanitize_stdio_maybe_daemonize faulty logic...
Message-ID: <45D2033D.9030908@avtrex.com>

Consider this program:

---------------------------------------
#include <stdio.h>
#include <sys/socket.h>


static int open_a_socket()
{
     int s = socket(PF_INET, SOCK_DGRAM, 0);
     printf("Opened on fd %d\n", s);
     return s;
}


int
main(int argc, char *argv[])
{
     int c;

     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     c = open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();
     open_a_socket();

     close(c);
     open_a_socket();

     return 0;
}
-----------------------------------

Note that the last open reuses the fd of the closed socket, but there 
are a lot of open sockets with fd values greater than the last socket 
opened.

Now look at bb_sanitize_stdio_maybe_daemonize:

-----------------------------------------
void bb_sanitize_stdio_maybe_daemonize(int daemonize)
{
         int fd;
         /* Mega-paranoid */
         fd = xopen(bb_dev_null, O_RDWR);
         while ((unsigned)fd < 2)
                 fd = dup(fd); /* have 0,1,2 open at least to /dev/null */
         if (daemonize) {
                 pid_t pid = fork();
                 if (pid < 0) /* wtf? */
                         bb_perror_msg_and_die("fork");
                 if (pid) /* parent */
                         exit(0);
                 /* child */
                 /* if daemonizing, make sure we detach from stdio */
                 setsid();
                 dup2(fd, 0);
                 dup2(fd, 1);
                 dup2(fd, 2);
         }
         while (fd > 2)
                 close(fd--); /* close everything after fd#2 */
}
-----------------------------------------

The result of the first xopen is used as a marker to try to find the 
highest active descriptor.  Then all descriptors greater than 2 and less 
than the marker are closed.

The problem is that the marker could fall in a hole in the middle of the 
range of open descriptors (as in the top example), in which case 
bb_sanitize_stdio_maybe_daemonize could leave some descriptors open that 
should have been closed.

David Daney


From hias at horus.com  Wed Feb 14 09:56:34 2007
From: hias at horus.com (Matthias Reichl)
Date: Wed, 14 Feb 2007 10:56:34 +0100
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <200702132355.14322.vda.linux@googlemail.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122334.03094.vda.linux@googlemail.com>
	<20070213004251.GA26535@horus.com>
	<200702132355.14322.vda.linux@googlemail.com>
Message-ID: <20070214095634.GB901@horus.com>

On Tue, Feb 13, 2007 at 11:55:14PM +0100, Denis Vlasenko wrote:
> +???????????????int fcount = 0; /* byte counter for first line */
> 
> You reset counter on each while() iteration

Thanks, you are right. It's in the wrong scope.

> +???????????????????????????????if (fcount == HTTP_200_CHECK_LEN) {
> +???????????????????????????????????????rbuf[fcount] = '\0';
> 
> What is the purpose of rbuf[fcount] = '\0' ?

Nothing. This is just old copied code. It was "rbuf[count] = '\0'"
before, used by the (removed) "strstr..." check.

so long,

Hias


From rep.dot.nop at gmail.com  Wed Feb 14 10:51:07 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Wed, 14 Feb 2007 11:51:07 +0100
Subject: [PATCH, CFT] fix awk -v -v handling
Message-ID: <20070214105107.GA28069@aon.at>

Hi,

<wihen> can anyone confirm if awk is broken on 1.4.1?
<wihen> multiple -v don't work.

Confirmed. The attached, untested patch against trunk should fix it.

Please verify and apply to trunk and the 1_4 branch.

TIA and cheers,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox_trunk.awk-option-v-handling.patch
Type: text/x-diff
Size: 876 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070214/e40df374/attachment-0002.bin 

From vapier at gentoo.org  Wed Feb 14 13:00:33 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Feb 2007 08:00:33 -0500
Subject: stop ignoring initramfs in df ?
Message-ID: <200702140800.33665.vapier@gentoo.org>

so i started to add a df build option, "ignore initramfs mount", that would 
control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
that in embedded/bootable systems, it is common to run right out of the 
initramfs rather than switching over to a "normal" root

however, i cant decide whether this warrants an actual build option ... the 
trade offs are that in the desktop case, you'd never want to see the rootfs 
output ... but does controlling literally 2 lines of code offset this ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070214/055ac0e3/attachment-0002.pgp 

From ddaney at avtrex.com  Wed Feb 14 16:53:57 2007
From: ddaney at avtrex.com (David Daney)
Date: Wed, 14 Feb 2007 08:53:57 -0800
Subject: Patch: Fix zcip deamonization...
Message-ID: <45D33EA5.7050804@avtrex.com>

The mailing list was broken yesterday.  I am resending this message:

-------- Original Message --------
Subject: Patch: Fix zcip deamonization...
Date: Tue, 13 Feb 2007 13:09:24 -0800
From: David Daney <ddaney at avtrex.com>
To: busybox at busybox.net

In r17390 the call to xdaemon(0, 0) was replaced with a call to
bb_daemonize().  This does not work because bb_daemonize() closes all
open file descriptors and zcip opens its socket before daemonzing.


The fix is to revert to using xdaemon(0, 0).  I also removed the call to
setsid(), as it is usless in this context.

Please commit if OK.

Thanks
David Daney

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zcip.diff
Type: text/x-patch
Size: 361 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070214/293ba11b/attachment-0002.bin 

From ddaney at avtrex.com  Wed Feb 14 18:54:43 2007
From: ddaney at avtrex.com (David Daney)
Date: Wed, 14 Feb 2007 10:54:43 -0800
Subject: bb_sanitize_stdio_maybe_daemonize faulty logic...
In-Reply-To: <200702141920.05128.vda.linux@googlemail.com>
References: <45D2033D.9030908@avtrex.com>
	<200702140044.09317.vda.linux@googlemail.com>
	<45D252A8.1020301@avtrex.com>
	<200702141920.05128.vda.linux@googlemail.com>
Message-ID: <45D35AF3.9090409@avtrex.com>

Denis Vlasenko wrote:
> On Wednesday 14 February 2007 01:07, David Daney wrote:
>>>>>> Yes, I know. Have better ideas (apart from closing all fds from 
>>>>>> 9999999999 to 3)?
>>>>> It is a difficult problem.  In practice you don't have to go all the way 
>>>>> to 9999999999, the value returned by ulimit -n would be high enough.
>>>>>
>>>>> You could also set the close-on-exec flag on all descriptors that should 
>>>>> not leak from busybox, then you would not need this part.
>>> You see, this function isn't meant to be 100.00% watertight.
>>>
>>> It just tries to close some stray opne fds, but does not
>>> promise to do it reliably for all weird cases.
>>>
>> It could easily be made 100% by:
>>
>> struct rlimit rl;
>> int i;
>> getrlimit(RLIMIT_NOFILE, &rl);
>> for (i = 3; i < rl.rlim_cur; i++)
>>      close(i);
> 
> This is what I meant by "close all fds from 9999999 to 3".

Fine.  You are the maintainer.  1024 is quite a bit smaller than 
9999999, but if you think it is useful as it is then I will not get too 
worked up about it.

David Daney


From vda.linux at googlemail.com  Wed Feb 14 20:47:58 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 14 Feb 2007 21:47:58 +0100
Subject: Patch: Fix zcip deamonization...
In-Reply-To: <45D33EA5.7050804@avtrex.com>
References: <45D33EA5.7050804@avtrex.com>
Message-ID: <200702142147.58814.vda.linux@googlemail.com>

On Wednesday 14 February 2007 17:53, David Daney wrote:
> The mailing list was broken yesterday.  I am resending this message:
> 
> -------- Original Message --------
> Subject: Patch: Fix zcip deamonization...
> Date: Tue, 13 Feb 2007 13:09:24 -0800
> From: David Daney <ddaney at avtrex.com>
> To: busybox at busybox.net
> 
> In r17390 the call to xdaemon(0, 0) was replaced with a call to
> bb_daemonize().  This does not work because bb_daemonize() closes all
> open file descriptors and zcip opens its socket before daemonzing.
> 
> 
> The fix is to revert to using xdaemon(0, 0).  I also removed the call to
> setsid(), as it is usless in this context.
> 
> Please commit if OK.

DOH! :(  Thanks!
--
vda


From vda.linux at googlemail.com  Wed Feb 14 20:51:39 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 14 Feb 2007 21:51:39 +0100
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702140800.33665.vapier@gentoo.org>
References: <200702140800.33665.vapier@gentoo.org>
Message-ID: <200702142151.39680.vda.linux@googlemail.com>

On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> so i started to add a df build option, "ignore initramfs mount", that would 
> control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> that in embedded/bootable systems, it is common to run right out of the 
> initramfs rather than switching over to a "normal" root
> 
> however, i cant decide whether this warrants an actual build option ... the 
> trade offs are that in the desktop case, you'd never want to see the rootfs 
> output ... but does controlling literally 2 lines of code offset this ?

I don't know what is a rationale for hiding that. It _is_ mounted there, right?
So why we are lying to user that it isn't there?

In my opinion we should just remove this feature.
--
vda


From vapier at gentoo.org  Wed Feb 14 22:34:48 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Feb 2007 17:34:48 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702142151.39680.vda.linux@googlemail.com>
References: <200702140800.33665.vapier@gentoo.org>
	<200702142151.39680.vda.linux@googlemail.com>
Message-ID: <200702141734.48564.vapier@gentoo.org>

On Wednesday 14 February 2007, Denis Vlasenko wrote:
> On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> > so i started to add a df build option, "ignore initramfs mount", that
> > would control the hardcoded filter in df.c for the "rootfs" mount ...
> > idea being that in embedded/bootable systems, it is common to run right
> > out of the initramfs rather than switching over to a "normal" root
> >
> > however, i cant decide whether this warrants an actual build option ...
> > the trade offs are that in the desktop case, you'd never want to see the
> > rootfs output ... but does controlling literally 2 lines of code offset
> > this ?
>
> I don't know what is a rationale for hiding that. It _is_ mounted there,
> right?

a small initramfs is always mounted in 2.6 kernels ... for most systems 
though, it isnt actually used

> So why we are lying to user that it isn't there? 

because to the layman, it can be confusing wtf this tiny little rootfs mount 
is about

> In my opinion we should just remove this feature.

i'm ok with that :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070214/0cbedc75/attachment-0002.pgp 

From rep.dot.nop at gmail.com  Thu Feb 15 14:12:43 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 15 Feb 2007 15:12:43 +0100
Subject: make tar restore mode again [was: Re: svn commit:
	trunk/busybox/archival/libunarchive]
In-Reply-To: <20070212220658.50DDB485CC@busybox.net>
References: <20070212220658.50DDB485CC@busybox.net>
Message-ID: <20070215141243.GD18188@aon.at>

On Mon, Feb 12, 2007 at 02:06:58PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-12 14:06:56 -0800 (Mon, 12 Feb 2007)
>New Revision: 17869
>
>Log:
>make tar restore mode again
>
>
>Modified:
>   trunk/busybox/archival/libunarchive/data_extract_all.c

vda, mind also fixing this on the 1_4_branch, please?



From akennedy at techmoninc.com  Thu Feb 15 16:19:27 2007
From: akennedy at techmoninc.com (Andy Kennedy)
Date: Thu, 15 Feb 2007 10:19:27 -0600
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <20070209211142.GY12488@aon.at>
References: <45C0EA70.4080508@techmoninc.com> <45C0EBB2.1090604@seiner.com>
	<45C0F180.4000904@techmoninc.com> <45C11D80.20906@techmoninc.com>
	<20070201005758.GA19486@nsk.no-ip.org>
	<45C776AD.5090602@techmoninc.com> <45CCCF5D.6040203@techmoninc.com>
	<20070209211142.GY12488@aon.at>
Message-ID: <45D4880F.7030607@techmoninc.com>

Bernhard Fischer wrote:
> On Fri, Feb 09, 2007 at 01:45:33PM -0600, Andy Kennedy wrote:
>   
>> Andy Kennedy wrote:
>>     
>>> To restate my problem (in case some kind developer decides to help me):
>>>
>>> When I have the kernel command line parameter "console=ttyS0,115200n8" 
>>> I get nice neat output on the serial line up until the init runs.  As 
>>> soon as init runs, I get missing chars.  So, I replace the BusyBox 
>>> init with minit, compiled from source and using the uCLibC gcc that I 
>>> let buildroot make for me.  Same problem.  For some reason, when the 
>>> system initializes -- after the kernel has reported all of its output, 
>>> my serial console goes splat.  When I initialize the console using 
>>> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
>>> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
>>> One of these letters will appear each time I send enter.
>>>
>>> I have tried everything I can think of.  There is no script setting 
>>> any of the line speeds -- in fact, I have even attempted to remove the 
>>> scripts and still get the same thing.  Removing the 
>>> console=ttyS0,115200n8 (or attempting any variant of it) has no 
>>> affect, except without the console= I get no good output on the line.  
>>> The only thing I haven't attempted yet is to replace the getty with an 
>>> equivalent to see if that makes a difference.  I have also tried 9600, 
>>> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
>>> every combination, but I still cannot get a serial console.
>>>
>>> Can anyone offer a suggestion as to how I might fix this -- or some 
>>> other place to start?
>>>
>>> Thanks in advance for any help you can offer,
>>> Andy
>>>       
>> Okay, now I'm really confused.  Here is what I have done so far:
>> Made my laptop boot with a console on ttyS0 and put a login shell on it 
>> (to verify that I can do it -- I was beginning to think maybe I needed 
>> to remove Linux from my computer and get rid of all of  it being to 
>> stupid to own a computer, much less program an embedded system) and I 
>> had no problems.  So, I took my syslinux disk and booted from it (the 
>> SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
>> everything comes up as you would expect.
>>
>> Given that this test worked there is one of about three possibilities:
>> 1) Cable issue.  Tested my serial cable on another embedded system (an 
>> Arcom Viper), checks out.  Replaced the break-out cable from the 
>> embedded system -- failed.  Tried a known good cable -- failed.  Tested 
>> a different VersaLogic board -- failed.  Now, here is the part that 
>> really yanked me around:
>>
>> The last time I booted the machine I didn't have the keyboard connected 
>> to the break-out cable.  The boot went as it normally does except the 
>> keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
>> BusyBox init takes over the console and prints all kind of whack.  I 
>> plug in the keyboard and the keyboard driver prints a perfect string 
>> onto the serial console.
>>
>> I've looked through the code to see what type of initialization init is 
>> doing to the console, but it doesn't look like it is re-initializing the 
>> sucker at all.  The only thing that I can think is that BusyBox is doing 
>> something that Linux doesn't do to interact with the ttyS0 so I'm not 
>> getting what I expect.
>>     
>
> IIRC busybox's init doesn't do anything special for serial lines.
>
> As vda already suggested, better seek help on lkml or try to find
> somebody to whom that <char><space><char>.. pattern sounds familiar.
>   
Found the problem.  Wasn't a bug in BusyBox, wasn't that I didn't know 
what I was doing either.  Found that the computer that has the UART 
16550A is configured such that the serial detection algorithm of Linux 
didn't see it as a 16550A, but a 16750.  Difference being that the 
16550A has a 16-Byte buffer, whereas the 16750 has a 64-byte buffer.  
The kernel, using the 16750 command set, waited for the buffer to get 
full, thus anything written to the serial line was getting trashed.  I 
have modified my kernel, for this specific computer, to "manually" set 
the kernel to 16550A as the serial interface.

So, with BusyBox's init, an inittab line of "ttyS0::respawn:-/bin/sh", 
and a kernel command line parameter of "console=ttyS0,115200n8" I get a 
nice, shiny, WORKING console and terminal on the serial port.

Thanks to all you that helped me with issue as your support led me to 
the underlying hardware issue.

Andy Kennedy


From ynakam at hitachisoft.jp  Thu Feb 15 07:37:01 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Thu, 15 Feb 2007 16:37:01 +0900
Subject: [PATCH 6/6] busybox -- SELinux option support for coreutils
In-Reply-To: <20070208155456.2d016051.ynakam@hitachisoft.jp>
References: <20070208155456.2d016051.ynakam@hitachisoft.jp>
Message-ID: <20070215163701.21d93627.ynakam@hitachisoft.jp>

On Thu, 8 Feb 2007 15:54:56 +0900
Yuichi Nakamura  wrote:

> [6/6] busybox-coreutils-06-id.patch
>  - -Z option support for id. Security context of process is shown by -Z option.
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> 
> 
> 

We found that -Z,-u,-g are exclusive, and modified previous patch.
Please review attached patch.

-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-id-06.v2.patch
Type: application/octet-stream
Size: 2727 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070215/6caa4bfd/attachment-0002.obj 

From vda.linux at googlemail.com  Thu Feb 15 20:45:01 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 15 Feb 2007 21:45:01 +0100
Subject: Possible Bug, or Possibly don't know what I'm doing.
In-Reply-To: <45D4880F.7030607@techmoninc.com>
References: <45C0EA70.4080508@techmoninc.com> <20070209211142.GY12488@aon.at>
	<45D4880F.7030607@techmoninc.com>
Message-ID: <200702152145.01126.vda.linux@googlemail.com>

On Thursday 15 February 2007 17:19, Andy Kennedy wrote:
> Bernhard Fischer wrote:
> > On Fri, Feb 09, 2007 at 01:45:33PM -0600, Andy Kennedy wrote:
> >   
> >> Andy Kennedy wrote:
> >>     
> >>> To restate my problem (in case some kind developer decides to help me):
> >>>
> >>> When I have the kernel command line parameter "console=ttyS0,115200n8" 
> >>> I get nice neat output on the serial line up until the init runs.  As 
> >>> soon as init runs, I get missing chars.  So, I replace the BusyBox 
> >>> init with minit, compiled from source and using the uCLibC gcc that I 
> >>> let buildroot make for me.  Same problem.  For some reason, when the 
> >>> system initializes -- after the kernel has reported all of its output, 
> >>> my serial console goes splat.  When I initialize the console using 
> >>> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
> >>> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
> >>> One of these letters will appear each time I send enter.
> >>>
> >>> I have tried everything I can think of.  There is no script setting 
> >>> any of the line speeds -- in fact, I have even attempted to remove the 
> >>> scripts and still get the same thing.  Removing the 
> >>> console=ttyS0,115200n8 (or attempting any variant of it) has no 
> >>> affect, except without the console= I get no good output on the line.  
> >>> The only thing I haven't attempted yet is to replace the getty with an 
> >>> equivalent to see if that makes a difference.  I have also tried 9600, 
> >>> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
> >>> every combination, but I still cannot get a serial console.
> >>>
> >>> Can anyone offer a suggestion as to how I might fix this -- or some 
> >>> other place to start?
> >>>
> >>> Thanks in advance for any help you can offer,
> >>> Andy
> >>>       
> >> Okay, now I'm really confused.  Here is what I have done so far:
> >> Made my laptop boot with a console on ttyS0 and put a login shell on it 
> >> (to verify that I can do it -- I was beginning to think maybe I needed 
> >> to remove Linux from my computer and get rid of all of  it being to 
> >> stupid to own a computer, much less program an embedded system) and I 
> >> had no problems.  So, I took my syslinux disk and booted from it (the 
> >> SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
> >> everything comes up as you would expect.
> >>
> >> Given that this test worked there is one of about three possibilities:
> >> 1) Cable issue.  Tested my serial cable on another embedded system (an 
> >> Arcom Viper), checks out.  Replaced the break-out cable from the 
> >> embedded system -- failed.  Tried a known good cable -- failed.  Tested 
> >> a different VersaLogic board -- failed.  Now, here is the part that 
> >> really yanked me around:
> >>
> >> The last time I booted the machine I didn't have the keyboard connected 
> >> to the break-out cable.  The boot went as it normally does except the 
> >> keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
> >> BusyBox init takes over the console and prints all kind of whack.  I 
> >> plug in the keyboard and the keyboard driver prints a perfect string 
> >> onto the serial console.
> >>
> >> I've looked through the code to see what type of initialization init is 
> >> doing to the console, but it doesn't look like it is re-initializing the 
> >> sucker at all.  The only thing that I can think is that BusyBox is doing 
> >> something that Linux doesn't do to interact with the ttyS0 so I'm not 
> >> getting what I expect.
> >>     
> >
> > IIRC busybox's init doesn't do anything special for serial lines.
> >
> > As vda already suggested, better seek help on lkml or try to find
> > somebody to whom that <char><space><char>.. pattern sounds familiar.
> >   
> Found the problem.  Wasn't a bug in BusyBox, wasn't that I didn't know 
> what I was doing either.  Found that the computer that has the UART 
> 16550A is configured such that the serial detection algorithm of Linux 
> didn't see it as a 16550A, but a 16750.  Difference being that the 
> 16550A has a 16-Byte buffer, whereas the 16750 has a 64-byte buffer.  
> The kernel, using the 16750 command set, waited for the buffer to get 
> full, thus anything written to the serial line was getting trashed.  I 
> have modified my kernel, for this specific computer, to "manually" set 
> the kernel to 16550A as the serial interface.

In case you will try to submit permanent fix for this into
mainlike kernel - I think that the only place where kernel
can decide that it is a 16750 is here:

drivers/serial/816:8250.c

        /*
         * No EFR.  Try to detect a TI16750, which only sets bit 5 of
         * the IIR when 64 byte FIFO mode is enabled when DLAB is set.
         * Try setting it with and without DLAB set.  Cheap clones
         * set bit 5 without DLAB set.
         */
        serial_outp(up, UART_LCR, 0);
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
        status1 = serial_in(up, UART_IIR) >> 5;
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
        serial_outp(up, UART_LCR, UART_LCR_DLAB);
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
        status2 = serial_in(up, UART_IIR) >> 5;
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
        serial_outp(up, UART_LCR, 0);

        DEBUG_AUTOCONF("iir1=%d iir2=%d ", status1, status2);

        if (status1 == 6 && status2 == 7) {
                up->port.type = PORT_16750;
                up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
                return;
        }
--
vda


From rob at landley.net  Thu Feb 15 21:44:15 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 16:44:15 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702140800.33665.vapier@gentoo.org>
References: <200702140800.33665.vapier@gentoo.org>
Message-ID: <200702151644.15320.rob@landley.net>

On Wednesday 14 February 2007 8:00 am, Mike Frysinger wrote:
> so i started to add a df build option, "ignore initramfs mount", that would 
> control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> that in embedded/bootable systems, it is common to run right out of the 
> initramfs rather than switching over to a "normal" root
> 
> however, i cant decide whether this warrants an actual build option ... the 
> trade offs are that in the desktop case, you'd never want to see the rootfs 
> output ... but does controlling literally 2 lines of code offset this ?

Look at the df I did in toybox.  I filter out overmounts (which hides 
initramfs if something's mounted over it but doesn't treat it specially), and 
I filter out mount points that have a total capacity (not free space) of zero 
(which nukes things like /proc and /sys).

> -mike

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery


From rob at landley.net  Thu Feb 15 21:46:23 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 16:46:23 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702142151.39680.vda.linux@googlemail.com>
References: <200702140800.33665.vapier@gentoo.org>
	<200702142151.39680.vda.linux@googlemail.com>
Message-ID: <200702151646.23104.rob@landley.net>

On Wednesday 14 February 2007 3:51 pm, Denis Vlasenko wrote:
> On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> > so i started to add a df build option, "ignore initramfs mount", that 
would 
> > control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> > that in embedded/bootable systems, it is common to run right out of the 
> > initramfs rather than switching over to a "normal" root
> > 
> > however, i cant decide whether this warrants an actual build option ... 
the 
> > trade offs are that in the desktop case, you'd never want to see the 
rootfs 
> > output ... but does controlling literally 2 lines of code offset this ?
> 
> I don't know what is a rationale for hiding that. It _is_ mounted there, 
right?
> So why we are lying to user that it isn't there?

Because 99% of the time something's mounted over it, so it's not an accessible 
mount point.  The knee jerk reaction was to hide initramfs specifically, but 
the general problem is actually mount points that aren't accessible because 
something else is mounted over them.

The logic to getting this to work right was nontrivial.  I was working on it 
while I was still doing busybox work, and I got a finished implementation of 
the way I think it should work into toybox months ago.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery


From rob at landley.net  Thu Feb 15 21:51:04 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 16:51:04 -0500
Subject: stop ignoring initramfs in df ?
In-Reply-To: <200702142151.39680.vda.linux@googlemail.com>
References: <200702140800.33665.vapier@gentoo.org>
	<200702142151.39680.vda.linux@googlemail.com>
Message-ID: <200702151651.04287.rob@landley.net>

On Wednesday 14 February 2007 3:51 pm, Denis Vlasenko wrote:
> On Wednesday 14 February 2007 14:00, Mike Frysinger wrote:
> > so i started to add a df build option, "ignore initramfs mount", that 
would 
> > control the hardcoded filter in df.c for the "rootfs" mount ... idea being 
> > that in embedded/bootable systems, it is common to run right out of the 
> > initramfs rather than switching over to a "normal" root
> > 
> > however, i cant decide whether this warrants an actual build option ... 
the 
> > trade offs are that in the desktop case, you'd never want to see the 
rootfs 
> > output ... but does controlling literally 2 lines of code offset this ?
> 
> I don't know what is a rationale for hiding that. It _is_ mounted there, 
right?
> So why we are lying to user that it isn't there?
> 
> In my opinion we should just remove this feature.

P.S.

http://landley.net/notes-2006.html#28-10-2006
and
http://landley.net/notes-2006.html#29-10-2006

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery


From rob at landley.net  Thu Feb 15 22:02:46 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 17:02:46 -0500
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171375130.2437.36.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122328.33155.vda.linux@googlemail.com>
	<1171375130.2437.36.camel@albrecht.rdi1.com>
Message-ID: <200702151702.46730.rob@landley.net>

On Tuesday 13 February 2007 8:58 am, Paul Albrecht wrote:
> However, I still think that because the read syscall is unbuffered you
> can't assume that if you write x bytes to one end of the pipe you're
> guaranteed x bytes on the *first* read on the other end of the pipe.

http://www.opengroup.org/onlinepubs/009695399/functions/write.html

  After a write() to a regular file has successfully returned:
    o Any successful read() from each byte position in the file that was
      modified by that write shall return the data specified by the write()
      for that position until such byte positions are again modified.

  Write requests to a pipe or FIFO shall be handled in the same way as a
  regular file with the following exceptions:
    o There is no file offset associated with a pipe, hence each write request
      shall append to the end of the pipe.
    o Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
      data from other processes doing writes on the same pipe.

Yes, you can.

> I think you're supposed to check the number of bytes read and continue
> doing reads until you get as much data as you're expecting or get end of
> file.

A pipe is attached to a kernel buffer which his updated atomically by write() 
and read() syscalls.  There is _cannot_ be any propogation delay, nor partial 
writes of less than PIPE_BUF, in an SUSv3 compliant pipe implementation.  The 
spec says so.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery


From albrecht at rdi1.com  Thu Feb 15 21:53:13 2007
From: albrecht at rdi1.com (Paul Albrecht)
Date: Thu, 15 Feb 2007 16:53:13 -0500
Subject: Must really be safe_read(),not full_read()? (was: [PATCH] fix
	httpd lockup in cgi POSTs)
In-Reply-To: <1171573780.2839.0.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<200702122328.33155.vda.linux@googlemail.com>
	<1171375130.2437.36.camel@albrecht.rdi1.com>
	<1171573780.2839.0.camel@albrecht.rdi1.com>
Message-ID: <1171576393.2985.31.camel@albrecht.rdi1.com>

On Thu, 2007-02-15 at 17:02 -0500, Rob Landley wrote:
> On Tuesday 13 February 2007 8:58 am, Paul Albrecht wrote:
> > However, I still think that because the read syscall is unbuffered you
> > can't assume that if you write x bytes to one end of the pipe you're
> > guaranteed x bytes on the *first* read on the other end of the pipe.
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/write.html
> 
>   After a write() to a regular file has successfully returned:
>     o Any successful read() from each byte position in the file that was
>       modified by that write shall return the data specified by the write()
>       for that position until such byte positions are again modified.
> 
>   Write requests to a pipe or FIFO shall be handled in the same way as a
>   regular file with the following exceptions:
>     o There is no file offset associated with a pipe, hence each write request
>       shall append to the end of the pipe.
>     o Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
>       data from other processes doing writes on the same pipe.
> 
> Yes, you can.
> 

Thanks for clarifying what the standard is for pipes, but this doesn't
really help much because it's a fact that busybox httpd fails
intermittently when the I run a simple cgi script to redirect a request.

It doesn't seem to me to do much good to fall back on a standard if the
it isn't applicable in the real world. The user receiving garbage back
from a web server doesn't really care if the server is standard
conforming or not.

> > I think you're supposed to check the number of bytes read and continue
> > doing reads until you get as much data as you're expecting or get end of
> > file.
> 
> A pipe is attached to a kernel buffer which his updated atomically by write() 
> and read() syscalls.  There is _cannot_ be any propogation delay, nor partial 
> writes of less than PIPE_BUF, in an SUSv3 compliant pipe implementation.  The 
> spec says so.

Again, it's a fact that a simple cgi program that returns status back to
the busybox httpd server will intermittently fail in the manner I have
previously described.

If you're suggesting the it's a kernel bug perhaps you should post it to
the linux kernel mailing list because that's what I'm using for an
operating system.


From rob at landley.net  Thu Feb 15 23:01:13 2007
From: rob at landley.net (Rob Landley)
Date: Thu, 15 Feb 2007 18:01:13 -0500
Subject: Must really be safe_read(),
	not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)
In-Reply-To: <1171576393.2985.31.camel@albrecht.rdi1.com>
References: <1171293909.3280.0.camel@albrecht.rdi1.com>
	<1171573780.2839.0.camel@albrecht.rdi1.com>
	<1171576393.2985.31.camel@albrecht.rdi1.com>
Message-ID: <200702151801.13634.rob@landley.net>

On Thursday 15 February 2007 4:53 pm, Paul Albrecht wrote:
> Thanks for clarifying what the standard is for pipes, but this doesn't
> really help much because it's a fact that busybox httpd fails
> intermittently when the I run a simple cgi script to redirect a request.
> 
> It doesn't seem to me to do much good to fall back on a standard if the
> it isn't applicable in the real world. The user receiving garbage back
> from a web server doesn't really care if the server is standard
> conforming or not.

I didn't say there wasn't a bug, just that it's not in the Linux pipe 
implementation. :)

> Again, it's a fact that a simple cgi program that returns status back to
> the busybox httpd server will intermittently fail in the manner I have
> previously described.

Taking a wild guess without actually looking at the httpd code: nobody said 
that sigchild's delivery had to be delayed until a process that performs a 
blocking read gets scheduled again, just that if you do a read _after_ 
getting sigchild you should get all pending data in one gulp (or EOF).

> If you're suggesting the it's a kernel bug perhaps you should post it to
> the linux kernel mailing list because that's what I'm using for an
> operating system.

I'm not suggesting it's a kernel bug.  Lots and lots of other people would 
have hit it by now.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery


From tsattler at gmx.de  Fri Feb 16 01:26:03 2007
From: tsattler at gmx.de (Thomas Sattler)
Date: Fri, 16 Feb 2007 02:26:03 +0100
Subject: sort broken when using more than one -k's
Message-ID: <20070216012603.GA8224@nancy.sattler.local>

Hi there ...

Current busybox (1.4.1) seems to be broken in applet sort when more
than one -k's are used:

The example on http://www.busybox.net/downloads/BusyBox.html says

> $ echo -e "c 3\nb 2\nd 2" | sort -k 2,2n -k 1,1r

should result in

> d 2
> b 2
> c 3

which is what my (coreutils-6.4) sort does. busybox sort produces this:

> $ echo -e "c 3\nb 2\nd 2" | ./busybox sort -k 2,2n -k 1,1r
> d 2
> c 3
> b 2

Thomas Sattler

-- 
keep mailinglists in english, feel free to send PM in german


From christopher.fanning at gmail.com  Fri Feb 16 10:11:05 2007
From: christopher.fanning at gmail.com (Chris Fanning)
Date: Fri, 16 Feb 2007 11:11:05 +0100
Subject: nfsmount, rpc failed: 2
Message-ID: <215ff4410702160211p75d6f252we42f38eef53f19bf@mail.gmail.com>

Hello,

I am getting an error when using nfsmount.
nfsmount host:/export mountpoint
rpc failed: 2

I've looked about on the net and can't see anything about "rcp failed: 2"
I can mount this same export from another machine so I don't think
it's a server problem.

What does "rpc failed: 2" mean?

Thanks.
Chris.


From parmarsatpal at gmail.com  Fri Feb 16 10:48:00 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Fri, 16 Feb 2007 16:18:00 +0530
Subject: linux 2.6.18.2 with GCC 4.1.1 shell not coming
Message-ID: <457d2dc30702160248h30f4a51do10c3c4d4d535ca85@mail.gmail.com>

Hi all ;

 I am facing some  problem in porting linux kernel 2.6.18. I went through
some mailing list,archives and find mails refering exactly the problem I am
facing but unfortunetly I didnt get any working hints or solutions.I am
wondering if what I am facing is a known issue for embeded community. I
apprecaite if someone can  share hsi/her experinece on this isue.

*Problem:* We are porting linux-2.6.18.2 on ARM based chip, with
toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
init.c, before the shell comes up.

I have traced the problem and it seems to be that i don't recover from
the function console_init (in file init.c) .

Same kernel and rootfile system works fine when I compile with  with
gcc-4.0.3 toolchain (without EABI).So I cannot doubt UART interrupt, or
console driver.

*following mail list similar problem without  any clues:*

http://buildroot.uclibc.org/lists/buildroot/2007-February/001516.html

http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021541.html


here is my log;



Waiting for image to be downloaded via ICE...

Linux version 2.6.18.2 (sainin at bmpbuild2.noida.conexant.com) (gcc version
4.1.1)

 #2 Fri Feb 16 15:44:48 IST 2007

CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177

Machine: Conexant Edwards-Based IRD

Memory policy: ECC disabled, Data cache writeback

CPU0: D VIVT write-back cache

CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

Built 1 zonelists.  Total pages: 16384

Kernel command line: console=ttyRI0 root=/dev/ram  mem=64M debug=0

PID hash table entries: 512 (order: 9, 2048 bytes)

Console: colour dummy device 80x30

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 64MB = 64MB total

Memory: 55040KB available (1112K code, 479K data, 68K init)

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like a

n initrd

Freeing initrd memory: 8192K

NetWinder Floating Point Emulator V0.97 (double precision)

Initializing Cryptographic API

io scheduler noop registered (default)

ttyRI0 at MMIO 0xe0412000 (irq = 2) is a CNXTUART

ttyRI1 at MMIO 0xe0411000 (irq = 1) is a CNXTUART

ttyRI2 at MMIO 0xe0410000 (irq = 0) is a CNXTUART

RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize

mice: PS/2 mouse device common for all mice

RAMDISK: ext2 filesystem found at block 0

RAMDISK: Loading 8092KiB [1 disk] into ram disk... done.

VFS: Mounted root (ext2 filesystem) readonly.

Freeing init memory: 68K

Hello WOrld inside init.c

before console_init

 (no shell)
Thanks for your patience and time.

Regards
satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070216/a2579e70/attachment-0001.htm 

From parmarsatpal at gmail.com  Fri Feb 16 10:44:19 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Fri, 16 Feb 2007 16:14:19 +0530
Subject: porting linux 2.6.18.1(EABI) support GCC-4.1.1(eabi) shell not coming
Message-ID: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>

Hi all ;

 I am facing some  problem in porting linux kernel 2.6.18. I went through
some mailing list,archives and find mails refering exactly the problem I am
facing but unfortunetly I didnt get any working hints or solutions.I am
wondering if what I am facing is a known issue for embeded community. I
apprecaite if someone can  share hsi/her experinece on this isue.

*Problem:* We are porting linux-2.6.18.2 on ARM based chip, with
toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
init.c, before the shell comes up.

I have traced the problem and it seems to be that i don't recover from
the function console_init (in file init.c) .

Same kernel and rootfile system works fine when I compile with  with
gcc-4.0.3 toolchain (without EABI).So I cannot doubt UART interrupt, or
console driver.

*following mail list similar problem without  any clues:*

http://buildroot.uclibc.org/lists/buildroot/2007-February/001516.html

http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021541.html


here is my log;



Waiting for image to be downloaded via ICE...

Linux version 2.6.18.2 (sainin at bmpbuild2.noida.conexant.com) (gcc version
4.1.1)

 #2 Fri Feb 16 15:44:48 IST 2007

CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177

Machine: Conexant Edwards-Based IRD

Memory policy: ECC disabled, Data cache writeback

CPU0: D VIVT write-back cache

CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets

Built 1 zonelists.  Total pages: 16384

Kernel command line: console=ttyRI0 root=/dev/ram  mem=64M debug=0

PID hash table entries: 512 (order: 9, 2048 bytes)

Console: colour dummy device 80x30

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 64MB = 64MB total

Memory: 55040KB available (1112K code, 479K data, 68K init)

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like a

n initrd

Freeing initrd memory: 8192K

NetWinder Floating Point Emulator V0.97 (double precision)

Initializing Cryptographic API

io scheduler noop registered (default)

ttyRI0 at MMIO 0xe0412000 (irq = 2) is a CNXTUART

ttyRI1 at MMIO 0xe0411000 (irq = 1) is a CNXTUART

ttyRI2 at MMIO 0xe0410000 (irq = 0) is a CNXTUART

RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize

mice: PS/2 mouse device common for all mice

RAMDISK: ext2 filesystem found at block 0

RAMDISK: Loading 8092KiB [1 disk] into ram disk... done.

VFS: Mounted root (ext2 filesystem) readonly.

Freeing init memory: 68K

Hello WOrld inside init.c

before console_init

 (no shell)
Thanks for your patience and time.

Regards
satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070216/aaec4f37/attachment-0001.htm 

From tsattler at gmx.de  Fri Feb 16 10:56:19 2007
From: tsattler at gmx.de (Thomas Sattler)
Date: Fri, 16 Feb 2007 11:56:19 +0100
Subject: bad *sign file: busybox-1.4.1.tar.bz2.sign
Message-ID: <20070216105619.GA5754@nancy.sattler.local>

Hi there ...

http://www.busybox.net/downloads/busybox-1.4.1.tar.bz2.sign contains a
bad md5 checksum. Not that the checksum does not match, it's just not a
md5 checksum (md5 checksums consist of [0-9a-z] only):

5728403RSU309STQRSVVQ414U2U64052  busybox-1.4.1.tar.bz2

I computed the checksum myself which is

5728403bce309cdabcffa414e2e64052  busybox-1.4.1.tar.bz2

Note that this is identical in respect of the digits.

Thomas

-- 
keep mailinglists in english, feel free to send PM in german


From iggarpe at terra.es  Fri Feb 16 11:20:16 2007
From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=)
Date: Fri, 16 Feb 2007 12:20:16 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1
Message-ID: <45D59370.6090204@terra.es>

See attached patch.

Would be nice to rewrite the option parsing code to make use of the 
libbb functions.

Regards.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-slattach.diff
Url: http://lists.busybox.net/pipermail/busybox/attachments/20070216/dd654357/attachment-0002.diff 

From iggarpe at terra.es  Fri Feb 16 11:21:57 2007
From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=)
Date: Fri, 16 Feb 2007 12:21:57 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1 (this is the GOOD one)
Message-ID: <45D593D5.9070507@terra.es>

Sorry, attached the wrong patch in previous message. This is the good one.

As I already said, would be nice to rewrite the option parsing code to 
make use of the libbb functions.

Regards.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.4.1-slattach.patch
Url: http://lists.busybox.net/pipermail/busybox/attachments/20070216/d3a5931e/attachment.diff 

From tsattler at gmx.de  Fri Feb 16 11:54:01 2007
From: tsattler at gmx.de (Thomas Sattler)
Date: Fri, 16 Feb 2007 12:54:01 +0100
Subject: sort broken when using more than one -k's
In-Reply-To: <20070216012603.GA8224@nancy.sattler.local>
References: <20070216012603.GA8224@nancy.sattler.local>
Message-ID: <20070216115401.GA9027@nancy.sattler.local>

Hi again ...

I checked busybox releases: They all work, until (and including)
busybox-1.3.2, since busybox-1.4.0 sort is broken.

Available snapshots seem all to be broken. So the change in the
sources must be older than 20070117.

HTH
Thomas

-- 
keep mailinglists in english, feel free to send PM in german


From rep.dot.nop at gmail.com  Fri Feb 16 13:23:28 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Fri, 16 Feb 2007 14:23:28 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1 (this is the GOOD one)
In-Reply-To: <45D593D5.9070507@terra.es>
References: <45D593D5.9070507@terra.es>
Message-ID: <20070216132328.GA28870@aon.at>

On Fri, Feb 16, 2007 at 12:21:57PM +0100, Ignacio Garc?a P?rez wrote:
>Sorry, attached the wrong patch in previous message. This is the good one.
>
>As I already said, would be nice to rewrite the option parsing code to 
>make use of the libbb functions.
>
>Regards.
>
>
>

>diff -urN busybox-1.4.1/include/applets.h busybox-1.4.1-modified/include/applets.h
>--- busybox-1.4.1/include/applets.h	2007-01-24 22:34:48.000000000 +0100
>+++ busybox-1.4.1-modified/include/applets.h	2007-02-16 11:45:33.000000000 +0100
>@@ -262,6 +262,7 @@
> USE_FEATURE_SH_IS_LASH(APPLET_NOUSAGE(sh, lash, _BB_DIR_BIN, _BB_SUID_NEVER))
> USE_FEATURE_SH_IS_MSH(APPLET_NOUSAGE(sh, msh, _BB_DIR_BIN, _BB_SUID_NEVER))
> USE_SHA1SUM(APPLET_ODDNAME(sha1sum, md5_sha1_sum, _BB_DIR_USR_BIN, _BB_SUID_NEVER, sha1sum))
>+USE_SLATTACH(APPLET(slattach, _BB_DIR_SBIN, _BB_SUID_NEVER))
> USE_SLEEP(APPLET(sleep, _BB_DIR_BIN, _BB_SUID_NEVER))
> USE_SOFTLIMIT(APPLET_ODDNAME(softlimit, chpst, _BB_DIR_USR_BIN, _BB_SUID_NEVER, softlimit))
> USE_SORT(APPLET(sort, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
>diff -urN busybox-1.4.1/include/usage.h busybox-1.4.1-modified/include/usage.h
>--- busybox-1.4.1/include/usage.h	2007-01-24 22:34:48.000000000 +0100
>+++ busybox-1.4.1-modified/include/usage.h	2007-02-16 11:44:10.000000000 +0100
>@@ -2788,6 +2788,20 @@
>        "	-s	Don't output anything, status code shows success\n" \
>        "	-w	Warn about improperly formatted SHA1 checksum lines")
> 
>+#define slattach_trivial_usage \
>+	"[-cehmLF] [-s speed] [-p protocol] DEVICEs"
>+#define slattach_full_usage \
>+	"Attach network interface(s) to serial line(s).\n" \
>+	"Options:\n" \
>+	"\t-p\tset a specific kind of protocol (slip, cslip, slip6, clisp6 or adaptive).\n" \
>+	"\t-s\tset a specific line speed.\n"
>+	"\t-c\texecute a command when the line is hung up\n" \
>+	"\t-e\texit right after initializing device.\n" \
>+	"\t-h\texit when the carrier is lost.\n" \
>+	"\t-m\tdo NOT initialize the line in raw 8 bits mode.\n" \
>+	"\t-L\tenable 3-wire operation.\n" \
>+	"\t-F\tdisable RTS/CTS flow control.\n" \
>+ 
> #define sleep_trivial_usage \
> 	USE_FEATURE_FANCY_SLEEP("[") "N" USE_FEATURE_FANCY_SLEEP("]...")
> #define sleep_full_usage \
>diff -urN busybox-1.4.1/networking/Config.in busybox-1.4.1-modified/networking/Config.in
>--- busybox-1.4.1/networking/Config.in	2007-01-24 22:34:34.000000000 +0100
>+++ busybox-1.4.1-modified/networking/Config.in	2007-02-16 11:47:50.000000000 +0100
>@@ -523,6 +523,12 @@
> 	help
> 	  Route displays or manipulates the kernel's IP routing tables.
> 
>+config SLATTACH
>+	bool "slattach"
>+	default n
>+	help
>+	  Slattach is a small utility to attach network interfaces to serial lines.
>+
> config TELNET
> 	bool "telnet"
> 	default n
>diff -urN busybox-1.4.1/networking/Kbuild busybox-1.4.1-modified/networking/Kbuild
>--- busybox-1.4.1/networking/Kbuild	2007-01-24 22:34:34.000000000 +0100
>+++ busybox-1.4.1-modified/networking/Kbuild	2007-02-16 11:38:37.000000000 +0100
>@@ -32,6 +32,7 @@
> lib-$(CONFIG_PING)         += ping.o
> lib-$(CONFIG_PING6)        += ping6.o
> lib-$(CONFIG_ROUTE)        += route.o
>+lib-$(CONFIG_SLATTACH)     += slattach.o
> lib-$(CONFIG_TELNET)       += telnet.o
> lib-$(CONFIG_TELNETD)      += telnetd.o
> lib-$(CONFIG_TFTP)         += tftp.o
>diff -urN busybox-1.4.1/networking/slattach.c busybox-1.4.1-modified/networking/slattach.c
>--- busybox-1.4.1/networking/slattach.c	1970-01-01 01:00:00.000000000 +0100
>+++ busybox-1.4.1-modified/networking/slattach.c	2007-02-16 12:03:18.000000000 +0100
>@@ -0,0 +1,266 @@
>+/*
>+ *		Stripped down version of net-tools for busybox.
>+ *
>+ *		Author: Ignacio Garcia Perez (iggarpe at gmail dot com)
>+ *
>+ *		License: GPLv2 or later, see LICENSE file in this tarball.
>+ *
>+ *		There are some differences from the standard net-tools slattach:
>+ *
>+ *		- The -l option is not supported.
>+ *
>+ *		- Several devices can be specified in the command line. This is
>+ *		  very useful if you are handling many identical serial lines since
>+ *		  only one process is necessary to configure them all.
>+ *
>+ *		- The -F options allows disabling of RTS/CTS flow control.
>+ *
>+ */
>+
>+#include <unistd.h>
>+#include <stdlib.h>
>+#include <string.h>
>+#include <stdio.h>
>+#include <signal.h>
>+#include <errno.h>
>+#include <sys/socket.h>
>+#include <sys/types.h>
>+#include <sys/stat.h>
>+#include <fcntl.h>
>+#include <termios.h>
>+#include <sys/ioctl.h>
>+
>+#include "libbb.h"
>+
>+struct tty {
>+	const char *	device;
>+	int				handle;
>+	int				saved_disc;
>+	struct termios	saved_state;
>+	struct tty *	next;
>+};
>+
>+static struct tty *_tty_head = NULL;
>+static struct tty *_tty_tail = NULL;
>+
>+/* Line discipline code table */
>+
>+static struct { const char *name; int code; } _proto [] = {
>+	{ "slip",		0 },
>+	{ "cslip",		1 },
>+	{ "slip6",		2 },
>+	{ "cslip6",		3 },
>+	{ "adaptive",	8 },
>+	{ NULL }
>+};
>+
>+/*
>+ * Save tty state and line discipline
>+ */
>+
>+static int _save_state (struct tty *t) {
>+
>+	if (t->handle < 0) return 0;
>+
>+	if (tcgetattr(t->handle, &t->saved_state) < 0)			/* Save line status */
>+		{ bb_perror_msg("get state"); return -1; }
>+
>+	if (ioctl(t->handle, TIOCGETD, &t->saved_disc) < 0)		/* Save line discipline */
>+		{ bb_perror_msg("get discipline"); return -1; }
>+
>+	return 0;
>+}
>+
>+/*
>+ * Set tty state, line discipline and encapsulation
>+ */
>+
>+static int _set_state (struct tty *t, struct termios *state, int encap) {
>+
>+	int disc = N_SLIP;
>+
>+	if (t->handle < 0) return 0;
>+
>+	if (tcsetattr(t->handle, TCSANOW, state) < 0)			/* Set line status */
>+		{ bb_perror_msg("set state"); return -1; }
>+
>+	if (ioctl(t->handle, TIOCSETD, &disc) < 0)				/* Set line discliple (N_SLIP always) */
>+		{ bb_perror_msg("set discipline"); return -1; }
>+
>+	if (ioctl(t->handle, SIOCSIFENCAP, &encap) < 0)			/* Set encapsulation (SLIP, CSLIP, etc) */
>+		{ bb_perror_msg("set encapsulation"); return -1; }
>+
>+	return 0;
>+}
>+
>+/*
>+ * Restore state and line discipline for ALL managed ttys
>+ *
>+ * Restoring ALL managed ttys is the only way to have a single
>+ * hangup delay.
>+ *
>+ */
>+
>+static int _restore_state_and_close (void) {
>+
>+	struct tty *t;
>+	struct termios state;
>+
>+	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>+
>+		if (ioctl(t->handle, TIOCSETD, &t->saved_disc) < 0)			/* Restore line discipline */
>+			{ bb_perror_msg("set discipline"); return -1; }
>+
>+		memcpy(&state, &t->saved_state, sizeof(state));				/* Hangup */
>+		cfsetispeed(&state, B0);
>+		cfsetospeed(&state, B0);
>+		if (tcsetattr(t->handle, TCSANOW, &state) < 0)
>+			{ bb_perror_msg("set state"); return -1; }
>+	}
>+
>+	sleep(1);	/* The sleep time does not depend on the number of managed ttys */
>+
>+	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>+
>+		if (tcsetattr(t->handle, TCSANOW, &t->saved_state) < 0)		/* Restore line status */
>+			{ perror("set state"); return -1; }
>+
>+		close(t->handle); t->handle = -1;
>+	}
>+
>+	return 0;
>+}
>+
>+static void _sig_handler (int signo) {
>+	if (_restore_state_and_close() < 0) sleep_and_die();
>+	exit(0);
>+}
>+
>+int slattach_main (int argc, char **argv) {
>+
>+	int i, encap;
>+	struct tty *t;
>+	struct termios state;
>+	char buf [PATH_MAX];

That's a large buffer, imho. xmalloc() or make it
RESERVE_CONFIG_BUFFER(buf,PATH_MAX)

>+
>+	const char *proto = "cslip";	/* Protocol */
>+	const char *extcmd = NULL;		/* Command to execute after hangup */
>+
>+	int baud = -1;		/* Line baud rate (value) */
>+	int baud_code = -1;	/* Line baud rate (system code) */
>+	int local = 0;		/* Local mode (disable carrier watch) */
>+	int quit = 0;		/* Initialize and exit */
>+	int watch = 0;		/* watch for line hangup */
>+	int raw = 1;		/* Initialize line in raw 8 bit mode */
>+	int flow = 1;		/* Disable RTS/CTS flow control (not in net-tools slattach !!!) */

most of these should use one variable and mask their bits in.
>+
>+	/* Parse command line options */
>+	/* TODO: use bb lib getopt_whatever? */

getopt32, yes.

The block below is just too bloated.
>+
>+	for (i = 1; i < argc; i++) {
>+
>+		if (argv[i][0] == '-') switch (argv[i][1]) {
>+			case 'p': proto = argv[++i]; break;
>+			case 's': baud = atoi(argv[++i]); break;
>+			case 'c': extcmd = argv[++i]; break;
>+			case 'e': quit = 1; break;
>+			case 'h': watch = 1; break;
>+			case 'm': raw = 0; break;
>+			case 'L': local = 1; break;
>+			case 'F': flow = 0; break;
>+			default: bb_error_msg_and_die("invalid option %s", argv[i]);
>+		}
>+
>+		else {
>+			t = (struct tty *)malloc(sizeof(struct tty));
>+			if (t == NULL) bb_error_msg_and_die("not enough memory");

No. xmalloc() instead

>+
>+			t->device = argv[i];
>+			t->handle = -1;
>+			t->next = NULL;
>+
>+			if (_tty_head == NULL) _tty_head = _tty_tail = t;
>+			else { _tty_tail->next = t; _tty_tail = t; }
>+		}
>+	}
>+
>+	if (_tty_head == NULL) bb_show_usage();
>+
>+	for (i = 0; _proto[i].name != NULL; i++)
>+		if (!strcmp(_proto[i].name, proto)) break;

index_in_str_array() instead

>+	if (_proto[i].name == NULL) bb_error_msg_and_die("invalid protocol %s", proto);
>+	encap = _proto[i].code;
>+
>+	baud_code = tty_value_to_baud(baud);
>+	if (baud_code < 0) bb_error_msg_and_die("invalid baud rate %i", baud);
>+
>+	/* Trap signals in order to restore tty states upon exit */
>+
>+	if (!quit) {
>+		signal(SIGHUP, _sig_handler);
>+		signal(SIGINT, _sig_handler);
>+		signal(SIGQUIT, _sig_handler);
>+		signal(SIGTERM, _sig_handler);
>+	}
>+
>+	/* Configure ttys */
>+
>+	for (t = _tty_head; t != NULL; t = t->next) {
>+
>+		t->handle = open(t->device, O_RDWR | O_NDELAY);
>+		if (t->handle < 0) {
>+			snprintf(buf, sizeof(buf), "/dev/%s", t->device);

concat_path_file() instead. Should make that huge buf from above
superfluous.

>+			t->handle = open(buf, O_RDWR | O_NDELAY);
>+			if (t->handle < 0) bb_perror_msg_and_die("open %s", t->device);
>+		}
>+
>+		if (_save_state(t) < 0) sleep_and_die();
>+
>+		memcpy(&state, &t->saved_state, sizeof(state));
>+
>+		if (raw) {
>+			memset(&state.c_cc, 0, sizeof(state.c_cc));
>+			state.c_cc[VMIN]	= 1;
>+			state.c_iflag		= IGNBRK | IGNPAR;
>+			state.c_oflag		= 0;
>+			state.c_lflag		= 0;
>+			state.c_cflag		= CS8 | HUPCL | CREAD
>+								| (local ? CLOCAL : 0) | (flow ? CRTSCTS : 0);
>+		}
>+
>+		if (baud_code >= 0) {

Didn't we check above that boud_rate not is < 0 above? drop it then.

>+			cfsetispeed(&state, baud_code);
>+			cfsetospeed(&state, baud_code);
>+		}
>+
>+		if (_set_state(t, &state, encap) < 0)
>+			{ _restore_state_and_close(); sleep_and_die(); }
>+	}
>+
>+	/* Exit now if option -e was passed */
>+
>+	if (quit) exit(0);
>+
>+	/* Watch line for hangup */
>+
>+	for (;;) {
>+
>+		if (watch)
>+			for (t = _tty_head; t != NULL; t = t->next)
>+				if (ioctl(t->handle, TIOCMGET, &i) < 0 || !(i & TIOCM_CAR))
>+					quit = 1;
>+
>+		if (quit) break;

would a while (!option_mask32 & QUIT) be smaller?

>+		sleep(15);
>+	}
>+
>+	/* Execute command on hangup */
>+
>+	if (extcmd != NULL) system(extcmd);
>+
>+	/* Restore states and exit */
>+
>+	_restore_state_and_close();
>+	return 0;
>+}
>+


From natanael.copa at gmail.com  Fri Feb 16 22:45:37 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 16 Feb 2007 23:45:37 +0100
Subject: serial console and log-in
Message-ID: <1171665937.2696.252.camel@localhost>

Hi,

>From the serial console kernel documentation:

 If no console device is specified, the first device found capable of
 acting as a system console will be used. At this time, the system
 first looks for a VGA card and then for a serial port. So if you don't
 have a VGA card in your system the first serial port will automatically
 become the console.

Is there some way to autodetect if the console is a serial console, and
if it is, activate a line like this in inittab:

ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100

And if /dev/console is not a serial console, it will not activate any
getty on the serial console.

The current problem is, that even if console goes to serial port so I
can see the kernel messages and bootscript output, busybox init will
never give a login from inittab unless the previous line is there.

But I'd prefer not to turn it on by default, in case somebody happen to
have something sensitive attatched to the serial port when running my
distro as rescue cd for example.

Natanael Copa



From vda.linux at googlemail.com  Sat Feb 17 00:39:09 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 01:39:09 +0100
Subject: nfsmount, rpc failed: 2
In-Reply-To: <215ff4410702160211p75d6f252we42f38eef53f19bf@mail.gmail.com>
References: <215ff4410702160211p75d6f252we42f38eef53f19bf@mail.gmail.com>
Message-ID: <200702170139.10011.vda.linux@googlemail.com>

On Friday 16 February 2007 11:11, Chris Fanning wrote:
> Hello,
> 
> I am getting an error when using nfsmount.
> nfsmount host:/export mountpoint
> rpc failed: 2

nfsmount is not a part of busybox, it's a program from nfs-utils, I think.

What happens when you run busybox's mount -t nfs host:/export mountpoint?
If you get an error, consider collecting strace log too.

> I've looked about on the net and can't see anything about "rcp failed: 2"
> I can mount this same export from another machine so I don't think
> it's a server problem.
> 
> What does "rpc failed: 2" mean?

I don't know. Maybe this?

#define ENOENT           2      /* No such file or directory */

enum nfsstat {
        NFS_OK= 0,              /* no error */
        NFSERR_PERM=1,          /* Not owner */
        NFSERR_NOENT=2,         /* No such file or directory */
--
vda


From chemuduguntar at gmail.com  Sat Feb 17 02:49:27 2007
From: chemuduguntar at gmail.com (Ravi Chemudugunta)
Date: Sat, 17 Feb 2007 15:49:27 +1300
Subject: Busybox build problem
Message-ID: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>

# make allnoconfig; make

  LINK    busybox_unstripped
/home/brion/busybox-1.4.1/scripts/trylink: 5: function: not found
/home/brion/busybox-1.4.1/scripts/trylink: 11: Syntax error: "}" unexpected
make: *** [busybox_unstripped] Error 2

This error occurs on *ubuntu due to the use of dash as the default
shell (sh->dash).  the scripts included were designed with bash which
uses some non-posix extensions which dash strives to meet
(posix-ness).

cd /bin
rm sh
ln -s bash sh

The reason for including dash is speed so your system might boot
slower or not at all.

hope this helps,

ravi


From vda.linux at googlemail.com  Sat Feb 17 15:28:28 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 16:28:28 +0100
Subject: porting linux 2.6.18.1(EABI) support GCC-4.1.1(eabi) shell not
	coming
In-Reply-To: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>
References: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>
Message-ID: <200702171628.28843.vda.linux@googlemail.com>

On Friday 16 February 2007 11:44, satpal parmar wrote:
> Hi all ;
> 
>  I am facing some  problem in porting linux kernel 2.6.18. I went through
> some mailing list,archives and find mails refering exactly the problem I am
> facing but unfortunetly I didnt get any working hints or solutions.I am
> wondering if what I am facing is a known issue for embeded community. I
> apprecaite if someone can  share hsi/her experinece on this isue.
> 
> *Problem:* We are porting linux-2.6.18.2 on ARM based chip, with
> toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
> We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
> init.c, before the shell comes up.
> 
> I have traced the problem and it seems to be that i don't recover from
> the function console_init (in file init.c) .

That's why I keep saying "you don't need any stinking init,
shell script will suffice". Because init has some really obscure
and ugly code (even our own init, which is *supposed to be*
small and simple).

Here we go:

static char console[CONSOLE_BUFF_SIZE] = "/dev/console";
static const char *log_console = VC_5;

static void console_init(void)
{
        int fd;
        int tried = 0;
        struct vt_stat vt;
        struct serial_struct sr;
        char *s;

        if ((s = getenv("CONSOLE")) != NULL || (s = getenv("console")) != NULL) {
                safe_strncpy(console, s, sizeof(console));
        } else {
                /* 2.2 kernels: identify the real console backend and try to use it */
                if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
                        /* this is a serial console */
                        snprintf(console, sizeof(console) - 1, SC_FORMAT, sr.line);
                } else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
                        /* this is linux virtual tty */
                        snprintf(console, sizeof(console) - 1, VC_FORMAT, vt.v_active);
                } else {
                        safe_strncpy(console, "/dev/console", sizeof(console));
                        tried++;
                }
        }

        while ((fd = open(console, O_RDONLY | O_NONBLOCK)) < 0 && tried < 2) {
                /* Can't open selected console -- try logical system console and VT_MASTER */
                safe_strncpy(console, (tried == 0 ? "/dev/console" : "/dev/tty0"), sizeof(console));
                tried++;
        }
        if (fd < 0) {
                /* Perhaps we should panic here? */
#if !ENABLE_SYSLOGD
                log_console =
#endif
                safe_strncpy(console, bb_dev_null, sizeof(console));
        } else {
		... set TERM ...
		close(fd)
	}
}

int init_main(int argc, char **argv)
{
 ...a few irrelevant things skipped...
        /* Figure out where the default console should be */
        console_init();
        /* Close whatever files are open, and reset the console. */
        close(0);
        close(1);
        close(2);
        if (device_open(console, O_RDWR | O_NOCTTY) == 0) {
                set_term();
                close(0);
        }

<bitching>
Hello? What a fsck is going on here? Why we are closing perfectly
fine open stdio desriptors which kernel gave us?
init=/bin/sh manages to work without such idiosyncrasies, why
we need a pile of this code - just for setting TERM?
</bitching>

After some grepping around:

console is = getenv("CONSOLE"/"console"), "/dev/console", "/dev/tty0"
or "/dev/null". It is used only in two places: in init_main
(shown above) and in new_init_action() is cons is "":

static void new_init_action(int action, const char *command, const char *cons)
{
        struct init_action *new_action, *a, *last;
        if (*cons == '\0')
                cons = console_name;

[cons subsequently ended up in init_action::terminal and
is used for open() and access() - not too hard to adapt
those places for just dup()ing fd#0 if we will want to fix the mess...]

Also note that 'console' is an awful variable name - grepping for it
is bound to produce tons of false positives. I think console_name is better.

log_console is vt#5 unless we failed to open getenv("CONSOLE"/"console"),
"/dev/console" and "/dev/tty0" (then console = "/dev/null"),
or if opened console turned out to be a serial line (in that case
log_console = console). log_console is used only by
message(LOG, ...) in init.c, nowhere else.

This is awfully messy.

> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing init memory: 68K
> Hello WOrld inside init.c
> before console_init
>  (no shell)
> Thanks for your patience and time.
> 
> Regards
> satpal

satpal, any chance you can pinpoint what exactly is failing
in init_console?
--
vda


From vda.linux at googlemail.com  Sat Feb 17 15:38:17 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 16:38:17 +0100
Subject: bad *sign file: busybox-1.4.1.tar.bz2.sign
In-Reply-To: <20070216105619.GA5754@nancy.sattler.local>
References: <20070216105619.GA5754@nancy.sattler.local>
Message-ID: <200702171638.17078.vda.linux@googlemail.com>

Hello Thomas,

On Friday 16 February 2007 11:56, Thomas Sattler wrote:
> http://www.busybox.net/downloads/busybox-1.4.1.tar.bz2.sign contains a
> bad md5 checksum. Not that the checksum does not match, it's just not a
> md5 checksum (md5 checksums consist of [0-9a-z] only):
> 
> 5728403RSU309STQRSVVQ414U2U64052  busybox-1.4.1.tar.bz2
> 
> I computed the checksum myself which is
> 
> 5728403bce309cdabcffa414e2e64052  busybox-1.4.1.tar.bz2
> 
> Note that this is identical in respect of the digits.

Oh no. This is a known (and already fixed) googfup on my part
regarding upper/lower case conversion. Apparently I used buggy
md5sum version when I made those files.

Corrected signatures are uploaded. Sorry.
--
vda


From m.pommerenke at avm.de  Fri Feb 16 11:15:56 2007
From: m.pommerenke at avm.de (m.pommerenke at avm.de)
Date: Fri, 16 Feb 2007 12:15:56 +0100
Subject: linux 2.6.18.2 with GCC 4.1.1 shell not coming
In-Reply-To: <457d2dc30702160248h30f4a51do10c3c4d4d535ca85@mail.gmail.com>
Message-ID: <OFBCDDFD71.59C791E7-ONC1257284.003D0ACE-C1257284.003DE2CC@avm.de>

Hi,

I had the same problem. We found out the gcc used an floating point
instruction FSTMX to push multible register onto the stack.
(on user space applications) This instruction ist not emulated by the
kernel floating point emulater.

I had configured the uclibc haveing a floating point processor. After
correcting this and rebuilding the gcc everything worked fine.


Martin Pommerenke





|-------------+--------------------------->
|             |                           |
|             | "satpal parmar"           |
|             | <parmarsatpal at gmail.com>  |
|             | Gesendet von:             |
|             | busybox-bounces at busybox.ne|
|             | t                         |
|             |                           |
|             |                           |
|             | 16.02.2007 11:48          |
|-------------+--------------------------->
  >-----------------------------------------------------------------------------------------------------------|
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  | An:                                                                                                       |
  |                                                                                                           |
  |          linux-arm-kernel at lists.arm.linux.org.uk, busybox at busybox.net, arm-gnu at codesourcery.com           |
  |                                                                                                           |
  | Kopie:                                                                                                    |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  | Thema:                                                                                                    |
  |                                                                                                           |
  |          linux 2.6.18.2 with GCC 4.1.1 shell not coming                                                   |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  |                                                                                                           |
  >-----------------------------------------------------------------------------------------------------------|




Hi all ;

 I am facing some  problem in porting linux kernel 2.6.18. I went through
some mailing list,archives and find mails refering exactly the problem I am
facing but unfortunetly I didnt get any working hints or solutions.I am
wondering if what I am facing is a known issue for embeded community. I
apprecaite if someone can  share hsi/her experinece on this isue.

Problem: We are porting linux-2.6.18.2 on ARM based chip, with
toochain-4.1.1(EABI), software floating point and uClibc-0.9.28.1.
We are using busybox-1.2.2.1 and ash shell.I am facing a certain problem in
init.c, before the shell comes up.

I have traced the problem and it seems to be that i don't recover from
the function console_init (in file init.c) .

Same kernel and rootfile system works fine when I compile with  with
gcc-4.0.3 toolchain (without EABI).So I cannot doubt UART interrupt, or
console driver.

following mail list similar problem without  any clues:

http://buildroot.uclibc.org/lists/buildroot/2007-February/001516.html

http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021541.html


here is my log;




Waiting for image to be downloaded via ICE...


Linux version 2.6.18.2 (sainin at bmpbuild2.noida.conexant.com ) (gcc version
4.1.1)


 #2 Fri Feb 16 15:44:48 IST 2007


CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177


Machine: Conexant Edwards-Based IRD


Memory policy: ECC disabled, Data cache writeback


CPU0: D VIVT write-back cache


CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets


CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets


Built 1 zonelists.  Total pages: 16384


Kernel command line: console=ttyRI0 root=/dev/ram  mem=64M debug=0


PID hash table entries: 512 (order: 9, 2048 bytes)


Console: colour dummy device 80x30


Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)


Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)


Memory: 64MB = 64MB total


Memory: 55040KB available (1112K code, 479K data, 68K init)


Mount-cache hash table entries: 512


CPU: Testing write buffer coherency: ok


checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like a


n initrd


Freeing initrd memory: 8192K


NetWinder Floating Point Emulator V0.97 (double precision)


Initializing Cryptographic API


io scheduler noop registered (default)


ttyRI0 at MMIO 0xe0412000 (irq = 2) is a CNXTUART


ttyRI1 at MMIO 0xe0411000 (irq = 1) is a CNXTUART


ttyRI2 at MMIO 0xe0410000 (irq = 0) is a CNXTUART


RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize


mice: PS/2 mouse device common for all mice


RAMDISK: ext2 filesystem found at block 0


RAMDISK: Loading 8092KiB [1 disk] into ram disk... done.


VFS: Mounted root (ext2 filesystem) readonly.


Freeing init memory: 68K


Hello WOrld inside init.c


before console_init


 (no shell)


Thanks for your patience and time.

Regards
satpal


 _______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox



From vda.linux at googlemail.com  Sat Feb 17 15:54:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 16:54:40 +0100
Subject: Busybox build problem
In-Reply-To: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
Message-ID: <200702171654.40381.vda.linux@googlemail.com>

On Saturday 17 February 2007 03:49, Ravi Chemudugunta wrote:
> # make allnoconfig; make
> 
>   LINK    busybox_unstripped
> /home/brion/busybox-1.4.1/scripts/trylink: 5: function: not found
> /home/brion/busybox-1.4.1/scripts/trylink: 11: Syntax error: "}" unexpected
> make: *** [busybox_unstripped] Error 2
> 
> This error occurs on *ubuntu due to the use of dash as the default
> shell (sh->dash).  the scripts included were designed with bash which
> uses some non-posix extensions which dash strives to meet
> (posix-ness).
> 
> cd /bin
> rm sh
> ln -s bash sh
> 
> The reason for including dash is speed so your system might boot
> slower or not at all.

I applaud ubuntu's efforts of trying to use smaller shell.
Really. bash is too big for any sensible embedded system.

Unfortunately it means that fixing just busybox's stripts
is not a solution - there are tons of other shell scripts
lying aroung.

dash should support "function". It shouldn't be too hard - 
dash already supports

do_something () {
    ...
}

It's just a matter of recognizing slightly diffeent syntax:

function do_something {
    ...
}

--
vda


From vda.linux at googlemail.com  Sat Feb 17 16:00:10 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 17:00:10 +0100
Subject: serial console and log-in
In-Reply-To: <1171665937.2696.252.camel@localhost>
References: <1171665937.2696.252.camel@localhost>
Message-ID: <200702171700.10195.vda.linux@googlemail.com>

On Friday 16 February 2007 23:45, Natanael Copa wrote:
> Hi,
> 
> >From the serial console kernel documentation:
> 
>  If no console device is specified, the first device found capable of
>  acting as a system console will be used. At this time, the system
>  first looks for a VGA card and then for a serial port. So if you don't
>  have a VGA card in your system the first serial port will automatically
>  become the console.
> 
> Is there some way to autodetect if the console is a serial console, and
> if it is, activate a line like this in inittab:
> 
> ttyS0 ::respawn:/sbin/getty -L ttyS0 115200 vt100 
> 
> And if /dev/console is not a serial console, it will not activate any
> getty on the serial console.

I propose making it possible to start getty (or whatever)
on any device which happens to be init's fd#0 (which is passed to it
by kernel). This way you will automatically get your getty whereever
kernel's console happened to be this time.

Proposed syntax:

::respawn:/sbin/getty - 115200 vt100 

or

0::respawn:/sbin/getty - 115200 vt100 

or 

stdin::respawn:/sbin/getty - 115200 vt100 

We should fix init's crazy handling of console and stdio fd's first
(see my earlier mail today). Not too hard, I just need people who
are willing to test changes.
--
vda


From vda.linux at googlemail.com  Sat Feb 17 18:09:34 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 19:09:34 +0100
Subject: sort broken when using more than one -k's
In-Reply-To: <20070216012603.GA8224@nancy.sattler.local>
References: <20070216012603.GA8224@nancy.sattler.local>
Message-ID: <200702171909.34408.vda.linux@googlemail.com>

On Friday 16 February 2007 02:26, Thomas Sattler wrote:
> Hi there ...
> 
> Current busybox (1.4.1) seems to be broken in applet sort when more
> than one -k's are used:
> 
> The example on http://www.busybox.net/downloads/BusyBox.html says
> 
> > $ echo -e "c 3\nb 2\nd 2" | sort -k 2,2n -k 1,1r
> 
> should result in
> 
> > d 2
> > b 2
> > c 3
> 
> which is what my (coreutils-6.4) sort does. busybox sort produces this:
> 
> > $ echo -e "c 3\nb 2\nd 2" | ./busybox sort -k 2,2n -k 1,1r
> > d 2
> > c 3
> > b 2

Thanks, fixed in svn. Patch is attached.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 5192 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070217/4d475980/attachment-0002.bin 

From hias at horus.com  Sat Feb 17 19:22:34 2007
From: hias at horus.com (Matthias Reichl)
Date: Sat, 17 Feb 2007 20:22:34 +0100
Subject: FEATURE_IFCONFIG_BROADCAST_PLUS broken
Message-ID: <20070217192233.GA18191@horus.com>

I just noticed that "ifconfig eth0 broadcast +" doesn't work, although
the FEATURE_IFCONFIG_BROADCAST_PLUS is enabled.

busybox 1.3.0 and 1.4.1 say "ifconfig: +: unknown host", current
svn says "ifconfig: bad address '+'".

I tested several older versions, this feature works fine up to 1.2.2.1
so I guess the bug must have sneaked in somewhere between October
and December last year.

so long,

Hias


From hias at horus.com  Sat Feb 17 20:43:16 2007
From: hias at horus.com (Matthias Reichl)
Date: Sat, 17 Feb 2007 21:43:16 +0100
Subject: FEATURE_IFCONFIG_BROADCAST_PLUS broken
In-Reply-To: <20070217192233.GA18191@horus.com>
References: <20070217192233.GA18191@horus.com>
Message-ID: <20070217204316.GA21241@horus.com>

Please forget about this. Busybox works fine, the problem was sitting
in front of the computer...

so long,

Hias


From vda.linux at googlemail.com  Sat Feb 17 22:35:58 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 17 Feb 2007 23:35:58 +0100
Subject: [PATCH] init cleanup - request for testing
In-Reply-To: <20070217133359.bfc52cea95091b0fffcb409eab6296ba.e20c8bfcab.wbe@email.secureserver.net>
References: <20070217133359.bfc52cea95091b0fffcb409eab6296ba.e20c8bfcab.wbe@email.secureserver.net>
Message-ID: <200702172335.58060.vda.linux@googlemail.com>

On Saturday 17 February 2007 21:33, akennedy at techmoninc.com wrote:
> > We should fix init's crazy handling of console and stdio fd's first
> > (see my earlier mail today). Not too hard, I just need people who
> > are willing to test changes.
> 
> I'll do some testing for you.  I can at least test the serial stuff ;).

Wow, nice.

Attached patch is a first step in making init's handling
of console simpler and hopefully saner.

We do not close fd 0,1,2 up-front and don't try to painfully discover
the name of console device - because we don't need to. It is
_already_ open_ for us!

open_new_terminal() now recognizes a special case of empty
tty name which means "just use existing fd 0".

log_console is retained - there can be users of that feature.
On serial lines, log_console is automatically redirected
to fd #2 (old code was trying to find the name of console,
open console again, yadda, yadda... it's all gone.
fd #2 _is_ the console).

On Friday 16 February 2007 23:45, Natanael Copa wrote:
> The current problem is, that even if console goes to serial port so I
> can see the kernel messages and bootscript output, busybox init will
> never give a login from inittab unless the previous line is there.

I did not test it, but maybe

::respawn:/sbin/getty - 115200 vt100

already works: i.e. starts a getty on /dev/tty1 or on /dev/ttyS0,
depending on kernel's command line.

Please test whether that works and whether such getty
is able to obtain controlling tty.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.patch
Type: text/x-diff
Size: 22138 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070217/db70e013/attachment-0002.bin 

From natanael.copa at gmail.com  Sun Feb 18 03:28:13 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 18 Feb 2007 04:28:13 +0100
Subject: Busybox build problem
In-Reply-To: <200702171654.40381.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
Message-ID: <20070218042813.154d9403.natanael.copa@gmail.com>

On Sat, 17 Feb 2007 16:54:40 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On Saturday 17 February 2007 03:49, Ravi Chemudugunta wrote:
> > # make allnoconfig; make
> > 
> >   LINK    busybox_unstripped
> > /home/brion/busybox-1.4.1/scripts/trylink: 5: function: not found

Without looking at the code, this could probably be walked around by
s/sh/bash/ on first line.

> > /home/brion/busybox-1.4.1/scripts/trylink: 11: Syntax error: "}" unexpected
> > make: *** [busybox_unstripped] Error 2
> > 
> > This error occurs on *ubuntu due to the use of dash as the default
> > shell (sh->dash).  the scripts included were designed with bash which
... 
> Unfortunately it means that fixing just busybox's stripts
> is not a solution - there are tons of other shell scripts
> lying aroung.
> 
> dash should support "function". It shouldn't be too hard - 

Since busybox ash is based on dash, this applies to busybox ash too.

I am using gentoo's bash centric init scripts, patching them to work
with busybox's ash. Its amazing how much really works in dash/ash and
most things that don't work are this kind of "meaningless" bash
features that just add bloat to your shell and can easy be avoided by
doing simple changes in the script. (like removing the "function"
keyword from function declarations)

I'd prefer people stop using bash specific things, rather than trying
to patch all shells to support all bash wierdness.

Natanael


From busybox at lists.lammerts.org  Sun Feb 18 04:04:19 2007
From: busybox at lists.lammerts.org (Eric Lammerts)
Date: Sat, 17 Feb 2007 23:04:19 -0500
Subject: [PATCH] svlogd bug?
Message-ID: <45D7D043.8080208@lists.lammerts.org>


Hi,
When I create a 'finish' script, runsv just keeps running it over and 
over again. It never goes back to 'run'.

Attached patch (against current svn) fixes it.

Eric

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: runsv-patch
Url: http://lists.busybox.net/pipermail/busybox/attachments/20070217/670a6e95/attachment.diff 

From vda.linux at googlemail.com  Sun Feb 18 11:03:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 18 Feb 2007 12:03:13 +0100
Subject: Busybox build problem
In-Reply-To: <20070218042813.154d9403.natanael.copa@gmail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
Message-ID: <200702181203.13453.vda.linux@googlemail.com>

On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > Unfortunately it means that fixing just busybox's stripts
> > is not a solution - there are tons of other shell scripts
> > lying aroung.
> > 
> > dash should support "function". It shouldn't be too hard - 
> 
> Since busybox ash is based on dash, this applies to busybox ash too.
> 
> I am using gentoo's bash centric init scripts, patching them to work
> with busybox's ash. Its amazing how much really works in dash/ash and
> most things that don't work are this kind of "meaningless" bash
> features that just add bloat to your shell and can easy be avoided by
> doing simple changes in the script. (like removing the "function"
> keyword from function declarations)
> 
> I'd prefer people stop using bash specific things,

It's too late. Face the reality. bash installed base is too big.

> rather than trying 
> to patch all shells to support all bash wierdness.

How you realistically imagine everyone starting to audit all their
scripts for usage of "function"? How many man-years will it take?
Then compare it to the effort required to add support for this feature
to dash.
--
vda


From vda.linux at googlemail.com  Sun Feb 18 11:05:06 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 18 Feb 2007 12:05:06 +0100
Subject: [PATCH] svlogd bug?
In-Reply-To: <45D7D043.8080208@lists.lammerts.org>
References: <45D7D043.8080208@lists.lammerts.org>
Message-ID: <200702181205.06289.vda.linux@googlemail.com>

On Sunday 18 February 2007 05:04, Eric Lammerts wrote:
> 
> Hi,
> When I create a 'finish' script, runsv just keeps running it over and 
> over again. It never goes back to 'run'.
> 
> Attached patch (against current svn) fixes it.

Applied, thanks!
--
vda


From chemuduguntar at gmail.com  Sun Feb 18 11:16:07 2007
From: chemuduguntar at gmail.com (Ravi Chemudugunta)
Date: Mon, 19 Feb 2007 00:16:07 +1300
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <7a4208ef0702180316j7cc2e6cdwfb5d43507ba80d6@mail.gmail.com>

the posix nazis will want you denis =)

I think its noble of dash adhering to posix standards (whatever they are for
shells) ... as you mentioned the base for bash is too big to 'cleanup' to
work with dash...I would have all scripts by default run on bash, unless
explicitly defined inside the scripts...for e.g. leave sh pointing to bash
but inside the shell scripts which are 'cleaned' ... have them execute
against dash with #!/bin/dash or fork dash that is like bash
(grammatically).


On 2/19/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > > Unfortunately it means that fixing just busybox's stripts
> > > is not a solution - there are tons of other shell scripts
> > > lying aroung.
> > >
> > > dash should support "function". It shouldn't be too hard -
> >
> > Since busybox ash is based on dash, this applies to busybox ash too.
> >
> > I am using gentoo's bash centric init scripts, patching them to work
> > with busybox's ash. Its amazing how much really works in dash/ash and
> > most things that don't work are this kind of "meaningless" bash
> > features that just add bloat to your shell and can easy be avoided by
> > doing simple changes in the script. (like removing the "function"
> > keyword from function declarations)
> >
> > I'd prefer people stop using bash specific things,
>
> It's too late. Face the reality. bash installed base is too big.
>
> > rather than trying
> > to patch all shells to support all bash wierdness.
>
> How you realistically imagine everyone starting to audit all their
> scripts for usage of "function"? How many man-years will it take?
> Then compare it to the effort required to add support for this feature
> to dash.
> --
> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070219/fc59f8d2/attachment-0001.htm 

From psmith at netezza.com  Sun Feb 18 15:40:21 2007
From: psmith at netezza.com (Paul Smith)
Date: Sun, 18 Feb 2007 10:40:21 -0500
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <1171813222.14708.80.camel@homebase>

On Sun, 2007-02-18 at 12:03 +0100, Denis Vlasenko wrote:

> > I'd prefer people stop using bash specific things,
> 
> It's too late. Face the reality. bash installed base is too big.

I disagree; major distributions such as Ubuntu are right now ditching
bash as /bin/sh, for other shells like dash and ash: they are doing this
to try to get more efficiency and speed during bootup etc.  They are not
compromising and they are forcing packages to clean up their sloppy
shell programming, and make /bin/sh scripts conform to POSIX.

> How you realistically imagine everyone starting to audit all their
> scripts for usage of "function"? How many man-years will it take?
> Then compare it to the effort required to add support for this feature
> to dash.

That, of course, is up to you.  However, I will point out that I can
count on the fingers of one hand (with some left over) the number of
package shell scripts I've ever seen that use "function".  And I've been
building free software since the 1980's.

I've seen lots scripts that are written to require bash, don't get me
wrong.  But for all different sorts of reasons and "function" is not a
common one, in my experience.

YMMV...


From vda.linux at googlemail.com  Sun Feb 18 16:12:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 18 Feb 2007 17:12:51 +0100
Subject: Busybox build problem
In-Reply-To: <1171813222.14708.80.camel@homebase>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
	<1171813222.14708.80.camel@homebase>
Message-ID: <200702181712.51372.vda.linux@googlemail.com>

On Sunday 18 February 2007 16:40, Paul Smith wrote:
> On Sun, 2007-02-18 at 12:03 +0100, Denis Vlasenko wrote:
> 
> > > I'd prefer people stop using bash specific things,
> > 
> > It's too late. Face the reality. bash installed base is too big.
> 
> I disagree; major distributions such as Ubuntu are right now ditching
> bash as /bin/sh, for other shells like dash and ash: they are doing this
> to try to get more efficiency and speed during bootup etc.

bash is not a reason why bootup is slow. For desktop machine,
bash is small enough (700kb IIRC) to not matter.

Bootup is slow because of SysV init scripts. I ditched them,
and my boot is fast enough for me ever since.

> They are not 
> compromising and they are forcing packages to clean up their sloppy
> shell programming, and make /bin/sh scripts conform to POSIX.

Standards are not gods, they are just codified practice.
What is so terribly wrong with "function" syntax?

> > How you realistically imagine everyone starting to audit all their
> > scripts for usage of "function"? How many man-years will it take?
> > Then compare it to the effort required to add support for this feature
> > to dash.
> 
> That, of course, is up to you.  However, I will point out that I can
> count on the fingers of one hand (with some left over) the number of
> package shell scripts I've ever seen that use "function".  And I've been
> building free software since the 1980's.

Wow, you read makefiles and supporting shell script machinery
of every package you build? Must be terribly time consuming task...
--
vda


From psmith at netezza.com  Mon Feb 19 00:40:08 2007
From: psmith at netezza.com (Paul Smith)
Date: Sun, 18 Feb 2007 19:40:08 -0500
Subject: Busybox build problem
In-Reply-To: <200702181712.51372.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
	<1171813222.14708.80.camel@homebase>
	<200702181712.51372.vda.linux@googlemail.com>
Message-ID: <1171845609.14708.108.camel@homebase>

On Sun, 2007-02-18 at 17:12 +0100, Denis Vlasenko wrote:

> > > It's too late. Face the reality. bash installed base is too big.
> > 
> > I disagree; major distributions such as Ubuntu are right now ditching
> > bash as /bin/sh, for other shells like dash and ash: they are doing this
> > to try to get more efficiency and speed during bootup etc.
> 
> bash is not a reason why bootup is slow. For desktop machine,
> bash is small enough (700kb IIRC) to not matter.
> 
> Bootup is slow because of SysV init scripts. I ditched them,
> and my boot is fast enough for me ever since.

Ubuntu is ditching SysV init scripts also; as of their previous release
they're now using Upstart https://wiki.ubuntu.com/ReplacementInit
although they're going there incrementally (so many of the services in
Edgy still use traditional scripts).  For a general purpose desktop
system you must have something more advanced than hardcoded scripting
(see the use cases described in the Wiki page above for some things that
need to be supported).

Anyway, this is neither here nor there; regardless of the reasons for it
and whether the reasons are correct or not, the fact remains that Ubuntu
(at least) does not use bash as /bin/sh, and they are convincing many
common packages to clean up their scripting.

> Standards are not gods, they are just codified practice.
> What is so terribly wrong with "function" syntax?

Nothing, other than the mild criticism that it's redundant and
potentially confusing ("this function doesn't have 'function' and this
one does... why is that?  What's the difference?" followed by a
time-wasting search through the documentation).  I have no problem with
adding it if you want to.  All I'm saying is that I don't believe
there's a technical reason to add it; I don't think "bash is ubiquitous
and so we should implement its idiosyncrasies" is accurate.

> > > How you realistically imagine everyone starting to audit all their
> > > scripts for usage of "function"? How many man-years will it take?
> > > Then compare it to the effort required to add support for this feature
> > > to dash.
> > 
> > That, of course, is up to you.  However, I will point out that I can
> > count on the fingers of one hand (with some left over) the number of
> > package shell scripts I've ever seen that use "function".  And I've been
> > building free software since the 1980's.
> 
> Wow, you read makefiles and supporting shell script machinery
> of every package you build? Must be terribly time consuming task...

I'm not sure where this hostile tone is coming from.

In fact, I've build hundreds of packages over many years on systems that
were NOT Linux, including various BSD's, SunOS, Solaris, HPUX, AIX,
DG-UX, OSF1, and others, and not one of those used or uses bash
as /bin/sh.  And while I had portability problems galore, and ran across
many bash-isms in files marked as /bin/sh, I hardly ever ran across a
situation where the failure was the use of "function" in a shell script.


From vapier at gentoo.org  Mon Feb 19 03:54:28 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 18 Feb 2007 22:54:28 -0500
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <200702182254.29429.vapier@gentoo.org>

On Sunday 18 February 2007, Denis Vlasenko wrote:
> On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > I'd prefer people stop using bash specific things,
>
> It's too late. Face the reality. bash installed base is too big.

if you want to use bashisms, that's fine, but at least declare the shebang 
properly:
#!/bin/bash
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070218/a4cbdec9/attachment-0002.pgp 

From natanael.copa at gmail.com  Mon Feb 19 10:32:55 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 19 Feb 2007 11:32:55 +0100
Subject: serial console and log-in
In-Reply-To: <200702171700.10195.vda.linux@googlemail.com>
References: <1171665937.2696.252.camel@localhost>
	<200702171700.10195.vda.linux@googlemail.com>
Message-ID: <1171881175.9155.4.camel@localhost>

On Sat, 2007-02-17 at 17:00 +0100, Denis Vlasenko wrote:
> On Friday 16 February 2007 23:45, Natanael Copa wrote:
> > Hi,
> > 
> > Is there some way to autodetect if the console is a serial console, and
> > if it is, activate a line like this in inittab:
> > 
> > ttyS0 ::respawn:/sbin/getty -L ttyS0 115200 vt100 
> > 
> > And if /dev/console is not a serial console, it will not activate any
> > getty on the serial console.
> 
> I propose making it possible to start getty (or whatever)
> on any device which happens to be init's fd#0 (which is passed to it
> by kernel). This way you will automatically get your getty whereever
> kernel's console happened to be this time.
> 
> Proposed syntax:
> 
> ::respawn:/sbin/getty - 115200 vt100 
> 
> or
> 
> 0::respawn:/sbin/getty - 115200 vt100 
> 
> or 
> 
> stdin::respawn:/sbin/getty - 115200 vt100 

Yes. something like that was exactly what I was hoping for.

> We should fix init's crazy handling of console and stdio fd's first
> (see my earlier mail today). Not too hard, I just need people who
> are willing to test changes.

I'm willing to test. I think I will be able to allocate some time during
the week. Unfortunally, the serial-only box hasn't arrived yet and you
can't remove the vga card in qemu afaik.

Thanks!
> --
> vda



From natanael.copa at gmail.com  Mon Feb 19 10:39:49 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 19 Feb 2007 11:39:49 +0100
Subject: Busybox build problem
In-Reply-To: <200702181203.13453.vda.linux@googlemail.com>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702171654.40381.vda.linux@googlemail.com>
	<20070218042813.154d9403.natanael.copa@gmail.com>
	<200702181203.13453.vda.linux@googlemail.com>
Message-ID: <1171881589.9155.11.camel@localhost>

On Sun, 2007-02-18 at 12:03 +0100, Denis Vlasenko wrote:
> On Sunday 18 February 2007 04:28, Natanael Copa wrote:
> > > Unfortunately it means that fixing just busybox's stripts
> > > is not a solution - there are tons of other shell scripts
> > > lying aroung.
> > > 
> > > dash should support "function". It shouldn't be too hard - 
> > 
> > Since busybox ash is based on dash, this applies to busybox ash too.
> > 
> > I am using gentoo's bash centric init scripts, patching them to work
> > with busybox's ash. Its amazing how much really works in dash/ash and
> > most things that don't work are this kind of "meaningless" bash
> > features that just add bloat to your shell and can easy be avoided by
> > doing simple changes in the script. (like removing the "function"
> > keyword from function declarations)
> > 
> > I'd prefer people stop using bash specific things,
> 
> It's too late. Face the reality. bash installed base is too big.
> 
> > rather than trying 
> > to patch all shells to support all bash wierdness.
> 
> How you realistically imagine everyone starting to audit all their
> scripts for usage of "function"? How many man-years will it take?
> Then compare it to the effort required to add support for this feature
> to dash.

I am doing it with gentoo init scripts. It's not that much work. (less
than rewrite for runinit). I'm doing it because bash is almost the size
as my entire busybox.

In your case, on a building machine, sure, you can expect bash to be
there. In that case, as someone already explained, use the:

#!/bin/bash




From vda.linux at googlemail.com  Mon Feb 19 23:46:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 20 Feb 2007 00:46:25 +0100
Subject: Busybox build problem
In-Reply-To: <1171845609.14708.108.camel@homebase>
References: <7a4208ef0702161849y7232a94wc490e710a897fc99@mail.gmail.com>
	<200702181712.51372.vda.linux@googlemail.com>
	<1171845609.14708.108.camel@homebase>
Message-ID: <200702200046.25206.vda.linux@googlemail.com>

On Monday 19 February 2007 01:40, Paul Smith wrote:
> > > That, of course, is up to you.  However, I will point out that I can
> > > count on the fingers of one hand (with some left over) the number of
> > > package shell scripts I've ever seen that use "function".  And I've been
> > > building free software since the 1980's.
> > 
> > Wow, you read makefiles and supporting shell script machinery
> > of every package you build? Must be terribly time consuming task...
> 
> I'm not sure where this hostile tone is coming from.

Oops, sorry. :(
--
vda


From marco-glatz at web.de  Tue Feb 20 14:55:59 2007
From: marco-glatz at web.de (Marco Glatz)
Date: Tue, 20 Feb 2007 15:55:59 +0100
Subject: segfault with ls
Message-ID: <580912971@web.de>

hello,

i have a strange problem here. when i do "ls -l /dev" i get a segmentation fault, runnig strace does not show any errors, and when running ls-cmd from within a shell-script, then it works. i'm using latest busybox with udev-104 and kernel 2.6.19


marco
_______________________________________________________________________
Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222



From akennedy at techmoninc.com  Tue Feb 20 21:50:25 2007
From: akennedy at techmoninc.com (akennedy at techmoninc.com)
Date: Tue, 20 Feb 2007 14:50:25 -0700
Subject: serial console and log-in
Message-ID: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>



> -------- Original Message --------
> Subject: RE: serial console and log-in
> From: akennedy at techmoninc.com
> Date: Sat, February 17, 2007 2:33 pm
> To: Denis Vlasenko <vda.linux at googlemail.com>
> 
> > We should fix init's crazy handling of console and stdio fd's first
> > (see my earlier mail today). Not too hard, I just need people who
> > are willing to test changes.
> 
> I'll do some testing for you.  I can at least test the serial stuff ;).
> 
> Andy

Serial console works with

::respawn:-/bin/sh

Haven't tested anything else, but I'd guess if that works, so does everything else.

Andy


From vda.linux at googlemail.com  Wed Feb 21 00:04:57 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 21 Feb 2007 01:04:57 +0100
Subject: serial console and log-in
In-Reply-To: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
Message-ID: <200702210104.57030.vda.linux@googlemail.com>

On Tuesday 20 February 2007 22:50, akennedy at techmoninc.com wrote:
> 
> > -------- Original Message --------
> > Subject: RE: serial console and log-in
> > From: akennedy at techmoninc.com
> > Date: Sat, February 17, 2007 2:33 pm
> > To: Denis Vlasenko <vda.linux at googlemail.com>
> > 
> > > We should fix init's crazy handling of console and stdio fd's first
> > > (see my earlier mail today). Not too hard, I just need people who
> > > are willing to test changes.
> > 
> > I'll do some testing for you.  I can at least test the serial stuff ;).
> > 
> > Andy
> 
> Serial console works with
> 
> ::respawn:-/bin/sh
> 
> Haven't tested anything else, but I'd guess if that works, so does everything else.

Ok, will apply that patch to svn.

A bit more tests will be useful.
Does it work _without_ serial console?
In both cases, is there controlling tty? IOW:

echo TEST >/dev/tty
TEST

This is good (controlling tty exists)

echo TEST >/dev/tty
sh: /dev/tty: No such device or address

This isn't good.
--
vda


From navalnovel at gmail.com  Wed Feb 21 08:54:54 2007
From: navalnovel at gmail.com (Naval Saini)
Date: Wed, 21 Feb 2007 14:24:54 +0530
Subject: Fwd: [arm-gnu] porting linux 2.6.18.1(EABI) support GCC-4.1.1(eabi)
	shell not coming
In-Reply-To: <d8dd82df0702190709m18c4d778i33b8f54bd6100c3f@mail.gmail.com>
References: <457d2dc30702160244ve26ffc5tdf21af6851feedf6@mail.gmail.com>
	<20070216202631.GA17153@mvista.com>
	<200702162204.51805.openembedded@hrw.one.pl>
	<er56n2$ihh$1@sea.gmane.org>
	<d8dd82df0702190709m18c4d778i33b8f54bd6100c3f@mail.gmail.com>
Message-ID: <d8dd82df0702210054y723f717axdd8a6ec042184b3b@mail.gmail.com>

Hi:

Hi Keon Kooi, it seems your patch is what we needed.

I further saw that, before we applied your patch there was a 'clz r1, r3'
instruction in objdump of busybox binary. At this instruction (maybe there
are others too) that we were getting an exception and jumping into the
kernel. This instruction is supported in v5 arch but not in v4, that we are
using (found on net).

So is this patch explained or is there more we are missing for informative
purpose on what this patch does? Its good enuf the shell is up.

Thanks and regards,
Naval Saini

On 2/19/07, Naval Saini <navalnovel at gmail.com> wrote:
>
> Hi Everyone:
>
> We have been able to move past init ( in busybox ).
> Earlier we were getting stuck while making first IOCTL  (with TIOCGSERIAL)
> call and then while close (2).   ( i commened console_init and hardcoded
> '/dev/console' in it ; and commened the line close (2) , next )
>
> But even after init, we donot get the shell.
>
> I find myself making a flurry of calls to do_notify_resume ( )    ( and
> then a do_signal , ... here is my result from printk's i put in the kernel -
> do_signal )
>
>  do_signal - syscall 0 , current->pid 119, current->gid 119
>  do_signal - syscall 1073913928 , current->pid 1, current->gid 1, signr -
> 0
>  do_signal - syscall 0 , current->pid 121, current->gid 121
>  do_signal - syscall 1073913928 , current->pid 1, current->gid 1, signr -
> 0
>  do_signal - syscall 0 , current->pid 123, current->gid 123
>  ...
>
> I find the value in parameter syscall quite absurd. Thats cause, when do_notify_resume
> calls do_signal ; the value in parameter (its the third param) is 10, 75,
> etc... but when i printk it, its 0 or some weird value.
>
> The stack frame in do_signal is as follows :-
>    do_signal
>    do_notify_resume
>    work_pending (asm)
>    exception                   ( SR: 0x ... some addr. )
>
>
> Also , would it be helpful to know, for which instruction/s is/are causing
> this exception?
>
> Help needed in zeroing down on the issue.
> By the way, other than the EABI patch for V4, i have tried all previous
> suggestions (without effect).  :-)
>
> Thanks for all the mails.
> Regards,
> Naval
>
> On 2/17/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Marcin Juszkiewicz schreef:
> > > Dnia pi?tek, 16 lutego 2007, George G. Davis napisa?:
> > >>> CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
> > >> ISTR hereing that ARM eABI support in GCC requires/assumes an ARMv5TE
> > >> or greater processor.  Yet you're using an ARMv4T based processor.  I
> > >> don't know for certain if this is causing problems for you here but
> > >> perhaps other may comment on status of GCC ARM eABI support on ARMv4T
> > >> targets, e.g. if you built userland under the assumption that the
> > >> processor is ARMv5TE or above, it aint gonna work on an ARMv4T based
> > >> processor?
> > >
> > > ?ngstr?m distribution supports armv4t/EABI. All needed parts of
> > toolchain
> > > are available in OpenEmbedded buildsystem.
> > >
> > > We use gcc 4.1.1/binutils 2.17.50.0.5/glibc 2.5 with amount of patches
> > to
> > > get it working properly. IIRC only armv4 (for example sa1100) are not
> > > supported in EABI.
> >
> > You can disable thumb-interworking and patch each and every -Werror out
> > of libc to get it
> > to compile for strongarm. Or pester the gcc people to implement proper
> > armv4 support.
> >
> > regards,
> >
> > Koen
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070221/5dad195d/attachment.htm 

From parmarsatpal at gmail.com  Wed Feb 21 09:23:10 2007
From: parmarsatpal at gmail.com (satpal parmar)
Date: Wed, 21 Feb 2007 14:53:10 +0530
Subject: time command wrong values
Message-ID: <457d2dc30702210123o139f0246wbce0910e93e07eec@mail.gmail.com>

Hi all;

             I am facing a very weird problem. I have ported linux kernel
2.6.18.2 on arm 9 base board.When I use time command from buzybox to
understanding the performance characteristics of a single program I am
getting  some finite values for real but sys and user values are always
zero.


/ # dd if=/dev/ram0  of=/dev/ram1  count=10000000
16384+0 records in
16384+0 records out

/ # time dd if=/dev/ram0  of=/dev/ram1  count=10000000
16384+0 records in
16384+0 records out
real    0m 0.80s
user    0m 0.00s
sys     0m 0.00s

/ # time dd if=/dev/ram0  of=/dev/ram1  count=100000000
16384+0 records in
16384+0 records out
real    0m 0.80s
user    0m 0.00s
sys     0m 0.00s

/ # time dd if=/dev/ram0  of=/dev/ram1  count=1000000000
16384+0 records in
16384+0 records out
real    0m 0.80s
user    0m 0.00s
sys     0m 0.00s
/ # time dd if=/dev/ram0  of=/dev/ram1  count=1000
1000+0 records in
1000+0 records out
real    0m 0.06s
user    0m 0.00s
sys     0m 0.00s

When I tried this same load *on linux system* I get following values.

time dd if=/dev/ram0  of=/dev/ram1  count=1000

real    0m0.022s
user    0m0.000s
sys     0m0.002s

Am I doing things wrong? My uneducated  guess is that there can some problem
in BSp side . Any thoughts?

Thanks in adavnce.

satpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070221/468d860e/attachment-0001.htm 

From natanael.copa at gmail.com  Wed Feb 21 10:44:17 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Wed, 21 Feb 2007 11:44:17 +0100
Subject: serial console and log-in
In-Reply-To: <200702210104.57030.vda.linux@googlemail.com>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
	<200702210104.57030.vda.linux@googlemail.com>
Message-ID: <1172054657.12630.38.camel@localhost>

On Wed, 2007-02-21 at 01:04 +0100, Denis Vlasenko wrote:
> On Tuesday 20 February 2007 22:50, akennedy at techmoninc.com wrote:
> > 
> > > -------- Original Message --------
> > > Subject: RE: serial console and log-in
> > > From: akennedy at techmoninc.com
> > > Date: Sat, February 17, 2007 2:33 pm
> > > To: Denis Vlasenko <vda.linux at googlemail.com>
> > > 
> > > > We should fix init's crazy handling of console and stdio fd's first
> > > > (see my earlier mail today). Not too hard, I just need people who
> > > > are willing to test changes.
> > > 
> > > I'll do some testing for you.  I can at least test the serial stuff ;).
> > > 
> > > Andy
> > 
> > Serial console works with
> > 
> > ::respawn:-/bin/sh
> > 
> > Haven't tested anything else, but I'd guess if that works, so does everything else.
> 
> Ok, will apply that patch to svn.

> A bit more tests will be useful.
> Does it work _without_ serial console?
> In both cases, is there controlling tty? IOW:
> 
> echo TEST >/dev/tty
> TEST
> 
> This is good (controlling tty exists)
> 
> echo TEST >/dev/tty
> sh: /dev/tty: No such device or address
> 
> This isn't good.

I backported the svn init to 1.4.1 (i depend on releases).

My inittab line looks like this:

::respawn:/sbin/getty - 9600 vt100

I got a login prompt but no controlling tty:

-ash: cant't access tty; job control turned off

~$ echo TEST > /dev/tty
-ash: cannot create /dev/tty: No such device or address

That was on a VGA console.

Then I tried to run it in qemu, with -nographic. It booted, it gave me a
login, but same as VGA, no controlling tty.


--
Natanael Copa



From stephane.billiart at gmail.com  Wed Feb 21 14:24:24 2007
From: stephane.billiart at gmail.com (Stephane Billiart)
Date: Wed, 21 Feb 2007 09:24:24 -0500
Subject: truncated syslog messages
Message-ID: <20070221142424.GA15913@salusa.home.net>

The problem:

server# logger "message to syslog"
server# killall syslogd
server# tail /var/log/messages 
Feb 21 08:50:19 server syslog.info syslogd started: BusyBox v1.5.0.svn
Feb 21 08:50:23 server kern.warn kernel: TSC 
Feb 21 08:50:31 server user.notice root: messa
Feb 21 08:51:25 server syslog.info syslogd exiting
server# ls -l /dev/log /var/syslog
lrwxrwxrwx    1 root     root           11 Jan  4  1980 /dev/log -> /var/syslog=
srw-rw-rw-    1 root     root            0 Feb 21 08:50 /var/syslog=

All messages syslog receives are truncated, not the ones it writes itself...

My embedded system runs linux 2.6.19.2 with uClibc 0.9.27.
I have mdev activated in busybox, /dev is a ramfs partition and /var is tmpfs.
I tried with and without CONFIG_FEATURE_IPC_SYSLOG and get the same results

I see the problem with the SVN and 1.4.1 versions but not with 1.2.2.1
With glibc 2.3.6, everything is fine also.

There's been a lot of changes in syslogd recently.
I started looking at the code but so far did not find anything to explain
those short reads from /dev/log.

Any idea?

-- 
St?phane Billiart                      http://perso.orange.fr/billiart/


From iggarpe at terra.es  Thu Feb 22 11:29:13 2007
From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=)
Date: Thu, 22 Feb 2007 12:29:13 +0100
Subject: [PATCH] slattach applet for busybox 1.4.1 (this is the GOOD one)
In-Reply-To: <20070216132328.GA28870@aon.at>
References: <45D593D5.9070507@terra.es> <20070216132328.GA28870@aon.at>
Message-ID: <45DD7E89.7010805@terra.es>

Bernhard Fischer escribi?:

Thank you for the corrections. Question is, should I correct the code 
and submit a new patch?

I ask because that would be practical if I was to maintain the slattach 
applet code, which as far as I know I'm not.

Nacho.
> On Fri, Feb 16, 2007 at 12:21:57PM +0100, Ignacio Garc?a P?rez wrote:
>   
>> Sorry, attached the wrong patch in previous message. This is the good one.
>>
>> As I already said, would be nice to rewrite the option parsing code to 
>> make use of the libbb functions.
>>
>> Regards.
>>
>>
>>
>>     
>
>   
>> diff -urN busybox-1.4.1/include/applets.h busybox-1.4.1-modified/include/applets.h
>> --- busybox-1.4.1/include/applets.h	2007-01-24 22:34:48.000000000 +0100
>> +++ busybox-1.4.1-modified/include/applets.h	2007-02-16 11:45:33.000000000 +0100
>> @@ -262,6 +262,7 @@
>> USE_FEATURE_SH_IS_LASH(APPLET_NOUSAGE(sh, lash, _BB_DIR_BIN, _BB_SUID_NEVER))
>> USE_FEATURE_SH_IS_MSH(APPLET_NOUSAGE(sh, msh, _BB_DIR_BIN, _BB_SUID_NEVER))
>> USE_SHA1SUM(APPLET_ODDNAME(sha1sum, md5_sha1_sum, _BB_DIR_USR_BIN, _BB_SUID_NEVER, sha1sum))
>> +USE_SLATTACH(APPLET(slattach, _BB_DIR_SBIN, _BB_SUID_NEVER))
>> USE_SLEEP(APPLET(sleep, _BB_DIR_BIN, _BB_SUID_NEVER))
>> USE_SOFTLIMIT(APPLET_ODDNAME(softlimit, chpst, _BB_DIR_USR_BIN, _BB_SUID_NEVER, softlimit))
>> USE_SORT(APPLET(sort, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
>> diff -urN busybox-1.4.1/include/usage.h busybox-1.4.1-modified/include/usage.h
>> --- busybox-1.4.1/include/usage.h	2007-01-24 22:34:48.000000000 +0100
>> +++ busybox-1.4.1-modified/include/usage.h	2007-02-16 11:44:10.000000000 +0100
>> @@ -2788,6 +2788,20 @@
>>        "	-s	Don't output anything, status code shows success\n" \
>>        "	-w	Warn about improperly formatted SHA1 checksum lines")
>>
>> +#define slattach_trivial_usage \
>> +	"[-cehmLF] [-s speed] [-p protocol] DEVICEs"
>> +#define slattach_full_usage \
>> +	"Attach network interface(s) to serial line(s).\n" \
>> +	"Options:\n" \
>> +	"\t-p\tset a specific kind of protocol (slip, cslip, slip6, clisp6 or adaptive).\n" \
>> +	"\t-s\tset a specific line speed.\n"
>> +	"\t-c\texecute a command when the line is hung up\n" \
>> +	"\t-e\texit right after initializing device.\n" \
>> +	"\t-h\texit when the carrier is lost.\n" \
>> +	"\t-m\tdo NOT initialize the line in raw 8 bits mode.\n" \
>> +	"\t-L\tenable 3-wire operation.\n" \
>> +	"\t-F\tdisable RTS/CTS flow control.\n" \
>> + 
>> #define sleep_trivial_usage \
>> 	USE_FEATURE_FANCY_SLEEP("[") "N" USE_FEATURE_FANCY_SLEEP("]...")
>> #define sleep_full_usage \
>> diff -urN busybox-1.4.1/networking/Config.in busybox-1.4.1-modified/networking/Config.in
>> --- busybox-1.4.1/networking/Config.in	2007-01-24 22:34:34.000000000 +0100
>> +++ busybox-1.4.1-modified/networking/Config.in	2007-02-16 11:47:50.000000000 +0100
>> @@ -523,6 +523,12 @@
>> 	help
>> 	  Route displays or manipulates the kernel's IP routing tables.
>>
>> +config SLATTACH
>> +	bool "slattach"
>> +	default n
>> +	help
>> +	  Slattach is a small utility to attach network interfaces to serial lines.
>> +
>> config TELNET
>> 	bool "telnet"
>> 	default n
>> diff -urN busybox-1.4.1/networking/Kbuild busybox-1.4.1-modified/networking/Kbuild
>> --- busybox-1.4.1/networking/Kbuild	2007-01-24 22:34:34.000000000 +0100
>> +++ busybox-1.4.1-modified/networking/Kbuild	2007-02-16 11:38:37.000000000 +0100
>> @@ -32,6 +32,7 @@
>> lib-$(CONFIG_PING)         += ping.o
>> lib-$(CONFIG_PING6)        += ping6.o
>> lib-$(CONFIG_ROUTE)        += route.o
>> +lib-$(CONFIG_SLATTACH)     += slattach.o
>> lib-$(CONFIG_TELNET)       += telnet.o
>> lib-$(CONFIG_TELNETD)      += telnetd.o
>> lib-$(CONFIG_TFTP)         += tftp.o
>> diff -urN busybox-1.4.1/networking/slattach.c busybox-1.4.1-modified/networking/slattach.c
>> --- busybox-1.4.1/networking/slattach.c	1970-01-01 01:00:00.000000000 +0100
>> +++ busybox-1.4.1-modified/networking/slattach.c	2007-02-16 12:03:18.000000000 +0100
>> @@ -0,0 +1,266 @@
>> +/*
>> + *		Stripped down version of net-tools for busybox.
>> + *
>> + *		Author: Ignacio Garcia Perez (iggarpe at gmail dot com)
>> + *
>> + *		License: GPLv2 or later, see LICENSE file in this tarball.
>> + *
>> + *		There are some differences from the standard net-tools slattach:
>> + *
>> + *		- The -l option is not supported.
>> + *
>> + *		- Several devices can be specified in the command line. This is
>> + *		  very useful if you are handling many identical serial lines since
>> + *		  only one process is necessary to configure them all.
>> + *
>> + *		- The -F options allows disabling of RTS/CTS flow control.
>> + *
>> + */
>> +
>> +#include <unistd.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +#include <stdio.h>
>> +#include <signal.h>
>> +#include <errno.h>
>> +#include <sys/socket.h>
>> +#include <sys/types.h>
>> +#include <sys/stat.h>
>> +#include <fcntl.h>
>> +#include <termios.h>
>> +#include <sys/ioctl.h>
>> +
>> +#include "libbb.h"
>> +
>> +struct tty {
>> +	const char *	device;
>> +	int				handle;
>> +	int				saved_disc;
>> +	struct termios	saved_state;
>> +	struct tty *	next;
>> +};
>> +
>> +static struct tty *_tty_head = NULL;
>> +static struct tty *_tty_tail = NULL;
>> +
>> +/* Line discipline code table */
>> +
>> +static struct { const char *name; int code; } _proto [] = {
>> +	{ "slip",		0 },
>> +	{ "cslip",		1 },
>> +	{ "slip6",		2 },
>> +	{ "cslip6",		3 },
>> +	{ "adaptive",	8 },
>> +	{ NULL }
>> +};
>> +
>> +/*
>> + * Save tty state and line discipline
>> + */
>> +
>> +static int _save_state (struct tty *t) {
>> +
>> +	if (t->handle < 0) return 0;
>> +
>> +	if (tcgetattr(t->handle, &t->saved_state) < 0)			/* Save line status */
>> +		{ bb_perror_msg("get state"); return -1; }
>> +
>> +	if (ioctl(t->handle, TIOCGETD, &t->saved_disc) < 0)		/* Save line discipline */
>> +		{ bb_perror_msg("get discipline"); return -1; }
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Set tty state, line discipline and encapsulation
>> + */
>> +
>> +static int _set_state (struct tty *t, struct termios *state, int encap) {
>> +
>> +	int disc = N_SLIP;
>> +
>> +	if (t->handle < 0) return 0;
>> +
>> +	if (tcsetattr(t->handle, TCSANOW, state) < 0)			/* Set line status */
>> +		{ bb_perror_msg("set state"); return -1; }
>> +
>> +	if (ioctl(t->handle, TIOCSETD, &disc) < 0)				/* Set line discliple (N_SLIP always) */
>> +		{ bb_perror_msg("set discipline"); return -1; }
>> +
>> +	if (ioctl(t->handle, SIOCSIFENCAP, &encap) < 0)			/* Set encapsulation (SLIP, CSLIP, etc) */
>> +		{ bb_perror_msg("set encapsulation"); return -1; }
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Restore state and line discipline for ALL managed ttys
>> + *
>> + * Restoring ALL managed ttys is the only way to have a single
>> + * hangup delay.
>> + *
>> + */
>> +
>> +static int _restore_state_and_close (void) {
>> +
>> +	struct tty *t;
>> +	struct termios state;
>> +
>> +	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>> +
>> +		if (ioctl(t->handle, TIOCSETD, &t->saved_disc) < 0)			/* Restore line discipline */
>> +			{ bb_perror_msg("set discipline"); return -1; }
>> +
>> +		memcpy(&state, &t->saved_state, sizeof(state));				/* Hangup */
>> +		cfsetispeed(&state, B0);
>> +		cfsetospeed(&state, B0);
>> +		if (tcsetattr(t->handle, TCSANOW, &state) < 0)
>> +			{ bb_perror_msg("set state"); return -1; }
>> +	}
>> +
>> +	sleep(1);	/* The sleep time does not depend on the number of managed ttys */
>> +
>> +	for (t = _tty_head; t != NULL; t = t->next) if (t->handle >= 0) {
>> +
>> +		if (tcsetattr(t->handle, TCSANOW, &t->saved_state) < 0)		/* Restore line status */
>> +			{ perror("set state"); return -1; }
>> +
>> +		close(t->handle); t->handle = -1;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static void _sig_handler (int signo) {
>> +	if (_restore_state_and_close() < 0) sleep_and_die();
>> +	exit(0);
>> +}
>> +
>> +int slattach_main (int argc, char **argv) {
>> +
>> +	int i, encap;
>> +	struct tty *t;
>> +	struct termios state;
>> +	char buf [PATH_MAX];
>>     
>
> That's a large buffer, imho. xmalloc() or make it
> RESERVE_CONFIG_BUFFER(buf,PATH_MAX)
>
>   
>> +
>> +	const char *proto = "cslip";	/* Protocol */
>> +	const char *extcmd = NULL;		/* Command to execute after hangup */
>> +
>> +	int baud = -1;		/* Line baud rate (value) */
>> +	int baud_code = -1;	/* Line baud rate (system code) */
>> +	int local = 0;		/* Local mode (disable carrier watch) */
>> +	int quit = 0;		/* Initialize and exit */
>> +	int watch = 0;		/* watch for line hangup */
>> +	int raw = 1;		/* Initialize line in raw 8 bit mode */
>> +	int flow = 1;		/* Disable RTS/CTS flow control (not in net-tools slattach !!!) */
>>     
>
> most of these should use one variable and mask their bits in.
>   
>> +
>> +	/* Parse command line options */
>> +	/* TODO: use bb lib getopt_whatever? */
>>     
>
> getopt32, yes.
>
> The block below is just too bloated.
>   
>> +
>> +	for (i = 1; i < argc; i++) {
>> +
>> +		if (argv[i][0] == '-') switch (argv[i][1]) {
>> +			case 'p': proto = argv[++i]; break;
>> +			case 's': baud = atoi(argv[++i]); break;
>> +			case 'c': extcmd = argv[++i]; break;
>> +			case 'e': quit = 1; break;
>> +			case 'h': watch = 1; break;
>> +			case 'm': raw = 0; break;
>> +			case 'L': local = 1; break;
>> +			case 'F': flow = 0; break;
>> +			default: bb_error_msg_and_die("invalid option %s", argv[i]);
>> +		}
>> +
>> +		else {
>> +			t = (struct tty *)malloc(sizeof(struct tty));
>> +			if (t == NULL) bb_error_msg_and_die("not enough memory");
>>     
>
> No. xmalloc() instead
>
>   
>> +
>> +			t->device = argv[i];
>> +			t->handle = -1;
>> +			t->next = NULL;
>> +
>> +			if (_tty_head == NULL) _tty_head = _tty_tail = t;
>> +			else { _tty_tail->next = t; _tty_tail = t; }
>> +		}
>> +	}
>> +
>> +	if (_tty_head == NULL) bb_show_usage();
>> +
>> +	for (i = 0; _proto[i].name != NULL; i++)
>> +		if (!strcmp(_proto[i].name, proto)) break;
>>     
>
> index_in_str_array() instead
>
>   
>> +	if (_proto[i].name == NULL) bb_error_msg_and_die("invalid protocol %s", proto);
>> +	encap = _proto[i].code;
>> +
>> +	baud_code = tty_value_to_baud(baud);
>> +	if (baud_code < 0) bb_error_msg_and_die("invalid baud rate %i", baud);
>> +
>> +	/* Trap signals in order to restore tty states upon exit */
>> +
>> +	if (!quit) {
>> +		signal(SIGHUP, _sig_handler);
>> +		signal(SIGINT, _sig_handler);
>> +		signal(SIGQUIT, _sig_handler);
>> +		signal(SIGTERM, _sig_handler);
>> +	}
>> +
>> +	/* Configure ttys */
>> +
>> +	for (t = _tty_head; t != NULL; t = t->next) {
>> +
>> +		t->handle = open(t->device, O_RDWR | O_NDELAY);
>> +		if (t->handle < 0) {
>> +			snprintf(buf, sizeof(buf), "/dev/%s", t->device);
>>     
>
> concat_path_file() instead. Should make that huge buf from above
> superfluous.
>
>   
>> +			t->handle = open(buf, O_RDWR | O_NDELAY);
>> +			if (t->handle < 0) bb_perror_msg_and_die("open %s", t->device);
>> +		}
>> +
>> +		if (_save_state(t) < 0) sleep_and_die();
>> +
>> +		memcpy(&state, &t->saved_state, sizeof(state));
>> +
>> +		if (raw) {
>> +			memset(&state.c_cc, 0, sizeof(state.c_cc));
>> +			state.c_cc[VMIN]	= 1;
>> +			state.c_iflag		= IGNBRK | IGNPAR;
>> +			state.c_oflag		= 0;
>> +			state.c_lflag		= 0;
>> +			state.c_cflag		= CS8 | HUPCL | CREAD
>> +								| (local ? CLOCAL : 0) | (flow ? CRTSCTS : 0);
>> +		}
>> +
>> +		if (baud_code >= 0) {
>>     
>
> Didn't we check above that boud_rate not is < 0 above? drop it then.
>
>   
>> +			cfsetispeed(&state, baud_code);
>> +			cfsetospeed(&state, baud_code);
>> +		}
>> +
>> +		if (_set_state(t, &state, encap) < 0)
>> +			{ _restore_state_and_close(); sleep_and_die(); }
>> +	}
>> +
>> +	/* Exit now if option -e was passed */
>> +
>> +	if (quit) exit(0);
>> +
>> +	/* Watch line for hangup */
>> +
>> +	for (;;) {
>> +
>> +		if (watch)
>> +			for (t = _tty_head; t != NULL; t = t->next)
>> +				if (ioctl(t->handle, TIOCMGET, &i) < 0 || !(i & TIOCM_CAR))
>> +					quit = 1;
>> +
>> +		if (quit) break;
>>     
>
> would a while (!option_mask32 & QUIT) be smaller?
>
>   
>> +		sleep(15);
>> +	}
>> +
>> +	/* Execute command on hangup */
>> +
>> +	if (extcmd != NULL) system(extcmd);
>> +
>> +	/* Restore states and exit */
>> +
>> +	_restore_state_and_close();
>> +	return 0;
>> +}
>> +
>>     
>
>
>   



From ceesaxp at gmail.com  Thu Feb 22 19:22:31 2007
From: ceesaxp at gmail.com (Andrei Popov)
Date: Thu, 22 Feb 2007 22:22:31 +0300
Subject: gethostbyname Resolver Error
In-Reply-To: <f29fbf3a0702221036n640bc78r7cce2169c49d6c2@mail.gmail.com>
References: <f29fbf3a0702221036n640bc78r7cce2169c49d6c2@mail.gmail.com>
Message-ID: <f29fbf3a0702221122p2557c9e4se142623d3dbbfefc@mail.gmail.com>

Hi,

I am running BusyBox on WRT54G as part of OpenWRT firmware.  WRT
serves a local WLAN, being connected via a leased line to ISP, and
then through a PPTP VPN to Internet.  ISP runs several VPN gateway
servers, all are replying to a common host name -- let's call it
vpn.corbina.net but with different IP addresses -- 195.14.38.x.

Up until recently there were fewer than 20 servers in the VPN pool,
but a few days ago ISP has added several new servers to cope with the
load, pushing the total number of them to 23.  From that moment
uClib's gethostbyname stopped resolving names to IP addresses and
returns an unkown resolver error:

$ ping vpn.corbina.net
ping: vpn.corbina.net: Resolver error

$ nslookup vpn.corbina.net
Server:         localhost
Address:        127.0.0.1

nslookup: vpn.corbina.net: Resolver error

It would seem that because of a large number of entries returned by
the DNS server, gethostbyname fails to provide an name to IP mapping.
Are there any known work-arounds to this?


Thanks & please keep me on cc, as I am not subscribed to the mailing list.

Andrei


From ynakam at hitachisoft.jp  Fri Feb 23 08:47:33 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:33 +0900
Subject: [PATCH 0/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174733.e67e5fc6.ynakam@hitachisoft.jp>

Hi.

The following patches provide SELinux options(like -Z) and applets to coreutils.
To maintain SELinux system, some commands must be extended to be able to handle 
attribute in SELinux(such as security context).

Current patch is version 3. 
We submitted previous patches some weeks ago, and some reviews were done.
chcon and runcon applets are added, since last patch.
I think that's all for coreutils.

We hope the patches are merged into busybox svn tree.

[1/8] busybox-coreutils-common-01.v3.patch
 - common component for SELinux options, applets
   like usage messages, the definition of applets and Kbuild/Config.in.

[2/8] busybox-coreutils-02-copy.v3.patch
  - cp: -c option support. 
      -c option: security context is preserved during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.
   -Z option is also supported, security context can be set during file copy.
(annotation) The reason why the above options are required:
  SELinux stores secutiry context of files/directories in its
  xattr area, but most of commands don't pay attention for xattr.
  Thus, it's not preserved during file copy includes a case when mv
  falled back into read/write copy.
  We have to preserve them to keep consistency of the secure system.

[3/8] busybox-coreutils-03-mk.v3.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.
 This improves compatibility with up-streamed coreutils.


[4/8] busybox-coreutils-04-stat.v3.patch
 - -Z option support for stat. Security context of file is shown by -Z option.
 Security context of file is very important attribute for SELinux, 
 so it should be shown in stat.

[5/8]  busybox-coreutils-05-ls.v3.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced
 by -Z option in recent coreutils, so -Z have to be added by this patch.

[6/8] busybox-coreutils-06-id.v3.patch
 - -Z option support for id. Security context of process is shown by -Z option.

[7/8] busybox-coreutils-07-chcon.v3.patch
 - chcon - change security context of file. 
  chcon provides one of the core facilities to associate a correct security
  context within files. It enables to change whole or specific parts of the
  security context within them.

[8/8] busybox-coreutils-08-runcon.v3.patch
 - runcon - run application with specified security context.
  runcon provides one of the core facilities to run application with explicitly
  specified security context. It enables users to run their application under
  the least privilege set explicitly.


This project is originated from some of JPSEUG(Japan SELinux User Group). 
We have more patches to support SELinux commands/options.
For list of our work, please visit following site.
http://code.google.com/p/sebusybox/

Regards,
Yuichi Nakamura


From ynakam at hitachisoft.jp  Fri Feb 23 08:47:39 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:39 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174739.300d673a.ynakam@hitachisoft.jp>

[1/8] busybox-coreutils-common-01.v3.patch
 - common component for SELinux options, applets

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>





-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v3.patch
Type: application/octet-stream
Size: 9162 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/5ac1700a/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 08:47:47 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:47 +0900
Subject: [PATCH 2/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174747.4ced9178.ynakam@hitachisoft.jp>

[2/8] busybox-coreutils-02-copy.v3.patch
  - cp: -Z,-c option support. 
      -c option: security context is preserved during file copy.
  - mv 
    In SELinux, it is recommended to preserve security context 
    when file is moved. By this patch, file context is preserved 
    during file move.
  - install
    When file is copied by install, security context of installed file 
    becomes different from value configured in file_contexts file.
    By this patch, security context is set according to file_contexts file.
    -Z option: security context can be set during file copy.

Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.v3.patch
Type: application/octet-stream
Size: 7808 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/c3e3e5dc/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 08:47:53 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:47:53 +0900
Subject: [PATCH 3/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174753.db70e01c.ynakam@hitachisoft.jp>

[3/8] busybox-coreutils-03-mk.v3.patch
 - -Z option support for mkdir, mkfifo, mknod. 
    By -Z, security context for created file can be set.

Signed-off-by:  Yoshinori Sato <ysato at users.sourceforge.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-mk-03.v3.patch
Type: application/octet-stream
Size: 2216 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/fe7a5ef8/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 08:48:01 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:01 +0900
Subject: [PATCH 4/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174801.76d28c39.ynakam@hitachisoft.jp>

[4/8] busybox-coreutils-04-stat.v3.patch
 - -Z option support for stat. Security context of file is shown by -Z option.

Signed-off-by:  Yoshinori Sato <ysato at users.sourceforge.jp>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-stat-04.v3.patch
Type: application/octet-stream
Size: 10382 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/52b62a04/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 08:48:07 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:07 +0900
Subject: [PATCH 5/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>

[5/8]  busybox-coreutils-05-ls.v3.patch
 - -Z option support for ls. Security context of file is shown by -Z option.
   In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.

Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-ls-05.v3.patch
Type: application/octet-stream
Size: 592 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/06b7e03d/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 08:48:17 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:17 +0900
Subject: [PATCH 6/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174817.ee9be179.ynakam@hitachisoft.jp>

[6/8] busybox-coreutils-06-id.v3.patch
 - -Z option support for id. Security context of process is shown by -Z option.

Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>





-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-id-06.v3.patch
Type: application/octet-stream
Size: 2727 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/4f2956ab/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 08:48:23 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:48:23 +0900
Subject: [PATCH 7/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>

[7/8] busybox-coreutils-07-chcon.v3.patch
 - chcon - change security context of file. 

Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>





-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-chcon-07.v3.patch
Type: application/octet-stream
Size: 6322 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/421ad5e7/attachment-0002.obj 

From ynakam at hitachisoft.jp  Fri Feb 23 08:49:29 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 23 Feb 2007 17:49:29 +0900
Subject: [PATCH 8/8] busybox -- SELinux option support for coreutils: ver3
Message-ID: <20070223174929.18e547ea.ynakam@hitachisoft.jp>

[8/8] busybox-coreutils-08-runcon.v3.patch
 - runcon - run application with specified security context.
  runcon provides one of the core facilities to run application with explicitly
  specified security context. It enables users to run their application under
  the least privilege set explicitly.

Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>






-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-runcon-08.v3.patch
Type: application/octet-stream
Size: 4463 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/805dd01b/attachment-0002.obj 

From wharms at bfs.de  Fri Feb 23 11:07:02 2007
From: wharms at bfs.de (walter harms)
Date: Fri, 23 Feb 2007 12:07:02 +0100
Subject: gethostbyname Resolver Error
In-Reply-To: <f29fbf3a0702221122p2557c9e4se142623d3dbbfefc@mail.gmail.com>
References: <f29fbf3a0702221036n640bc78r7cce2169c49d6c2@mail.gmail.com>
	<f29fbf3a0702221122p2557c9e4se142623d3dbbfefc@mail.gmail.com>
Message-ID: <45DECAD6.4040104@bfs.de>

hi Andrei,
i am sorry that you have that problem, personally, i would try the ulibc mailing list.
This is the busybox ml. A tool that provides stuff in /bin like ls,cp,mv etc.
it *can* use uclib but also any other libc.

re,
 walter



Andrei Popov wrote:
> Hi,
> 
> I am running BusyBox on WRT54G as part of OpenWRT firmware.  WRT
> serves a local WLAN, being connected via a leased line to ISP, and
> then through a PPTP VPN to Internet.  ISP runs several VPN gateway
> servers, all are replying to a common host name -- let's call it
> vpn.corbina.net but with different IP addresses -- 195.14.38.x.
> 
> Up until recently there were fewer than 20 servers in the VPN pool,
> but a few days ago ISP has added several new servers to cope with the
> load, pushing the total number of them to 23.  From that moment
> uClib's gethostbyname stopped resolving names to IP addresses and
> returns an unkown resolver error:
> 
> $ ping vpn.corbina.net
> ping: vpn.corbina.net: Resolver error
> 
> $ nslookup vpn.corbina.net
> Server:         localhost
> Address:        127.0.0.1
> 
> nslookup: vpn.corbina.net: Resolver error
> 
> It would seem that because of a large number of entries returned by
> the DNS server, gethostbyname fails to provide an name to IP mapping.
> Are there any known work-arounds to this?
> 
> 
> Thanks & please keep me on cc, as I am not subscribed to the mailing list.
> 
> Andrei
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
> 
> 


From Kim.Heino at bluegiga.com  Fri Feb 23 13:28:22 2007
From: Kim.Heino at bluegiga.com (Kim B. Heino)
Date: Fri, 23 Feb 2007 15:28:22 +0200
Subject: dpkg - updating a package can break dependencies
Message-ID: <45DEEBF6.8030907@bluegiga.com>

Hello,

When installing a new package with dpkg dependencies are checked 
correctly. But when I try to update an existing package, the 
dependencies are checked against the old package, not against new 
package. Thus the new package can break dependencies.

Attached patch fixes this problem. It should apply cleanly to todays 
snapshot.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dpkg-collision.patch
Type: text/x-patch
Size: 507 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070223/af07ba1c/attachment-0002.bin 

From dick at streefland.net  Fri Feb 23 22:31:33 2007
From: dick at streefland.net (Dick Streefland)
Date: Fri, 23 Feb 2007 23:31:33 +0100
Subject: memory leak in awk applet
Message-ID: <20070223223133.GB6022@streefland.xs4all.nl>

I noticed that awk leaks memory when you read the $<N> variables
repeatably. You can easily reproduce this with the following script:

BEGIN{
	for (;;)
	{
		"echo foo" | getline;
		foo = $1;
	}
}

The problem is that the same string is allocated by bb_xstrdup() over
and over again. The following patch stops the leak, but I'm not
completely sure if it is the right fix:

diff -pu busybox-1.4.1/editors/awk.c.orig busybox-1.4.1/editors/awk.c
--- busybox-1.4.1/editors/awk.c.orig	2007-01-24 22:34:50.000000000 +0100
+++ busybox-1.4.1/editors/awk.c	2007-02-23 23:28:36.000000000 +0100
@@ -740,7 +740,7 @@ static var *copyvar(var *dest, const var
 {
 	if (dest != src) {
 		clrvar(dest);
-		dest->type |= (src->type & ~VF_DONTTOUCH);
+		dest->type |= (src->type & ~(VF_DONTTOUCH|VF_FSTR));
 		dest->number = src->number;
 		if (src->string)
 			dest->string = xstrdup(src->string);

-- 
Dick


From dick at streefland.net  Fri Feb 23 23:00:31 2007
From: dick at streefland.net (Dick Streefland)
Date: Sat, 24 Feb 2007 00:00:31 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <20070223230031.GA23727@streefland.xs4all.nl>

On Friday 2007-02-02 23:14, Brion Finlay wrote:
| Alternatively, since awk is being invoked anyway, this line could be changed
| to just a single line awk invocation to do away with the sed, the grep, and
| the echo:
| 
| awk '/^#? ?CONFIG_/ {gsub(/\"/,"\\\\\"",$0); print "\"" $0 "\\n\"";}'
| $config
| 
| I tested this change under bash and dash and it also works in both shells.

I just ran into this dash/bash problem and (before I found this
discussion) worked around it by replacing the whole line by a single
sed invocation:

sed '/^#\? \?CONFIG/!d; s/"/\\"/g; s/.*/"&\\n"/' $config

-- 
Dick


From Alexander at Kriegisch.name  Sat Feb 24 11:33:59 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 12:33:59 +0100
Subject: Replacing CR (\r) character with sed
Message-ID: <45E022A7.4010002@Kriegisch.name>

I wonder how I can make sed work as a replacement for dos2unix. I do
know how to strip CR characters with tr or dos2unix, but I have reasons
to do it with sed besides just wanting to know how. Those reasons include
  - a bug in some tr versions making it strip special characters like
    German umlauts unintentionally (I have no influence on the version
    of tr used by other people) and
  - dos2unix not being part of our DSL router firmware mod's busybox
    (again, I have it, but many others don't).

I played around with several variants working in other sed versions,
tried to use basic regex mode as well as the -r switch for extended
regex syntax, but to no avail. BTW, I have not tried to put the sed
script into a file, as I want to use it as a command line argument.

Hints are most welcome.
Regards
-- 
Alexander Kriegisch


From vda.linux at googlemail.com  Sat Feb 24 12:31:34 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 13:31:34 +0100
Subject: ash test suite
In-Reply-To: <f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>
References: <45B719C7.8010503@bfs.de> <45BF6F79.4020601@bfs.de>
	<f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>
Message-ID: <200702241331.34553.vda.linux@googlemail.com>

Guys,

On Thursday 01 February 2007 14:23, Yuwen Dai wrote:
> On 1/31/07, walter harms <wharms at bfs.de> wrote:
> >
> > your are right,
> > note:  have removed the original diff for a 'diff -y | less' to see more
> > clearly the differences.
> > take also a look at the readme inside the ash* tests.
> 
> 
> I see ash-* directories as well as test files in the same directory. While
> in Bash testsuite, all test files are in same level, no subdirectories.  Did
> you intend to put all all the test files into subdirectories?

Can you send me the testsuite?

If it is not polished, send it as-is anyway.
--
vda


From vda.linux at googlemail.com  Sat Feb 24 12:57:55 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 13:57:55 +0100
Subject: Replacing CR (\r) character with sed
In-Reply-To: <45E022A7.4010002@Kriegisch.name>
References: <45E022A7.4010002@Kriegisch.name>
Message-ID: <200702241357.55093.vda.linux@googlemail.com>

On Saturday 24 February 2007 12:33, Alexander Kriegisch wrote:
> I wonder how I can make sed work as a replacement for dos2unix. I do
> know how to strip CR characters with tr or dos2unix, but I have reasons
> to do it with sed besides just wanting to know how. Those reasons include
>   - a bug in some tr versions making it strip special characters like
>     German umlauts unintentionally (I have no influence on the version
>     of tr used by other people) and
>   - dos2unix not being part of our DSL router firmware mod's busybox
>     (again, I have it, but many others don't).
> 
> I played around with several variants working in other sed versions,
> tried to use basic regex mode as well as the -r switch for extended
> regex syntax, but to no avail. BTW, I have not tried to put the sed
> script into a file, as I want to use it as a command line argument.

bash-3.2# echo -ne 'dos\r\ntext\r\n' | hexdump -C
00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
0000000b

bash-3.2# echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
00000009

--
vda


From Alexander at Kriegisch.name  Sat Feb 24 13:14:12 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 14:14:12 +0100
Subject: Replacing CR (\r) character with sed
In-Reply-To: <200702241357.55093.vda.linux@googlemail.com>
References: <45E022A7.4010002@Kriegisch.name>
	<200702241357.55093.vda.linux@googlemail.com>
Message-ID: <45E03A24.6010209@Kriegisch.name>

Sorry, Denis,

I want to do this with busybox (ash, not bash). I know it works in a
bash, but when I try this in my busybox, I get the following:

$ uname -a
Linux fritz.box 2.6.13.1-ohio #1 Sun Feb 18 14:18:07 CET 2007 mips unknown
$ echo -ne 'dos\r\ntext\r\n' | hexdump -C
00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
0000000b
$ echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
0000000b

--
Alexander Kriegisch

> On Saturday 24 February 2007 12:33, Alexander Kriegisch wrote:
>> I wonder how I can make sed work as a replacement for dos2unix. I do
>> know how to strip CR characters with tr or dos2unix, but I have reasons
>> to do it with sed besides just wanting to know how. Those reasons include
>>   - a bug in some tr versions making it strip special characters like
>>     German umlauts unintentionally (I have no influence on the version
>>     of tr used by other people) and
>>   - dos2unix not being part of our DSL router firmware mod's busybox
>>     (again, I have it, but many others don't).
>>
>> I played around with several variants working in other sed versions,
>> tried to use basic regex mode as well as the -r switch for extended
>> regex syntax, but to no avail. BTW, I have not tried to put the sed
>> script into a file, as I want to use it as a command line argument.
> 
> bash-3.2# echo -ne 'dos\r\ntext\r\n' | hexdump -C
> 00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
> 0000000b
> 
> bash-3.2# echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
> 00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
> 00000009
> 
> --
> vda
> 


From strange at nsk.no-ip.org  Sat Feb 24 13:26:16 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Sat, 24 Feb 2007 13:26:16 +0000
Subject: Replacing CR (\r) character with sed
In-Reply-To: <45E03A24.6010209@Kriegisch.name>
References: <45E022A7.4010002@Kriegisch.name>
	<200702241357.55093.vda.linux@googlemail.com>
	<45E03A24.6010209@Kriegisch.name>
Message-ID: <20070224132616.GA12329@nsk.no-ip.org>

On Sat, Feb 24, 2007 at 02:14:12PM +0100, Alexander Kriegisch wrote:
> Sorry, Denis,
> 
> I want to do this with busybox (ash, not bash). I know it works in a
> bash, but when I try this in my busybox, I get the following:
> 
> $ uname -a
> Linux fritz.box 2.6.13.1-ohio #1 Sun Feb 18 14:18:07 CET 2007 mips unknown
> $ echo -ne 'dos\r\ntext\r\n' | hexdump -C
> 00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
> 0000000b
> $ echo -ne 'dos\r\ntext\r\n' | sed $'s/\r//g' | hexdump -C
> 00000000  64 6f 73 0d 0a 74 65 78  74 0d 0a                 |dos..text..|
> 0000000b

$ echo -ne 'dos\r\ntext\r\n' |  sed "s/`echo -ne '\r'`//g" | hexdump -C
00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
00000009

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070224/a62e5416/attachment-0002.pgp 

From Alexander at Kriegisch.name  Sat Feb 24 13:48:58 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 14:48:58 +0100
Subject: Replacing CR (\r) character with sed
In-Reply-To: <20070224132616.GA12329@nsk.no-ip.org>
References: <45E022A7.4010002@Kriegisch.name>
	<200702241357.55093.vda.linux@googlemail.com>
	<45E03A24.6010209@Kriegisch.name>
	<20070224132616.GA12329@nsk.no-ip.org>
Message-ID: <45E0424A.3080704@Kriegisch.name>

> $ echo -ne 'dos\r\ntext\r\n' |  sed "s/`echo -ne '\r'`//g" | hexdump -C
> 00000000  64 6f 73 0a 74 65 78 74  0a                       |dos.text.|
> 00000009

Bingo! Thanks. :)
--
Alexander Kriegisch


From vda.linux at googlemail.com  Sat Feb 24 15:01:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:11 +0100
Subject: [PATCH 5/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>
References: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>
Message-ID: <200702241601.11806.vda.linux@googlemail.com>

On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
> [5/8]  busybox-coreutils-05-ls.v3.patch
>  - -Z option support for ls. Security context of file is shown by -Z option.
>    In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.
> 
> Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>

+       USE_FEATURE_AUTOWIDTH("T:w:")
+    USE_SELINUX("Z");

Use tab here instead of four spaces.
--
vda


From vda.linux at googlemail.com  Sat Feb 24 15:01:06 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:06 +0100
Subject: [PATCH 0/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174733.e67e5fc6.ynakam@hitachisoft.jp>
References: <20070223174733.e67e5fc6.ynakam@hitachisoft.jp>
Message-ID: <200702241601.06224.vda.linux@googlemail.com>

On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> Hi.
> 
> The following patches provide SELinux options(like -Z) and applets to coreutils.
> To maintain SELinux system, some commands must be extended to be able to handle 
> attribute in SELinux(such as security context).
> 
> Current patch is version 3. 
> We submitted previous patches some weeks ago, and some reviews were done.
> chcon and runcon applets are added, since last patch.
> I think that's all for coreutils.

Thanks for persistent effort. Review follows.
--
vda


From vda.linux at googlemail.com  Sat Feb 24 15:01:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:13 +0100
Subject: [PATCH 8/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174929.18e547ea.ynakam@hitachisoft.jp>
References: <20070223174929.18e547ea.ynakam@hitachisoft.jp>
Message-ID: <200702241601.13536.vda.linux@googlemail.com>

On Friday 23 February 2007 09:49, Yuichi Nakamura wrote:
> [8/8] busybox-coreutils-08-runcon.v3.patch
>  - runcon - run application with specified security context.
>   runcon provides one of the core facilities to run application with explicitly
>   specified security context. It enables users to run their application under
>   the least privilege set explicitly.
> 
> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>

+       char *role = NULL;
+       char *range = NULL;
+       char *user = NULL;
+       char *type = NULL;
+       char *context = NULL;
+       unsigned int opts;
+
+       selinux_or_die();
+
+       opts = getopt32(argc, argv, "r:t:u:l:ch", &role, &type, &user, &range);
+
+       if (!role && !type && !user && !range) {
+               if (optind >= argc)
+                       bb_error_msg_and_die("must specify -c, -t, -u, -l, -r, or context");
+               context = argv[optind++];
+       }

Testing if(!(opt & MASK_role_type_user_range)) will result in smaller code.
--
vda


From vda.linux at googlemail.com  Sat Feb 24 15:01:12 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:12 +0100
Subject: [PATCH 7/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>
References: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>
Message-ID: <200702241601.12758.vda.linux@googlemail.com>

On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
> [7/8] busybox-coreutils-07-chcon.v3.patch
>  - chcon - change security context of file. 
> 
> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>

+#define OPT_QUIET              (1<<3)  /* 'f' */
+#define OPT_REFERENCE          (1<<4)  /* '\n' */
+#define OPT_USER               (1<<5)  /* 'u' */

...


+       {"quiet",       0,      NULL,   'f'},
+       {"reference",   1,      NULL,   '\n' }, /* no short option */
+       {"user",        1,      NULL,   'u' },
+       {"role",        1,      NULL,   'r' },
+       {"type",        1,      NULL,   't' },
+       {"range",       1,      NULL,   'l' },
+       {"verbose",     0,      NULL,   'v' },
+       {NULL,          0,      NULL,   0 },
+};
+#endif
+
+int chcon_main(int argc, char *argv[]);
+int chcon_main(int argc, char *argv[])
+{
+       char *reference_file;
+       char **target_files;
+       int i, opts, errors = 0;
+
+#ifdef CONFIG_FEATURE_CHCON_LONG_OPTIONS
+       applet_long_options = chcon_options;
+#endif
+       opt_complementary = "-1"  /* at least 1 param */
+               ":q--v:v--q";     /* 'verbose' and 'quiet' are exclusive */
+       opts = getopt32(argc, argv, "Rchf\n:u:r:t:l:v",
+                       &reference_file, &user, &role, &type, &range);
+       if (opts & OPT_REFERENCE) {
+               if (opts & OPT_COMPONENT_SPECIFIED)
+                       bb_error_msg_and_die("conflicting security context specifiers given");


Again see wget.c how to not pass '\n' to getopt32.

You can make OPT_REFERENCE and OPT_COMPONENT_SPECIFIED
exclusive by using suitable opt_complementary.
--
vda


From vda.linux at googlemail.com  Sat Feb 24 15:01:14 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:14 +0100
Subject: [PATCH 2/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174747.4ced9178.ynakam@hitachisoft.jp>
References: <20070223174747.4ced9178.ynakam@hitachisoft.jp>
Message-ID: <200702241601.14214.vda.linux@googlemail.com>

On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> [2/8] busybox-coreutils-02-copy.v3.patch
>   - cp: -Z,-c option support. 
>       -c option: security context is preserved during file copy.
>   - mv 
>     In SELinux, it is recommended to preserve security context 
>     when file is moved. By this patch, file context is preserved 
>     during file move.
>   - install
>     When file is copied by install, security context of installed file 
>     becomes different from value configured in file_contexts file.
>     By this patch, security context is set according to file_contexts file.
>     -Z option: security context can be set during file copy.
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>

        FILEUTILS_MAKE_SOFTLINK = 0x40,
+#if ENABLE_SELINUX
+       FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
+       FILEUTILS_SET_SECURITY_CONTEXT = 0x100
+#endif
 };
-#define FILEUTILS_CP_OPTSTR "pdRfils"

+#define FILEUTILS_CP_OPTSTR "pdRfils" USE_SELINUX("c\b")
+
 extern const char *applet_name;
...
        { "owner",               0, NULL, 'o' },
+#if ENABLE_SELINUX
+       { "context",             1, NULL, 'Z' },
+       { "preserve_context",    0, NULL, '\b'},
+       { "preserve-context",    0, NULL, '\b'},
+
+#endif
        { 0, 0, 0, 0 }

Hmmm... we typically use high ascii values for this kind
of "fake" option chars. Example in wget.c:

        static const struct option wget_long_options[] = {
...
                { "user-agent",       required_argument, NULL, 'U' },
                { "passive-ftp",      no_argument, NULL, 0xff },
                { "header",           required_argument, NULL, 0xfe },
                { 0, 0, 0, 0 }
        };
        applet_long_options = wget_long_options;
#endif
        opt_complementary = "-1" USE_FEATURE_WGET_LONG_OPTIONS(":\xfe::");
        opt = getopt32(argc, argv, "cqO:P:Y:U:",   ...);

Notice that in this example we avoid giving "strange" chars to getopt32
*at all*, preventing our applets from having "hidden" options a-la
"wget $'-\xff' ftp://kernel.org/".

Can you avoid passing '\b' to getopt32 in install etc?


+                       bb_error_msg("warning: ignoring --preserve-context. "
+                                        "The kernel is not SELinux-enabled.\n" );

bb_error_msg don't need trailing '\n'.
I already mentioned that in the previous round of review.


+#if ENABLE_SELINUX
+       if ((flags & FILEUTILS_PRESERVE_SECURITY_CONTEXT) && is_selinux_enabled() > 0){
+               security_context_t con;
+               if (lgetfilecon (source, &con) >= 0){
+                       if (setfscreatecon(con) < 0) {
+                               bb_perror_msg ("cannot set setfscreatecon %s", con);
+                               freecon(con);
+                               return -1;
+                       }
+               }else{
+                       if( errno == ENOTSUP || errno == ENODATA ) {
+                               setfscreatecon(NULL);
+                       } else {
+                               bb_perror_msg ("cannot  lgetfilecon %s", source);
+                               return -1;
+                       }
+               }
+       }
+#endif

Usage of whitespace is very different from the rest of busybox code here.

--
vda


From vda.linux at googlemail.com  Sat Feb 24 15:01:14 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 16:01:14 +0100
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070223174739.300d673a.ynakam@hitachisoft.jp>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
Message-ID: <200702241601.14808.vda.linux@googlemail.com>

On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> [1/8] busybox-coreutils-common-01.v3.patch
>  - common component for SELinux options, applets
> 
> Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>

        "       -i      Interactive, prompt before overwrite\n" \
        "       -R,-r   Copy directories recursively\n" \
-       "       -l,-s   Create (sym)links"
+       "       -l,-s   Create (sym)links\n"

 #define cpio_trivial_usage \

Why?


 USE_RPM2CPIO(APPLET(rpm2cpio, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_RUNCON(APPLET(runcon, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
 USE_RUN_PARTS(APPLET_ODDNAME(run-parts, run_parts, _BB_DIR_BIN, _BB_SUID_NEVER, run_parts))
 USE_RUNLEVEL(APPLET(runlevel, _BB_DIR_SBIN, _BB_SUID_NEVER))

*Must* be in ASCII order.


--
vda


From vda.linux at googlemail.com  Sat Feb 24 17:03:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 24 Feb 2007 18:03:37 +0100
Subject: memory leak in awk applet
In-Reply-To: <20070223223133.GB6022@streefland.xs4all.nl>
References: <20070223223133.GB6022@streefland.xs4all.nl>
Message-ID: <200702241803.37090.vda.linux@googlemail.com>

On Friday 23 February 2007 23:31, Dick Streefland wrote:
> I noticed that awk leaks memory when you read the $<N> variables
> repeatably. You can easily reproduce this with the following script:
> 
> BEGIN{
> 	for (;;)
> 	{
> 		"echo foo" | getline;
> 		foo = $1;
> 	}
> }
> 
> The problem is that the same string is allocated by bb_xstrdup() over
> and over again. The following patch stops the leak, but I'm not
> completely sure if it is the right fix:
> 
> diff -pu busybox-1.4.1/editors/awk.c.orig busybox-1.4.1/editors/awk.c
> --- busybox-1.4.1/editors/awk.c.orig	2007-01-24 22:34:50.000000000 +0100
> +++ busybox-1.4.1/editors/awk.c	2007-02-23 23:28:36.000000000 +0100
> @@ -740,7 +740,7 @@ static var *copyvar(var *dest, const var
>  {
>  	if (dest != src) {
>  		clrvar(dest);
> -		dest->type |= (src->type & ~VF_DONTTOUCH);
> +		dest->type |= (src->type & ~(VF_DONTTOUCH|VF_FSTR));
>  		dest->number = src->number;
>  		if (src->string)
>  			dest->string = xstrdup(src->string);

Looks ok to me. Applied, thanks!
--
vda


From Alexander at Kriegisch.name  Sat Feb 24 20:10:04 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 24 Feb 2007 21:10:04 +0100
Subject: tar -t segmentation fault
Message-ID: <45E09B9C.8080302@Kriegisch.name>

I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
when listing tar archives, no matter whether they are uncompressed or
compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
problems, though.

Could ba a bug. Please acknowledge or ask me for more information. I
think it ought to be easily reproducible.

Regards
-- 
Alexander Kriegisch


From natanael.copa at gmail.com  Sun Feb 25 00:43:02 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 01:43:02 +0100
Subject: tar -t segmentation fault
In-Reply-To: <45E09B9C.8080302@Kriegisch.name>
References: <45E09B9C.8080302@Kriegisch.name>
Message-ID: <20070225014302.a30264ab.natanael.copa@gmail.com>

On Sat, 24 Feb 2007 21:10:04 +0100
Alexander Kriegisch <Alexander at Kriegisch.name> wrote:

> I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> when listing tar archives, no matter whether they are uncompressed or
> compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> problems, though.
> 
> Could ba a bug. Please acknowledge or ask me for more information. I
> think it ought to be easily reproducible.

I can confirm this on x86/uclibc. I have tested with and wihtout the
patches for 1.4.1.

gdb output:

This GDB was configured as "i386-gentoo-linux-uclibc"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set args tar -ztf /var/cache/distfiles/dnrd-2.20.1.tar.gz
(gdb) run
Starting program: /busybox/busybox-1.4.1/busybox_unstripped tar -ztf /var/cache/distfiles/dnrd-2.20.1.tar.gz
warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4

Program received signal SIGSEGV, Segmentation fault.
tar_main (argc=3, argv=0xffd77798) at archival/tar.c:835
835                             llist_t *temp = excludes->link;
(gdb) bt
#0  tar_main (argc=3, argv=0xffd77798) at archival/tar.c:835
#1  0x08048342 in run_applet_by_name (name=0xffd77b74 "tar", argc=3, 
    argv=0xffd77798) at applets/applets.c:489
#2  0x08048491 in busybox_main (argc=4, argv=0xffd77794)
    at applets/busybox.c:143
#3  0x080482fb in run_applet_by_name (name=0xffd77b61 "busybox_unstripped", 
    argc=4, argv=0xffd77794) at applets/applets.c:480
#4  0x080483bd in main (argc=-2656364, argv=0xffd77794) at applets/busybox.c:72
(gdb) 

config:
al-1.5 busybox-1.4.1 # sed 's/\#.*//; /^$/d' .config
CONFIG_HAVE_DOT_CONFIG=y
CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe"
CONFIG_STATIC=y
CONFIG_DEBUG=y
CONFIG_DEBUG_PESSIMIZE=y
CONFIG_NO_DEBUG_LIB=y
CONFIG_INSTALL_APPLET_SYMLINKS=y
CONFIG_PREFIX="./_install"
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SIZE_VS_SPEED=2
CONFIG_BUNZIP2=y
CONFIG_GUNZIP=y
CONFIG_GZIP=y
CONFIG_TAR=y
CONFIG_FEATURE_TAR_CREATE=y
CONFIG_FEATURE_TAR_BZIP2=y
CONFIG_FEATURE_TAR_LZMA=y
CONFIG_FEATURE_TAR_FROM=y
CONFIG_FEATURE_TAR_GZIP=y
CONFIG_FEATURE_TAR_COMPRESS=y
CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y
CONFIG_FEATURE_LESS_MAXLINES=
CONFIG_FEATURE_SH_IS_NONE=y
CONFIG_FEATURE_COMMAND_HISTORY=
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=


From vda.linux at googlemail.com  Sun Feb 25 00:44:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 01:44:03 +0100
Subject: tar -t segmentation fault
In-Reply-To: <45E09B9C.8080302@Kriegisch.name>
References: <45E09B9C.8080302@Kriegisch.name>
Message-ID: <200702250144.03251.vda.linux@googlemail.com>

On Saturday 24 February 2007 21:10, Alexander Kriegisch wrote:
> I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> when listing tar archives, no matter whether they are uncompressed or
> compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> problems, though.
> 
> Could ba a bug. Please acknowledge or ask me for more information. I
> think it ought to be easily reproducible.

I think it's http://bugs.busybox.net/view.php?id=1183
--
vda


From natanael.copa at gmail.com  Sun Feb 25 00:51:08 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 01:51:08 +0100
Subject: ash test suite
In-Reply-To: <200702241331.34553.vda.linux@googlemail.com>
References: <45B719C7.8010503@bfs.de> <45BF6F79.4020601@bfs.de>
	<f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>
	<200702241331.34553.vda.linux@googlemail.com>
Message-ID: <20070225015108.0d679f85.natanael.copa@gmail.com>

On Sat, 24 Feb 2007 13:31:34 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> Guys,
> 
> On Thursday 01 February 2007 14:23, Yuwen Dai wrote:
> > On 1/31/07, walter harms <wharms at bfs.de> wrote:
> > >
> > > your are right,
> > > note:  have removed the original diff for a 'diff -y | less' to see more
> > > clearly the differences.
> > > take also a look at the readme inside the ash* tests.
> > 
> > 
> > I see ash-* directories as well as test files in the same directory. While
> > in Bash testsuite, all test files are in same level, no subdirectories.  Did
> > you intend to put all all the test files into subdirectories?
> 
> Can you send me the testsuite?
> 
> If it is not polished, send it as-is anyway.

yes. would be nice to have it in svn. I know some things to test that i
know will fail. For example:

function foo() {
}

[ "yes" || "" ] && echo hello

[[ "yes" && "yes" ]] && echo hello

I dont care so much about "function", but I could probalby reduce
my bash->ash patches with 50% if test could do [ ... && ... ]

(im patching bash scripts to make them run on busybox ash)

There are some issues with arrays too but I expect that to be
non-trivial to fix in bb ash.



From vda.linux at googlemail.com  Sun Feb 25 00:52:16 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 01:52:16 +0100
Subject: tar -t segmentation fault
In-Reply-To: <20070225014302.a30264ab.natanael.copa@gmail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<20070225014302.a30264ab.natanael.copa@gmail.com>
Message-ID: <200702250152.16360.vda.linux@googlemail.com>

On Sunday 25 February 2007 01:43, Natanael Copa wrote:
> On Sat, 24 Feb 2007 21:10:04 +0100
> Alexander Kriegisch <Alexander at Kriegisch.name> wrote:
> 
> > I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> > when listing tar archives, no matter whether they are uncompressed or
> > compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> > problems, though.
> > 
> > Could ba a bug. Please acknowledge or ask me for more information. I
> > think it ought to be easily reproducible.
> 
> I can confirm this on x86/uclibc. I have tested with and wihtout the
> patches for 1.4.1.

http://bugs.busybox.net/view.php?id=1183 - fixed.

Does svn work for you?
--
vda


From vda.linux at googlemail.com  Sun Feb 25 00:54:22 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 01:54:22 +0100
Subject: ash test suite
In-Reply-To: <20070225015108.0d679f85.natanael.copa@gmail.com>
References: <45B719C7.8010503@bfs.de>
	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
Message-ID: <200702250154.22207.vda.linux@googlemail.com>

On Sunday 25 February 2007 01:51, Natanael Copa wrote:
> On Sat, 24 Feb 2007 13:31:34 +0100
> Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > Can you send me the testsuite?
> > 
> > If it is not polished, send it as-is anyway.
> 
> yes. would be nice to have it in svn. I know some things to test that i
> know will fail. For example:
> 
> function foo() {
> }
> 
> [ "yes" || "" ] && echo hello
> 
> [[ "yes" && "yes" ]] && echo hello
> 
> I dont care so much about "function", but I could probalby reduce
> my bash->ash patches with 50% if test could do [ ... && ... ]

bash-3.2# [ "yes" || "" ] && echo hello
bash: [: missing `]'
bash: : command not found

I suspect a bug in the example.
--
vda


From natanael.copa at gmail.com  Sun Feb 25 01:06:10 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 02:06:10 +0100
Subject: eject and umount /dev/cdrom fails on busybox-1.4.1
Message-ID: <20070225020610.e7aaeeaa.natanael.copa@gmail.com>

I noticed that "eject" fails on busybox-1.4.1. Looks like it fails on
umount. 

~ $ mount /dev/cdrom
~ $ umount /dev/cdrom
umount: cannot umount /dev/cdrom: Invalid argument
~ $ mount
rootfs on / type rootfs (rw)
/dev/none on / type tmpfs (rw)
proc on /proc type proc (rw)
none on /sys type sysfs (rw)
mdev on /dev type tmpfs (rw)
none on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/md1 on /var type ext3 (rw,data=ordered)
/dev/cdrom on /media/cdrom type iso9660 (ro)

umount /media/cdrom works.

Funny enough, unmouting /dev/loop0 works:

~ $ mount -o loop /media/cdrom/modules.cmg /lib/modules/
mount: /dev/loop0 is write-protected, mounting read-only
mount: /dev/loop0 is write-protected, mounting read-only
mount: /dev/loop0 is write-protected, mounting read-only
mount: /dev/loop0 is write-protected, mounting read-only
~ $ mount
rootfs on / type rootfs (rw)
/dev/none on / type tmpfs (rw)
proc on /proc type proc (rw)
none on /sys type sysfs (rw)
mdev on /dev type tmpfs (rw)
none on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/md1 on /var type ext3 (rw,data=ordered)
/dev/cdrom on /media/cdrom type iso9660 (ro)
/dev/loop0 on /lib/modules type cramfs (ro)
~ $ umount /dev/loop0
~ $

/dev/cdrom is a symbolic link to /dev/hda

here is the strace output (gdb dont work on that pax'ed kernel, sorry):

open("/proc/mounts", O_RDONLY)          = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x59d0ffd0) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "rootfs / rootfs rw 0 0\n/dev/none"..., 4096) = 251
read(4, "", 4096)                       = 0
close(4)                                = 0
readlink("/dev", 0x59d0e0ec, 4095)      = -1 EINVAL (Invalid argument)
readlink("/dev/cdrom", "hda", 4095)     = 3
readlink("/dev/hda", 0x59d0e0ec, 4095)  = -1 EINVAL (Invalid argument)
oldumount("/dev/cdrom")                 = -1 EINVAL (Invalid argument)
write(2, "umount", 6umount)                   = 6
write(2, ": ", 2: )                       = 2
write(2, "cannot umount ", 14cannot umount )          = 14
write(2, "/dev/cdrom", 10/dev/cdrom)              = 10
write(2, ": ", 2: )                       = 2
write(2, "Invalid argument", 16Invalid argument)        = 16
write(2, "\n", 1
)                       = 1
_exit(1)                                = ?
Process 30996 detached


From psmith at netezza.com  Sun Feb 25 02:31:05 2007
From: psmith at netezza.com (Paul Smith)
Date: Sat, 24 Feb 2007 21:31:05 -0500
Subject: ash test suite
In-Reply-To: <200702250154.22207.vda.linux@googlemail.com>
References: <45B719C7.8010503@bfs.de>
	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
	<200702250154.22207.vda.linux@googlemail.com>
Message-ID: <1172370665.16437.19.camel@homebase>

On Sun, 2007-02-25 at 01:54 +0100, Denis Vlasenko wrote:

> bash-3.2# [ "yes" || "" ] && echo hello
> bash: [: missing `]'
> bash: : command not found
> 
> I suspect a bug in the example.

Correct; this is not valid shell syntax.  Perhaps they mean:

  [ "yes" -o "" ] && echo hello

You can't use a shell "or" operator (||) inside a test invocation; the
|| will end the command.


From Alexander at Kriegisch.name  Sun Feb 25 06:01:58 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 25 Feb 2007 07:01:58 +0100
Subject: tar -t segmentation fault
In-Reply-To: <200702250152.16360.vda.linux@googlemail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<20070225014302.a30264ab.natanael.copa@gmail.com>
	<200702250152.16360.vda.linux@googlemail.com>
Message-ID: <45E12656.9060103@Kriegisch.name>

> http://bugs.busybox.net/view.php?id=1183 - fixed.
> 
> Does svn work for you?

I applied
http://www.busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/archival/tar.c?rev=17772&r1=17740&r2=17772&makepatch=1&diff_format=u

It works, thank you.
--
Alexander Kriegisch


From natanael.copa at gmail.com  Sun Feb 25 13:42:51 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 14:42:51 +0100
Subject: ash test suite
In-Reply-To: <200702250154.22207.vda.linux@googlemail.com>
References: <45B719C7.8010503@bfs.de>
	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
	<200702250154.22207.vda.linux@googlemail.com>
Message-ID: <20070225144251.80d33097.natanael.copa@gmail.com>

On Sun, 25 Feb 2007 01:54:22 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On Sunday 25 February 2007 01:51, Natanael Copa wrote:
> > On Sat, 24 Feb 2007 13:31:34 +0100
> > Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > > Can you send me the testsuite?
> > > 
> > > If it is not polished, send it as-is anyway.
> > 
> > yes. would be nice to have it in svn. I know some things to test that i
> > know will fail. For example:
> > 
> > function foo() {
> > }
> > 
> > [ "yes" || "" ] && echo hello
> > 
> > [[ "yes" && "yes" ]] && echo hello
> > 
> > I dont care so much about "function", but I could probalby reduce
> > my bash->ash patches with 50% if test could do [ ... && ... ]
> 
> bash-3.2# [ "yes" || "" ] && echo hello
> bash: [: missing `]'
> bash: : command not found
> 
> I suspect a bug in the example.

Yes it was a bug. Sorry.

[[ "yes" || "" ]] echo hello

Natanael Copa


From natanael.copa at gmail.com  Sun Feb 25 15:10:15 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 16:10:15 +0100
Subject: tar -t segmentation fault
In-Reply-To: <200702250152.16360.vda.linux@googlemail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<20070225014302.a30264ab.natanael.copa@gmail.com>
	<200702250152.16360.vda.linux@googlemail.com>
Message-ID: <20070225161015.7e1a80a1.natanael.copa@gmail.com>

On Sun, 25 Feb 2007 01:52:16 +0100
Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On Sunday 25 February 2007 01:43, Natanael Copa wrote:
> > On Sat, 24 Feb 2007 21:10:04 +0100
> > Alexander Kriegisch <Alexander at Kriegisch.name> wrote:
> > 
> > > I always get segmentation faults in busybox 1.4.1 on my MIPS-based box
> > > when listing tar archives, no matter whether they are uncompressed or
> > > compressed with -z (gzip) or -j (bzip2). I can un-tar them without any
> > > problems, though.
> > > 
> > > Could ba a bug. Please acknowledge or ask me for more information. I
> > > think it ought to be easily reproducible.
> > 
> > I can confirm this on x86/uclibc. I have tested with and wihtout the
> > patches for 1.4.1.
> 
> http://bugs.busybox.net/view.php?id=1183 - fixed.
> 
> Does svn work for you?

Applied same patch as Alexander and it works. Could it be added to the fixes-1.4.1?

thanks

> --
> vda


From natanael.copa at gmail.com  Sun Feb 25 15:17:36 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Sun, 25 Feb 2007 16:17:36 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
Message-ID: <20070225161736.d3cd295d.natanael.copa@gmail.com>

The attatched patch adds support for group with the --chuid.

  start-stop-daemon --chuid user:group

Patch is against 1.4.1.

btw... the usage message is wrong:
 
  -U|--chuid <username>|<uid>     Start process with this name

its -c and not -U for --chuid short opt.

thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-ssd-chuid.patch
Type: application/octet-stream
Size: 493 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070225/09956c9f/attachment-0002.obj 

From vda.linux at googlemail.com  Sun Feb 25 20:55:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 21:55:13 +0100
Subject: tar -t segmentation fault
In-Reply-To: <20070225161015.7e1a80a1.natanael.copa@gmail.com>
References: <45E09B9C.8080302@Kriegisch.name>
	<200702250152.16360.vda.linux@googlemail.com>
	<20070225161015.7e1a80a1.natanael.copa@gmail.com>
Message-ID: <200702252155.13293.vda.linux@googlemail.com>

On Sunday 25 February 2007 16:10, Natanael Copa wrote:
> > > I can confirm this on x86/uclibc. I have tested with and wihtout the
> > > patches for 1.4.1.
> > 
> > http://bugs.busybox.net/view.php?id=1183 - fixed.
> > 
> > Does svn work for you?
> 
> Applied same patch as Alexander and it works. Could it be added to the fixes-1.4.1?

Added.
--
vda


From vda.linux at googlemail.com  Sun Feb 25 21:50:50 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 25 Feb 2007 22:50:50 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <20070225161736.d3cd295d.natanael.copa@gmail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
Message-ID: <200702252250.50488.vda.linux@googlemail.com>

On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> The attatched patch adds support for group with the --chuid.
> 
>   start-stop-daemon --chuid user:group
> 
> Patch is against 1.4.1.

Thanks. I see that we do something similar in chown.
I want to make this code common.

Please try attached patch which does that.

> btw... the usage message is wrong:
>  
>   -U|--chuid <username>|<uid>     Start process with this name
> 
> its -c and not -U for --chuid short opt.

Corrected, along with description.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 7428 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070225/c467db28/attachment-0002.bin 

From wharms at bfs.de  Mon Feb 26 08:08:58 2007
From: wharms at bfs.de (walter harms)
Date: Mon, 26 Feb 2007 09:08:58 +0100
Subject: ash test suite
In-Reply-To: <20070225015108.0d679f85.natanael.copa@gmail.com>
References: <45B719C7.8010503@bfs.de>
	<45BF6F79.4020601@bfs.de>	<f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>	<200702241331.34553.vda.linux@googlemail.com>
	<20070225015108.0d679f85.natanael.copa@gmail.com>
Message-ID: <45E2959A.1080702@bfs.de>




> }
> 
> [ "yes" || "" ] && echo hello
> 
> [[ "yes" && "yes" ]] && echo hello
> 

this exposes an other problem anyway. in ash [ is used just like [[
therefore the [[ specific tests fail. Someone will need the extent test.

re,
 wh


From rogelio.serrano at gmail.com  Mon Feb 26 08:54:09 2007
From: rogelio.serrano at gmail.com (Rogelio Serrano)
Date: Mon, 26 Feb 2007 08:54:09 +0000
Subject: zcip
Message-ID: <a9951d2a0702260054p727a93a4x7f293e8568325545@mail.gmail.com>

how much of rfc 3927 is implemented by busybox zcip?

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items


From natanael.copa at gmail.com  Mon Feb 26 14:06:38 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Mon, 26 Feb 2007 15:06:38 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <200702252250.50488.vda.linux@googlemail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
Message-ID: <1172498798.27284.1.camel@localhost>

On Sun, 2007-02-25 at 22:50 +0100, Denis Vlasenko wrote:
> On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> > The attatched patch adds support for group with the --chuid.
> > 
> >   start-stop-daemon --chuid user:group
> > 
> > Patch is against 1.4.1.
> 
> Thanks. I see that we do something similar in chown.
> I want to make this code common.
> 
> Please try attached patch which does that.

Works for me. (I'm using 1.4.1 + patches in production though)

> 
> > btw... the usage message is wrong:
> >  
> >   -U|--chuid <username>|<uid>     Start process with this name
> > 
> > its -c and not -U for --chuid short opt.
> 
> Corrected, along with description.

Thanks!




From tternes at gmail.com  Mon Feb 26 13:51:23 2007
From: tternes at gmail.com (Thaddeus Ternes)
Date: Mon, 26 Feb 2007 07:51:23 -0600
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <200702252250.50488.vda.linux@googlemail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
Message-ID: <ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>

On 2006/7/16, I posted a patch that added chuid support to
start-stop-daemon.  See this thread for the original patch:

http://busybox.net/lists/busybox/2006-July/023212.html

I'm including a modification of that patch to add chgid support as
well.  The syntax is a bit different the previous proposed patch on
this thread, but it may be of interest to some.

I have to note that I haven't tried this against recent builds of
Busybox.  The project I'm working on is locked at 1.2.2.1 right now,
so I patch against that.  This patch will likely not work against
current SVN, but could obviously be coaxed to fit in with a little
love.

Hopefully it's of use to somebody still using older builds.

-Thaddeus

diff -Naur busybox-1.2.2.1.clean/debianutils/start_stop_daemon.c
busybox-1.2.2.1/debianutils/start_stop_daemon.c
--- busybox-1.2.2.1.clean/debianutils/start_stop_daemon.c	2006-06-30
17:42:04.000000000 -0500
+++ busybox-1.2.2.1/debianutils/start_stop_daemon.c	2007-02-06
11:10:38.000000000 -0600
@@ -22,8 +22,11 @@

 static int signal_nr = 15;
 static int user_id = -1;
+static int group_id = -1;
 static int quiet;
 static char *userspec = NULL;
+static char *chuid = NULL;
+static char *chgid = NULL;
 static char *cmdname = NULL;
 static char *execname = NULL;
 static char *pidfile = NULL;
@@ -211,6 +214,8 @@
 	{ "name",			1,		NULL,		'n' },
 	{ "signal",			1,		NULL,		's' },
 	{ "user",			1,		NULL,		'u' },
+	{ "chuid", 			1,		NULL,		'c' },
+	{ "chgid", 			1,		NULL,		'g' },
 	{ "exec",			1,		NULL,		'x' },
 	{ "pidfile",		1,		NULL,		'p' },
 #if ENABLE_FEATURE_START_STOP_DAEMON_FANCY
@@ -249,9 +254,9 @@
 	opt = bb_getopt_ulflags(argc, argv, "KSbqm"
 //		USE_FEATURE_START_STOP_DAEMON_FANCY("ovR:")
 		USE_FEATURE_START_STOP_DAEMON_FANCY("ov")
-		"a:n:s:u:x:p:"
+		"a:n:s:u:c:g:x:p:"
 //		USE_FEATURE_START_STOP_DAEMON_FANCY(,&retry_arg)
-		,&startas, &cmdname, &signame, &userspec, &execname, &pidfile);
+		,&startas, &cmdname, &signame, &userspec, &chuid, &chgid,
&execname, &pidfile);

 	quiet = (opt & SSD_OPT_QUIET)
 			USE_FEATURE_START_STOP_DAEMON_FANCY(&& !(opt & SSD_OPT_VERBOSE));
@@ -301,6 +306,17 @@
 		fprintf(pidf, "%d\n", pidt);
 		fclose(pidf);
 	}
+	if(chgid) {
+		if(sscanf(chgid, "%d", &group_id) != 1)
+			group_id = bb_xgetgrnam(chgid);
+		setgid(group_id);
+	}
+	if(chuid) {
+		if(sscanf(chuid, "%d", &user_id) != 1)
+			user_id = bb_xgetpwnam(chuid);
+		setuid(user_id);
+	}
+
 	execv(startas, argv);
 	bb_perror_msg_and_die ("unable to start %s", startas);
 }
diff -Naur busybox-1.2.2.1.clean/include/usage.h busybox-1.2.2.1/include/usage.h
--- busybox-1.2.2.1.clean/include/usage.h	2006-06-30 17:42:10.000000000 -0500
+++ busybox-1.2.2.1/include/usage.h	2007-02-06 11:10:45.000000000 -0600
@@ -2693,7 +2693,9 @@
 	"\n\t-o|--oknodo\t\t\texit status 0 if nothing done" \
 	"\n\t-v|--verbose\t\t\tbe verbose" \
 ) \
-	"\n\t-s|--signal <signal>\t\tsignal to send (default TERM)"
+	"\n\t-s|--signal <signal>\t\tsignal to send (default TERM)" \
+	"\n\t-g|--chgid <group>|<gid>\tstart process with this group" \
+	"\n\t-c|--chuid <username>|<uid>\tstart process with this name"

 #ifdef CONFIG_FEATURE_STAT_FORMAT
 #  define USAGE_STAT_FORMAT(a) a


On 2/25/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> > The attatched patch adds support for group with the --chuid.
> >
> >   start-stop-daemon --chuid user:group
> >
> > Patch is against 1.4.1.
>
> Thanks. I see that we do something similar in chown.
> I want to make this code common.
>
> Please try attached patch which does that.
>
> > btw... the usage message is wrong:
> >
> >   -U|--chuid <username>|<uid>     Start process with this name
> >
> > its -c and not -U for --chuid short opt.
>
> Corrected, along with description.
> --
> vda
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox_start-stop-daemon_chuid_chgid.patch
Type: application/octet-stream
Size: 2474 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070226/b0f91bc4/attachment-0002.obj 

From ddaney at avtrex.com  Mon Feb 26 17:33:14 2007
From: ddaney at avtrex.com (David Daney)
Date: Mon, 26 Feb 2007 09:33:14 -0800
Subject: zcip
In-Reply-To: <a9951d2a0702260054p727a93a4x7f293e8568325545@mail.gmail.com>
References: <a9951d2a0702260054p727a93a4x7f293e8568325545@mail.gmail.com>
Message-ID: <45E319DA.60802@avtrex.com>

Rogelio Serrano wrote:
> how much of rfc 3927 is implemented by busybox zcip?
> 

As far as I know: All of it.  You will however need to apply a kernel 
patch for full compliance.  Search the list archives for mail from me 
for the patch.

David Daney


From kaigai at kaigai.gr.jp  Mon Feb 26 17:45:46 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Tue, 27 Feb 2007 02:45:46 +0900
Subject: [BUGFIX] matchpathcon didn't abort, if exclusive options were given.
Message-ID: <45E31CCA.8000102@kaigai.gr.jp>

Hi,

This small patch fixes a bug when exclusive options were given
to matchpathcon.
The reason of this problem is lacking of '?' in opt_complementary.

This patch enables to abort, if inconsistent options are given.

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-libselinux-bugfix-matchpathcon.patch
Type: text/x-patch
Size: 547 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/6321e1cb/attachment-0002.bin 

From ynakam at hitachisoft.jp  Mon Feb 26 01:31:14 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Mon, 26 Feb 2007 10:31:14 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.14808.vda.linux@googlemail.com>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
	<200702241601.14808.vda.linux@googlemail.com>
Message-ID: <20070226103114.71efbc26.ynakam@hitachisoft.jp>

Thank you for review!

On Sat, 24 Feb 2007 16:01:14 +0100
Denis Vlasenko wrote:
> On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> > [1/8] busybox-coreutils-common-01.v3.patch
> >  - common component for SELinux options, applets
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> > Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> 
>         "       -i      Interactive, prompt before overwrite\n" \
>         "       -R,-r   Copy directories recursively\n" \
> -       "       -l,-s   Create (sym)links"
> +       "       -l,-s   Create (sym)links\n"
> 
>  #define cpio_trivial_usage \
> 
> Why?
Removed this one.

>  USE_RPM2CPIO(APPLET(rpm2cpio, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
> +USE_RUNCON(APPLET(runcon, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
>  USE_RUN_PARTS(APPLET_ODDNAME(run-parts, run_parts, _BB_DIR_BIN, _BB_SUID_NEVER, run_parts))
>  USE_RUNLEVEL(APPLET(runlevel, _BB_DIR_SBIN, _BB_SUID_NEVER))
> 
> *Must* be in ASCII order.
Fixed.


> 
> 
> --
> vda

Attached is reviesed patch.


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v4.patch
Type: application/octet-stream
Size: 10143 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070226/840b26b6/attachment-0002.obj 

From ynakam at hitachisoft.jp  Mon Feb 26 01:52:49 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Mon, 26 Feb 2007 10:52:49 +0900
Subject: [PATCH 2/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.14214.vda.linux@googlemail.com>
References: <20070223174747.4ced9178.ynakam@hitachisoft.jp>
	<200702241601.14214.vda.linux@googlemail.com>
Message-ID: <20070226105249.98bf6e55.ynakam@hitachisoft.jp>

On Sat, 24 Feb 2007 16:01:14 +0100
Denis Vlasenko  wrote:
> On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> > [2/8] busybox-coreutils-02-copy.v3.patch
> >   - cp: -Z,-c option support. 
> >       -c option: security context is preserved during file copy.
> >   - mv 
> >     In SELinux, it is recommended to preserve security context 
> >     when file is moved. By this patch, file context is preserved 
> >     during file move.
> >   - install
> >     When file is copied by install, security context of installed file 
> >     becomes different from value configured in file_contexts file.
> >     By this patch, security context is set according to file_contexts file.
> >     -Z option: security context can be set during file copy.
> > 
> > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
>         FILEUTILS_MAKE_SOFTLINK = 0x40,
> +#if ENABLE_SELINUX
> +       FILEUTILS_PRESERVE_SECURITY_CONTEXT = 0x80,
> +       FILEUTILS_SET_SECURITY_CONTEXT = 0x100
> +#endif
>  };
> -#define FILEUTILS_CP_OPTSTR "pdRfils"
> 
> +#define FILEUTILS_CP_OPTSTR "pdRfils" USE_SELINUX("c\b")
> +
>  extern const char *applet_name;
> ...
>         { "owner",               0, NULL, 'o' },
> +#if ENABLE_SELINUX
> +       { "context",             1, NULL, 'Z' },
> +       { "preserve_context",    0, NULL, '\b'},
> +       { "preserve-context",    0, NULL, '\b'},
> +
> +#endif
>         { 0, 0, 0, 0 }
> 
> Hmmm... we typically use high ascii values for this kind
> of "fake" option chars. Example in wget.c:
> 
>         static const struct option wget_long_options[] = {
> ...
>                 { "user-agent",       required_argument, NULL, 'U' },
>                 { "passive-ftp",      no_argument, NULL, 0xff },
>                 { "header",           required_argument, NULL, 0xfe },
>                 { 0, 0, 0, 0 }
>         };
>         applet_long_options = wget_long_options;
> #endif
>         opt_complementary = "-1" USE_FEATURE_WGET_LONG_OPTIONS(":\xfe::");
>         opt = getopt32(argc, argv, "cqO:P:Y:U:",   ...);
> 
> Notice that in this example we avoid giving "strange" chars to getopt32
> *at all*, preventing our applets from having "hidden" options a-la
> "wget $'-\xff' ftp://kernel.org/".
> 
> Can you avoid passing '\b' to getopt32 in install etc?
Fixed. Using "0xff" instead.


> 
> 
> +                       bb_error_msg("warning: ignoring --preserve-context. "
> +                                        "The kernel is not SELinux-enabled.\n" );
> 
> bb_error_msg don't need trailing '\n'.
> I already mentioned that in the previous round of review.
> 
> 
> +#if ENABLE_SELINUX
> +       if ((flags & FILEUTILS_PRESERVE_SECURITY_CONTEXT) && is_selinux_enabled() > 0){
> +               security_context_t con;
> +               if (lgetfilecon (source, &con) >= 0){
> +                       if (setfscreatecon(con) < 0) {
> +                               bb_perror_msg ("cannot set setfscreatecon %s", con);
> +                               freecon(con);
> +                               return -1;
> +                       }
> +               }else{
> +                       if( errno == ENOTSUP || errno == ENODATA ) {
> +                               setfscreatecon(NULL);
> +                       } else {
> +                               bb_perror_msg ("cannot  lgetfilecon %s", source);
> +                               return -1;
> +                       }
> +               }
> +       }
> +#endif
> 
> Usage of whitespace is very different from the rest of busybox code here.
Fixed. And I found other bad usage of white space, and fixed.

> 
> --
> vda

Attached is revised patch(v4).

--
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-copy-02.v4.patch
Type: application/octet-stream
Size: 7805 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070226/91d09e74/attachment-0002.obj 

From ynakam at hitachisoft.jp  Mon Feb 26 01:54:09 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Mon, 26 Feb 2007 10:54:09 +0900
Subject: [PATCH 5/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.11806.vda.linux@googlemail.com>
References: <20070223174807.ef262eb5.ynakam@hitachisoft.jp>
	<200702241601.11806.vda.linux@googlemail.com>
Message-ID: <20070226105409.3a228ff6.ynakam@hitachisoft.jp>

On Sat, 24 Feb 2007 16:01:11 +0100
Denis Vlasenko  wrote:
> On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
> > [5/8]  busybox-coreutils-05-ls.v3.patch
> >  - -Z option support for ls. Security context of file is shown by -Z option.
> >    In current busybox, -k/-K shows security context. However, they are replaced by -Z option in recent coreutils, so -Z have to be added by this patch.
> > 
> > Signed-off-by:  Yuichi Nakamura <ynakam at hitachisoft.jp>
> 
> +       USE_FEATURE_AUTOWIDTH("T:w:")
> +    USE_SELINUX("Z");
> 
> Use tab here instead of four spaces.
Fixed.

> --
> vda

Attached is revised patch(v4).

-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-ls-05.v4.patch
Type: application/octet-stream
Size: 589 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070226/c6186ea1/attachment-0002.obj 

From kaigai at kaigai.gr.jp  Mon Feb 26 17:40:22 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Tue, 27 Feb 2007 02:40:22 +0900
Subject: [PATCH 7/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.12758.vda.linux@googlemail.com>
References: <20070223174823.8109ef4c.ynakam@hitachisoft.jp>
	<200702241601.12758.vda.linux@googlemail.com>
Message-ID: <45E31B86.8080200@kaigai.gr.jp>

Hi, Denis.

Thanks for your reviews.

Denis Vlasenko wrote:
> On Friday 23 February 2007 09:48, Yuichi Nakamura wrote:
>> [7/8] busybox-coreutils-07-chcon.v3.patch
>>  - chcon - change security context of file. 
>>
>> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> 
> +#define OPT_QUIET              (1<<3)  /* 'f' */
> +#define OPT_REFERENCE          (1<<4)  /* '\n' */
> +#define OPT_USER               (1<<5)  /* 'u' */
> 
> ...
> 
> 
> +       {"quiet",       0,      NULL,   'f'},
> +       {"reference",   1,      NULL,   '\n' }, /* no short option */
> +       {"user",        1,      NULL,   'u' },
> +       {"role",        1,      NULL,   'r' },
> +       {"type",        1,      NULL,   't' },
> +       {"range",       1,      NULL,   'l' },
> +       {"verbose",     0,      NULL,   'v' },
> +       {NULL,          0,      NULL,   0 },
> +};
> +#endif
> +
> +int chcon_main(int argc, char *argv[]);
> +int chcon_main(int argc, char *argv[])
> +{
> +       char *reference_file;
> +       char **target_files;
> +       int i, opts, errors = 0;
> +
> +#ifdef CONFIG_FEATURE_CHCON_LONG_OPTIONS
> +       applet_long_options = chcon_options;
> +#endif
> +       opt_complementary = "-1"  /* at least 1 param */
> +               ":q--v:v--q";     /* 'verbose' and 'quiet' are exclusive */
> +       opts = getopt32(argc, argv, "Rchf\n:u:r:t:l:v",
> +                       &reference_file, &user, &role, &type, &range);
> +       if (opts & OPT_REFERENCE) {
> +               if (opts & OPT_COMPONENT_SPECIFIED)
> +                       bb_error_msg_and_die("conflicting security context specifiers given");
> 
> 
> Again see wget.c how to not pass '\n' to getopt32.
> 
> You can make OPT_REFERENCE and OPT_COMPONENT_SPECIFIED
> exclusive by using suitable opt_complementary.

OK, fixed.

* '\n' was replaced by '0xff'
* Checks for exclusive options were added. chcon applet will will abort
   if --reference and '-u','-r','-t','-l' are appeared concurrently,

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-chcon-07.v4.patch
Type: text/x-patch
Size: 6357 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/3c22b222/attachment-0002.bin 

From kaigai at kaigai.gr.jp  Mon Feb 26 17:40:38 2007
From: kaigai at kaigai.gr.jp (KaiGai Kohei)
Date: Tue, 27 Feb 2007 02:40:38 +0900
Subject: [PATCH 8/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <200702241601.13536.vda.linux@googlemail.com>
References: <20070223174929.18e547ea.ynakam@hitachisoft.jp>
	<200702241601.13536.vda.linux@googlemail.com>
Message-ID: <45E31B96.3060406@kaigai.gr.jp>

Hi, Denis

Thanks for your reviews.

Denis Vlasenko wrote:
> On Friday 23 February 2007 09:49, Yuichi Nakamura wrote:
>> [8/8] busybox-coreutils-08-runcon.v3.patch
>>  - runcon - run application with specified security context.
>>   runcon provides one of the core facilities to run application with explicitly
>>   specified security context. It enables users to run their application under
>>   the least privilege set explicitly.
>>
>> Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> 
> +       char *role = NULL;
> +       char *range = NULL;
> +       char *user = NULL;
> +       char *type = NULL;
> +       char *context = NULL;
> +       unsigned int opts;
> +
> +       selinux_or_die();
> +
> +       opts = getopt32(argc, argv, "r:t:u:l:ch", &role, &type, &user, &range);
> +
> +       if (!role && !type && !user && !range) {
> +               if (optind >= argc)
> +                       bb_error_msg_and_die("must specify -c, -t, -u, -l, -r, or context");
> +               context = argv[optind++];
> +       }
> 
> Testing if(!(opt & MASK_role_type_user_range)) will result in smaller code.

I'm sorry, it was overlooked.
The attached patch replace the above if-conditions by a single logical
operation as you suggested.

Thanks,
-- 
KaiGai Kohei <kaigai at kaigai.gr.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-runcon-08.v4.patch
Type: text/x-patch
Size: 4558 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/c2c09d76/attachment-0002.bin 

From vda.linux at googlemail.com  Mon Feb 26 22:45:31 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 26 Feb 2007 23:45:31 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <1172498798.27284.1.camel@localhost>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
	<1172498798.27284.1.camel@localhost>
Message-ID: <200702262345.31317.vda.linux@googlemail.com>

On Monday 26 February 2007 15:06, Natanael Copa wrote:
> On Sun, 2007-02-25 at 22:50 +0100, Denis Vlasenko wrote:
> > On Sunday 25 February 2007 16:17, Natanael Copa wrote:
> > > The attatched patch adds support for group with the --chuid.
> > > 
> > >   start-stop-daemon --chuid user:group
> > > 
> > > Patch is against 1.4.1.
> > 
> > Thanks. I see that we do something similar in chown.
> > I want to make this code common.
> > 
> > Please try attached patch which does that.
> 
> Works for me. (I'm using 1.4.1 + patches in production though)

Ok, applying then.
--
vda


From vda.linux at googlemail.com  Mon Feb 26 22:45:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 26 Feb 2007 23:45:37 +0100
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
	<ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>
Message-ID: <200702262345.37726.vda.linux@googlemail.com>

On Monday 26 February 2007 14:51, Thaddeus Ternes wrote:
> On 2006/7/16, I posted a patch that added chuid support to
> start-stop-daemon.  See this thread for the original patch:
> 
> http://busybox.net/lists/busybox/2006-July/023212.html
> 
> I'm including a modification of that patch to add chgid support as
> well.  The syntax is a bit different the previous proposed patch on
> this thread, but it may be of interest to some.

If there is a "standard" start-stop-daemon (I suppose there is,
but I don't use Debian, so I don't know for sure), it's better
to match it, I think.

With the patch Natanael just tested, bbox ssd supports:

--chuid <user>[:[<group>]]
or
--chuid :<group>

Does this match "standard"? If not, I will gladly take
patches which fix that...
--
vda


From strange at nsk.no-ip.org  Mon Feb 26 23:00:31 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Mon, 26 Feb 2007 23:00:31 +0000
Subject: [PATCH] start-stop-daemon cannot set gid
In-Reply-To: <200702262345.37726.vda.linux@googlemail.com>
References: <20070225161736.d3cd295d.natanael.copa@gmail.com>
	<200702252250.50488.vda.linux@googlemail.com>
	<ecbbda800702260551u17e0528p9aab860f737b5bcd@mail.gmail.com>
	<200702262345.37726.vda.linux@googlemail.com>
Message-ID: <20070226230031.GA19584@nsk.no-ip.org>

On Mon, Feb 26, 2007 at 11:45:37PM +0100, Denis Vlasenko wrote:
> On Monday 26 February 2007 14:51, Thaddeus Ternes wrote:
> > On 2006/7/16, I posted a patch that added chuid support to
> > start-stop-daemon.  See this thread for the original patch:
> > 
> > http://busybox.net/lists/busybox/2006-July/023212.html
> > 
> > I'm including a modification of that patch to add chgid support as
> > well.  The syntax is a bit different the previous proposed patch on
> > this thread, but it may be of interest to some.
> 
> If there is a "standard" start-stop-daemon (I suppose there is,
> but I don't use Debian, so I don't know for sure), it's better
> to match it, I think.
> 
> With the patch Natanael just tested, bbox ssd supports:
> 
> --chuid <user>[:[<group>]]
> or
> --chuid :<group>
> 
> Does this match "standard"? If not, I will gladly take
> patches which fix that...
> --

man page:

 -g|--group group|gid
        Change to group or gid when starting the process.

 -c|--chuid username|uid
        Change to this username/uid before starting the process. You can
        also  specify a group by appending a :, then the group or gid in
        the same way as you would for the `chown' command  (user:group).
        When  using  this  option  you must realize that the primary and
        supplemental groups are set as well, even if the --group  option
        is  not  specified.   The --group option is only for groups that
        the user isn't normally a member  of  (like  adding  per/process
        group membership for generic users like nobody).

According to source code, username is mandatory (otherwise getpwnam will
fail and cause the process to terminate).

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070226/368453bd/attachment-0002.pgp 

From ynakam at hitachisoft.jp  Mon Feb 26 23:42:58 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Tue, 27 Feb 2007 08:42:58 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <20070226103114.71efbc26.ynakam@hitachisoft.jp>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
	<200702241601.14808.vda.linux@googlemail.com>
	<20070226103114.71efbc26.ynakam@hitachisoft.jp>
Message-ID: <20070227084258.93dc26e2.ynakam@hitachisoft.jp>

In previous patch, 
definitions about another SELinux-related applet was included.
I am sorry, and I've removed that one.
Please use attached patch instead of busybox-coreutils-common-01.v4.patch.


On Mon, 26 Feb 2007 10:31:14 +0900
Yuichi Nakamura  wrote:

> Thank you for review!
> 
> On Sat, 24 Feb 2007 16:01:14 +0100
> Denis Vlasenko wrote:
> > On Friday 23 February 2007 09:47, Yuichi Nakamura wrote:
> > > [1/8] busybox-coreutils-common-01.v3.patch
> > >  - common component for SELinux options, applets
> > > 
> > > Signed-off-by: Yuichi Nakamura <ynakam at hitachisoft.jp>
> > > Signed-off-by: KaiGai Kohei <kaigai at kaigai.gr.jp>
> > 
> >         "       -i      Interactive, prompt before overwrite\n" \
> >         "       -R,-r   Copy directories recursively\n" \
> > -       "       -l,-s   Create (sym)links"
> > +       "       -l,-s   Create (sym)links\n"
> > 
> >  #define cpio_trivial_usage \
> > 
> > Why?
> Removed this one.
> 
> >  USE_RPM2CPIO(APPLET(rpm2cpio, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
> > +USE_RUNCON(APPLET(runcon, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
> >  USE_RUN_PARTS(APPLET_ODDNAME(run-parts, run_parts, _BB_DIR_BIN, _BB_SUID_NEVER, run_parts))
> >  USE_RUNLEVEL(APPLET(runlevel, _BB_DIR_SBIN, _BB_SUID_NEVER))
> > 
> > *Must* be in ASCII order.
> Fixed.
> 
> 
> > 
> > 
> > --
> > vda
> 
> Attached is reviesed patch.
> 
> 
> -- 
> Yuichi Nakamura
> Hitachi Software Engineering Co., Ltd.
> SELinux Policy Editor: http://seedit.sourceforge.net/
> 
> 


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-coreutils-common-01.v5.patch
Type: application/octet-stream
Size: 8893 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/3ec842c1/attachment-0002.obj 

From marco.braga at gmail.com  Mon Feb 26 23:22:55 2007
From: marco.braga at gmail.com (Marco Braga)
Date: Tue, 27 Feb 2007 00:22:55 +0100
Subject: Multiple configuration scripts
Message-ID: <d459bb380702261522m75db77e6tcf0b7bf4a77a6a39@mail.gmail.com>

Hello,

pardon me if this is a newbie question, but google did not help me.

I am trying to build a busybox based embedded system from scratch. I'd like
to use busybox in initramfs and in the main root fs. The first one should be
a minimal busybox statically linked, while in the main root fs I can put a
more complete one. Now, the question: is there any simple "make trick" to
compile BB using 2 separate config files instead of copying/linking
".config" to 2 separate configs?

Specifically, at the moment I've created 2 different config files, one for
initramfs and one for rootfs. The first one selects static linking, few
applets, and a specific initramfs target directory. The second config
selects a dynamic linked BB with complete apples and a different target dir.

Now, is there any simple and elegant way to edit and compile without having
to copy or link the configs to .config? Anything like, for example, "make
menuconfig initramfs.config"?
A script will work, but I am looking for the "official" way to do this.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070227/dad98912/attachment-0001.htm 

From ynakam at hitachisoft.jp  Tue Feb 27 02:15:12 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Tue, 27 Feb 2007 11:15:12 +0900
Subject: [PATCH 1/8] busybox -- SELinux option support for coreutils: ver3
In-Reply-To: <e739902b0702261759wc2fc2fap4e353c87385f5a0b@mail.gmail.com>
References: <20070223174739.300d673a.ynakam@hitachisoft.jp>
	<200702241601.14808.vda.linux@googlemail.com>
	<20070226103114.71efbc26.ynakam@hitachisoft.jp>
	<20070227084258.93dc26e2.ynakam@hitachisoft.jp>
	<e739902b0702261759wc2fc2fap4e353c87385f5a0b@mail.gmail.com>
Message-ID: <20070227111512.1fa673b7.ynakam@hitachisoft.jp>

Hi.

It seems that it is a bug of init.c.
We have not noticed that, 
please submit that patch independently to busybox.net list.

Regards,
Yuichi Nakamura

On Mon, 26 Feb 2007 17:59:41 -0800
"Ryan Bradetich"  wrote:

> Hello Nakamura-san,
> 
> I have been using your patches against the latest SVN snapshot of
> busybox.  In my testing I get a compiler error in the init/init.c
> file.  I do not believe these patched introduce the error, but was
> curious if your patch set was going to address this error, or if I
> should submit this patch independently of your work.
> 
> I have attached the patch I am using for reference.
> 
> Thanks for your work!
> 
> - Ryan


From rbradetich at gmail.com  Tue Feb 27 02:39:39 2007
From: rbradetich at gmail.com (Ryan Bradetich)
Date: Mon, 26 Feb 2007 18:39:39 -0800
Subject: [PATCH] Fix compile error when init/init.c is compiled with
	ENABLE_SELINUX.
Message-ID: <e739902b0702261839p2d50cac9kf53eccf913efb429@mail.gmail.com>

Hello all,

Here is a trivial patch to fix a compile error in init.c when
ENABLE_SELINUX is defined.

Thanks,

- Ryan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-init.patch
Type: text/x-patch
Size: 556 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070226/eb46689b/attachment-0002.bin 

From terry1 at beam.ltd.uk  Tue Feb 27 09:22:25 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Tue, 27 Feb 2007 09:22:25 +0000
Subject: Modifying init to create /dev/console ?
Message-ID: <45E3F851.4060004@beam.ltd.uk>

Hi,

I am trying to create a basic Linux system based on Busybox and would 
like the ability to create the root file system as a normal user and 
without any /dev entries. The startup script would create the /dev 
entries as needed.
However, init and other programs obviously require /dev/console (and 
other /dev entries).

I was wondering about adding an option to init where it would create a 
tmpfs file system, mount it on /dev and create a /dev/console node if no 
/dev/console was found. I guess it could do a bit more and function as 
udev as well.

Do people with Busybox experience think that this a reasonable thing to 
do ??

Cheers


Terry


From Alexander at Kriegisch.name  Tue Feb 27 15:52:24 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Tue, 27 Feb 2007 16:52:24 +0100
Subject: ls on symlinked directories
Message-ID: <45E453B8.3070807@Kriegisch.name>

This might be a classical question which has been answered here before.
If so, I apologise.

There are a few known bugs in coreutils/ls.c which have been documented,
but not tackled for years. I am speaking of these:

>  * KNOWN BUGS:
>  * 1. ls -l of a directory doesn't give "total <blocks>" header
>  * 2. ls of a symlink to a directory doesn't list directory contents
>  * 3. hidden files can make column width too large

I am especially interested in getting #2 fixed. I don't intend to urge
anybody, I would just like to know if there are reasons for not fixing
this (it is really annoying). Maybe somebody can take the time to look
into this.
-- 
Alexander Kriegisch


From somlo at cmu.edu  Tue Feb 27 17:50:41 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Tue, 27 Feb 2007 12:50:41 -0500
Subject: PATCH: RFC3397 domain search support
Message-ID: <20070227175041.GC13939@hedwig.net.cmu.edu>

Denis,

Enclosed below is a patch that adds RFC3397 support to udhcp. It adds
an 'option search' to the udhcpd.conf file on the server side, and
fills the 'search' environment variable on the client side before
udhcpc.script is called. Both client and server need to comply for
this to be useful (e.g., isc dhcp version 3.1.0 or later), so the
default setting for this in the build script is off.

I tested it with isc 3.1.0 alpha, and it seems to work.

Please let me know what you think. Apply if you like.

Regards,
Gabriel

On Mon, Jan 29, 2007 at 09:06:14PM -0600, Jason Schoon wrote:
> Great idea, but if you need this functionality you should add support to
> udhcp for option 119, specified in RFC3397.  This is the exact problem that
> was solved by that new option.



diff -NarU5 busybox-svn-17929.orig/networking/udhcp/Config.in busybox-svn-17929/networking/udhcp/Config.in
--- busybox-svn-17929.orig/networking/udhcp/Config.in	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/Config.in	2007-02-27 12:03:52.000000000 -0500
@@ -63,5 +63,13 @@
 	  If selected, udhcpd will output extra debugging output.  If using
 	  this option, compile uDHCP with "-g", and do not fork the daemon to
 	  the background.
 
 	  See http://udhcp.busybox.net for further details.
+
+config FEATURE_RFC3397
+	bool "Support for RFC3397 domain search (experimental)"
+	default n
+	depends on APP_UDHCPD || APP_UDHCPC
+	help
+	  If selected, both client and server will support passing of domain
+	  search lists via option 119, specified in RFC3397.
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/Kbuild busybox-svn-17929/networking/udhcp/Kbuild
--- busybox-svn-17929.orig/networking/udhcp/Kbuild	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/Kbuild	2007-02-24 09:41:22.000000000 -0500
@@ -14,5 +14,6 @@
 				   script.o
 lib-$(CONFIG_APP_UDHCPD)	+= dhcpd.o arpping.o files.o leases.o \
 				   serverpacket.o static_leases.o
 lib-$(CONFIG_APP_DUMPLEASES)	+= dumpleases.o
 lib-$(CONFIG_APP_DHCPRELAY)     += dhcprelay.o
+lib-$(CONFIG_FEATURE_RFC3397)   += domain_codec.o
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/domain_codec.c busybox-svn-17929/networking/udhcp/domain_codec.c
--- busybox-svn-17929.orig/networking/udhcp/domain_codec.c	1969-12-31 19:00:00.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/domain_codec.c	2007-02-26 18:01:49.000000000 -0500
@@ -0,0 +1,205 @@
+/* vi: set sw=4 ts=4: */
+
+/* RFC1035 domain compression routines (C) 2007 Gabriel Somlo <somlo at cmu.edu>
+ *
+ * Loosely based on the isc-dhcpd implementation by dhankins at isc.org
+ *
+ * Licensed under GPLv2 or later, see file LICENSE in this tarball for details.
+ */
+
+#if ENABLE_FEATURE_RFC3397
+
+#include "common.h"
+#include "options.h"
+
+#define NS_MAXDNAME  1025	/* max domain name length */
+#define NS_MAXCDNAME  255	/* max compressed domain name length */
+#define NS_MAXLABEL    63	/* max label length */
+#define NS_MAXDNSRCH    6	/* max domains in search path */
+#define NS_CMPRSFLGS 0xc0	/* name compression pointer flag */
+
+
+/* expand a RFC1035-compressed list of domain names "cstr", of length "clen";
+ * returns a newly allocated string containing the space-separated domains,
+ * prefixed with the contents of string pre, or NULL if an error occurs.
+ */
+char *dname_dec(const uint8_t *cstr, int clen, const char *pre)
+{
+	const uint8_t *c;
+	int crtpos, retpos, depth, plen = 0, len = 0;
+	char *dst = NULL;
+
+	if (!cstr)
+		return NULL;
+
+	if (pre)
+		plen = strlen(pre);
+
+	/* We make two passes over the cstr string. First, we compute
+	 * how long the resulting string would be. Then we allocate a
+	 * new buffer of the required length, and fill it in with the
+	 * expanded content. The advantage of this approach is not
+	 * having to deal with requiring callers to supply their own
+	 * buffer, then having to check if it's sufficiently large, etc.
+	 */
+
+	while (!dst) {
+
+		if (len > 0) {	/* second pass? allocate dst buffer and copy pre */
+			dst = xmalloc(len + plen);
+			memcpy(dst, pre, plen);
+		}
+
+		crtpos = retpos = depth = len = 0;
+
+		while (crtpos < clen) {
+			c = cstr + crtpos;
+
+			if ((*c & NS_CMPRSFLGS) != 0) {	/* pointer */
+				if (crtpos + 2 > clen)		/* no offset to jump to? abort */
+					return NULL;
+				if (retpos == 0)			/* toplevel? save return spot */
+					retpos = crtpos + 2;
+				depth++;
+				crtpos = ((*c & 0x3f) << 8) | (*(c + 1) & 0xff); /* jump */
+			} else if (*c) {			/* label */
+				if (crtpos + *c + 1 > clen)		/* label too long? abort */
+					return NULL;
+				if (dst)
+					memcpy(dst + plen + len, c + 1, *c);
+				len += *c + 1;
+				crtpos += *c + 1;
+				if (dst)
+					*(dst + plen + len - 1) = '.';
+			} else {					/* null: end of current domain name */
+				if (retpos == 0) {			/* toplevel? keep going */
+					crtpos++;
+				} else {					/* return to toplevel saved spot */
+					crtpos = retpos;
+					retpos = depth = 0;
+				}
+				if (dst)
+					*(dst + plen + len - 1) = ' ';
+			}
+
+			if (depth > NS_MAXDNSRCH || /* too many jumps? abort, it's a loop */
+				len > NS_MAXDNAME * NS_MAXDNSRCH) /* result too long? abort */
+				return NULL;
+		}
+
+		if (!len)			/* expanded string has 0 length? abort */
+			return NULL;
+
+		if (dst)
+			*(dst + plen + len - 1) = '\0';
+	}
+
+	return dst;
+}
+
+/* Convert a domain name (src) from human-readable "foo.blah.com" format into
+ * RFC1035 encoding "\003foo\004blah\003com\000". Return allocated string, or
+ * NULL if an error occurs.
+ */
+static uint8_t *convert_dname(const char *src)
+{
+	uint8_t c, *res, *lp, *rp;
+	int len;
+
+	res = xmalloc(strlen(src) + 2);
+	rp = lp = res;
+	rp++;
+
+	for (;;) {
+		c = (uint8_t)*src++;
+		if (c == '.' || c == '\0') {	/* end of label */
+			len = rp - lp - 1;
+			/* label too long, too short, or two '.'s in a row? abort */
+			if (len > NS_MAXLABEL || len == 0 || (c == '.' && *src == '.')) {
+				free(res);
+				return NULL;
+			}
+			*lp = len;
+			lp = rp++;
+			if (c == '\0' || *src == '\0')	/* end of dname */
+				break;
+		} else {
+			if (c >= 0x41 && c <= 0x5A)		/* uppercase? convert to lower */
+				c += 0x20;
+			*rp++ = c;
+		}
+	}
+
+	*lp = 0;
+	if (rp - res > NS_MAXCDNAME) {	/* dname too long? abort */
+		free(res);
+		return NULL;
+	}
+	return res;
+}
+
+/* returns the offset within cstr at which dname can be found, or -1
+ */
+static int find_offset(const uint8_t *cstr, int clen, const uint8_t *dname)
+{
+	const uint8_t *c, *d;
+	int off, inc;
+
+	/* find all labels in cstr */
+	off = 0;
+	while (off < clen) {
+		c = cstr + off;
+
+		if ((*c & NS_CMPRSFLGS) != 0) {	/* pointer, skip */
+			off += 2;
+		} else if (*c) {	/* label, try matching dname */
+			inc = *c + 1;
+			d = dname;
+			while (*c == *d && memcmp(c + 1, d + 1, *c) == 0) {
+				if (*c == 0)	/* match, return offset */
+					return off;
+				d += *c + 1;
+				c += *c + 1;
+				if ((*c & NS_CMPRSFLGS) != 0)	/* pointer, jump */
+					c = cstr + (((*c & 0x3f) << 8) | (*(c + 1) & 0xff));
+			}
+			off += inc;
+		} else {	/* null, skip */
+			off++;
+		}
+	}
+
+	return -1;
+}
+
+/* computes string to be appended to cstr so that src would be added to
+ * the compression (best case, it's a 2-byte pointer to some offset within
+ * cstr; worst case, it's all of src, converted to rfc3011 format).
+ * The computed string is returned directly; its length is returned via retlen;
+ * NULL and 0, respectively, are returned if an error occurs.
+ */
+uint8_t *dname_enc(const uint8_t *cstr, int clen, const char *src, int *retlen)
+{
+	uint8_t *d, *dname;
+	int off;
+
+	dname = convert_dname(src);
+	if (dname == NULL) {
+		*retlen = 0;
+		return NULL;
+	}
+
+	for (d = dname; *d != 0; d += *d + 1) {
+		off = find_offset(cstr, clen, d);
+		if (off >= 0) {	/* found a match, add pointer and terminate string */
+			*d++ = NS_CMPRSFLGS;
+			*d = off;
+			break;
+		}
+	}
+
+	*retlen = d - dname + 1;
+	return dname;
+}		
+
+#endif /* ENABLE_FEATURE_RFC3397 */
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/files.c busybox-svn-17929/networking/udhcp/files.c
--- busybox-svn-17929.orig/networking/udhcp/files.c	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/files.c	2007-02-24 09:41:22.000000000 -0500
@@ -102,10 +102,16 @@
 
 	existing = find_option(*opt_list, option->code);
 	if (!existing) {
 		DEBUG("Attaching option %s to list", option->name);
 
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035)
+			/* reuse buffer and length for RFC1035-formatted string */
+			buffer = dname_enc(NULL, 0, buffer, &length);
+#endif
+
 		/* make a new option */
 		new = xmalloc(sizeof(struct option_set));
 		new->data = xmalloc(length + 2);
 		new->data[OPT_CODE] = option->code;
 		new->data[OPT_LEN] = length;
@@ -115,16 +121,26 @@
 		while (*curr && (*curr)->data[OPT_CODE] < option->code)
 			curr = &(*curr)->next;
 
 		new->next = *curr;
 		*curr = new;
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035 && buffer != NULL)
+			free(buffer);
+#endif
 		return;
 	}
 
 	/* add it to an existing option */
 	DEBUG("Attaching option %s to existing member of list", option->name);
 	if (option->flags & OPTION_LIST) {
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035)
+			/* reuse buffer and length for RFC1035-formatted string */
+			buffer = dname_enc(existing->data + 2,
+									existing->data[OPT_LEN], buffer, &length);
+#endif
 		if (existing->data[OPT_LEN] + length <= 255) {
 			existing->data = xrealloc(existing->data,
 					existing->data[OPT_LEN] + length + 3);
 			if ((option->flags & TYPE_MASK) == OPTION_STRING) {
 				/* ' ' can bring us to 256 - bad */
@@ -135,10 +151,14 @@
 				existing->data[OPT_LEN]++;
 			}
 			memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
 			existing->data[OPT_LEN] += length;
 		} /* else, ignore the data, we could put this in a second option in the future */
+#if ENABLE_FEATURE_RFC3397
+		if ((option->flags & TYPE_MASK) == OPTION_STR1035 && buffer != NULL)
+			free(buffer);
+#endif
 	} /* else, ignore the new data */
 }
 
 
 /* read a dhcp option and add it to opt_list */
@@ -181,10 +201,13 @@
 			retval = read_ip(val, buffer);
 			if (!(val = strtok(NULL, ", \t/-"))) retval = 0;
 			if (retval) retval = read_ip(val, buffer + 4);
 			break;
 		case OPTION_STRING:
+#if ENABLE_FEATURE_RFC3397
+		case OPTION_STR1035:
+#endif
 			length = strlen(val);
 			if (length > 0) {
 				if (length > 254) length = 254;
 				opt = val;
 				retval = 1;
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/options.c busybox-svn-17929/networking/udhcp/options.c
--- busybox-svn-17929.orig/networking/udhcp/options.c	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/options.c	2007-02-24 09:41:22.000000000 -0500
@@ -9,11 +9,11 @@
 #include "options.h"
 
 
 /* supported options are easily added here */
 const struct dhcp_option dhcp_options[] = {
-	/* name[10]     flags                                   code */
+	/* name[12]     flags                                   code */
 	{"subnet",      OPTION_IP | OPTION_REQ,                 0x01},
 	{"timezone",    OPTION_S32,                             0x02},
 	{"router",      OPTION_IP | OPTION_LIST | OPTION_REQ,   0x03},
 	{"timesvr",     OPTION_IP | OPTION_LIST,                0x04},
 	{"namesvr",     OPTION_IP | OPTION_LIST,                0x05},
@@ -41,10 +41,13 @@
 	{"vendorclass", OPTION_STRING,                          0x3C},
 	{"clientid",    OPTION_STRING,                          0x3D},
 	{"tftp",        OPTION_STRING,                          0x42},
 	{"bootfile",    OPTION_STRING,                          0x43},
 	{"userclass",   OPTION_STRING,                          0x4D},
+#if ENABLE_FEATURE_RFC3397
+	{"search",      OPTION_STR1035 | OPTION_LIST | OPTION_REQ, 0x77},
+#endif
 	/* MSIE's "Web Proxy Autodiscovery Protocol" support */
 	{"wpad",        OPTION_STRING,                          0xfc},
 	{"",            0x00,                                   0x00}
 };
 
@@ -52,10 +55,13 @@
 const unsigned char option_lengths[] = {
 	[OPTION_IP] =      4,
 	[OPTION_IP_PAIR] = 8,
 	[OPTION_BOOLEAN] = 1,
 	[OPTION_STRING] =  1,
+#if ENABLE_FEATURE_RFC3397
+	[OPTION_STR1035] = 1,
+#endif
 	[OPTION_U8] =      1,
 	[OPTION_U16] =     2,
 	[OPTION_S16] =     2,
 	[OPTION_U32] =     4,
 	[OPTION_S32] =     4
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/options.h busybox-svn-17929/networking/udhcp/options.h
--- busybox-svn-17929.orig/networking/udhcp/options.h	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/options.h	2007-02-24 09:41:22.000000000 -0500
@@ -7,10 +7,13 @@
 
 enum {
 	OPTION_IP=1,
 	OPTION_IP_PAIR,
 	OPTION_STRING,
+#if ENABLE_FEATURE_RFC3397
+	OPTION_STR1035,	/* RFC1035 compressed domain name list */
+#endif
 	OPTION_BOOLEAN,
 	OPTION_U8,
 	OPTION_U16,
 	OPTION_S16,
 	OPTION_U32,
@@ -31,7 +34,11 @@
 
 uint8_t *get_option(struct dhcpMessage *packet, int code);
 int end_option(uint8_t *optionptr);
 int add_option_string(uint8_t *optionptr, uint8_t *string);
 int add_simple_option(uint8_t *optionptr, uint8_t code, uint32_t data);
+#if ENABLE_FEATURE_RFC3397
+char *dname_dec(const uint8_t *cstr, int clen, const char *pre);
+uint8_t *dname_enc(const uint8_t *cstr, int clen, const char *src, int *retlen);
+#endif
 
 #endif
diff -NarU5 busybox-svn-17929.orig/networking/udhcp/script.c busybox-svn-17929/networking/udhcp/script.c
--- busybox-svn-17929.orig/networking/udhcp/script.c	2007-02-19 15:33:43.000000000 -0500
+++ busybox-svn-17929/networking/udhcp/script.c	2007-02-24 09:41:22.000000000 -0500
@@ -17,10 +17,13 @@
 /* get a rough idea of how long an option will be (rounding up...) */
 static const int max_option_length[] = {
 	[OPTION_IP] =		sizeof("255.255.255.255 "),
 	[OPTION_IP_PAIR] =	sizeof("255.255.255.255 ") * 2,
 	[OPTION_STRING] =	1,
+#if ENABLE_FEATURE_RFC3397
+	[OPTION_STR1035] =  1,
+#endif
 	[OPTION_BOOLEAN] =	sizeof("yes "),
 	[OPTION_U8] =		sizeof("255 "),
 	[OPTION_U16] =		sizeof("65535 "),
 	[OPTION_S16] =		sizeof("-32768 "),
 	[OPTION_U32] =		sizeof("4294967295 "),
@@ -51,25 +54,27 @@
 	for (i = 0; i < 32 && !((bits >> i) & 1); i++);
 	return 32 - i;
 }
 
 
-/* Fill dest with the text of option 'option'. */
-static void fill_options(char *dest, uint8_t *option,
-			const struct dhcp_option *type_p)
+/* Allocate and fill with the text of option 'option'. */
+static char *alloc_fill_opts(uint8_t *option, const struct dhcp_option *type_p)
 {
-	int type, optlen;
+	int len, type, optlen;
 	uint16_t val_u16;
 	int16_t val_s16;
 	uint32_t val_u32;
 	int32_t val_s32;
-	int len = option[OPT_LEN - 2];
-
-	dest += sprintf(dest, "%s=", type_p->name);
+	char *dest, *ret;
 
+	len = option[OPT_LEN - 2];
 	type = type_p->flags & TYPE_MASK;
 	optlen = option_lengths[type];
+
+	dest = ret = xmalloc(upper_length(len, type) + strlen(type_p->name) + 2);
+	dest += sprintf(ret, "%s=", type_p->name);
+
 	for (;;) {
 		switch (type) {
 		case OPTION_IP_PAIR:
 			dest += sprintip(dest, "", option);
 			*(dest++) = '/';
@@ -101,17 +106,25 @@
 			dest += sprintf(dest, "%ld", (long) ntohl(val_s32));
 			break;
 		case OPTION_STRING:
 			memcpy(dest, option, len);
 			dest[len] = '\0';
-			return;	 /* Short circuit this case */
+			return ret;	 /* Short circuit this case */
+#if ENABLE_FEATURE_RFC3397
+		case OPTION_STR1035:
+			/* unpack option into dest; use ret for prefix (i.e., "optname=") */
+			dest = dname_dec(option, len, ret);
+			free(ret);
+			return dest;
+#endif
 		}
 		option += optlen;
 		len -= optlen;
 		if (len <= 0) break;
 		dest += sprintf(dest, " ");
 	}
+	return ret;
 }
 
 
 /* put all the parameters into an environment */
 static char **fill_envp(struct dhcpMessage *packet)
@@ -153,13 +166,11 @@
 
 	for (i = 0; dhcp_options[i].code; i++) {
 		temp = get_option(packet, dhcp_options[i].code);
 		if (!temp)
 			continue;
-		envp[j] = xmalloc(upper_length(temp[OPT_LEN - 2],
-			dhcp_options[i].flags & TYPE_MASK) + strlen(dhcp_options[i].name) + 2);
-		fill_options(envp[j++], temp, &dhcp_options[i]);
+		envp[j++] = alloc_fill_opts(temp, &dhcp_options[i]);
 
 		/* Fill in a subnet bits option for things like /24 */
 		if (dhcp_options[i].code == DHCP_SUBNET) {
 			memcpy(&subnet, temp, 4);
 			envp[j++] = xasprintf("mask=%d", mton(&subnet));


From vda.linux at googlemail.com  Tue Feb 27 17:59:38 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 18:59:38 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E3F851.4060004@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
Message-ID: <200702271859.38772.vda.linux@googlemail.com>

On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
> I am trying to create a basic Linux system based on Busybox and would 
> like the ability to create the root file system as a normal user and 
> without any /dev entries. The startup script would create the /dev 
> entries as needed.
> However, init and other programs obviously require /dev/console (and 
> other /dev entries).
> 
> I was wondering about adding an option to init where it would create a 
> tmpfs file system, mount it on /dev and create a /dev/console node if no 
> /dev/console was found. I guess it could do a bit more and function as 
> udev as well.

I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.

http://busybox.net/~vda/example_fs/README
--
vda


From vapier at gentoo.org  Tue Feb 27 18:28:05 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 27 Feb 2007 13:28:05 -0500
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E3F851.4060004@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
Message-ID: <200702271328.06297.vapier@gentoo.org>

On Tuesday 27 February 2007, Terry Barnaby wrote:
> However, init and other programs obviously require /dev/console (and
> other /dev entries).

they dont require /dev/console

> I was wondering about adding an option to init where it would create a
> tmpfs file system, mount it on /dev and create a /dev/console node if no
> /dev/console was found. I guess it could do a bit more and function as
> udev as well.

it wouldnt work ... the kernel opens up /dev/console before executing init, so 
even if /sbin/init created the device node, it wouldnt matter

also, this is what init scripts are for ... such / policy handling does not 
belong hardcoded in the C code
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/d22d4891/attachment-0002.pgp 

From vda.linux at googlemail.com  Tue Feb 27 19:17:52 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 20:17:52 +0100
Subject: [PATCH] Fix compile error when init/init.c is compiled with
	ENABLE_SELINUX.
In-Reply-To: <e739902b0702261839p2d50cac9kf53eccf913efb429@mail.gmail.com>
References: <e739902b0702261839p2d50cac9kf53eccf913efb429@mail.gmail.com>
Message-ID: <200702272017.52689.vda.linux@googlemail.com>

On Tuesday 27 February 2007 03:39, Ryan Bradetich wrote:
> Hello all,
> 
> Here is a trivial patch to fix a compile error in init.c when
> ENABLE_SELINUX is defined.

Applied, thanks!
--
vda


From vda.linux at googlemail.com  Tue Feb 27 19:23:43 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 20:23:43 +0100
Subject: ls on symlinked directories
In-Reply-To: <45E453B8.3070807@Kriegisch.name>
References: <45E453B8.3070807@Kriegisch.name>
Message-ID: <200702272023.43468.vda.linux@googlemail.com>

On Tuesday 27 February 2007 16:52, Alexander Kriegisch wrote:
> This might be a classical question which has been answered here before.
> If so, I apologise.
> 
> There are a few known bugs in coreutils/ls.c which have been documented,
> but not tackled for years. I am speaking of these:
> 
> >  * KNOWN BUGS:
> >  * 1. ls -l of a directory doesn't give "total <blocks>" header

Indeed (/usr/bin/ls is from coreutils-6.3):

# ls -l /sys
drwxr-xr-x   29 root     root            0 Feb 27 17:56 block
drwxr-xr-x   11 root     root            0 Feb 27 17:56 bus
drwxr-xr-x   22 root     root            0 Feb 27 17:56 class
drwxr-xr-x    7 root     root            0 Feb 27 18:56 devices
drwxr-xr-x    3 root     root            0 Feb 27 18:56 firmware
drwxr-xr-x    2 root     root            0 Feb 27 18:56 fs
drwxr-xr-x    3 root     root            0 Feb 27 18:56 kernel
drwxr-xr-x   50 root     root            0 Feb 27 17:57 module
drwxr-xr-x    2 root     root            0 Feb 27 18:56 power
# /usr/bin/ls -l /sys
total 0
drwxr-xr-x 29 root root 0 2007-02-27 17:56 block
drwxr-xr-x 11 root root 0 2007-02-27 17:56 bus
drwxr-xr-x 22 root root 0 2007-02-27 17:56 class
drwxr-xr-x  7 root root 0 2007-02-27 18:56 devices
drwxr-xr-x  3 root root 0 2007-02-27 18:56 firmware
drwxr-xr-x  2 root root 0 2007-02-27 18:56 fs
drwxr-xr-x  3 root root 0 2007-02-27 18:56 kernel
drwxr-xr-x 50 root root 0 2007-02-27 17:57 module
drwxr-xr-x  2 root root 0 2007-02-27 18:56 power

But I don't miss this feature. Is it a real problem?

> >  * 2. ls of a symlink to a directory doesn't list directory contents

Coreutils doesn't do it either:

# ls -l /etc
lrwxrwxrwx    1 root     root           11 May 21  2006 /etc -> /.local/etc
# /usr/bin/ls -l /etc
lrwxrwxrwx 1 root root 11 2006-05-21 22:08 /etc -> /.local/etc

(hmmm.... I like coreutils' ISO date/time!)

> >  * 3. hidden files can make column width too large

Can you elaborate on #3?
--
vda


From vda.linux at googlemail.com  Tue Feb 27 19:40:21 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 20:40:21 +0100
Subject: serial console and log-in
In-Reply-To: <1172054657.12630.38.camel@localhost>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
	<200702210104.57030.vda.linux@googlemail.com>
	<1172054657.12630.38.camel@localhost>
Message-ID: <200702272040.22024.vda.linux@googlemail.com>

On Wednesday 21 February 2007 11:44, Natanael Copa wrote:
> > A bit more tests will be useful.
> > Does it work _without_ serial console?
> > In both cases, is there controlling tty? IOW:
> > 
> > echo TEST >/dev/tty
> > TEST
> > 
> > This is good (controlling tty exists)
> > 
> > echo TEST >/dev/tty
> > sh: /dev/tty: No such device or address
> > 
> > This isn't good.
> 
> I backported the svn init to 1.4.1 (i depend on releases).
> 
> My inittab line looks like this:
> 
> ::respawn:/sbin/getty - 9600 vt100
> 
> I got a login prompt but no controlling tty:
> 
> -ash: cant't access tty; job control turned off
> 
> ~$ echo TEST > /dev/tty
> -ash: cannot create /dev/tty: No such device or address
> 
> That was on a VGA console.
> 
> Then I tried to run it in qemu, with -nographic. It booted, it gave me a
> login, but same as VGA, no controlling tty.

I expected that. It stems from the fact that /dev/console
cannot be a ctty.

I'm not sure this can be classified as 'bug'.
--
vda


From vda.linux at googlemail.com  Tue Feb 27 21:12:18 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 22:12:18 +0100
Subject: PATCH: RFC3397 domain search support
In-Reply-To: <20070227175041.GC13939@hedwig.net.cmu.edu>
References: <20070227175041.GC13939@hedwig.net.cmu.edu>
Message-ID: <200702272212.18051.vda.linux@googlemail.com>

On Tuesday 27 February 2007 18:50, Gabriel L. Somlo wrote:
> Denis,
> 
> Enclosed below is a patch that adds RFC3397 support to udhcp. It adds
> an 'option search' to the udhcpd.conf file on the server side, and
> fills the 'search' environment variable on the client side before
> udhcpc.script is called. Both client and server need to comply for
> this to be useful (e.g., isc dhcp version 3.1.0 or later), so the
> default setting for this in the build script is off.
> 
> I tested it with isc 3.1.0 alpha, and it seems to work.
> 
> Please let me know what you think. Apply if you like.

Applied, thanks.
--
vda


From strange at nsk.no-ip.org  Tue Feb 27 21:41:17 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 27 Feb 2007 21:41:17 +0000
Subject: ls on symlinked directories
In-Reply-To: <200702272023.43468.vda.linux@googlemail.com>
References: <45E453B8.3070807@Kriegisch.name>
	<200702272023.43468.vda.linux@googlemail.com>
Message-ID: <20070227214117.GB30382@nsk.no-ip.org>

On Tue, Feb 27, 2007 at 08:23:43PM +0100, Denis Vlasenko wrote:
> > >  * 2. ls of a symlink to a directory doesn't list directory contents
> 
> Coreutils doesn't do it either:

It does w/o -l:
$ ls /usr/tmp 
<bunch of files>
$ busybox ls /usr/tmp
/usr/tmp

Busybox is 1.2.2.1.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/2e02847c/attachment-0002.pgp 

From terry1 at beam.ltd.uk  Tue Feb 27 21:45:49 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Tue, 27 Feb 2007 21:45:49 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702271328.06297.vapier@gentoo.org>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271328.06297.vapier@gentoo.org>
Message-ID: <45E4A68D.9020008@beam.ltd.uk>

Mike Frysinger wrote:
> On Tuesday 27 February 2007, Terry Barnaby wrote:
>> However, init and other programs obviously require /dev/console (and
>> other /dev entries).
> 
> they dont require /dev/console
> 
>> I was wondering about adding an option to init where it would create a
>> tmpfs file system, mount it on /dev and create a /dev/console node if no
>> /dev/console was found. I guess it could do a bit more and function as
>> udev as well.
> 
> it wouldnt work ... the kernel opens up /dev/console before executing init, so 
> even if /sbin/init created the device node, it wouldnt matter
> 
> also, this is what init scripts are for ... such / policy handling does not 
> belong hardcoded in the C code
> -mike

No, they don't require /dev/console just to operate, but if you want 
debug printout they do :)

Init could easily reopen its controlling terminal to the created 
/dev/console and continue ...

The reason I was looking at getting init to create /dev/console was so 
that I could debug my init scripts that are not working when 
/dev/console does not exist ...

Terry


From terry1 at beam.ltd.uk  Tue Feb 27 21:53:22 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Tue, 27 Feb 2007 21:53:22 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702271859.38772.vda.linux@googlemail.com>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271859.38772.vda.linux@googlemail.com>
Message-ID: <45E4A852.5050209@beam.ltd.uk>

Denis Vlasenko wrote:
> On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
>> I am trying to create a basic Linux system based on Busybox and would 
>> like the ability to create the root file system as a normal user and 
>> without any /dev entries. The startup script would create the /dev 
>> entries as needed.
>> However, init and other programs obviously require /dev/console (and 
>> other /dev entries).
>>
>> I was wondering about adding an option to init where it would create a 
>> tmpfs file system, mount it on /dev and create a /dev/console node if no 
>> /dev/console was found. I guess it could do a bit more and function as 
>> udev as well.
> 
> I think you are on the right track, but move in the wrong direction
> along that track. Code shouldn't be added to init, it should be removed.
> 
> http://busybox.net/~vda/example_fs/README
> --
> vda

Hi Denis,

But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)

Terry


From vda.linux at googlemail.com  Tue Feb 27 22:09:37 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 23:09:37 +0100
Subject: truncated syslog messages
In-Reply-To: <20070221142424.GA15913@salusa.home.net>
References: <20070221142424.GA15913@salusa.home.net>
Message-ID: <200702272309.37746.vda.linux@googlemail.com>

On Wednesday 21 February 2007 15:24, Stephane Billiart wrote:
> The problem:
> 
> server# logger "message to syslog"
> server# killall syslogd
> server# tail /var/log/messages 
> Feb 21 08:50:19 server syslog.info syslogd started: BusyBox v1.5.0.svn
> Feb 21 08:50:23 server kern.warn kernel: TSC 
> Feb 21 08:50:31 server user.notice root: messa
> Feb 21 08:51:25 server syslog.info syslogd exiting
> server# ls -l /dev/log /var/syslog
> lrwxrwxrwx    1 root     root           11 Jan  4  1980 /dev/log -> /var/syslog=
> srw-rw-rw-    1 root     root            0 Feb 21 08:50 /var/syslog=
> 
> All messages syslog receives are truncated, not the ones it writes itself...
> 
> My embedded system runs linux 2.6.19.2 with uClibc 0.9.27.
> I have mdev activated in busybox, /dev is a ramfs partition and /var is tmpfs.
> I tried with and without CONFIG_FEATURE_IPC_SYSLOG and get the same results

busybox and uclibc .config? syslogd parameters?

> I see the problem with the SVN and 1.4.1 versions but not with 1.2.2.1
> With glibc 2.3.6, everything is fine also.

glibc 2.4 and uclibc x86_64 svn (patched to fix stdio bug) works ok with

syslogd -m 0 -n -S -s 999 -b 9 -O $PWD/syslog

here

> There's been a lot of changes in syslogd recently.
> I started looking at the code but so far did not find anything to explain
> those short reads from /dev/log.

Adding few printf's is probably the fastest method to narrow it down.
Example:


static void log_locally(char *msg)
{
        static time_t last;
        struct flock fl;
        int len = strlen(msg);

+fprintf(stderr, "log_locally: '%s'\n", msg);

#if ENABLE_FEATURE_IPC_SYSLOG
...

static void timestamp_and_log(int pri, char *msg, int len)
{
        char *timestamp;

+fprintf(stderr, "timestamp_and_log: %d '%s'\n", len, msg);

        if (len < 16 || msg[3] != ' ' || msg[6] != ' '
         || msg[9] != ':' || msg[12] != ':' || msg[15] != ' '
        ) {
...

static void split_escape_and_log(char *tmpbuf, int len)
{
        char *p = tmpbuf;

+fprintf(stderr, "split_escape_and_log: %d '%s'\n", len, tmpbuf);

        tmpbuf += len;
        while (p < tmpbuf) {


Then killall syslogd, run new one with -n from the console,
and watch debug output.
--
vda


From vda.linux at googlemail.com  Tue Feb 27 22:35:02 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Tue, 27 Feb 2007 23:35:02 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E4A852.5050209@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271859.38772.vda.linux@googlemail.com>
	<45E4A852.5050209@beam.ltd.uk>
Message-ID: <200702272335.02502.vda.linux@googlemail.com>

On Tuesday 27 February 2007 22:53, Terry Barnaby wrote:
> Denis Vlasenko wrote:
> > On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
> >> I am trying to create a basic Linux system based on Busybox and would 
> >> like the ability to create the root file system as a normal user and 
> >> without any /dev entries. The startup script would create the /dev 
> >> entries as needed.
> >> However, init and other programs obviously require /dev/console (and 
> >> other /dev entries).
> >>
> >> I was wondering about adding an option to init where it would create a 
> >> tmpfs file system, mount it on /dev and create a /dev/console node if no 
> >> /dev/console was found. I guess it could do a bit more and function as 
> >> udev as well.
> > 
> > I think you are on the right track, but move in the wrong direction
> > along that track. Code shouldn't be added to init, it should be removed.
> > 
> > http://busybox.net/~vda/example_fs/README
> > --
> > vda
> 
> Hi Denis,
> 
> But then you end up with init implemented in several shell scripts.
> I guess it depends if you prefer 'C' or shell programs :)

Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda


From strange at nsk.no-ip.org  Tue Feb 27 23:49:38 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 27 Feb 2007 23:49:38 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E3F851.4060004@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
Message-ID: <20070227234938.GA2357@nsk.no-ip.org>

On Tue, Feb 27, 2007 at 09:22:25AM +0000, Terry Barnaby wrote:
> Hi,
> 
> I am trying to create a basic Linux system based on Busybox and would 
> like the ability to create the root file system as a normal user and 
> without any /dev entries. The startup script would create the /dev 
> entries as needed.
> However, init and other programs obviously require /dev/console (and 
> other /dev entries).

Are you using initramfs? You can create cpios with special files,
different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
in the Linux source tree.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/6e2577fe/attachment-0002.pgp 

From terry1 at beam.ltd.uk  Wed Feb 28 09:23:22 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 09:23:22 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <20070227234938.GA2357@nsk.no-ip.org>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
Message-ID: <45E54A0A.6030207@beam.ltd.uk>

Luciano Miguel Ferreira Rocha wrote:
> On Tue, Feb 27, 2007 at 09:22:25AM +0000, Terry Barnaby wrote:
>> Hi,
>>
>> I am trying to create a basic Linux system based on Busybox and would 
>> like the ability to create the root file system as a normal user and 
>> without any /dev entries. The startup script would create the /dev 
>> entries as needed.
>> However, init and other programs obviously require /dev/console (and 
>> other /dev entries).
> 
> Are you using initramfs? You can create cpios with special files,
> different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
> in the Linux source tree.
> 

Hi Luciano,

Yes, I am using initramfs and thanks for the info. I could use this for 
the boot initrd, but the system then mounts its real root fs using a 
read only NFS mount. I would prefer not to have a /dev/console in my NFS 
mounted file system either ...

Cheers

Terry


From terry1 at beam.ltd.uk  Wed Feb 28 09:46:22 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 09:46:22 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <200702272335.02502.vda.linux@googlemail.com>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702271859.38772.vda.linux@googlemail.com>
	<45E4A852.5050209@beam.ltd.uk>
	<200702272335.02502.vda.linux@googlemail.com>
Message-ID: <45E54F6E.7090003@beam.ltd.uk>

Denis Vlasenko wrote:
> On Tuesday 27 February 2007 22:53, Terry Barnaby wrote:
>> Denis Vlasenko wrote:
>>> On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
>>>> I am trying to create a basic Linux system based on Busybox and would 
>>>> like the ability to create the root file system as a normal user and 
>>>> without any /dev entries. The startup script would create the /dev 
>>>> entries as needed.
>>>> However, init and other programs obviously require /dev/console (and 
>>>> other /dev entries).
>>>>
>>>> I was wondering about adding an option to init where it would create a 
>>>> tmpfs file system, mount it on /dev and create a /dev/console node if no 
>>>> /dev/console was found. I guess it could do a bit more and function as 
>>>> udev as well.
>>> I think you are on the right track, but move in the wrong direction
>>> along that track. Code shouldn't be added to init, it should be removed.
>>>
>>> http://busybox.net/~vda/example_fs/README
>>> --
>>> vda
>> Hi Denis,
>>
>> But then you end up with init implemented in several shell scripts.
>> I guess it depends if you prefer 'C' or shell programs :)
> 
> Shell programs are easier to tailor for particular system without
> messing up with compiler and toolchain - exactly what you need
> for "I want to create /dev/console".
> --
> vda

Hi Denis,

I notice your http://busybox.net/~vda/example_fs has /dev/console and 
/dev/null nodes. Have you managed to get a busybox system to boot and 
run using shell scripts without these nodes ?

In my system the final rootfs will be a read-only NFS mount and I don't 
want to have a /dev/console in the NFS mounted file system. So I need to 
create this at boot time. My shell scripts do not appear to run from 
init if I do not have a /dev/console though ...

Terry


From strange at nsk.no-ip.org  Wed Feb 28 10:16:45 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Wed, 28 Feb 2007 10:16:45 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E54A0A.6030207@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
	<45E54A0A.6030207@beam.ltd.uk>
Message-ID: <20070228101645.GA13363@nsk.no-ip.org>

On Wed, Feb 28, 2007 at 09:23:22AM +0000, Terry Barnaby wrote:
> Yes, I am using initramfs and thanks for the info. I could use this for 
> the boot initrd, but the system then mounts its real root fs using a 
> read only NFS mount. I would prefer not to have a /dev/console in my NFS 
> mounted file system either ...

Well, you'll still need some RW paths in your system. You can accomplish
that for /dev and get a working one too by keeping the one in initramfs:

mount --bind /dev /nfsroot/dev
...
switch_root

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070228/7eb11e7d/attachment-0002.pgp 

From Alexander at Kriegisch.name  Wed Feb 28 10:18:28 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Wed, 28 Feb 2007 11:18:28 +0100
Subject: ls on symlinked directories
In-Reply-To: <200702272023.43468.vda.linux@googlemail.com>
References: <45E453B8.3070807@Kriegisch.name>
	<200702272023.43468.vda.linux@googlemail.com>
Message-ID: <45E556F4.907@Kriegisch.name>

Hi community!

Accidentally, I answered Denis' first reply without sending a copy to
the list, so now I am quoting our conversation FYI in ascending
chronological order below. Just two more annotations:

1. Busybox also has the ls -L switch mentioned in my last post. It works
   fine, even without Denis' patch, i.e. ls -L <symlinked_dir> shows a
   dereferenced and detailed directory listing. Even so, the patch is
   great and should be integrated into Bb.

2. The attached patch is my version with the cleaned up diff header
   lines, not Denis' original.

Regards
--
Alexander Kriegisch


----------------------------------------------------------------------


Hi Denis!

>>> >>>  * KNOWN BUGS:
>>> >>>  * 1. ls -l of a directory doesn't give "total <blocks>" header
> >
> > But I don't miss this feature. Is it a real problem?

Nope.

>>> >>>  * 2. ls of a symlink to a directory doesn't list directory contents
> >
> > Coreutils doesn't do it either:

Whatever Coreutils is. I was comparing the behaviour to that of other
(desktop) Linuxes. And each one I know shows the symlinked directory's
content. It is not a good argument that another tool is also buggy. It
is listed as a known bug by the author, after all.

>>> >>>  * 3. hidden files can make column width too large
> >
> > Can you elaborate on #3?

No, I was really just writing because of #2, as I said. I only quoted
all three, because SVN says they are all several years old. I would be
happy enough geeting #2 fixed.


Kind regards
--
Alexander Kriegisch


----------------------------------------------------------------------


On Tuesday 27 February 2007 22:34, Alexander Kriegisch wrote:
>>>> > >>>  * 2. ls of a symlink to a directory doesn't list directory
contents
>> > >
>> > > Coreutils doesn't do it either:
> >
> > Whatever Coreutils is.

coreutils is the GNU package which is used by virtually all Linux
distributions. It contains ls, among other utilities.

> > I was comparing the behaviour to that of other
> > (desktop) Linuxes. And each one I know shows the symlinked directory's
> > content.

Does ls -l follow links on your desktop Linux?
If yes, which distro is it?

> > It is not a good argument that another tool is also buggy.

I am not arguing whether it is bug or not. I want to
simply match coreutils ls, in case people parse
ls output in shell scripts.

> > It is listed as a known bug by the author, after all.

As others indicate, the bug is that bbox ls _without_ -l
doesn't follow links, but GNU ls does.

Attached patch makes bbox ls compatible with GNU coreutils one
regarding link dereferencing.
--
vda


----------------------------------------------------------------------


> > Does ls -l follow links on your desktop Linux? If yes, which distro
> > is it?
> >
> > As others indicate, the bug is that bbox ls _without_ -l
> > doesn't follow links, but GNU ls does.

You are right, it only follows without -l by default. My mistake, I
apologise. There are two switches that can do this, if necessary (Ubuntu
6.10 and others). Quote from the ls manpage:

> > -H, --dereference-command-line
> >     follow symbolic links listed on the command line
> > --dereference-command-line-symlink-to-dir
> >     follow each command line symbolic link that points to a directory

The difference is that the former (-lH) also works for symlinked files
(lists the size and modification date of the referenced file rather than
that of the link), whereas the latter only expands directories. It would
be nice to have those switches in Busybox, too, but if they are not part
of Coreutils, I understand we won't get them. I will try and apply your
patch and check the behaviour of ls without the -l switch, though, and
give you feedback later.

Thanks for now, I think that especially you support on this list is
exemplary. Compliments
--
Alexander Kriegisch


----------------------------------------------------------------------


> > Attached patch makes bbox ls compatible with GNU coreutils one
> > regarding link dereferencing.

As promised, here is my feedback: It works. Thank you. Maybe you could
provide patches for 1.4.1 and other relevant versions still supported. I
guess there might be more users wishing to profit from this.

BTW: I called by patch file busybox-1.4.1-ls_symlink.patch and slightly
changed the header, like so:

Before:
diff -d -urpN busybox.7/coreutils/ls.c busybox.8/coreutils/ls.c
--- busybox.7/coreutils/ls.c	2007-02-11 17:14:18.000000000 +0100
+++ busybox.8/coreutils/ls.c	2007-02-28 00:21:14.000000000 +0100

After:
--- coreutils/ls.c	2007-02-11 17:14:18.000000000 +0100
+++ coreutils/ls.c	2007-02-28 00:21:14.000000000 +0100


----------------------------------------------------------------------


Sorry, yet another message. BTW, was it on purpose to keep this
conversation private and not send copies to the list?

I wrote:
> > You are right, it only follows without -l by default. My mistake, I
> > apologise. There are two switches that can do this, if necessary (Ubuntu
> > 6.10 and others). Quote from the ls manpage:
> >
>> >> -H, --dereference-command-line
>> >>     follow symbolic links listed on the command line
>> >> --dereference-command-line-symlink-to-dir
>> >>     follow each command line symbolic link that points to a directory
> >
> > The difference is that the former (-lH) also works for symlinked files
> > (lists the size and modification date of the referenced file rather than
> > that of the link), whereas the latter only expands directories. It would
> > be nice to have those switches in Busybox, too, but if they are not part
> > of Coreutils, I understand we won't get them. I will try and apply your
> > patch and check the behaviour of ls without the -l switch, though, and
> > give you feedback later.

There also is this option:
> > -L, --dereference
> >     when showing file information for a symbolic link, show information
> >     for the file the link references rather than for the link itself

In Coreutils 6.7 (current version, I did not check others and don't know
which one exactly Busybox is intended to compatible with) we have this:

> > enum Dereference_symlink
> >   {
> >     DEREF_UNDEFINED = 1,
> >     DEREF_NEVER,
> >     DEREF_COMMAND_LINE_ARGUMENTS,      /* -H */
> >     DEREF_COMMAND_LINE_SYMLINK_TO_DIR, /* the default, in certain
cases */
> >     DEREF_ALWAYS                       /* -L */
> >   };

Greetings from Germany (where are you?)
--
Alexander Kriegisch


----------------------------------------------------------------------

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.4.1-ls_symlink.patch
Url: http://lists.busybox.net/pipermail/busybox/attachments/20070228/61c6147d/attachment.diff 

From terry1 at beam.ltd.uk  Wed Feb 28 10:37:48 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 10:37:48 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <20070228101645.GA13363@nsk.no-ip.org>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
	<45E54A0A.6030207@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org>
Message-ID: <45E55B7C.3010906@beam.ltd.uk>

Luciano Miguel Ferreira Rocha wrote:
> On Wed, Feb 28, 2007 at 09:23:22AM +0000, Terry Barnaby wrote:
>> Yes, I am using initramfs and thanks for the info. I could use this for 
>> the boot initrd, but the system then mounts its real root fs using a 
>> read only NFS mount. I would prefer not to have a /dev/console in my NFS 
>> mounted file system either ...
> 
> Well, you'll still need some RW paths in your system. You can accomplish
> that for /dev and get a working one too by keeping the one in initramfs:
> 
> mount --bind /dev /nfsroot/dev
> ...
> switch_root
> 
I guess I could do that, but I would like the initial boot tmpfs to have 
gone once the system is booted so that the NFS mounted file system is 
the only one in operation. I have created tmpfs file systems for 
/dev,/tmp etc in my /etc/init.d/rcS script and this works fine if there 
is a /dev/console ...

I have had a quick look at the busybox init, and it appears that if 
there is not a /dev/console or /dev/null then it will not run any of the 
scripts .... So /dev/console or /dev/null is required for init to run.

I am still thinking it would be best to add the ability for init to 
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as 
possible to at-least get debug info from programs running.


Terry


From terry1 at beam.ltd.uk  Wed Feb 28 11:55:40 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 11:55:40 +0000
Subject: [PATCH]: Modifying init to create /dev/console and /dev/null
In-Reply-To: <45E55B7C.3010906@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org>
	<45E54A0A.6030207@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org>
	<45E55B7C.3010906@beam.ltd.uk>
Message-ID: <45E56DBC.9030407@beam.ltd.uk>

Hi,

I have decided to have a go and add support to init to create
a tmpfs file system on /dev and the two main device nodes /dev/console 
and /dev/null if no /dev/console exists on the rootfs.

This feature is enabled with the FEATURE_INIT_UDEV option.

If this option is enabled and the file /dev/console does not exist then
init will mount a tmpfs file system on /dev and create the basic device 
nodes /dev/console and /dev/null. This allows a system to boot and run 
without any device nodes in the root file system. The system startup 
scripts can create additional device nodes as needed or a full udev 
implementation can then take over.

I am using this for my own system at the moment and thought I would 
release the patch for interest. This is probably not the best way to 
achieve the task in hand, but it does work well.

Cheers


Terry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beam-init-udev-1.patch
Type: text/x-patch
Size: 1963 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070228/f73e4e37/attachment-0002.bin 

From Thomas.Necker at marconi.com  Wed Feb 28 16:30:18 2007
From: Thomas.Necker at marconi.com (Thomas Necker)
Date: Wed, 28 Feb 2007 17:30:18 +0100
Subject: sed: missing LF
Message-ID: <OF758DBA6F.2C713D02-ONC1257290.005A3C0E@uk.marconicomms.com>

I have the following file test.cfg:

ADDRESS=
NETMASK=
GATEWAY=

When I issue the command

sed "/^ADDRESS/c\ADDRESS=1.2.3.4"

I get

ADDRESS=1.2.3.4NETMASK=
GATEWAY=

instead of

ADDRESS=1.2.3.4
NETMASK=
GATEWAY=

So, a LF is missing. I'm using Busybox 1.4.0. It worked with 1.0.

Thomas


From ddaney at avtrex.com  Wed Feb 28 17:33:54 2007
From: ddaney at avtrex.com (David Daney)
Date: Wed, 28 Feb 2007 09:33:54 -0800
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E4A68D.9020008@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>	<200702271328.06297.vapier@gentoo.org>
	<45E4A68D.9020008@beam.ltd.uk>
Message-ID: <45E5BD02.6050606@avtrex.com>

Terry Barnaby wrote:
> Mike Frysinger wrote:
>> On Tuesday 27 February 2007, Terry Barnaby wrote:
>>> However, init and other programs obviously require /dev/console (and
>>> other /dev entries).
>> they dont require /dev/console
>>
>>> I was wondering about adding an option to init where it would create a
>>> tmpfs file system, mount it on /dev and create a /dev/console node if no
>>> /dev/console was found. I guess it could do a bit more and function as
>>> udev as well.
>> it wouldnt work ... the kernel opens up /dev/console before executing init, so 
>> even if /sbin/init created the device node, it wouldnt matter
>>
>> also, this is what init scripts are for ... such / policy handling does not 
>> belong hardcoded in the C code
>> -mike
> 
> No, they don't require /dev/console just to operate, but if you want 
> debug printout they do :)
> 
> Init could easily reopen its controlling terminal to the created 
> /dev/console and continue ...
> 
> The reason I was looking at getting init to create /dev/console was so 
> that I could debug my init scripts that are not working when 
> /dev/console does not exist ...
> 

Why do you think what Make says is false?  All your posts on this 
subject are premised on that false belief.

I think it is time that you change your assumption that you can boot a 
system that does not contain /dev/console in its root file system.  You 
cannot do it with a standard Linux kernel.

As I see it you have two choices:

1) Put /dev/console in your root filesystem.
2) Hack up your kernel so that /dev/console is not needed.

David Daney


From florian at alphacore.net  Wed Feb 28 19:44:31 2007
From: florian at alphacore.net (Florian Fainelli)
Date: Wed, 28 Feb 2007 20:44:31 +0100
Subject: [PATCH] ping.c : fix min/max packet size usage
Message-ID: <45E5DB9F.2030704@alphacore.net>

Hi all,

An OpenWrt user reported that using packet size lower than 15, you could
trigger the following bug :

ping -s 1 -c 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 1 data bytes
9 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=291869364.5 ms


The following patch adds maximum length checking for ICMP packets, as
well as minimum usable size. Also, I noticed that datalen was not used
when generating packets, when not specified, datalen is initialized to
DEFDATALEN.

Thanks.

--- busybox-1.4.1/networking/ping.c     2007-01-24 22:34:34.000000000 +0100
+++ busybox-1.4.1.new/networking/ping.c 2007-02-28 20:35:59.000000000 +0100
@@ -70,7 +70,7 @@
        struct sockaddr_in pingaddr;
        struct icmp *pkt;
        int pingsock, c;
-       char packet[DEFDATALEN + MAXIPLEN + MAXICMPLEN];
+       char packet[datalen + MAXIPLEN + MAXICMPLEN];

        pingsock = create_icmp_socket();

@@ -86,7 +86,7 @@
        pkt->icmp_type = ICMP_ECHO;
        pkt->icmp_cksum = in_cksum((unsigned short *) pkt, sizeof(packet));

-       c = sendto(pingsock, packet, DEFDATALEN + ICMP_MINLEN, 0,
+       c = sendto(pingsock, packet, datalen + ICMP_MINLEN, 0,
                           (struct sockaddr *) &pingaddr, sizeof(struct
sockaddr_in));

        if (c < 0) {
@@ -257,8 +257,8 @@

        gettimeofday(&tv, NULL);

-       /* discard if too short */
-       if (sz < (datalen + ICMP_MINLEN))
+       /* discard if too short / long */
+       if (sz < (datalen + ICMP_MINLEN) || sz > (MAXICMPLEN))
                return;

        /* check IP header */
@@ -274,6 +274,10 @@
                ++nreceived;
                tp = (struct timeval *) icmppkt->icmp_data;

+               /* If packet is too short, results will be truncated */
+               if (sz < (ICMP_MINLEN + sizeof(tv.tv_sec) +
sizeof(tv.tv_usec)))
+                       return;
+
                if ((tv.tv_usec -= tp->tv_usec) < 0) {
                        --tv.tv_sec;
                        tv.tv_usec += 1000000;


From terry1 at beam.ltd.uk  Wed Feb 28 21:29:45 2007
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 28 Feb 2007 21:29:45 +0000
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E5BD02.6050606@avtrex.com>
References: <45E3F851.4060004@beam.ltd.uk>	<200702271328.06297.vapier@gentoo.org>
	<45E4A68D.9020008@beam.ltd.uk> <45E5BD02.6050606@avtrex.com>
Message-ID: <45E5F449.2090308@beam.ltd.uk>

David Daney wrote:
> Terry Barnaby wrote:
>> Mike Frysinger wrote:
>>> On Tuesday 27 February 2007, Terry Barnaby wrote:
>>>> However, init and other programs obviously require /dev/console (and
>>>> other /dev entries).
>>> they dont require /dev/console
>>>
>>>> I was wondering about adding an option to init where it would create a
>>>> tmpfs file system, mount it on /dev and create a /dev/console node 
>>>> if no
>>>> /dev/console was found. I guess it could do a bit more and function as
>>>> udev as well.
>>> it wouldnt work ... the kernel opens up /dev/console before executing 
>>> init, so even if /sbin/init created the device node, it wouldnt matter
>>>
>>> also, this is what init scripts are for ... such / policy handling 
>>> does not belong hardcoded in the C code
>>> -mike
>>
>> No, they don't require /dev/console just to operate, but if you want 
>> debug printout they do :)
>>
>> Init could easily reopen its controlling terminal to the created 
>> /dev/console and continue ...
>>
>> The reason I was looking at getting init to create /dev/console was so 
>> that I could debug my init scripts that are not working when 
>> /dev/console does not exist ...
>>
> 
> Why do you think what Make says is false?  All your posts on this 
> subject are premised on that false belief.
> 
> I think it is time that you change your assumption that you can boot a 
> system that does not contain /dev/console in its root file system.  You 
> cannot do it with a standard Linux kernel.
> 
> As I see it you have two choices:
> 
> 1) Put /dev/console in your root filesystem.
> 2) Hack up your kernel so that /dev/console is not needed.
> 
> David Daney

Hi,

Because, you can !
You can boot a system without /dev/console and get init to create the 
basic /dev/console and continue. At least with the 2.6.19 kernel. My 
patch to the Busybox init later in this thread does this and with an 
un-modified kernel (in fact a standard Fedora 6 binary kernel).

I can now boot my system without any /dev nodes in sight. Init mounts a 
tmpfs file system on /dev and creates the two necessary nodes 
/dev/console and /dev/null and the rcS init script creates the rest.
However, being new to Busybox I'm not sure that this is the best 
approach ...

Cheers

Terry


From vda.linux at googlemail.com  Wed Feb 28 22:38:47 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 28 Feb 2007 23:38:47 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E54F6E.7090003@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<200702272335.02502.vda.linux@googlemail.com>
	<45E54F6E.7090003@beam.ltd.uk>
Message-ID: <200702282338.47578.vda.linux@googlemail.com>

On Wednesday 28 February 2007 10:46, Terry Barnaby wrote:
> Denis Vlasenko wrote:
> > On Tuesday 27 February 2007 22:53, Terry Barnaby wrote:
> >> Denis Vlasenko wrote:
> >>> On Tuesday 27 February 2007 10:22, Terry Barnaby wrote:
> >>>> I am trying to create a basic Linux system based on Busybox and would 
> >>>> like the ability to create the root file system as a normal user and 
> >>>> without any /dev entries. The startup script would create the /dev 
> >>>> entries as needed.
> >>>> However, init and other programs obviously require /dev/console (and 
> >>>> other /dev entries).
> >>>>
> >>>> I was wondering about adding an option to init where it would create a 
> >>>> tmpfs file system, mount it on /dev and create a /dev/console node if no 
> >>>> /dev/console was found. I guess it could do a bit more and function as 
> >>>> udev as well.
> >>> I think you are on the right track, but move in the wrong direction
> >>> along that track. Code shouldn't be added to init, it should be removed.
> >>>
> >>> http://busybox.net/~vda/example_fs/README
> >>> --
> >>> vda
> >> Hi Denis,
> >>
> >> But then you end up with init implemented in several shell scripts.
> >> I guess it depends if you prefer 'C' or shell programs :)
> > 
> > Shell programs are easier to tailor for particular system without
> > messing up with compiler and toolchain - exactly what you need
> > for "I want to create /dev/console".
> > --
> > vda
> 
> Hi Denis,
> 
> I notice your http://busybox.net/~vda/example_fs has /dev/console and 
> /dev/null nodes. Have you managed to get a busybox system to boot and 
> run using shell scripts without these nodes ?

Yes, see below
 
> In my system the final rootfs will be a read-only NFS mount and I don't 
> want to have a /dev/console in the NFS mounted file system. So I need to 
> create this at boot time. My shell scripts do not appear to run from 
> init if I do not have a /dev/console though ...

This is the script which runs as /linuxrc (PID=1) in my initrd.
Notice that it mounts ramfs on /dev and creates console
and null there before chrooting into new ("real") root.
--
vda

#!/bin/sh

export PATH=/bin:/usr/bin

if ! test "$INIT"; then
    INIT=/sbin/init
fi

cd /
# devfs allows me to use /dev/ide/.../.../.. root= param
#mount -n -t devfs none /dev
mount -n -t proc none /proc
#mount -n -t sysfs none /sys

echo "# Mounting root fs"
/script/mount_root

# Clean up
#umount /sys
umount /proc

echo "# Chrooting into root fs"
test -d /new_root/dev -a -d /new_root/proc || {
    echo "Root fs (ls -l):"
    cd /new_root; ls -l
    echo "Root fs has no /dev and/or /proc!"
    echo "Fatal, cannot continue booting"
    while true; do sleep 32000; done
}
mount -n -t ramfs none /new_root/dev || {
    echo "! mount -n -t ramfs none /new_root/dev failed, continuing in 10 sec"
    sleep 10
}
cp -dp /dev/console /dev/null /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc || {
    echo "pivot_root failed. Fatal, cannot continue booting"
    while true; do sleep 32000; done
}

exec \
chroot . \
sh -c '\
umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
exec /bin/env - $INIT
'

echo "chroot . sh failed. Fatal, cannot continue booting"
while true; do sleep 32000; done


From vda.linux at googlemail.com  Wed Feb 28 22:43:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 28 Feb 2007 23:43:40 +0100
Subject: Modifying init to create /dev/console ?
In-Reply-To: <45E55B7C.3010906@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org>
	<45E55B7C.3010906@beam.ltd.uk>
Message-ID: <200702282343.40891.vda.linux@googlemail.com>

On Wednesday 28 February 2007 11:37, Terry Barnaby wrote:
> Luciano Miguel Ferreira Rocha wrote:
> I have had a quick look at the busybox init, and it appears that if 
> there is not a /dev/console or /dev/null then it will not run any of the 
> scripts .... So /dev/console or /dev/null is required for init to run.
> 
> I am still thinking it would be best to add the ability for init to 
> create a basic /dev with /dev/console etc if these do not exist. This
> still appears a cleaner way of doing things to me at the moment ...
> This could be done internally or by calling an external script from
> init although it would be nice if /dev/console existed as early on as 
> possible to at-least get debug info from programs running.

kernel boored with: init=/somewhere/fix_dev.sh

fix_dev.sh:

#!/bin/sh
mknod ... /dev/....
exec /sbin/init "$@"

No hacking in init! :)

Do you see any problems with this approach?
--
vda


From vda.linux at googlemail.com  Wed Feb 28 23:14:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Mar 2007 00:14:19 +0100
Subject: [PATCH] ping.c : fix min/max packet size usage
In-Reply-To: <45E5DB9F.2030704@alphacore.net>
References: <45E5DB9F.2030704@alphacore.net>
Message-ID: <200703010014.19437.vda.linux@googlemail.com>

On Wednesday 28 February 2007 20:44, Florian Fainelli wrote:
> Hi all,
> 
> An OpenWrt user reported that using packet size lower than 15, you could
> trigger the following bug :
> 
> ping -s 1 -c 1 192.168.0.1
> PING 192.168.0.1 (192.168.0.1): 1 data bytes
> 9 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=291869364.5 ms
> 
> The following patch adds maximum length checking for ICMP packets, as
> well as minimum usable size. Also, I noticed that datalen was not used
> when generating packets, when not specified, datalen is initialized to
> DEFDATALEN.

Thanks!

Unfortunately after 1.4.1 ping and ping6 got merged into one ping.c
(saving kilobytes of code) and your patch doesn't apply to current svn.

Care to rediff?

ping.c from current svn is attached.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ping.c
Type: text/x-csrc
Size: 20563 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070301/f15aa685/attachment-0002.c 

From vda.linux at googlemail.com  Wed Feb 28 23:26:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Mar 2007 00:26:56 +0100
Subject: serial console and log-in
In-Reply-To: <1172674255.27284.58.camel@localhost>
References: <20070220145025.bfc52cea95091b0fffcb409eab6296ba.c4ccc45496.wbe@email.secureserver.net>
	<200702272040.22024.vda.linux@googlemail.com>
	<1172674255.27284.58.camel@localhost>
Message-ID: <200703010026.56844.vda.linux@googlemail.com>

On Wednesday 28 February 2007 15:50, Natanael Copa wrote:
> > > I backported the svn init to 1.4.1 (i depend on releases).
> > > 
> > > My inittab line looks like this:
> > > 
> > > ::respawn:/sbin/getty - 9600 vt100
> > > 
> > > I got a login prompt but no controlling tty:
> > > 
> > > -ash: cant't access tty; job control turned off
> > > 
> > > ~$ echo TEST > /dev/tty
> > > -ash: cannot create /dev/tty: No such device or address
> > > 
> > > That was on a VGA console.
> > > 
> > > Then I tried to run it in qemu, with -nographic. It booted, it gave me a
> > > login, but same as VGA, no controlling tty.
> > 
> > I expected that. It stems from the fact that /dev/console
> > cannot be a ctty.
> > 
> > I'm not sure this can be classified as 'bug'.
> 
> Probably not. But then I need another feature :-/
> 
> Something like running a specified row only when controlling terminal is
> serial.
> 
> ttyS0:serial:respawn:/sbin/getty -L ttyS0 9600 vt100
> 
> Drawback is that it needs to use an unused field in inittab.

How about writing small hack which analyzes stdin (fd #0)
and closes fd #0,1,2 + reopens/dups /dev/ttyN or /dev/ttySn:


/* From <linux/vt.h> */
struct vt_stat {
        unsigned short v_active;        /* active vt */
        unsigned short v_signal;        /* signal to send */
        unsigned short v_state; /* vt bitmask */
};
enum { VT_GETSTATE = 0x5603 };  /* get global vt state info */

/* From <linux/serial.h> */
struct serial_struct {
        int     type;
        int     line;
        unsigned int    port;
        int     irq;
        int     flags;
        int     xmit_fifo_size;
        int     custom_divisor;
        int     baud_base;
        unsigned short  close_delay;
        char    io_type;
        char    reserved_char[1];
        int     hub6;
        unsigned short  closing_wait; /* time to wait before closing */
        unsigned short  closing_wait2; /* no longer used... */
        unsigned char   *iomem_base;
        unsigned short  iomem_reg_shift;
        unsigned int    port_high;
        unsigned long   iomap_base;     /* cookie passed into ioremap */
        int     reserved[1];
};

        int fd;
        struct vt_stat vt;
        struct serial_struct sr;
        char console[64];

        /* identify the real console backend and try to use it */
        if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
                /* this is a serial console */
                snprintf(console, sizeof(console) - 1, "/dev/ttyS%d", sr.line);
        } else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
                /* this is linux virtual tty */
                snprintf(console, sizeof(console) - 1, "/dev/tty%d", vt.v_active);
        } else {
               /* unable to figure it out */
               ...
        }

	fd = xopen(console, O_RDWR);
	dup2(fd, 0);
	dup2(fd, 1);
	dup2(fd, 2);
	while (fd > 2) close(fd--);

then exec it's argv?

Use it like this:

::respawn:/somewhere/cttyhack /sbin/getty - 9600 vt100

Care to try? ;)
--
vda


From wimpunk at gmail.com  Wed Feb 28 16:13:13 2007
From: wimpunk at gmail.com (Wim Vinckier)
Date: Wed, 28 Feb 2007 17:13:13 +0100
Subject: [PATCH]: Modifying init to create /dev/console and /dev/null
In-Reply-To: <45E56DBC.9030407@beam.ltd.uk>
References: <45E3F851.4060004@beam.ltd.uk>
	<20070227234938.GA2357@nsk.no-ip.org> <45E54A0A.6030207@beam.ltd.uk>
	<20070228101645.GA13363@nsk.no-ip.org> <45E55B7C.3010906@beam.ltd.uk>
	<45E56DBC.9030407@beam.ltd.uk>
Message-ID: <5c43128e0702280813g243d0ab4n5bf5a688309a9dc6@mail.gmail.com>

Nice, looks like the patch I just needed. :-)

On 2/28/07, Terry Barnaby <terry1 at beam.ltd.uk> wrote:
> Hi,
>
> I have decided to have a go and add support to init to create
> a tmpfs file system on /dev and the two main device nodes /dev/console
> and /dev/null if no /dev/console exists on the rootfs.
>
> This feature is enabled with the FEATURE_INIT_UDEV option.
>
> If this option is enabled and the file /dev/console does not exist then
> init will mount a tmpfs file system on /dev and create the basic device
> nodes /dev/console and /dev/null. This allows a system to boot and run
> without any device nodes in the root file system. The system startup
> scripts can create additional device nodes as needed or a full udev
> implementation can then take over.
>
> I am using this for my own system at the moment and thought I would
> release the patch for interest. This is probably not the best way to
> achieve the task in hand, but it does work well.
>
> Cheers
>
>
> Terry
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
>


-- 
You have been on the computer to long when you start tilting your head
sideways to smile :-)