From vapier at gentoo.org  Wed Aug  1 02:23:12 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 1 Aug 2007 05:23:12 -0400
Subject: BusyBox poweroff problem with SMP kernel
In-Reply-To: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
References: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
Message-ID: <200708010523.12629.vapier@gentoo.org>

On Tuesday 31 July 2007, Zhiming Zhou wrote:
> So, I want to know is there someone successfully use busybox to poweroff 
> computer with SMP kernel? And what is the possible reason of my problem?

sounds like a kernel problem, not a busybox problem
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070801/31c34880/attachment.pgp 

From strange at nsk.no-ip.org  Wed Aug  1 06:09:14 2007
From: strange at nsk.no-ip.org (Luciano Rocha)
Date: Wed, 1 Aug 2007 14:09:14 +0100
Subject: BusyBox poweroff problem with SMP kernel
In-Reply-To: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
References: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
Message-ID: <20070801130913.GA10643@bit.office.eurotux.com>

On Wed, Aug 01, 2007 at 11:08:28AM +0800, Zhiming Zhou wrote:
<snip>
> But while the system run in computer with multiple processors; system
> stopped while "Power down system" was printed, it seems out of busybox, and
> acpi_power_off is not called.
> 
> And if I compiled my linux kernel without CONFIG_SMP configed, and use the
> same busybox root file system, there was none poweroff problems in my
> system.
> 
> ------------------------------------------------------------------------------
> So, I want to know is there someone successfully use busybox to poweroff
> computer with SMP kernel? And what is the possible reason of my problem?

That's a kernel problem, not a busybox one.

If you're using APM, the kernel disables it at boot when it's running
with more than one processor. You can force it on, only for
powering-off, with the option apm=power-off to the kernel.

If you're using ACPI, then I don't know why it isn't powering down. It
could be because of an older BIOS, blacklisted when in SMP mode. But
then you can try activating apm like above.

-- 
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/20070801/1d013e64/attachment.pgp 

From tefyxcegmkow at spammotel.com  Wed Aug  1 08:07:54 2007
From: tefyxcegmkow at spammotel.com (wimpunk)
Date: Wed, 01 Aug 2007 17:07:54 +0200
Subject: reboot/poweroff/halt commands not working
In-Reply-To: <1185560429.3596.3.camel@localhost>
References: <1185560429.3596.3.camel@localhost>
Message-ID: <47k6o4-c5c.ln1@l29.abba.lin.vlaanderen.be>

Dallas Clement wrote:
> I'm using 1.6.1 and none of these commands seem to work all by
> themselves.  If I provide the -f option, they all work just fine.  I'm
> not sure if this is a regression problem or it has always been this way.
> 
> I thought things were working properly in previous versions.  I'm pretty
> sure I did not have to supply the -f option.

I have the same problem with 1.5.* and 1.4.2.  It fails on ARM but it
works on i386.

wimpunk.


From tefyxcegmkow at spammotel.com  Wed Aug  1 08:13:28 2007
From: tefyxcegmkow at spammotel.com (wimpunk)
Date: Wed, 01 Aug 2007 17:13:28 +0200
Subject: BusyBox poweroff problem with SMP kernel
In-Reply-To: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
References: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
Message-ID: <jhk6o4-j8c.ln1@l29.abba.lin.vlaanderen.be>

Zhiming Zhou wrote:
> I compiled a smp linux kernel to support multiple processors, and use 
> busybox 1.6.1 as root filesystem.
> The compiled linux system can be successfully started, and busybox ash 
> is started, while I typed "poweroff" in ash,
> 
> If the system run in computer with single processor; system stopped 
> while "Sending SIGTERM to all processes" was printed,
> and I found in busybox source directory/init/init.c, function 
> shutdown_system(void):
> 
> message(L_CONSOLE | L_LOG, "Sending SIG%s to all processes", "TERM");
> kill(-1, SIGTERM);
> 
> but kill function can not be proceeded, and system stopped.
> 
> But while the system run in computer with multiple processors; system 
> stopped while "Power down system" was printed, it seems out of busybox, 
> and acpi_power_off is not called.
> 
> And if I compiled my linux kernel without CONFIG_SMP configed, and use 
> the same busybox root file system, there was none poweroff problems in 
> my system.
> 
> ------------------------------------------------------------------------------ 
> 
> So, I want to know is there someone successfully use busybox to poweroff 
> computer with SMP kernel? And what is the possible reason of my problem?
> 
> Thanks
> 
> 


Referring to a previous post: try the -f option.  I'm just curious if
that one works...

wimpunk.


From vrashtchi at yahoo.com  Wed Aug  1 14:59:25 2007
From: vrashtchi at yahoo.com (vahid rashtchi)
Date: Wed, 1 Aug 2007 14:59:25 -0700 (PDT)
Subject: I/O difficulties
Message-ID: <867947.64675.qm@web53106.mail.re2.yahoo.com>

I am using KB9202b evaluation board for developing a real time control system project.  I am using c++ for programming and use buildroot compiler.I have difficulties  in input /output operation and configuring interupt routin under busybox.
  I can't perform I/O operation and see "permission  denied"  error. Does anyone have sample source code for these propose ?
   
  with best regard
  V.Rashtchi

       
---------------------------------
Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070801/20863f8c/attachment.htm 

From vda.linux at googlemail.com  Wed Aug  1 15:49:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 1 Aug 2007 23:49:19 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <866511.5093.qm@web62501.mail.re1.yahoo.com>
References: <866511.5093.qm@web62501.mail.re1.yahoo.com>
Message-ID: <200708012349.19564.vda.linux@googlemail.com>

On Tuesday 24 July 2007 10:54, Alex Landau wrote:
> Hi,
> 
> The attached patch fixes a compilation error:
>    undefined reference to `_BUG_bb_daemonize_is_unavailable_on_nommu
> and makes start-stop-daemon usable on no-MMU by using bb_daemonize only if BB_MMU and
> emulating it if !BB_MMU.
> 
> This is a bit hackish, since after vfork(), the child does all the work and exec()s the
> daemon, rather than execing right away, as the vfork paradigma says. Still I think this
> is better than re-execing start-stop-daemon and only then execing the daemon itself since
> this approach requires removing the -b (or --background) arguments from the command line,
> which is not fun (what if there are several -b options? etc.),

For the record: no, you don't need that. You can just re-exec with entire
command line intact. -b option will be seen again, and re-exec will be
seemingly done again... but second re-exec will actually NOT be done
because of this:

void forkexit_or_rexec(char **argv)
{
        pid_t pid;
        /* Maybe we are already re-execed and come here again? */
        if (re_execed)     <===================
                return;    <===================

The magic is in re_execed variable. grep for it.

BTW does current svn work for you?
--
vda

From vda.linux at googlemail.com  Wed Aug  1 16:21:26 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 00:21:26 +0100
Subject: editors/patch.c is broken
In-Reply-To: <fcaeb9bf0707311230v1aaff203n60f67a9e3d958a1d@mail.gmail.com>
References: <fcaeb9bf0707311230v1aaff203n60f67a9e3d958a1d@mail.gmail.com>
Message-ID: <200708020021.26709.vda.linux@googlemail.com>

On Tuesday 31 July 2007 20:30, Nguyen Thai Ngoc Duy wrote:
> src/dest file names are read by xmalloc_fgets which include trailing
> \n characters. Therefore patch either reads from wrong source file or
> write to wrong destination file. The attached patch should fix it.
> I'm not sure about the rest of xmalloc_fgets used in patch, though.

Applied, thanks
--
vda

From dallas.a.clement at gmail.com  Wed Aug  1 19:35:52 2007
From: dallas.a.clement at gmail.com (Dallas Clement)
Date: Wed, 1 Aug 2007 21:35:52 -0500
Subject: reboot/poweroff/halt commands not working
In-Reply-To: <47k6o4-c5c.ln1@l29.abba.lin.vlaanderen.be>
References: <1185560429.3596.3.camel@localhost>
	<47k6o4-c5c.ln1@l29.abba.lin.vlaanderen.be>
Message-ID: <46b1430a.38f8220a.3e1b.721a@mx.google.com>

It's failing on a i686 for me.  Version 1.6.1.  Haven't retried 1.6.0, but
as far as I recall it was working in that version.

> -----Original Message-----
> From: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net]
> On Behalf Of wimpunk
> Sent: Wednesday, August 01, 2007 10:08 AM
> To: busybox at busybox.net
> Subject: Re: reboot/poweroff/halt commands not working
> 
> Dallas Clement wrote:
> > I'm using 1.6.1 and none of these commands seem to work all by
> > themselves.  If I provide the -f option, they all work just fine.
> I'm
> > not sure if this is a regression problem or it has always been this
> way.
> >
> > I thought things were working properly in previous versions.  I'm
> pretty
> > sure I did not have to supply the -f option.
> 
> I have the same problem with 1.5.* and 1.4.2.  It fails on ARM but it
> works on i386.
> 
> wimpunk.
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox


From vapier at gentoo.org  Wed Aug  1 21:18:04 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 2 Aug 2007 00:18:04 -0400
Subject: I/O difficulties
In-Reply-To: <867947.64675.qm@web53106.mail.re2.yahoo.com>
References: <867947.64675.qm@web53106.mail.re2.yahoo.com>
Message-ID: <200708020018.05315.vapier@gentoo.org>

On Wednesday 01 August 2007, vahid rashtchi wrote:
> I am using KB9202b evaluation board for developing a real time control
> system project.  I am using c++ for programming and use buildroot
> compiler.I have difficulties  in input /output operation and configuring
> interupt routin under busybox. I can't perform I/O operation and see
> "permission  denied"  error. Does anyone have sample source code for these
> propose ?

this question isnt appropriate for the busybox lists.  please try a generic 
embedded forum (like ucdot.org) or the kernel mailing list for whatever 
architecture you're developing for.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070802/1b8111b2/attachment.pgp 

From natanael.copa at gmail.com  Wed Aug  1 21:42:46 2007
From: natanael.copa at gmail.com (Natanael copa)
Date: Thu, 02 Aug 2007 06:42:46 +0200
Subject: [PATCH] sendmail/ssmtp applet
Message-ID: <1186029766.14577.2.camel@nat-desktop>

Hi,

Here is a crude sendmail applet based on ssmtp:
http://dev.alpinelinux.org/~ncopa/busybox-initial-sendmail.patch

(It is bigger than 40k so I was not allowed to post it on the mailing list)

It is an initial version but I post it anyway so experienced busybox'ers
can give hits and give the opportunity for volunteers (with more time
than me) to continue work on it.

Some issues I saw while preparing it:
* fix Copyright
* fix include files
* we will probably never want ssl support so that part can simply be
cutted
* argument parsing could use getopt32
* unused options could be cutted. Maybe have an config option for
sendmail compatibility.
* bool_t should be bool
* many of the global bool vars can be compressed into a "flags" variable
where every bool represent a bit.
* base64 code can probably be reuse from previous busybox code.
* md5 auth?
* logging could be handled with something from libbb?

I'm sure there are more things. The size is not too bad anyway and it
can only become smaller from here :-)

I do intend to fix those things (if there are enough interest) but by
posting it here early i give interested ppl a chance to give a hand.


function                                             old     new   delta
ssmtp                                                  -    2962   +2962
sendmail_main                                          -    1160   +1160
die                                                    -     565    +565
header_parse                                           -     545    +545
smtp_write                                             -     352    +352
rcpt_parse                                             -     334    +334
smtp_open                                              -     240    +240
log_event                                              -     223    +223
to64frombits                                           -     222    +222
TimeoutJmpBuf                                          -     200    +200
smtp_read                                              -     183    +183
paq                                                    -     161    +161
append_domain                                          -     152    +152
addr_parse                                             -     141    +141
packed_usage                                         318     446    +128
standardise                                            -      90     +90
rcpt_remap                                             -      84     +84
base64digits                                           -      65     +65
hostname                                               -      64     +64
strip_post_ws                                          -      37     +37
strip_pre_ws                                           -      32     +32
arpadate                                               -      32     +32
smtp_okay                                              -      20     +20
handler                                                -      19     +19
rcpt_list                                              -      16     +16
headers                                                -      16     +16
applets                                               48      64     +16
uad                                                    -       8      +8
static.stdin@@GLIBC_2                                  -       8      +8
rt                                                     -       8      +8
root                                                   -       8      +8
minus_f                                                -       8      +8
minus_F                                                -       8      +8
mailhost                                               -       8      +8
ht                                                     -       8      +8
gecos                                                  -       8      +8
from                                                   -       8      +8
auth_user                                              -       8      +8
auth_pass                                              -       8      +8
auth_method                                            -       8      +8
static.Version                                         -       7      +7
use_starttls                                           -       4      +4
port                                                   -       4      +4
override_from                                          -       4      +4
minus_v                                                -       4      +4
minus_t                                                -       4      +4
log_level                                              -       4      +4
have_from                                              -       4      +4
have_date                                              -       4      +4
------------------------------------------------------------------------------
(add/remove: 47/0 grow/shrink: 2/0 up/down: 8202/0)          Total: 8202
bytes
   text    data     bss     dec     hex filename
  14827     816    8280   23923    5d73 busybox_old
  27764    1155    8728   37647    930f busybox_unstripped



Natanael Copa


From landau_alex at yahoo.com  Wed Aug  1 23:26:58 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Wed, 1 Aug 2007 23:26:58 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0707311000w6a977564ncfd8c2f23e666594@mail.gmail.com>
Message-ID: <899460.68656.qm@web62503.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> Applied with some other minor changes added, please check svn
> and yell if you see something bad.
> 
> vda
> 

Yelling! I found several problems, the attached patch fixes them.

1. pid_is_exec(): you changed the return to (~n) from something akin to (!n). This works
fine if n==0, but then n!=0, the returned value is also non-zero, and it breaks the
calling code.
2. When vfork()ing, the parent should exit(0) and not return(0), since the child has run
quite some time and may have changed the return address in stack. So, no returns in the
parent, only function calls. Added a comment about that. Better safe than sorry.
3. After vfork(), the check of (pid==0) to see if I'm the parent is wrong. It should be
(pid!=0).
4. Added a setsid() call just before daemonize_or_rexec.

Alex


      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: start-stop-daemon-round2.patch
Type: text/x-patch
Size: 979 bytes
Desc: 660604078-start-stop-daemon-round2.patch
Url : http://busybox.net/lists/busybox/attachments/20070801/0c02bdcd/attachment.bin 

From vapier at gentoo.org  Wed Aug  1 23:45:08 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 2 Aug 2007 02:45:08 -0400
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <899460.68656.qm@web62503.mail.re1.yahoo.com>
References: <899460.68656.qm@web62503.mail.re1.yahoo.com>
Message-ID: <200708020245.10367.vapier@gentoo.org>

On Thursday 02 August 2007, Alex Landau wrote:
> +???????????????if (pid != 0) /* parent */
> +???????????????????????exit(0); /* the child may have changed the stack,
> so no return possible, only function calls */ /* child */

i havent read the code, but gut feeling says that should be _exit(0) ... or do 
i need to read the code ? :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070802/9403e96b/attachment.pgp 

From landau_alex at yahoo.com  Thu Aug  2 00:48:10 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 00:48:10 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <200708020245.10367.vapier@gentoo.org>
Message-ID: <868676.99832.qm@web62505.mail.re1.yahoo.com>


--- Mike Frysinger <vapier at gentoo.org> wrote:

> On Thursday 02 August 2007, Alex Landau wrote:
> > +               if (pid != 0) /* parent */
> > +                       exit(0); /* the child may have changed the stack,
> > so no return possible, only function calls */ /* child */
> 
> i havent read the code, but gut feeling says that should be _exit(0) ... or do 
> i need to read the code ? :)
> -mike
> 

You do need to read the code :-)
It's the parent who runs exit(), not the child, so it should be exit() and not _exit().
The child merely execv()s.

Alex


       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 

From Devinim.SOLEN at motiontrue.com  Thu Aug  2 01:25:14 2007
From: Devinim.SOLEN at motiontrue.com (=?iso-8859-9?Q?Devinim_=DE=D6LEN?=)
Date: Thu, 2 Aug 2007 11:25:14 +0300
Subject: NFS Support
Message-ID: <7D23D3548EC1874CBA41E02F76963A614B36EB8B30@MTEX01.motiontrue.entp>

Hi;

I am using BusyBox version 1.6.1 and have a NFS mounting problem.  When I try to mount NFS external point getting this error;

mount -t nfs 192.168.10.64:/ /mnt
mount: mounting 192.168.10.64:/ on /mnt failed

can anybody help ?

Best Regards

Devinim SOLEN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070802/6ba1bf43/attachment.htm 

From vda.linux at googlemail.com  Thu Aug  2 03:03:31 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 11:03:31 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <868676.99832.qm@web62505.mail.re1.yahoo.com>
References: <200708020245.10367.vapier@gentoo.org>
	<868676.99832.qm@web62505.mail.re1.yahoo.com>
Message-ID: <1158166a0708020303k3c00b435qd72a8c3e00d0b9a0@mail.gmail.com>

On 8/2/07, Alex Landau <landau_alex at yahoo.com> wrote:
> --- Mike Frysinger <vapier at gentoo.org> wrote:
>
> > On Thursday 02 August 2007, Alex Landau wrote:
> > > +               if (pid != 0) /* parent */
> > > +                       exit(0); /* the child may have changed the stack,
> > > so no return possible, only function calls */ /* child */
> >
> > i havent read the code, but gut feeling says that should be _exit(0) ... or do
> > i need to read the code ? :)
> > -mike

Thanks for testing Alex, I am applying the patch.
I am also reusing write_pidfile() from libbb here:

        if (opt & OPT_MAKEPID) {
                /* user wants _us_ to make the pidfile */
                write_pidfile(pidfile);
        }

In the process I (hopefully) fixed that nasty
"ifupdown + udhcpc_without_pidpile_creation" fsckup...

> You do need to read the code :-)
> It's the parent who runs exit(), not the child, so it should be exit() and not _exit().

Mike is implying that _exit() is mucking around much less that exit()
and for paranoid
reasons we are better off using it. So I changed exit to _exit in that spot.
We don't even need to fflush() before that, we did no output yet.

> The child merely execv()s.

So on NOMMU execv() basically creates another process in another
memory region, and
terminates current one, unless there is a parent sitting in vfork and waiting
(in which case parent is woken up instead of exit)?
--
vda

From strange at nsk.no-ip.org  Thu Aug  2 03:13:18 2007
From: strange at nsk.no-ip.org (Luciano Rocha)
Date: Thu, 2 Aug 2007 11:13:18 +0100
Subject: I/O difficulties
In-Reply-To: <867947.64675.qm@web53106.mail.re2.yahoo.com>
References: <867947.64675.qm@web53106.mail.re2.yahoo.com>
Message-ID: <20070802101318.GB28023@bit.office.eurotux.com>

On Wed, Aug 01, 2007 at 02:59:25PM -0700, vahid rashtchi wrote:
> I am using KB9202b evaluation board for developing a real time control system project.  I am using c++ for programming and use buildroot compiler.I have difficulties  in input /output operation and configuring interupt routin under busybox.
>   I can't perform I/O operation and see "permission  denied"  error. Does anyone have sample source code for these propose ?

For the low-level I/O instructions (inb, inw, outb, outw, ...), you need
to explicitly enable them with ioperm or iopl. See their manual pages.

However, you can't change the interrupt routing table. You need to
develop a kernel driver instead. See the book Linux Device Drivers:
http://lwn.net/Kernel/LDD3/

(also http://www.kroah.com/log/linux/ddk.html)

-- 
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/20070802/39b54895/attachment.pgp 

From landau_alex at yahoo.com  Thu Aug  2 03:32:10 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 03:32:10 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0708020303k3c00b435qd72a8c3e00d0b9a0@mail.gmail.com>
Message-ID: <810692.43452.qm@web62509.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On 8/2/07, Alex Landau <landau_alex at yahoo.com> wrote:
> > --- Mike Frysinger <vapier at gentoo.org> wrote:
> >
> > > On Thursday 02 August 2007, Alex Landau wrote:
> > > > +               if (pid != 0) /* parent */
> > > > +                       exit(0); /* the child may have changed the stack,
> > > > so no return possible, only function calls */ /* child */
> > >
> > > i havent read the code, but gut feeling says that should be _exit(0) ... or do
> > > i need to read the code ? :)
> > > -mike
> 
> Thanks for testing Alex, I am applying the patch.
> I am also reusing write_pidfile() from libbb here:
> 
>         if (opt & OPT_MAKEPID) {
>                 /* user wants _us_ to make the pidfile */
>                 write_pidfile(pidfile);
>         }
> 
> In the process I (hopefully) fixed that nasty
> "ifupdown + udhcpc_without_pidpile_creation" fsckup...
> 

Tested, working.

> > You do need to read the code :-)
> > It's the parent who runs exit(), not the child, so it should be exit() and not
> _exit().
> 
> Mike is implying that _exit() is mucking around much less that exit()
> and for paranoid
> reasons we are better off using it. So I changed exit to _exit in that spot.
> We don't even need to fflush() before that, we did no output yet.

I'm still not sure _exit is better in this case, but I'm not 100% sure it's wrong too...
Anyway it's currently working.

> 
> > The child merely execv()s.
> 
> So on NOMMU execv() basically creates another process in another
> memory region, and
> terminates current one, unless there is a parent sitting in vfork and waiting
> (in which case parent is woken up instead of exit)?

No, execve works exactly it does on an MMU system. It loads a new executable into the
current process. The difference is with vfork: on vfork, the parent is suspended, and the
child shares it's whole address space with the parent (the stack is shared too - that's
why this is so tricky!). The parent is resumed when the child either execve()s or
_exit()s.

> --
> vda
> 

Alex


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 

From vda.linux at googlemail.com  Thu Aug  2 03:36:46 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 11:36:46 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <810692.43452.qm@web62509.mail.re1.yahoo.com>
References: <1158166a0708020303k3c00b435qd72a8c3e00d0b9a0@mail.gmail.com>
	<810692.43452.qm@web62509.mail.re1.yahoo.com>
Message-ID: <1158166a0708020336r261e714hc3d3d443c8fdb30@mail.gmail.com>

> > > The child merely execv()s.
> >
> > So on NOMMU execv() basically creates another process in another
> > memory region, and
> > terminates current one, unless there is a parent sitting in vfork and waiting
> > (in which case parent is woken up instead of exit)?
>
> No, execve works exactly it does on an MMU system. It loads a new executable into the
> current process.

...trashing all memory area occupied by the process? how parent is
able to run then?

> The difference is with vfork: on vfork, the parent is suspended, and the
> child shares it's whole address space with the parent (the stack is shared too - that's
> why this is so tricky!). The parent is resumed when the child either execve()s or
> _exit()s.

I don't understand how parent is able to run if execve just nuked
parent's text segment
with unrelated code of execed program.
--
vda

From landau_alex at yahoo.com  Thu Aug  2 04:02:18 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 04:02:18 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0708020336r261e714hc3d3d443c8fdb30@mail.gmail.com>
Message-ID: <867356.54135.qm@web62509.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> > > > The child merely execv()s.
> > >
> > > So on NOMMU execv() basically creates another process in another
> > > memory region, and
> > > terminates current one, unless there is a parent sitting in vfork and waiting
> > > (in which case parent is woken up instead of exit)?
> >
> > No, execve works exactly it does on an MMU system. It loads a new executable into the
> > current process.
> 
> ...trashing all memory area occupied by the process? how parent is
> able to run then?

And what about the normal fork and execve? With fork, the text vmas are shared too, and,
I guess, on execve they are unshared. Not sure, but I guess the same happens here. Well,
not the same, since there is a difference between a shared vma and a shared
address_space, but it's the same idea.
Anyway, that's my understanding.

Alx

> 
> > The difference is with vfork: on vfork, the parent is suspended, and the
> > child shares it's whole address space with the parent (the stack is shared too -
> that's
> > why this is so tricky!). The parent is resumed when the child either execve()s or
> > _exit()s.
> 
> I don't understand how parent is able to run if execve just nuked
> parent's text segment
> with unrelated code of execed program.
> --
> vda
> 



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

From landau_alex at yahoo.com  Thu Aug  2 04:37:21 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 04:37:21 -0700 (PDT)
Subject: [PATCH] Fix udhcpc on no-MMU
Message-ID: <798831.68564.qm@web62515.mail.re1.yahoo.com>

Hi,
Now it's udhcpc's turn. Actually a tiny patch that only changes the #ifdef which decides
whether we have an MMU or not.
Alex

Index: networking/udhcp/dhcpc.c
===================================================================
--- networking/udhcp/dhcpc.c	(revision 19396)
+++ networking/udhcp/dhcpc.c	(working copy)
@@ -109,7 +109,7 @@
 
 static void client_background(void)
 {
-#ifdef __uClinux__
+#if !BB_MMU
 	bb_error_msg("cannot background in uclinux (yet)");
 /* ... mainly because udhcpc calls client_background()
  * in _the _middle _of _udhcpc _run_, not at the start!



       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

From landau_alex at yahoo.com  Thu Aug  2 05:08:09 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 05:08:09 -0700 (PDT)
Subject: msh and functions
Message-ID: <320731.69074.qm@web62514.mail.re1.yahoo.com>

Hi,

The Blackfin uClinux distribution at blackfin.uclinux.org includes a patch to busybox's
msh that adds support for functions. It's a bit outdated (the last time I checked), but I
integrated it into busybox 1.4.1 and it works (for me) fine. msh hasn't changed
considerably since then, so I think with small effort the patch could be integrated into
trunk.
I'm willing to volunteer to do that, but I'm having some concerns mainly do to the fact
that I'm not the author of the original patch.
The patch does not contain copyright information, but a readme is included with it
saying:
--START--
                README for hacked msh

                Mickael.Kang (blackfin.kang at gmail.com)

                        Dec. 13th 2005

This patch is for enhancement of msh.  After apply this patch, msh can support
function recursive call.  So it is more like bash than before.  Many
applications under uClinux maybe need this patch to run some bash script under
msh, such as oprofile.
--END--

What can you say about that? Can someone from blackfin.uclinux.org (Mike?) check the
issue and integrate the patch / approve the integration by someone else (e.g. me) /
reject it?

Thanks,
Alex


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 

From landau_alex at yahoo.com  Thu Aug  2 06:54:38 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 06:54:38 -0700 (PDT)
Subject: [PATCH] Add Blackfin to scripts/checkstack.pl
Message-ID: <342715.31112.qm@web62502.mail.re1.yahoo.com>

Hi,
The patch below adds support for Blackfin to scripts/checkstack.pl.
Please apply, if it seems appropriate.
Alex

Index: scripts/checkstack.pl
===================================================================
--- scripts/checkstack.pl	(revision 19396)
+++ scripts/checkstack.pl	(working copy)
@@ -39,6 +39,9 @@
 	if ($arch eq 'arm') {
 		#c0008ffc:	e24dd064	sub	sp, sp, #100	; 0x64
 		$re = qr/.*sub.*sp, sp, #(([0-9]{2}|[3-9])[0-9]{2})/o;
+	} elsif ($arch eq 'blackfin') {
+		#      52:       00 e8 03 00     LINK 0xc;
+		$re = qr/.*LINK (0x$x{1,5});$/o;
 	} elsif ($arch =~ /^i[3456]86$/) {
 		#c0105234:       81 ec ac 05 00 00       sub    $0x5ac,%esp
 		$re = qr/^.*[as][du][db]    \$(0x$x{1,8}),\%esp$/o;



       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC

From vda.linux at googlemail.com  Thu Aug  2 10:52:46 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 18:52:46 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <867356.54135.qm@web62509.mail.re1.yahoo.com>
References: <1158166a0708020336r261e714hc3d3d443c8fdb30@mail.gmail.com>
	<867356.54135.qm@web62509.mail.re1.yahoo.com>
Message-ID: <1158166a0708021052o1a6123f7j5d1dbdb3c7f7a56f@mail.gmail.com>

On 8/2/07, Alex Landau <landau_alex at yahoo.com> wrote:
> > > > > The child merely execv()s.
> > > >
> > > > So on NOMMU execv() basically creates another process in another
> > > > memory region, and
> > > > terminates current one, unless there is a parent sitting in vfork and waiting
> > > > (in which case parent is woken up instead of exit)?
> > >
> > > No, execve works exactly it does on an MMU system. It loads a new executable into the
> > > current process.
> >
> > ...trashing all memory area occupied by the process? how parent is
> > able to run then?
>
> And what about the normal fork and execve?

That's MMU, and there it's all crystal clear.

I was specifically thinking how our trick is working on _NOMMU_.
Mostly for self-education. So, after execve on NOMMU old process
is not destroyed, but "returned" to parent-after-vfork, and
while parent does something, new process is already has memory
allocated for it?

OIW: at execve, does kernel do something like this?

 if (vfork_was_done) {
    create_and_start_new_process();
    wake_up_parent_in_vfork();
 } else {
    destroy_current_process();
    create_and_start_new_process();
 }


--
vda

From Gary.Leong at nasdaq.com  Thu Aug  2 13:26:02 2007
From: Gary.Leong at nasdaq.com (Leong, Gary)
Date: Thu, 2 Aug 2007 16:26:02 -0400
Subject: pivot_root, switch_root, initramfs and kexec
Message-ID: <FD98A53269F5F74082DFBB12E8AA603208D1E34C@TRM-EXCH1.CORP.NASDAQ.COM>

I have an unsual situation.

 

 

The first OS, a busybox OS, boots up through PXE.  This first OS has
"kexec" which is used to boot up a second OS.  The second OS (also a
busybox OS) boots up find as long as the system is diskless.  However,
when I try to do a switch_root onto the disk (which contains the second
OS binaries), it craps out saying, "switch_root: not rootfs."
But....when I replaced the switch_root with pivot_root style, it works
fine.

 

So I figure switch_root is checking to see process kicking it off is PID
1, and craps out if it isn't.  And pivot_root doesn't check as
thoroughly, or doesn't care if the process kicking it off is  PID 1?
How do I find out f the process kicking off is PID 1?

 

To make it more interesting.  I'm using initramfs, not initrd style, but
using pivot_root that is suppose to be used only for initrd style.  So
another questions, is there really any harm using pivot_root with
initramfs?  It works. Or is pivot_root now able to be used with
initramfs. 

 

Thanks in advance!

 

Gary

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070802/2ffd7a50/attachment.htm 

From vda.linux at googlemail.com  Thu Aug  2 15:48:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 23:48:19 +0100
Subject: [PATCH] Fix udhcpc on no-MMU
In-Reply-To: <798831.68564.qm@web62515.mail.re1.yahoo.com>
References: <798831.68564.qm@web62515.mail.re1.yahoo.com>
Message-ID: <200708022348.19496.vda.linux@googlemail.com>

On Thursday 02 August 2007 12:37, Alex Landau wrote:
> Hi,
> Now it's udhcpc's turn. Actually a tiny patch that only changes the #ifdef which decides
> whether we have an MMU or not.
> Alex
> 
> Index: networking/udhcp/dhcpc.c
> ===================================================================
> --- networking/udhcp/dhcpc.c	(revision 19396)
> +++ networking/udhcp/dhcpc.c	(working copy)
> @@ -109,7 +109,7 @@
>  
>  static void client_background(void)
>  {
> -#ifdef __uClinux__
> +#if !BB_MMU
>  	bb_error_msg("cannot background in uclinux (yet)");
>  /* ... mainly because udhcpc calls client_background()
>   * in _the _middle _of _udhcpc _run_, not at the start!

Applied, thanks.

udhcp still needs more love. For one, the plan is to make
udhcpc NOMMU-friendly someday.
--
vda

From ynakam at hitachisoft.jp  Thu Aug  2 17:15:35 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 03 Aug 2007 09:15:35 +0900
Subject: [patch] setfiles update
Message-ID: <20070803091304.54C4.YNAKAM@hitachisoft.jp>

Hi.

This is a patch for setfiles applet.
Following is change.
* Bug fix: -f option did not work.
* Using bb_simplify_path to remove extra slash for smaller code.

Regards,
-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
SELinux Policy Editor: http://seedit.sourceforge.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setfiles_update.patch
Type: application/octet-stream
Size: 1511 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070803/ab1b900d/attachment.obj 

From vda.linux at googlemail.com  Fri Aug  3 01:31:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 3 Aug 2007 09:31:33 +0100
Subject: NFS Support
In-Reply-To: <7D23D3548EC1874CBA41E02F76963A614B36EB8B30@MTEX01.motiontrue.entp>
References: <7D23D3548EC1874CBA41E02F76963A614B36EB8B30@MTEX01.motiontrue.entp>
Message-ID: <200708030931.33706.vda.linux@googlemail.com>

On Thursday 02 August 2007 09:25, Devinim ??LEN wrote:
> Hi;
> 
> I am using BusyBox version 1.6.1 and have a NFS mounting problem.  When I try to mount NFS external point getting this error;
> 
> mount -t nfs 192.168.10.64:/ /mnt
> mount: mounting 192.168.10.64:/ on /mnt failed
> 
> can anybody help ?

* Please find the following line in mount.c:
  bb_error_msg("mounting %s on %s failed", mp->mnt_fsname, mp->mnt_dir);
  and replace "_error_" with "_perror_". What does it print now?

* Do "strace -o mnt.log mount -t nfs 192.168.10.64:/ /mnt" and post log

* Do "tcpdump -nl -iethN -s0 -vvv host 192.168.10.64 and host <NFS client IP>"
  and post log here (bzip2 it if it's big)
--
vda

From ynakam at hitachisoft.jp  Thu Aug  2 16:58:52 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 03 Aug 2007 08:58:52 +0900
Subject: [patch]setfiles/restorecon applet
In-Reply-To: <200707251807.58814.farmatito@tiscali.it>
References: <20070724085858.41D8.YNAKAM@hitachisoft.jp>
	<200707251807.58814.farmatito@tiscali.it>
Message-ID: <20070803084348.54BD.YNAKAM@hitachisoft.jp>

Hi.

Sorry for late reply.

On Wed, 25 Jul 2007 18:07:58 +0200
Tito  wrote:
> On Tuesday 24 July 2007 02:08:24 Yuichi Nakamura wrote:
> > Hi.
> > 
> 
> snip
> 
> > 
> > About sanitize_path, it is pending.
> > Removing extra slashes is done only there in setfiles.c .
> > Is removing extra slashes done in other applets?
> 
> Yes in devfsd, removing extra slashes at the end of filename:
> 
> in one earlier revision there was:
> 
>  /* strip last / from mount point, so we don't need to check for it later */
>          while (argv[1][1] != '\0' && argv[1][strlen(argv[1]) - 1] == '/') 	 
>                  argv[1][strlen(argv[1]) - 1] = '\0';
> 
> later it changed to
> 
>          mount_point = bb_simplify_path(argv[1]);
> 
> so far nobody complained.....
I looked at setfiles.c again,
and I found I can use bb_simplify_path, then code gets smaller.
I will use bb_simplify_path.
I will send patch soon.


> > If so, should it be in libbb?
> 
> Could be useful......
> just my 0,02 ?
> 
> Ciao,
> Tito
> > I've found bb_simplify_path, but it is expanding "." .
> > 
> > > >
> > > > [snipping the rest of you patch for now]
> > > > HTH,
> > > --
> > > vda
> > 
> > Attached is update.
> 

Regards,
-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
SELinux Policy Editor: http://seedit.sourceforge.net/


From landau_alex at yahoo.com  Fri Aug  3 02:14:45 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Fri, 3 Aug 2007 02:14:45 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0708021052o1a6123f7j5d1dbdb3c7f7a56f@mail.gmail.com>
Message-ID: <879819.8242.qm@web62513.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> I was specifically thinking how our trick is working on _NOMMU_.
> Mostly for self-education. So, after execve on NOMMU old process
> is not destroyed, but "returned" to parent-after-vfork, and
> while parent does something, new process is already has memory
> allocated for it?
> 
> OIW: at execve, does kernel do something like this?
> 
>  if (vfork_was_done) {
>     create_and_start_new_process();
>     wake_up_parent_in_vfork();
>  } else {
>     destroy_current_process();
>     create_and_start_new_process();
>  }
> 
> 
> --
> vda
> 

No, vfork creates a new process (just like fork). I mean it creates a new struct
task_struct, copies the kernel stack, and so on. So the child is an entirely new process
with its own PID. What it does not copy is the mm_struct, but instead the child's one
points to the parent's one. So now the parent and child are different processes sharing
the same address space (due to CLONE_VM).
vfork on Blackfin calls do_fork() with flags CLONE_VFORK | CLONE_VM | SIGCHLD, see
kernel/fork.c for do_fork().
Inside do_fork(), if CLONE_VFORK is set, the parent waits on a completion variable until
the child signals it, which happens on execve() and on exit().

On execve(), the child detaches from the parent mm_struct (flush_old_exec() which calls
exec_mmap(), and itself called from the binary handler, e.g. load_flat_file() in
fs/binfmt_flat.c for FLAT), and sets the child's mm to point to a newly allocated
mm_struct (do_execve() does the allocation).
mm_release() called from exec_mmap() (on execve) and from exit_mm() (called itself from
do_exit()) checks whether the parent wait for a vfork completion, and if yes, signals it.

I hope that helps.
Regards,
Alex


      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

From kalyanatejaswi at yahoo.co.in  Fri Aug  3 09:44:33 2007
From: kalyanatejaswi at yahoo.co.in (kalyanatejaswi balabhadrapatruni)
Date: Fri, 3 Aug 2007 17:44:33 +0100 (BST)
Subject: bug in coreutils/printenv.c
Message-ID: <6823.69286.qm@web8605.mail.in.yahoo.com>

Hi all,
"printenv" command prints argv[1] and exits, doesnt
run through rest of the elements of argv[].
---------------
Example:
#busybox printenv SHELL PWD
/bin/sh
#
Doesnt print PWD
----------------

No great deal, small patch attached.

regards
kalyan


      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: printenv-patch.txt
Url: http://busybox.net/lists/busybox/attachments/20070803/690f37b4/attachment.txt 

From pclouds at gmail.com  Fri Aug  3 14:58:12 2007
From: pclouds at gmail.com (Nguyen Thai Ngoc Duy)
Date: Fri, 3 Aug 2007 17:58:12 -0400
Subject: [PATCH] patch: extract_filename should strip all dirs if patch_level
	is -1
Message-ID: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>

It is also documented in the comment above the function but not implemented
-- 
Duy

From pclouds at gmail.com  Fri Aug  3 17:45:32 2007
From: pclouds at gmail.com (Nguyen Thai Ngoc Duy)
Date: Fri, 3 Aug 2007 20:45:32 -0400
Subject: [PATCH] sed: save the last regex for use later
Message-ID: <fcaeb9bf0708031745u59d7d2b0gb3086a83b6550bcc@mail.gmail.com>

I'm not really get into sed source code, so I might be wrong. Please recheck it.
With this patch, the following command should return 'abc' (GNU sed
does but busybox did not):
echo 'URL: abc'|busybox sed -ne '/^URL: */{ s///p; q }'
-- 
Duy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-sed-save-the-last-regex-for-use-later-with-s.patch
Type: text/x-patch
Size: 1116 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070803/0feb4696/attachment.bin 

From cristian.ionescu-idbohrn at axis.com  Sat Aug  4 04:07:23 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sat, 4 Aug 2007 13:07:23 +0200 (CEST)
Subject: just a few more compilation warnings
Message-ID: <0708041302530.10759@somehost>

Please find attached a sorted list of "declared with attribute
warn_unused_result" warnings.


Cheers,

-- 
Cristian
-------------- next part --------------
init/init.c:923:				warning: ignoring return value of 'chdir',	declared with attribute warn_unused_result
procps/fuser.c:278:				warning: ignoring return value of 'chdir',	declared with attribute warn_unused_result
archival/rpm.c:366:				warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
loginutils/getty.c:329:				warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
miscutils/crontab.c:169:			warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
util-linux/mdev.c:185:				warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
loginutils/sulogin.c:63:			warning: ignoring return value of 'dup',	declared with attribute warn_unused_result
loginutils/sulogin.c:65:			warning: ignoring return value of 'dup',	declared with attribute warn_unused_result
sysklogd/syslogd.c:538:				warning: ignoring return value of 'fchdir',	declared with attribute warn_unused_result
libbb/update_passwd.c:56:			warning: ignoring return value of 'fchown',	declared with attribute warn_unused_result
loginutils/login.c:346:				warning: ignoring return value of 'fchown',	declared with attribute warn_unused_result
coreutils/comm.c:101:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
coreutils/comm.c:103:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
coreutils/comm.c:55:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
coreutils/comm.c:95:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
editors/ed.c:244:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/arp.c:381:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/interface.c:567:			warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/interface.c:568:			warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/libiproute/iptunnel.c:447:		warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/libiproute/iptunnel.c:448:		warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/wget.c:447:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
procps/top.c:265:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
util-linux/fbset.c:183:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
util-linux/fbset.c:195:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
modutils/lsmod.c:32:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:267:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:283:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:292:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:293:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
util-linux/mkfs_minix.c:528:			warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
sysklogd/syslogd.c:378:				warning: ignoring return value of 'ftruncate',	declared with attribute warn_unused_result
coreutils/fold.c:117:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/fold.c:135:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/fold.c:144:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/fold.c:94:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/tee.c:68:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
debianutils/pipe_progress.c:30:			warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
runit/svlogd.c:899:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
runit/svlogd.c:927:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/test.c:574:				warning: ignoring return value of 'getgroups',	declared with attribute warn_unused_result
archival/libunarchive/data_extract_all.c:115:	warning: ignoring return value of 'lchown',	declared with attribute warn_unused_result
miscutils/less.c:745:				warning: ignoring return value of 'read',	declared with attribute warn_unused_result
modutils/insmod.c:3673:				warning: ignoring return value of 'read',	declared with attribute warn_unused_result
networking/inetd.c:1597:			warning: ignoring return value of 'read',	declared with attribute warn_unused_result
debianutils/start_stop_daemon.c:45:		warning: ignoring return value of 'readlink',	declared with attribute warn_unused_result
util-linux/umount.c:96:				warning: ignoring return value of 'realpath',	declared with attribute warn_unused_result
console-tools/resize.c:54:			warning: ignoring return value of 'scanf',	declared with attribute warn_unused_result
util-linux/mdev.c:183:				warning: ignoring return value of 'symlink',	declared with attribute warn_unused_result
loginutils/adduser.c:76:			warning: ignoring return value of 'system',	declared with attribute warn_unused_result
networking/udhcp/files.c:410:			warning: ignoring return value of 'system',	declared with attribute warn_unused_result
procps/watch.c:76:				warning: ignoring return value of 'system',	declared with attribute warn_unused_result
console-tools/dumpkmap.c:37:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
console-tools/dumpkmap.c:46:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
console-tools/dumpkmap.c:59:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
editors/ed.c:979:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
ipsvd/tcpudp.c:314:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:549:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:557:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:569:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:795:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:848:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/crontab.c:279:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/crontab.c:281:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:105:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:211:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:232:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:239:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:81:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/watchdog.c:19:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/watchdog.c:53:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
modutils/insmod.c:3677:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/inetd.c:1719:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/inetd.c:1758:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:117:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:148:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:195:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:269:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:430:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:656:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:98:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
procps/sysctl.c:53:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:104:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:149:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:189:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:98:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsvdir.c:300:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
util-linux/dmesg.c:45:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
util-linux/mdev.c:278:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
util-linux/mdev.c:280:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result

From cristian.ionescu-idbohrn at axis.com  Sat Aug  4 04:43:45 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sat, 4 Aug 2007 13:43:45 +0200 (CEST)
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
Message-ID: <0708041341350.10759@somehost>

...which is the latest distributed.

  CC      miscutils/readahead.o
miscutils/readahead.c: In function `readahead_main':
miscutils/readahead.c:27: warning: implicit declaration of function `readahead'


  CC      miscutils/taskset.o
miscutils/taskset.c:17: error: syntax error before '*' token
miscutils/taskset.c:18: warning: function declaration isn't a prototype
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.)
miscutils/taskset.c:26: warning: implicit declaration of function `CPU_ISSET'
miscutils/taskset.c:26: error: `mask' undeclared (first use in this function)
miscutils/taskset.c: In function `taskset_main':
miscutils/taskset.c:47: error: `cpu_set_t' undeclared (first use in this function)
miscutils/taskset.c:47: error: syntax error before "mask"
miscutils/taskset.c:68: warning: implicit declaration of function `CPU_ZERO'
miscutils/taskset.c:68: error: `new_mask' undeclared (first use in this function)
miscutils/taskset.c:69: error: `CPU_SETSIZE' undeclared (first use in this function)
miscutils/taskset.c:71: warning: implicit declaration of function `CPU_SET'
miscutils/taskset.c:78: warning: implicit declaration of function `sched_getaffinity'
miscutils/taskset.c:78: error: `mask' undeclared (first use in this function)
miscutils/taskset.c:86: warning: implicit declaration of function `sched_setaffinity'
make[1]: *** [miscutils/taskset.o] Error 1
make: *** [miscutils] Error 2


Cheers,

-- 
Cristian

From Alexander at Kriegisch.name  Sat Aug  4 06:22:08 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 04 Aug 2007 15:22:08 +0200
Subject: ash - exit code for a piped process
Message-ID: <46B47D80.7040909@Kriegisch.name>

I would like to determine the exit code of 'foo' in
foo | bar

I bash there is the PIPESTATUS array, but in ash (which I must use)
there is no such thing as PIPESTATUS or arrays. Is there any canonical
way or at least a workaround to achieve both piping the foo's output
into bar unconditionally *and* determining foo's exit code?

Thanks
-- 
Alexander Kriegisch

From vapier at gentoo.org  Sat Aug  4 06:48:43 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 4 Aug 2007 09:48:43 -0400
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
In-Reply-To: <0708041341350.10759@somehost>
References: <0708041341350.10759@somehost>
Message-ID: <200708040948.44414.vapier@gentoo.org>

On Saturday 04 August 2007, Cristian Ionescu-Idbohrn wrote:
> ...which is the latest distributed.

no it isnt, Debian is out of date

>   CC      miscutils/readahead.o
>   CC      miscutils/taskset.o

if the applets fail, dont enable them
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070804/c8a52132/attachment.pgp 

From loic.grenie at gmail.com  Sat Aug  4 06:45:56 2007
From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=)
Date: Sat, 4 Aug 2007 13:45:56 +0000
Subject: ash - exit code for a piped process
In-Reply-To: <46B47D80.7040909@Kriegisch.name>
References: <46B47D80.7040909@Kriegisch.name>
Message-ID: <9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>

2007/8/4, Alexander Kriegisch <Alexander at kriegisch.name>:
> I would like to determine the exit code of 'foo' in
> foo | bar
>
> I bash there is the PIPESTATUS array, but in ash (which I must use)
> there is no such thing as PIPESTATUS or arrays. Is there any canonical
> way or at least a workaround to achieve both piping the foo's output
> into bar unconditionally *and* determining foo's exit code?

x=`((( foo 3>&- 4>&- ); echo $? >&3)| bar >&4  3>&- 4>&-) 3>&1` 4>&1

  should do the trick. The exit code of foo is in x, the output of bar
  goes to the output of the command.

      Hope this helps.

         Lo?c

From Alexander at Kriegisch.name  Sat Aug  4 07:16:44 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 04 Aug 2007 16:16:44 +0200
Subject: ash - exit code for a piped process
In-Reply-To: <9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
References: <46B47D80.7040909@Kriegisch.name>
	<9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
Message-ID: <46B48A4C.8060001@Kriegisch.name>

> x=`((( foo 3>&- 4>&- ); echo $? >&3)| bar >&4  3>&- 4>&-) 3>&1` 4>&1

Thanks, Lo?c. I will consider your solution if I ever have a case like
this again, but my current workaround is rather simple to read and uses
a text buffer for the first command's output. I can do this because I
know that foo's output has a limited size which can be easily handled in
memory. So I choose this way for the sake of readability:

output=$(foo)
result=$?
echo "$output" | bar

I know the solution is somewhat limited, but a feasibly workaround in my
special case. Yours is more refined and really uses pipes.
--
Alexander Kriegisch




From farmatito at tiscali.it  Sat Aug  4 07:24:18 2007
From: farmatito at tiscali.it (Tito)
Date: Sat, 4 Aug 2007 16:24:18 +0200
Subject: ash - exit code for a piped process
In-Reply-To: <9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
References: <46B47D80.7040909@Kriegisch.name>
	<9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
Message-ID: <200708041624.18065.farmatito@tiscali.it>

On Saturday 04 August 2007 15:45:56 Lo?c Greni? wrote:
> 2007/8/4, Alexander Kriegisch <Alexander at kriegisch.name>:
> > I would like to determine the exit code of 'foo' in
> > foo | bar
> >
> > I bash there is the PIPESTATUS array, but in ash (which I must use)
> > there is no such thing as PIPESTATUS or arrays. Is there any canonical
> > way or at least a workaround to achieve both piping the foo's output
> > into bar unconditionally *and* determining foo's exit code?
> 
> x=`((( foo 3>&- 4>&- ); echo $? >&3)| bar >&4  3>&- 4>&-) 3>&1` 4>&1
> 
>   should do the trick. The exit code of foo is in x, the output of bar
>   goes to the output of the command.
> 
>       Hope this helps.
> 
>          Lo?c

foo > out.file
ret=$?
cat out.file | bar
# rm out.file

Untested. Just an idea...........

Ciao,
Tito

From cristian.ionescu-idbohrn at axis.com  Sun Aug  5 00:48:41 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sun, 5 Aug 2007 09:48:41 +0200 (CEST)
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
In-Reply-To: <200708040948.44414.vapier@gentoo.org>
References: <0708041341350.10759@somehost>
	<200708040948.44414.vapier@gentoo.org>
Message-ID: <0708050905310.9234@somehost>

On Sat, 4 Aug 2007, Mike Frysinger wrote:

> On Saturday 04 August 2007, Cristian Ionescu-Idbohrn wrote:
> > ...which is the latest distributed.
>
> no it isnt,

yes, it is :) the latest debian distributed uclibc-toolchain.

> Debian is out of date

of course.

> >   CC      miscutils/readahead.o
> >   CC      miscutils/taskset.o
>
> if the applets fail, dont enable them

right. my message was just meant to provide some information, nothing
else.


Cheers,

-- 
Cristian

From rep.dot.nop at gmail.com  Sun Aug  5 04:33:14 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 5 Aug 2007 13:33:14 +0200
Subject: just a few more compilation warnings
In-Reply-To: <0708041302530.10759@somehost>
References: <0708041302530.10759@somehost>
Message-ID: <20070805113314.GN11697@aon.at>

On Sat, Aug 04, 2007 at 01:07:23PM +0200, Cristian Ionescu-Idbohrn wrote:
>Please find attached a sorted list of "declared with attribute
>warn_unused_result" warnings.

See
$ svn log -r18877

From rep.dot.nop at gmail.com  Sun Aug  5 04:36:52 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 5 Aug 2007 13:36:52 +0200
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
In-Reply-To: <0708050905310.9234@somehost>
References: <0708041341350.10759@somehost>
	<200708040948.44414.vapier@gentoo.org>
	<0708050905310.9234@somehost>
Message-ID: <20070805113652.GO11697@aon.at>

On Sun, Aug 05, 2007 at 09:48:41AM +0200, Cristian Ionescu-Idbohrn wrote:
>On Sat, 4 Aug 2007, Mike Frysinger wrote:
>
>> On Saturday 04 August 2007, Cristian Ionescu-Idbohrn wrote:
>> > ...which is the latest distributed.
>>
>> no it isnt,
>
>yes, it is :) the latest debian distributed uclibc-toolchain.

No, it isn't. About any toolchain that may be downloadable from
uClibc.org or busybox.net is outdated.
Nowadays, you should either use emdebian, buildroot or gentoo or one of
the dozend other distros that come with native uClibc support.

>> if the applets fail, dont enable them
>
>right. my message was just meant to provide some information, nothing
>else.

Thanks, but as you can see from the archives (and even some help-texts
of one of the abovementioned applets) this is a non-issue since you're
using an outdated toolchain :)

From ml at zastrow4u.de  Sun Aug  5 10:40:12 2007
From: ml at zastrow4u.de (Alfred Zastrow)
Date: Sun, 05 Aug 2007 19:40:12 +0200
Subject: applet-request: expand
Message-ID: <46B60B7C.6080108@zastrow4u.de>

Hello list,

glibc-2.6.1 compiles fine by using most of the applets of busybox-1.6.1,
but "expand" of coreutils is still missing:

----------snip----------------
sed -e 's,[{}],@&,g'				\
	    -e 's,/\*\(@.*\)\*/,\1,g'			\
	    -e 's,/\*  *,/* @r{,g' -e 's,  *\*/,} */,'	\
	    -e 's/\(@[a-z][a-z]*\)@{\([^}]*\)@}/\1{\2}/g'\
	    examples/stpcpy.c | expand > stpcpy.c.texi.new
/bin/sh: line 4: expand: command not found
make[2]: *** [stpcpy.c.texi] Error 127
make[2]: Leaving directory `/build/glibc-2.6.1/manual'
make[1]: *** [manual/subdir_install] Error 2
make[1]: Leaving directory `/build/glibc-2.6.1'
make: *** [install] Fehler 2
----------snap----------------

Is there any chance to get this in?

cu
Alfred


From jako at grand.com.tw  Sun Aug  5 18:05:56 2007
From: jako at grand.com.tw (Grandtec Jako)
Date: Mon, 6 Aug 2007 09:05:56 +0800
Subject: httpd question
Message-ID: <002601c7d7c5$f1eb7e60$d3a8a8c0@GRANDTECJACKY>

Hi,

I use busybox v1.00 version at PC board.
I use "ifconfig eth0 192.168.168.214 up" , and "httpd -p 80 -h /cgi-bin -c /etc/httpd.conf -r "Web Server Authentication" &" commands.
Then I open webpage at http://192.168.168.214.
Now, I have two questions.

Q1. If I open webpage at first http://192.168.168.214, I will not open Web Page at second http://192.168.168.214. 
       But it have displayed login-in (input id and password) pup-up.

Q2. When I open webpage at first http://192.168.168.214, the index.html can't link to other Web Pages.

About httpd.conf file:
------------------------------
A:*
/:root:admin
/cgi-bin:foo:bar
/adm:admin:setup
/adm:toor:PaSsWd
.htm:text/html
.html:text/html
-------------------------------

Can you give me some suggestions ?
Thanks.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070806/0c609b59/attachment.htm 

From vda.linux at googlemail.com  Sun Aug  5 19:26:16 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 03:26:16 +0100
Subject: [patch] setfiles update
In-Reply-To: <20070803091304.54C4.YNAKAM@hitachisoft.jp>
References: <20070803091304.54C4.YNAKAM@hitachisoft.jp>
Message-ID: <200708060326.16357.vda.linux@googlemail.com>

On Friday 03 August 2007 01:15, Yuichi Nakamura wrote:
> This is a patch for setfiles applet.
> Following is change.
> * Bug fix: -f option did not work.
> * Using bb_simplify_path to remove extra slash for smaller code.

Applied, thanks
--
vda

From vda.linux at googlemail.com  Sun Aug  5 19:46:09 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 03:46:09 +0100
Subject: bug in coreutils/printenv.c
In-Reply-To: <6823.69286.qm@web8605.mail.in.yahoo.com>
References: <6823.69286.qm@web8605.mail.in.yahoo.com>
Message-ID: <200708060346.09171.vda.linux@googlemail.com>

On Friday 03 August 2007 17:44, kalyanatejaswi balabhadrapatruni wrote:
> Hi all,
> "printenv" command prints argv[1] and exits, doesnt
> run through rest of the elements of argv[].
> ---------------
> Example:
> #busybox printenv SHELL PWD
> /bin/sh
> #
> Doesnt print PWD
> ----------------
> 
> No great deal, small patch attached.

I am replacing open-coded environ[] scan there with getenv:

+               while ((arg = *++argv) != NULL) {
+                       env = getenv(arg);
+                       if (env)
+                               puts(env);
+               }

Saves ~75 bytes too.

Please test svn, should be fixed now. Thanks.
--
vda

From vda.linux at googlemail.com  Sun Aug  5 19:47:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 03:47:32 +0100
Subject: [PATCH] patch: extract_filename should strip all dirs if
	patch_level is -1
In-Reply-To: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
References: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
Message-ID: <200708060347.32312.vda.linux@googlemail.com>

On Friday 03 August 2007 22:58, Nguyen Thai Ngoc Duy wrote:
> It is also documented in the comment above the function but not implemented

No patch is attached to your mail...
--
vda

From vda.linux at googlemail.com  Sun Aug  5 20:31:02 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 04:31:02 +0100
Subject: [PATCH] sed: save the last regex for use later
In-Reply-To: <fcaeb9bf0708031745u59d7d2b0gb3086a83b6550bcc@mail.gmail.com>
References: <fcaeb9bf0708031745u59d7d2b0gb3086a83b6550bcc@mail.gmail.com>
Message-ID: <200708060431.02810.vda.linux@googlemail.com>

On Saturday 04 August 2007 01:45, Nguyen Thai Ngoc Duy wrote:
> I'm not really get into sed source code, so I might be wrong. Please recheck it.
> With this patch, the following command should return 'abc' (GNU sed
> does but busybox did not):
> echo 'URL: abc'|busybox sed -ne '/^URL: */{ s///p; q }'

Applied, thanks. Seems to not break any of testsuite entry.
--
vda

From vapier at gentoo.org  Mon Aug  6 01:14:55 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 6 Aug 2007 04:14:55 -0400
Subject: @mail.com users are now banned in bugs
Message-ID: <200708060414.56144.vapier@gentoo.org>

we've seen ~40 spam accounts registered this last week (a few every day) and 
each one was @mail.com so ive tweaked mantis to silently ignore registrations 
for @mail.com addresses.

not a big deal since of the ~1200 registered people, 0 are using this 
craptastic webmail service.

if it starts to be a problem with random addresses, we can look at requiring 
captchas, but i personally hate those goddamn things ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070806/d9b8c7f7/attachment.pgp 

From per.hallsmark at t2data.se  Mon Aug  6 01:21:50 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Mon, 06 Aug 2007 10:21:50 +0200
Subject: hush in arm nommu environment
Message-ID: <46B6DA1E.1090502@t2data.se>

Hi all,

I've tried out the hush shell in busybox 1.6.1.
Seems to work fairly well with the patch last in
this mail.

The only(?) thing that doesn't work however, is
backspace... or to be more correct, it do backspace
in the commandline but it isn't displayed correctly.
If I have fancy editing enabling then the character
is moved to the RIGHT instead of LEFT when I backspace.
If I don't have fancy editing enabled, it prints out
some garbage (same all time) like:

~ # lsUP!) UP!)UP!) UP!)
(backspace pressed twice)

The only string I can find that looks like UP!) is:

[per at phlap3 busybox-1.6.1]$ grep -r UP\! *
networking/ping.c:      const char *dupmsg = " (DUP!)";
[per at phlap3 busybox-1.6.1]$

So it seems like a weird pointer issue...

I use busybox 1.6.1, gcc 4.1.2 and kernel 2.6.19-uc1 on
a arm7tdmi'ish mcu.

Anyone encountered this behaviour?

/Per

--- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
+++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
@@ -658,7 +658,11 @@
         pid_t pid;

         debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
+#if BB_MMU
         pid = fork();
+#else
+       pid = vfork();
+#endif
         if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
                 return;
         ctrl_z_flag = 1;


From per.hallsmark at t2data.se  Mon Aug  6 02:35:41 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Mon, 06 Aug 2007 11:35:41 +0200
Subject: hush in arm nommu environment
In-Reply-To: <46B6DA1E.1090502@t2data.se>
References: <46B6DA1E.1090502@t2data.se>
Message-ID: <46B6EB6D.8000300@t2data.se>

well... sometimes one can answer oneself... :)

--- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
+++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
@@ -165,10 +165,12 @@

         if (cmdedit_x >= num) {
                 cmdedit_x -= num;
+#if 0
                 if (num <= 4) {
                         printf("\b\b\b\b" + (4-num));
                         return;
                 }
+#endif
                 printf("\033[%uD", num);
                 return;
         }


With above patch backspace works ok.

The \b\b... printf looks rather mystic... guess the author
perhaps wanted something like this instead?

switch (num) {
   case 4:
     printf("\b");
     /* fall trough */
   case 3:
     printf("\b");
     /* fall trough */
   case 2:
     printf("\b");
     /* fall trough */
   case 1:
     printf("\b");
     return;
   default:
}

but I wonder what the benefits are...

Per Hallsmark wrote:
> Hi all,
> 
> I've tried out the hush shell in busybox 1.6.1.
> Seems to work fairly well with the patch last in
> this mail.
> 
> The only(?) thing that doesn't work however, is
> backspace... or to be more correct, it do backspace
> in the commandline but it isn't displayed correctly.
> If I have fancy editing enabling then the character
> is moved to the RIGHT instead of LEFT when I backspace.
> If I don't have fancy editing enabled, it prints out
> some garbage (same all time) like:
> 
> ~ # lsUP!) UP!)UP!) UP!)
> (backspace pressed twice)
> 
> The only string I can find that looks like UP!) is:
> 
> [per at phlap3 busybox-1.6.1]$ grep -r UP\! *
> networking/ping.c:      const char *dupmsg = " (DUP!)";
> [per at phlap3 busybox-1.6.1]$
> 
> So it seems like a weird pointer issue...
> 
> I use busybox 1.6.1, gcc 4.1.2 and kernel 2.6.19-uc1 on
> a arm7tdmi'ish mcu.
> 
> Anyone encountered this behaviour?
> 
> /Per
> 
> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
> @@ -658,7 +658,11 @@
>          pid_t pid;
> 
>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
> +#if BB_MMU
>          pid = fork();
> +#else
> +       pid = vfork();
> +#endif
>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>                  return;
>          ctrl_z_flag = 1;
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox



From per.hallsmark at t2data.se  Mon Aug  6 02:35:52 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Mon, 06 Aug 2007 11:35:52 +0200
Subject: hush in arm nommu environment
In-Reply-To: <46B6DA1E.1090502@t2data.se>
References: <46B6DA1E.1090502@t2data.se>
Message-ID: <46B6EB78.7040204@t2data.se>

well... sometimes one can answer oneself... :)

--- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
+++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
@@ -165,10 +165,12 @@

         if (cmdedit_x >= num) {
                 cmdedit_x -= num;
+#if 0
                 if (num <= 4) {
                         printf("\b\b\b\b" + (4-num));
                         return;
                 }
+#endif
                 printf("\033[%uD", num);
                 return;
         }


With above patch backspace works ok.

The \b\b... printf looks rather mystic... guess the author
perhaps wanted something like this instead?

switch (num) {
   case 4:
     printf("\b");
     /* fall trough */
   case 3:
     printf("\b");
     /* fall trough */
   case 2:
     printf("\b");
     /* fall trough */
   case 1:
     printf("\b");
     return;
   default:
}

but I wonder what the benefits are...

Per Hallsmark wrote:
> Hi all,
> 
> I've tried out the hush shell in busybox 1.6.1.
> Seems to work fairly well with the patch last in
> this mail.
> 
> The only(?) thing that doesn't work however, is
> backspace... or to be more correct, it do backspace
> in the commandline but it isn't displayed correctly.
> If I have fancy editing enabling then the character
> is moved to the RIGHT instead of LEFT when I backspace.
> If I don't have fancy editing enabled, it prints out
> some garbage (same all time) like:
> 
> ~ # lsUP!) UP!)UP!) UP!)
> (backspace pressed twice)
> 
> The only string I can find that looks like UP!) is:
> 
> [per at phlap3 busybox-1.6.1]$ grep -r UP\! *
> networking/ping.c:      const char *dupmsg = " (DUP!)";
> [per at phlap3 busybox-1.6.1]$
> 
> So it seems like a weird pointer issue...
> 
> I use busybox 1.6.1, gcc 4.1.2 and kernel 2.6.19-uc1 on
> a arm7tdmi'ish mcu.
> 
> Anyone encountered this behaviour?
> 
> /Per
> 
> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
> @@ -658,7 +658,11 @@
>          pid_t pid;
> 
>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
> +#if BB_MMU
>          pid = fork();
> +#else
> +       pid = vfork();
> +#endif
>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>                  return;
>          ctrl_z_flag = 1;
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox



From landau_alex at yahoo.com  Mon Aug  6 04:23:01 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Mon, 6 Aug 2007 04:23:01 -0700 (PDT)
Subject: Bug in lastest commit of scripts/trylink (r19409)
Message-ID: <586940.66267.qm@web62504.mail.re1.yahoo.com>

Hi,

At the very end, when doing the final link it's written:
try <some text> && exit 1
which should be:
try <some text> || exit 1

Currently busybox is not being built from busybox_unstripped.

Alex


      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

From pclouds at gmail.com  Mon Aug  6 04:33:58 2007
From: pclouds at gmail.com (Nguyen Thai Ngoc Duy)
Date: Mon, 6 Aug 2007 07:33:58 -0400
Subject: [PATCH] patch: extract_filename should strip all dirs if
	patch_level is -1
In-Reply-To: <200708060347.32312.vda.linux@googlemail.com>
References: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
	<200708060347.32312.vda.linux@googlemail.com>
Message-ID: <fcaeb9bf0708060433h580742f3ve1ecd203d0801694@mail.gmail.com>

Oops, sorry.  Here coms the patch.

On 8/5/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Friday 03 August 2007 22:58, Nguyen Thai Ngoc Duy wrote:
> > It is also documented in the comment above the function but not implemented
>
> No patch is attached to your mail...
> --
> vda
>


-- 
Duy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-strip.patch
Type: text/x-patch
Size: 589 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070806/9c39a5a5/attachment.bin 

From landau_alex at yahoo.com  Mon Aug  6 04:50:43 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Mon, 6 Aug 2007 04:50:43 -0700 (PDT)
Subject: [PATCH] catv wrong behaviour when no arguments passed
Message-ID: <514417.87596.qm@web62503.mail.re1.yahoo.com>

Hi,

When catv gets no files on the command line (argv[0] == NULL after getopt), after doing
its work it increments argv to point to the next argument, but since argv is already
NULL, catv tries to open files whose names are the environment strings (e.g.
"HOME=/home/user", "PATH=...").
The fix/workaround below is to pre-decrement argv in this case, so that when it is
incremented later it will be NULL and the loop will break.

Alex

Index: coreutils/catv.c
===================================================================
--- coreutils/catv.c	(revision 19409)
+++ coreutils/catv.c	(working copy)
@@ -27,8 +27,10 @@
 
 	/* Read from stdin if there's nothing else to do. */
 	fd = 0;
-	if (!argv[0])
+	if (!argv[0]) {
+		argv--;
 		goto jump_in;
+	}
 	do {
 		fd = open_or_warn(*argv, O_RDONLY);
 		if (fd < 0) {



       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

From vda.linux at googlemail.com  Mon Aug  6 05:07:54 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 13:07:54 +0100
Subject: Bug in lastest commit of scripts/trylink (r19409)
In-Reply-To: <586940.66267.qm@web62504.mail.re1.yahoo.com>
References: <586940.66267.qm@web62504.mail.re1.yahoo.com>
Message-ID: <200708061307.54607.vda.linux@googlemail.com>

On Monday 06 August 2007 12:23, Alex Landau wrote:
> At the very end, when doing the final link it's written:
> try <some text> && exit 1
> which should be:
> try <some text> || exit 1
> 
> Currently busybox is not being built from busybox_unstripped.

Thanks, fixed.
--
vda

From vda.linux at googlemail.com  Mon Aug  6 05:26:16 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 13:26:16 +0100
Subject: [PATCH] patch: extract_filename should strip all dirs if
	patch_level is -1
In-Reply-To: <fcaeb9bf0708060433h580742f3ve1ecd203d0801694@mail.gmail.com>
References: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
	<200708060347.32312.vda.linux@googlemail.com>
	<fcaeb9bf0708060433h580742f3ve1ecd203d0801694@mail.gmail.com>
Message-ID: <200708061326.16666.vda.linux@googlemail.com>

On Monday 06 August 2007 12:33, Nguyen Thai Ngoc Duy wrote:
> Oops, sorry.  Here coms the patch.
> 
> On 8/5/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > On Friday 03 August 2007 22:58, Nguyen Thai Ngoc Duy wrote:
> > > It is also documented in the comment above the function but not implemented
> >
> > No patch is attached to your mail...
> > --
> > vda

Fixed in svn, thanks
--
vda

From vda.linux at googlemail.com  Mon Aug  6 06:23:49 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:23:49 +0100
Subject: [PATCH] Add Blackfin to scripts/checkstack.pl
In-Reply-To: <342715.31112.qm@web62502.mail.re1.yahoo.com>
References: <342715.31112.qm@web62502.mail.re1.yahoo.com>
Message-ID: <200708061423.49765.vda.linux@googlemail.com>

On Thursday 02 August 2007 14:54, Alex Landau wrote:
> Hi,
> The patch below adds support for Blackfin to scripts/checkstack.pl.
> Please apply, if it seems appropriate.
> Alex

Applied, thanks.
--
vda

From vda.linux at googlemail.com  Mon Aug  6 06:25:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:25:03 +0100
Subject: [PATCH] catv wrong behaviour when no arguments passed
In-Reply-To: <514417.87596.qm@web62503.mail.re1.yahoo.com>
References: <514417.87596.qm@web62503.mail.re1.yahoo.com>
Message-ID: <200708061425.03178.vda.linux@googlemail.com>

On Monday 06 August 2007 12:50, Alex Landau wrote:
> Hi,
> 
> When catv gets no files on the command line (argv[0] == NULL after getopt), after doing
> its work it increments argv to point to the next argument, but since argv is already
> NULL, catv tries to open files whose names are the environment strings (e.g.
> "HOME=/home/user", "PATH=...").
> The fix/workaround below is to pre-decrement argv in this case, so that when it is
> incremented later it will be NULL and the loop will break.

Applied, thanks
--
vda

From vda.linux at googlemail.com  Mon Aug  6 06:26:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:26:40 +0100
Subject: [PATCH-suggestion] The pidfile problem of udhcpc
In-Reply-To: <1183388051.4000.45.camel@Blue2net-mats.bellman.mea>
References: <1183388051.4000.45.camel@Blue2net-mats.bellman.mea>
Message-ID: <200708061426.40949.vda.linux@googlemail.com>

On Monday 02 July 2007 15:54, Mats Erik Andersson wrote:
> Hi again,
> 
> I have analyzed and located the problem with udhcpc
> for todays snapshot of Busybox when one uses
> 
> # CONFIG_FEATURE_PIDFILE is not set

It should be fixed now.
If it's not, let me know.
--
vda

From vda.linux at googlemail.com  Mon Aug  6 06:28:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:28:19 +0100
Subject: httpd question
In-Reply-To: <002601c7d7c5$f1eb7e60$d3a8a8c0@GRANDTECJACKY>
References: <002601c7d7c5$f1eb7e60$d3a8a8c0@GRANDTECJACKY>
Message-ID: <200708061428.19752.vda.linux@googlemail.com>

On Monday 06 August 2007 02:05, Grandtec Jako wrote:
> Hi,
> 
> I use busybox v1.00 version at PC board.
> I use "ifconfig eth0 192.168.168.214 up" , and "httpd -p 80 -h /cgi-bin -c /etc/httpd.conf -r "Web Server Authentication" &" commands.
> Then I open webpage at http://192.168.168.214.
> Now, I have two questions.
> 
> Q1. If I open webpage at first http://192.168.168.214, I will not open Web Page at second http://192.168.168.214. 
>        But it have displayed login-in (input id and password) pup-up.
> 
> Q2. When I open webpage at first http://192.168.168.214, the index.html can't link to other Web Pages.

I failed to understand both questions.

http://catb.org/~esr/faqs/smart-questions.html
--
vda

From vda.linux at googlemail.com  Mon Aug  6 07:07:26 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 15:07:26 +0100
Subject: hush in arm nommu environment
In-Reply-To: <46B6EB78.7040204@t2data.se>
References: <46B6DA1E.1090502@t2data.se> <46B6EB78.7040204@t2data.se>
Message-ID: <200708061507.26107.vda.linux@googlemail.com>

On Monday 06 August 2007 10:35, Per Hallsmark wrote:
> well... sometimes one can answer oneself... :)
> 
> --- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
> +++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
> @@ -165,10 +165,12 @@
> 
>          if (cmdedit_x >= num) {
>                  cmdedit_x -= num;
> +#if 0
>                  if (num <= 4) {
>                          printf("\b\b\b\b" + (4-num));
>                          return;
>                  }
> +#endif
>                  printf("\033[%uD", num);
>                  return;
>          }
> 
> 
> With above patch backspace works ok.
> 
> The \b\b... printf looks rather mystic... guess the author
> perhaps wanted something like this instead?
> 
> switch (num) {
>    case 4:
>      printf("\b");
>      /* fall trough */
>    case 3:
>      printf("\b");
>      /* fall trough */
>    case 2:
>      printf("\b");
>      /* fall trough */
>    case 1:
>      printf("\b");
>      return;
>    default:
> }
> 
> but I wonder what the benefits are...

printf("\b\b\b\b" + (4-num));

does exactly the same in 4 times less code.
If num==4, it does printf("\b\b\b\b" + 0) => printf("\b\b\b\b")
If num==3, it does printf("\b\b\b\b" + 1) => printf("\b\b\b")
If num==2, it does printf("\b\b\b\b" + 2) => printf("\b\b")
If num==1, it does printf("\b\b\b\b" + 3) => printf("\b")
etc

The benefits are that we send less bytes than with printf("\033[%uD", num);
It's done primarily for the most common case: single [Backspace] key.
It's silly to send ESC [ 1 D instead of single backspace char.

Now, I wonder why \b for you does not do what it should (that is,
going back one char). Can you compile and run this test program?

int main(int argc, char **argv) {
        printf("987654321\b\b\b\b" + argc);
        fflush(0);
        sleep(3);
        puts("");
}

When I run it, I see this:

# ./a.out
87654321   <---- cursor is under '4'
# ./a.out 1
7654321    <---- cursor is under '4'
# ./a.out 1 1
654321     <---- cursor is under '4'
# ./a.out 1 1 | hexdump -vC
00000000  36 35 34 33 32 31 08 08  08 08 0a                 |654321.....|
0000000b

IOW, both printf("str" + n) and '\b' work right for me.

What do you see
--
vda

From vda.linux at googlemail.com  Mon Aug  6 07:10:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 15:10:25 +0100
Subject: hush in arm nommu environment
In-Reply-To: <46B6DA1E.1090502@t2data.se>
References: <46B6DA1E.1090502@t2data.se>
Message-ID: <200708061510.25873.vda.linux@googlemail.com>

On Monday 06 August 2007 09:21, Per Hallsmark wrote:
> Hi all,
> 
> I've tried out the hush shell in busybox 1.6.1.
> Seems to work fairly well with the patch last in
> this mail.
...
> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
> @@ -658,7 +658,11 @@
>          pid_t pid;
> 
>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
> +#if BB_MMU
>          pid = fork();
> +#else
> +       pid = vfork();
> +#endif
>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>                  return;
>          ctrl_z_flag = 1;

I'm afraid this maybe works for some simple scripts, but I'm sure as hell
there are nasty bugs. Code does assume that after fork() we create
new process. Simply replacing it with vfork is not going to work stably.
--
vda

From vda.linux at googlemail.com  Mon Aug  6 07:11:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 15:11:32 +0100
Subject: applet-request: expand
In-Reply-To: <46B60B7C.6080108@zastrow4u.de>
References: <46B60B7C.6080108@zastrow4u.de>
Message-ID: <200708061511.32929.vda.linux@googlemail.com>

On Sunday 05 August 2007 18:40, Alfred Zastrow wrote:
> Hello list,
> 
> glibc-2.6.1 compiles fine by using most of the applets of busybox-1.6.1,
> but "expand" of coreutils is still missing:
> 
> ----------snip----------------
> sed -e 's,[{}],@&,g'				\
> 	    -e 's,/\*\(@.*\)\*/,\1,g'			\
> 	    -e 's,/\*  *,/* @r{,g' -e 's,  *\*/,} */,'	\
> 	    -e 's/\(@[a-z][a-z]*\)@{\([^}]*\)@}/\1{\2}/g'\
> 	    examples/stpcpy.c | expand > stpcpy.c.texi.new
> /bin/sh: line 4: expand: command not found
> make[2]: *** [stpcpy.c.texi] Error 127
> make[2]: Leaving directory `/build/glibc-2.6.1/manual'
> make[1]: *** [manual/subdir_install] Error 2
> make[1]: Leaving directory `/build/glibc-2.6.1'
> make: *** [install] Fehler 2
> ----------snap----------------
> 
> Is there any chance to get this in?

I read the expand manpage. I'd say it's not that hard. Wanna try? ;)
--
vda

From ml at zastrow4u.de  Mon Aug  6 11:56:30 2007
From: ml at zastrow4u.de (Alfred Zastrow)
Date: Mon, 06 Aug 2007 20:56:30 +0200
Subject: applet-request: expand
In-Reply-To: <200708061511.32929.vda.linux@googlemail.com>
References: <46B60B7C.6080108@zastrow4u.de>
	<200708061511.32929.vda.linux@googlemail.com>
Message-ID: <46B76EDE.5020100@zastrow4u.de>

Denis Vlasenko schrieb:
> On Sunday 05 August 2007 18:40, Alfred Zastrow wrote:
>> Hello list,
>>
>> glibc-2.6.1 compiles fine by using most of the applets of busybox-1.6.1,
>> but "expand" of coreutils is still missing:
>>
>> ----------snip----------------
>> sed -e 's,[{}],@&,g'				\
>> 	    -e 's,/\*\(@.*\)\*/,\1,g'			\
>> 	    -e 's,/\*  *,/* @r{,g' -e 's,  *\*/,} */,'	\
>> 	    -e 's/\(@[a-z][a-z]*\)@{\([^}]*\)@}/\1{\2}/g'\
>> 	    examples/stpcpy.c | expand > stpcpy.c.texi.new
>> /bin/sh: line 4: expand: command not found
>> make[2]: *** [stpcpy.c.texi] Error 127
>> make[2]: Leaving directory `/build/glibc-2.6.1/manual'
>> make[1]: *** [manual/subdir_install] Error 2
>> make[1]: Leaving directory `/build/glibc-2.6.1'
>> make: *** [install] Fehler 2
>> ----------snap----------------
>>
>> Is there any chance to get this in?
> 
> I read the expand manpage. I'd say it's not that hard. Wanna try? ;)

Yes, please.

My 1st thought was to create a shell wrapper with `tr`, but a more 
professional solution (without patching the source) would be much more 
nicer.

Regards
Alfred


From farmatito at tiscali.it  Mon Aug  6 14:00:56 2007
From: farmatito at tiscali.it (Tito)
Date: Mon, 6 Aug 2007 23:00:56 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <46B76EDE.5020100@zastrow4u.de>
References: <46B60B7C.6080108@zastrow4u.de>
	<200708061511.32929.vda.linux@googlemail.com>
	<46B76EDE.5020100@zastrow4u.de>
Message-ID: <200708062300.56120.farmatito@tiscali.it>

Hi,
this is a first attempt to implement a stripped down version of expand.
This version is only little tested so it may contain all sort of bugs.
Hints, critics and help in testing and improving it is welcome. 

bloat-o-meter (after make defconfig and enabling the expand applet) says:
function                                             old     new   delta
expand_main                                            -     437    +437
.rodata                                           121357  121485    +128
packed_usage                                       22558   22660    +102
applets                                             3108    3120     +12
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 3/0 up/down: 679/0)             Total: 679 bytes

Usage is: expand  [-i] [-t NUM] [FILE | -]

 *  Options:
 *  -t num		Convert tabs to num spaces (default 8 spaces).
 *
 *              Caveat: this version doesn't accept tab lists and
 *              therefore isn't conform to The Open Group Base 
 *              Specifications Issue 6.
 *
 *  -i			Only convert initial tabs on each line to spaces.

Ciao,
Tito
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expand.patch
Type: text/x-diff
Size: 5052 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070806/61687011/attachment.bin 

From dave at cray.com  Mon Aug  6 18:26:57 2007
From: dave at cray.com (David Updegraff)
Date: Mon, 06 Aug 2007 20:26:57 -0500
Subject: udhcp lease bug
Message-ID: <f98hp2$7c8$1@sea.gmane.org>

Hi.

udhcp keeps sending out same IPs to diff. macs w/o this patch when a
bunch boot at the same time.  Annoying.


----------snip-----
svn diff networking/udhcp/leases.c
Index: networking/udhcp/leases.c
===================================================================
--- networking/udhcp/leases.c   (revision 19415)
+++ networking/udhcp/leases.c   (working copy)
@@ -33,7 +33,7 @@
        for (j = 0; j < 16 && !chaddr[j]; j++);

        for (i = 0; i < server_config.max_leases; i++)
-               if ((j != 16 && memcmp(leases[i].chaddr, chaddr, 16) != 0)
+               if ((j != 16 && memcmp(leases[i].chaddr, chaddr, 16) == 0)
                 || (yiaddr && leases[i].yiaddr == yiaddr)
                ) {
                        memset(&(leases[i]), 0, sizeof(struct
dhcpOfferedAddr));
-----------------snip--------


From jakolee at gmail.com  Mon Aug  6 21:51:16 2007
From: jakolee at gmail.com (Jako Lee)
Date: Tue, 7 Aug 2007 12:51:16 +0800
Subject: Httpd serve multiple pages
Message-ID: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>

Hi all,

How do I serve multiple pages using httpd for a single user?
Right now I have a main page with a link to another page on
my Linux directory. After logging in I can see the main page
but when I click on the link it tell me that it can't find
the server (both the main page and the linked page are in
the same directory). However, if the link is set to "Google"
or "Yahoo" homepage it will work fine.

I had searched about busybox at forum and I used Google to
find "busybox httpd command", "busybox httpd directives" and
 "busybox httpd.conf" on the Web, but I got no useful hits.

I am using BusyBox 1.0.0. and linux kernel is 2.6.18-1.2798.fc6xen.

Best regards
Jako
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070807/0b068163/attachment.htm 

From vapier at gentoo.org  Mon Aug  6 23:39:10 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 7 Aug 2007 02:39:10 -0400
Subject: [PATCH] Add Blackfin to scripts/checkstack.pl
In-Reply-To: <200708061423.49765.vda.linux@googlemail.com>
References: <342715.31112.qm@web62502.mail.re1.yahoo.com>
	<200708061423.49765.vda.linux@googlemail.com>
Message-ID: <200708070239.11570.vapier@gentoo.org>

On Monday 06 August 2007, Denis Vlasenko wrote:
> On Thursday 02 August 2007 14:54, Alex Landau wrote:
> > Hi,
> > The patch below adds support for Blackfin to scripts/checkstack.pl.
> > Please apply, if it seems appropriate.
> > Alex
>
> Applied, thanks.

really you should just pull down the latest version from the kernel git
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070807/6e610249/attachment.pgp 

From per.hallsmark at t2data.se  Tue Aug  7 00:41:31 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Tue, 07 Aug 2007 09:41:31 +0200
Subject: hush in arm nommu environment
In-Reply-To: <200708061507.26107.vda.linux@googlemail.com>
References: <46B6DA1E.1090502@t2data.se> <46B6EB78.7040204@t2data.se>
	<200708061507.26107.vda.linux@googlemail.com>
Message-ID: <46B8222B.8000000@t2data.se>

Ahhh.. yes I see it know, how could I ever miss :)

Well, the testapp works same here, both in my host and
target.

The hexdump is also same:

00000000  36 35 34 33 32 31 08 08  08 08 0a      |654321.....|
0000000b

Busybox though behaves different. Extremely odd.
It seems then as some offset errors in busybox datasegment
for some reasons, since I get some text out from a completely
different string.

Denis Vlasenko wrote:
> On Monday 06 August 2007 10:35, Per Hallsmark wrote:
>> well... sometimes one can answer oneself... :)
>>
>> --- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
>> +++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
>> @@ -165,10 +165,12 @@
>>
>>          if (cmdedit_x >= num) {
>>                  cmdedit_x -= num;
>> +#if 0
>>                  if (num <= 4) {
>>                          printf("\b\b\b\b" + (4-num));
>>                          return;
>>                  }
>> +#endif
>>                  printf("\033[%uD", num);
>>                  return;
>>          }
>>
>>
>> With above patch backspace works ok.
>>
>> The \b\b... printf looks rather mystic... guess the author
>> perhaps wanted something like this instead?
>>
>> switch (num) {
>>    case 4:
>>      printf("\b");
>>      /* fall trough */
>>    case 3:
>>      printf("\b");
>>      /* fall trough */
>>    case 2:
>>      printf("\b");
>>      /* fall trough */
>>    case 1:
>>      printf("\b");
>>      return;
>>    default:
>> }
>>
>> but I wonder what the benefits are...
> 
> printf("\b\b\b\b" + (4-num));
> 
> does exactly the same in 4 times less code.
> If num==4, it does printf("\b\b\b\b" + 0) => printf("\b\b\b\b")
> If num==3, it does printf("\b\b\b\b" + 1) => printf("\b\b\b")
> If num==2, it does printf("\b\b\b\b" + 2) => printf("\b\b")
> If num==1, it does printf("\b\b\b\b" + 3) => printf("\b")
> etc
> 
> The benefits are that we send less bytes than with printf("\033[%uD", num);
> It's done primarily for the most common case: single [Backspace] key.
> It's silly to send ESC [ 1 D instead of single backspace char.
> 
> Now, I wonder why \b for you does not do what it should (that is,
> going back one char). Can you compile and run this test program?
> 
> int main(int argc, char **argv) {
>         printf("987654321\b\b\b\b" + argc);
>         fflush(0);
>         sleep(3);
>         puts("");
> }
> 
> When I run it, I see this:
> 
> # ./a.out
> 87654321   <---- cursor is under '4'
> # ./a.out 1
> 7654321    <---- cursor is under '4'
> # ./a.out 1 1
> 654321     <---- cursor is under '4'
> # ./a.out 1 1 | hexdump -vC
> 00000000  36 35 34 33 32 31 08 08  08 08 0a                 |654321.....|
> 0000000b
> 
> IOW, both printf("str" + n) and '\b' work right for me.
> 
> What do you see
> --
> vda



From per.hallsmark at t2data.se  Tue Aug  7 00:51:38 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Tue, 07 Aug 2007 09:51:38 +0200
Subject: hush in arm nommu environment
In-Reply-To: <200708061510.25873.vda.linux@googlemail.com>
References: <46B6DA1E.1090502@t2data.se>
	<200708061510.25873.vda.linux@googlemail.com>
Message-ID: <46B8248A.2050703@t2data.se>

well... the exact same style is made in other places
for nommu portability.

I only have two scripts in my target, one rc and one
upgrade, both works fine starting background stuff etc.
They do some if's, starting background processes, variabel handling
and so on.

Since, with working backspace ;-), hush is such a better
solution than sash I'd rather stick with hush and take
eventual bugs/"nommu features" as they come.

So, while not perfect, it's better than other current
solutions at least for our usage.

Denis Vlasenko wrote:
> On Monday 06 August 2007 09:21, Per Hallsmark wrote:
>> Hi all,
>>
>> I've tried out the hush shell in busybox 1.6.1.
>> Seems to work fairly well with the patch last in
>> this mail.
> ...
>> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
>> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
>> @@ -658,7 +658,11 @@
>>          pid_t pid;
>>
>>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
>> +#if BB_MMU
>>          pid = fork();
>> +#else
>> +       pid = vfork();
>> +#endif
>>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>>                  return;
>>          ctrl_z_flag = 1;
> 
> I'm afraid this maybe works for some simple scripts, but I'm sure as hell
> there are nasty bugs. Code does assume that after fork() we create
> new process. Simply replacing it with vfork is not going to work stably.
> --
> vda



From hinko.kocevar at cetrtapot.si  Tue Aug  7 00:38:50 2007
From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si)
Date: Tue, 07 Aug 2007 09:38:50 +0200
Subject: Httpd serve multiple pages
In-Reply-To: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>
References: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>
Message-ID: <46B8218A.1090306@cetrtapot.si>

Jako Lee wrote:
> Hi all,
> 
> How do I serve multiple pages using httpd for a single user?

For me it works the same as on all other web servers - put them in the 
web root (or subdirs of web root) directory and navigate to that address.

> Right now I have a main page with a link to another page on
> my Linux directory. After logging in I can see the main page
> but when I click on the link it tell me that it can't find
> the server (both the main page and the linked page are in
> the same directory). However, if the link is set to "Google"
> or "Yahoo" homepage it will work fine.

Could you post your html pages so that we can take a look?

regards,
hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si


From alexander.griesser at lkh-vil.or.at  Tue Aug  7 05:00:08 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Tue, 07 Aug 2007 14:00:08 +0200
Subject: Again, troubles with uploading files using busybox httpd
Message-ID: <46B85EC8.1030800@lkh-vil.or.at>

Hi folks!

This one seems to be a duplicate of a previous bug report for bb
1.3.1/1.4.1, here's the link:

http://www.busybox.net/lists/busybox/2007-February/026289.html

Currently (latest svn version), I'm unable to upload files onto my
busybox installation running busybox httpd.

The problem is, that the `cat` command never finishes after it wrote
the uploaded file successfully to the temporary location, that means
uploading works, but after the upload has finished, `cat` doesn't quit.

I also tried `dd of=$TMPOUT` => didn't work either (hangs after upload
has finished).

As mentioned in the above link, I had a similar problem a few months ago
and have looked at the patch posted back then from Denis, but wasn't
able to merge it to the current httpd.c (don't even know if it would
have made sense ;) ).

Any ideas, what's going wrong here?

The sample cgi-script for uploading the file follows:

----------[ uploadconfig.cgi ] -------------------------

#!/bin/sh

# parameters:
# $1 - file destination
upload_file()
{
  TMPOUT=$(mktemp /tmp/XXXXXX)

  # upload the file to $TMPOUT
  cat >$TMPOUT

  # get the line count and remove the first 4 and the last 2 lines
  # of the uploaded file (these lines contain boundery and content-type
  # information only)
  LINE_COUNT=$(wc -l $TMPOUT | awk "-F " '{ print $1 }')
  if [ $LINE_COUNT -le 6 ]; then
    RETURN=1
  else
    UPPER_BOUND=$(( $LINE_COUNT - 4 ))
    LOWER_BOUND=$(( $UPPER_BOUND - 2 ))
    tail -n $UPPER_BOUND $TMPOUT | head -n $LOWER_BOUND > $1
    RETURN=$?
  fi

  rm -f $TMPOUT

  if [ "$RETURN" = "0" ]; then
    echo "<p class=\"statusok\">Upload successful.</p>"
  else
    echo "<p class=\"statusfail\">Error while uploading the file!</p>"
  fi

  return $RETURN
}


echo "<h2>Upload configuration file</h2>"

if [ "$REQUEST_METHOD" = "POST" ]; then
  if upload_file /system/etc/lxtc-config; then
    echo "<center><pre>"
    cat /system/etc/lxtc-config
    echo "</pre></center>"
  fi
else
  echo "<form name=\"test\" method=\"post\"
action=\"/cgi-bin/uploadconfig.cgi\" enctype=\"multipart/form-data\">"
  echo "<input type=\"file\" name=\"configfile\" maxlength=\"10240\" />"
  echo "<input type=\"submit\" value=\"Upload configuration file\" />"
  echo "</form>"
fi
---------------------------------- 8< --------------------

ciao,
-- 
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061

From farmatito at tiscali.it  Tue Aug  7 06:16:28 2007
From: farmatito at tiscali.it (Tito)
Date: Tue, 7 Aug 2007 15:16:28 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <46B8671B.3030107@bfs.de>
References: <46B60B7C.6080108@zastrow4u.de>
	<200708062300.56120.farmatito@tiscali.it> <46B8671B.3030107@bfs.de>
Message-ID: <200708071516.28795.farmatito@tiscali.it>

On Tuesday 07 August 2007 14:35:39 walter harms wrote:
> do you do unexpand also ?
> re,
>  wh
Hi,
i ignored the existence of expand/unexpand  :-) till yesterday....
If there is some interest I can try, or are you volunteering?

It should be possible to merge expand/unexpand into a single
applet (as long as we don't try to do the expand -t list files stuff)
but before attempting it I would like the current code to be 
better tested, debugged and optimized, as it is mostly untested.

Ciao,
Tito

From ml at zastrow4u.de  Tue Aug  7 12:14:09 2007
From: ml at zastrow4u.de (Alfred Zastrow)
Date: Tue, 07 Aug 2007 21:14:09 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <200708062300.56120.farmatito@tiscali.it>
References: <46B60B7C.6080108@zastrow4u.de>	<200708061511.32929.vda.linux@googlemail.com>	<46B76EDE.5020100@zastrow4u.de>
	<200708062300.56120.farmatito@tiscali.it>
Message-ID: <46B8C481.4080904@zastrow4u.de>

Tito schrieb:
> Hi,
> this is a first attempt to implement a stripped down version of expand.
> This version is only little tested so it may contain all sort of bugs.
> Hints, critics and help in testing and improving it is welcome. 

Thanks a lot, it works. I didn't compare the results in detail yet, but
compiling glibc-2.6.1 doesn't break anymore.

Will this patch go into the next busybox release?

regards
Alfred



From landau_alex at yahoo.com  Wed Aug  8 05:09:27 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Wed, 8 Aug 2007 05:09:27 -0700 (PDT)
Subject: [PATCH] httpd: Support "Status: " header in CGI script
Message-ID: <937796.3923.qm@web62503.mail.re1.yahoo.com>

Hi,

The attached patch adds to httpd support for a Status header.
This header (as per the CGI spec) is used by CGI scripts to ask the server to send an
HTTP response different than 200. Why is it needed, and why the script can't send the
"HTTP/1.0 302 Found" (or similar) by itself is beyond me...
PHP (at least in CGI mode) sends "Status: 302" and the appropriate Location when running
header('Location: something'). That was my motivation for the patch.

Due to efficiency and space considerations, when httpd receives a "Status: xxx" header it
sends "HTTP/1.0 xxx" without the textual code representation (e.g. "HTTP/1.0 302" instead
of "HTTP/1.0 302 Found"). This works at least with Firefox 2.0.0.6 on Linux and IE 6 on,
well..., Windows.
If you think it's worth it, I can add proper message ("Found" etc.) handling.

Alex


       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpd.patch
Type: text/x-patch
Size: 947 bytes
Desc: 4014077785-httpd.patch
Url : http://busybox.net/lists/busybox/attachments/20070808/f5c26d95/attachment.bin 

From creder at digitalcpt.com  Wed Aug  8 13:39:08 2007
From: creder at digitalcpt.com (Christopher Reder)
Date: Wed, 8 Aug 2007 15:39:08 -0500
Subject: 'df' output
Message-ID: <011101c7d9fc$2b1dd5b0$2600a8c0@engineering5>

I am trying to figure out more information on the 'df' output and how it may
indicate how something is setup wrong with my kernel.  If this is the wrong
list to ask the question, I'll be glad to repost elsewhere.

 

If you look at the output below, you'll see that I have 1 mtd block setup on
a nand flash.  This flash is 256 MB.  You can see that in the iomem output
and in the mtd output.  However, when I run 'df', it shows the there is 5.7
Meg. 

 

I am wondering why it is and/or what it is looking at to see that when
everything else in the kernel is showing correctly.  If anyone can direct me
in the correct spot, or tell me to repost to a kernel list, I'll be glad to
do it.

 

major minor  #blocks  name

 

  31     0     262144 mtdblock0

 254     0    1985024 mmcblk0

 254     1    1983619 mmcblk0p1

# cat iomem

00300000-003fffff : at91_ohci

  00300000-003fffff : ohci_hcd

20000000-21ffffff : System RAM

  2002c000-202a1fff : Kernel text

  202a2000-202d0fd7 : Kernel data

40000000-4fffffff : at91_nand

80000000-8017ffff : FPGA video memory

  80000000-8017ffff : dcifb mem

80800000-80800004 : FPGA video registers

  80800000-80800004 : dcifb regs

fefbc000-fefbffff : at91_ether

fefff200-fefff3ff : atmel_usart.0

  fefff200-fefff3ff : atmel_serial

fffb4000-fffb7fff : at91_mci

  fffb4000-fffb7fff : at91_mci

fffe0000-fffe3fff : at91_spi.0

  fffe0000-fffe3fff : at91_spi

# cat mtd

dev:    size   erasesize  name

mtd0: 10000000 00020000 "NAND1"

# df

Filesystem                Size      Used Available Use% Mounted on

/dev/mtdblock0            5.7M      3.3M      2.4M  58% /

#

 

 

static struct mtd_partition __initdata dci_nand_partition[] = {

{

.name   = "NAND1",

.offset   = 0,

.size     = MTDPART_SIZ_FULL,

},

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070808/da70cd00/attachment.htm 

From farmatito at tiscali.it  Wed Aug  8 23:27:07 2007
From: farmatito at tiscali.it (Tito)
Date: Thu, 9 Aug 2007 08:27:07 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <200708062300.56120.farmatito@tiscali.it>
References: <46B60B7C.6080108@zastrow4u.de> <46B76EDE.5020100@zastrow4u.de>
	<200708062300.56120.farmatito@tiscali.it>
Message-ID: <200708090827.07423.farmatito@tiscali.it>

On Monday 06 August 2007 23:00:56 Tito wrote:
> Hi,
> this is a first attempt to implement a stripped down version of expand.
> This version is only little tested so it may contain all sort of bugs.
> Hints, critics and help in testing and improving it is welcome. 
> 
> bloat-o-meter (after make defconfig and enabling the expand applet) says:
> function                                             old     new   delta
> expand_main                                            -     437    +437
> .rodata                                           121357  121485    +128
> packed_usage                                       22558   22660    +102
> applets                                             3108    3120     +12
> ------------------------------------------------------------------------------
> (add/remove: 1/0 grow/shrink: 3/0 up/down: 679/0)             Total: 679 bytes
> 
> Usage is: expand  [-i] [-t NUM] [FILE | -]
> 
>  *  Options:
>  *  -t num		Convert tabs to num spaces (default 8 spaces).
>  *
>  *              Caveat: this version doesn't accept tab lists and
>  *              therefore isn't conform to The Open Group Base 
>  *              Specifications Issue 6.
>  *
>  *  -i			Only convert initial tabs on each line to spaces.
> 
> Ciao,
> Tito
> 

Hi Denis,
please don't apply this patch fro the moment,
I'm working on an improved one with less bugs,
tests for our test suite and also unexpand.
Need a few days for it.

Ciao,
Tito


From vda.linux at googlemail.com  Thu Aug  9 00:53:02 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 9 Aug 2007 08:53:02 +0100
Subject: udhcp lease bug
In-Reply-To: <f98hp2$7c8$1@sea.gmane.org>
References: <f98hp2$7c8$1@sea.gmane.org>
Message-ID: <200708090853.02188.vda.linux@googlemail.com>

On Tuesday 07 August 2007 02:26, David Updegraff wrote:
> Hi.
> 
> udhcp keeps sending out same IPs to diff. macs w/o this patch when a
> bunch boot at the same time.  Annoying.

Thanks for finding it. Fixed in svn.
--
vda

From alexander.griesser at lkh-vil.or.at  Thu Aug  9 01:00:43 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Thu, 09 Aug 2007 10:00:43 +0200
Subject: Again, troubles with uploading files using busybox httpd
In-Reply-To: <46B85EC8.1030800@lkh-vil.or.at>
References: <46B85EC8.1030800@lkh-vil.or.at>
Message-ID: <46BAC9AB.6010600@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Griesser wrote:
> Hi folks!
> 
> This one seems to be a duplicate of a previous bug report for bb
> 1.3.1/1.4.1, here's the link:
> 
> http://www.busybox.net/lists/busybox/2007-February/026289.html

Noone else experiencing this problem?

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

iD8DBQFGusmr66HVD6KUm1oRAk/OAJ0VI7Ktfr+hzut5OAqPK3cSRZHi7ACfci2b
Lw5W3mDE/XAPwjYgkexNHMU=
=amen
-----END PGP SIGNATURE-----

From vda.linux at googlemail.com  Thu Aug  9 01:03:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 9 Aug 2007 09:03:03 +0100
Subject: Httpd serve multiple pages
In-Reply-To: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>
References: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>
Message-ID: <200708090903.03970.vda.linux@googlemail.com>

On Tuesday 07 August 2007 05:51, Jako Lee wrote:
> Hi all,
> 
> How do I serve multiple pages using httpd for a single user?
> Right now I have a main page with a link to another page on
> my Linux directory. After logging in I can see the main page
> but when I click on the link it tell me that it can't find
> the server (both the main page and the linked page are in
> the same directory). However, if the link is set to "Google"
> or "Yahoo" homepage it will work fine.

Let's say you have first_page.htm and second_page.htm in the same dir.

"Second page is <a href=second_page.htm>here</a>" should work.

Please post these two pages (or their simplified versions
if they are big), explain in which directory do you put
these files and how do you start httpd (exact command line).
Will try to reproduce here.
--
vda

From vda.linux at googlemail.com  Thu Aug  9 01:17:31 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 9 Aug 2007 09:17:31 +0100
Subject: Fw: Bug in PS command
In-Reply-To: <019101c7d8c1$2cec9b60$0402a8c0@seorot377rl65q>
References: <019101c7d8c1$2cec9b60$0402a8c0@seorot377rl65q>
Message-ID: <200708090917.31711.vda.linux@googlemail.com>

On Tuesday 07 August 2007 08:04, Amit Saha wrote:
> I found one Bug in PS command of BusyBox 1.00.

But we are on 1.6.1...

> While the ps is getting size of output screen, it is passing the parameter 0 instead of 1, procps/ps.c line 56.

There is only "}" on that line in current busybox.

It took me a bit of time to figure out what do you mean.
Fixed now. Thanks.
--
vda

From himainu-ynakam at miomio.jp  Tue Aug  7 21:38:45 2007
From: himainu-ynakam at miomio.jp (himainu-ynakam at miomio.jp)
Date: Wed, 08 Aug 2007 13:38:45 +0900
Subject: [patch][BusyBox] Domain assignment support for SELinux/AppArmor/LIDS
Message-ID: <200708080438.l784cj4N015640@mbox.iijmio-mail.jp>

Hello.

We would like to suggest Secure OSes(such as SELinux/AppArmor/LIDS) domain
assignment support for BusyBox. This work is done by Hiroshi Shinji.

1. Background

Secure OSes such as SELinux, AppArmor and LIDS can assign domain to processes.
"Domain" means set of access rights.
Domain is assinged to processes at the time of "exec" system call.
# This is a little similar to "suid" feature of Linux.

For example, in the case of SELinux, /sbin/syslogd is assigned syslogd_t
domain at the execution time of /sbin/syslogd. syslogd_t are allowed to
read syslogd.conf, write log files, etc.

However, current BusyBox does not suitable for assigning domains.
Because BusyBox is a single file that is called through a lot of links.

Secure OS treats "/sbin/syslogd" and "/sbin/httpd" as "/bin/busybox".
So, /sbin/syslogd and /sbin/httpd run as the same domain.

Known solutions to this problem is preparing wrapper program that calls
applet.
? For example, /sbin/syslogd is a small C program that calls
"/bin/busybox syslogd". Then, at the execution of /sbin/syslogd,
syslogd_t domain is assigned and "/bin/busybox syslogd" is called
and inherits assinged domain(syslogd_t).
However, such wrapper consumes storage(more than 1k byte per wrapper).
For detailed description about this problem,
Yusuke Sato wrote documentation:
http://www.selinux.gr.jp/LIDS-JP/LIDS_en/document/general/web_lids_busybox/main.html

2. Our solution
Shinji came up with one idea. He thought "script wrappper" like below.

If you enabled "INSTALL_APPLET_SCRIPT_WRAPPERS", wrappers like below are
installed.

The contents of "/sbin/syslogd" is following.

#!/bin/busybox

It is only 15 byte.

When /sbin/syslogd is executed, "/bin/busybox /sbin/syslogd <other arguments>" is called.

To achive above, we had to modify applets.c

-       applet_name = argv[0];
-       run_applet_and_exit(argv[0], argv);
+       applet_name = bb_get_last_path_component(argv[0]);
+       run_applet_and_exit(applet_name, argv);

We tried the patch for SELinux and AppArmor.
And domains were assigned sucessfully!

3. Limitation
Programs that are used as interpreter can not be installed as script wrapper.
It is due to limitation of exec(interpreter can not be called twice).
For example, /bin/sh can not be installed as script wrapper.
If /bin/sh is installed as script wrapper, shell scripts do not run.
In interpreting #!/bin/sh

-> /bin/sh is #!/bin/busybox,
-> #! is called twice
-> exec system call fails(limitation of exec system call).

In our patch, sh is installed as symlink or hard link by default
(you can install it as script wrapper if you still need).

Assigning domain is critical to secure OSes.
We want way to assign to domains to busybox applets.
Please review this patch and consider merging.

Regards,
Yuichi Nakamura
JSELUG(Japan SELinux Users Group)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: domain_assign.patch
Type: application/octet-stream
Size: 5261 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070808/2cf3f159/attachment-0001.obj 

From vda.linux at googlemail.com  Thu Aug  9 01:52:34 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 9 Aug 2007 09:52:34 +0100
Subject: Again, troubles with uploading files using busybox httpd
In-Reply-To: <46BAC9AB.6010600@lkh-vil.or.at>
References: <46B85EC8.1030800@lkh-vil.or.at> <46BAC9AB.6010600@lkh-vil.or.at>
Message-ID: <200708090952.34639.vda.linux@googlemail.com>

On Thursday 09 August 2007 09:00, Alexander Griesser wrote:
> Alexander Griesser wrote:
> > Hi folks!
> >
> > This one seems to be a duplicate of a previous bug report for bb
> > 1.3.1/1.4.1, here's the link:
> >
> > http://www.busybox.net/lists/busybox/2007-February/026289.html
> 
> Noone else experiencing this problem?

Sorry, had no time to look at it, yet. Will try today in the evening.
--
vda

From Alexander at Kriegisch.name  Thu Aug  9 05:27:55 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Thu, 09 Aug 2007 14:27:55 +0200
Subject: Again, troubles with uploading files using busybox httpd
In-Reply-To: <46B85EC8.1030800@lkh-vil.or.at>
References: <46B85EC8.1030800@lkh-vil.or.at>
Message-ID: <46BB084B.5020708@Kriegisch.name>

Hi Alexander!

Your uploadconfig.cgi looks interesting, some months ago I also tried to
handle form-based uploads in shell script, but felt it was too tricky
and unstable. What if another browser sends more headers? Why read the
uploaded file several times for line counting, head and tail operations?
and so forth.

[OT]
I use httpd (currently BB 1.5.1) on a mipsel platform (embedded router
system) in combination with Haserl (http://haserl.sourceforge.net/) as a
CGI handler and am very satisfied. Maybe this is an option to be
considered for you, too. The latest Haserl release 0.9.18 comes with an
interesting new option which has been incorporated by the author upon my
request: The upload is not stored as a temp-file, but written into a
pipe (FIFO). A handler for reading the FIFO is called asynchronously, so
 a shell script can extract a tar archive on the fly, for example. This
is an advantage on platforms with limited memory if you want to avoid
double memory consumption (archive plus extracted content). And the best
thing is that the upload is read once and only once. Haserl is lean and
the very simple template mechanism integrates beautifully in shell
scripts (or Lua scripts, if you prefer).

BTW: No, I don't get money for promoting Haserl, I am just a satisfied
user. ;-)
[/OT]

Back to your shell script: I think it would be better to develop a
version which reads the content length header and then acts accordingly,
not reading linewise, but bytewise, even though in your case you always
seem to upload text files or maybe base64-encoded binaries. But don't
forget that binary uploads are also allowed. So if you want a more
general solution, you might have to improve your script considerably.

Best regards
--
Alexander Kriegisch

From alexander.griesser at lkh-vil.or.at  Thu Aug  9 06:12:54 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Thu, 09 Aug 2007 15:12:54 +0200
Subject: Again, troubles with uploading files using busybox httpd
In-Reply-To: <46BB084B.5020708@Kriegisch.name>
References: <46B85EC8.1030800@lkh-vil.or.at> <46BB084B.5020708@Kriegisch.name>
Message-ID: <46BB12D6.6040806@lkh-vil.or.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Kriegisch wrote:
> Your uploadconfig.cgi looks interesting, some months ago I also tried to
> handle form-based uploads in shell script, but felt it was too tricky
> and unstable. What if another browser sends more headers?

Well, I never thought about that, as Mozilla and IE6/7 worked with it.

> Why read the uploaded file several times for line counting,
> head and tail operations?

Because I had no other idea about how to do that without investing much
time into it.

> I use httpd (currently BB 1.5.1) on a mipsel platform (embedded router
> system) in combination with Haserl (http://haserl.sourceforge.net/) as a
> CGI handler and am very satisfied.

Will have a look at it, but doesn't haserl only read what it gets from
busybox httpd?
To me it seems as if the upload never finishes because of a bug in httpd
and although using haserl and pipes and whatsoever, wouldn't that wait
for the end of the stream too?

> The upload is not stored as a temp-file, but written into a pipe (FIFO).

Not really a necessity for me currently, but it sounds great.

> Haserl is lean and the very simple template mechanism integrates
> beautifully in shell scripts (or Lua scripts, if you prefer).

Unfortunately, there are no examples on the website, but I'll try to
build a demo script with haserl just to see how it fairs.

> Back to your shell script: I think it would be better to develop a
> version which reads the content length header and then acts accordingly,

Well, that was what came to my mind at first after recognizing that the
upload of the file works, but afterwards the read() doesn't finish.
Reading only n bytes of data would - of course - work around this
problem, but mentioning the bug is worth it, because it was fixed some
releases ago (as stated in my first mail) and has now somehow been
reintroduced.

> But don't forget that binary uploads are also allowed. So if you want
> a more general solution, you might have to improve your script
> considerably.

I once had an "upload firmware" button too which uploaded base64
converted firmware files, but wasn't satisfied with this solution as
the resulting converted files were at least twice as big as the
original file :-/

So maybe the use of haserl will reintroduce firmware uploads as well ;)

Thanks for the hint so far,
will see what I can accomplish.

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

iD8DBQFGuxLW66HVD6KUm1oRAmARAJ47lcf7VfE8FXNqyxOUiGVNkBH2gACeJfdE
pAvty+SHejydI7wl2PV/DCA=
=nwYv
-----END PGP SIGNATURE-----

From vshrirama at gmail.com  Thu Aug  9 09:00:11 2007
From: vshrirama at gmail.com (Ram)
Date: Thu, 9 Aug 2007 21:30:11 +0530
Subject: Busybox utils to set u-boot environment?
Message-ID: <8bf247760708090900v6a715520hc7fecc7d76e17cbf@mail.gmail.com>

Hi,
     Are there any busybox utility to get and set the u-boot
environments from linux.


Regards,
sriram

From mats at blue2net.com  Thu Aug  9 10:42:23 2007
From: mats at blue2net.com (Mats Erik Andersson)
Date: Thu, 09 Aug 2007 19:42:23 +0200
Subject: Rewritten autoconf and build directory
Message-ID: <1186681343.4744.78.camel@Blue2net-mats.bellman.mea>

Hello all,

I stumbled on a possible issue with today's
svn edition of Busybox. There was no problem
whatsoever to build Busybox 1.6.1 fresh out of the
box into a separate build directory, but when I tried
the same with svn trunk of today, the changed autoconf
handling gives a warning and then an error is caused
by applets/usage.c and include/applets.h, thus breaking
an chance of progress early on. I am not sure whether the
fault is mine or not, but I thought it best to point
it out anyway. I will revert to 1.6.1 for the moment,
since I have no time to spare in the near future.

Regards   Mats E A

From swu at rgbnetworks.com  Thu Aug  9 11:18:05 2007
From: swu at rgbnetworks.com (Songyan Wu)
Date: Thu, 9 Aug 2007 11:18:05 -0700
Subject: Is busybox support doPost?
Message-ID: <9964EE0EF7D1234C8ADD051DB304E0CC08EFDD@MSG10001.rgbnetworks.com>

Hi,

 

I am working on busybox web server. I tried HTML  form with POST method,
it does not looks support. Is it true? 

 

 

Thanks,

 

Songyan

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070809/50daa7cc/attachment.htm 

From vda.linux at googlemail.com  Thu Aug  9 12:24:08 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 9 Aug 2007 20:24:08 +0100
Subject: Is busybox support doPost?
In-Reply-To: <9964EE0EF7D1234C8ADD051DB304E0CC08EFDD@MSG10001.rgbnetworks.com>
References: <9964EE0EF7D1234C8ADD051DB304E0CC08EFDD@MSG10001.rgbnetworks.com>
Message-ID: <1158166a0708091224m54377543n62f5e9d820737389@mail.gmail.com>

On 8/9/07, Songyan Wu <swu at rgbnetworks.com> wrote:
> Hi,
>
> I am working on busybox web server. I tried HTML  form with POST method, it
> does not looks support. Is it true?

IIRC no, POST is supported. But it may be buggy.

Explain the problem you are seeing in more detail
and it can be diagnosed and fixed.

http://catb.org/~esr/faqs/smart-questions.html
--
vda

From Jari.Takkala at Q9.com  Thu Aug  9 13:04:00 2007
From: Jari.Takkala at Q9.com (Jari Takkala)
Date: Thu, 9 Aug 2007 16:04:00 -0400
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not moved
	forward
Message-ID: <413FEEF1743111439393FB76D0221E4807C8B2EE@leopard.zoo.q9networks.com>

Hello,

The following patch fixes the circular log buffer in syslogd. Currently the head pointer is never moved forward. The 'logread' command will always read from the beginning of the buffer, even if the log buffer wraps.

The head pointer is not moved forward because it is 0 by default, so the comparison (old_tail < shbuf->head) never evaluates to true.

I have only been able to test this patch on Busybox 1.4.2. I've included a patch for 1.6.0 as well, if someone would please test and commit it. Thank you!

Regards,

Jari

--- busybox-1.4.2/sysklogd/syslogd.c	2007-06-29 13:50:37.000000000 -0400
+++ busybox-1.4.2/sysklogd/syslogd.c	2007-08-09 14:45:38.000000000 -0400
@@ -215,7 +215,7 @@
 	if (new_tail < shbuf->size) {
 		/* No need to move head if shbuf->head <= old_tail,
 		 * else... */
-		if (old_tail < shbuf->head && shbuf->head <= new_tail) {
+		if (old_tail <= shbuf->head && shbuf->head <= new_tail) {
 			/* ...need to move head forward */
 			c = memchr(shbuf->data + new_tail, '\0',
 					   shbuf->size - new_tail);

--- busybox-1.6.1/sysklogd/syslogd.c	2007-06-30 11:06:35.000000000 -0400
+++ busybox-1.6.1/sysklogd/syslogd.c	2007-08-09 15:16:33.000000000 -0400
@@ -253,7 +253,7 @@
 	if (new_tail < G.shbuf->size) {
 		/* No need to move head if shbuf->head <= old_tail,
 		 * else... */
-		if (old_tail < G.shbuf->head && G.shbuf->head <= new_tail) {
+		if (old_tail <= G.shbuf->head && G.shbuf->head <= new_tail) {
 			/* ...need to move head forward */
 			c = memchr(G.shbuf->data + new_tail, '\0',
 					   G.shbuf->size - new_tail);

From vapier at gentoo.org  Thu Aug  9 21:58:31 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 10 Aug 2007 00:58:31 -0400
Subject: hush in arm nommu environment
In-Reply-To: <46B8248A.2050703@t2data.se>
References: <46B6DA1E.1090502@t2data.se>
	<200708061510.25873.vda.linux@googlemail.com>
	<46B8248A.2050703@t2data.se>
Message-ID: <200708100058.32332.vapier@gentoo.org>

On Tuesday 07 August 2007, Per Hallsmark wrote:
> well... the exact same style is made in other places
> for nommu portability.

that's because the other places dont have the same problems hush does ... they 
account for the nommu issue, hush isnt even close to doing so

> So, while not perfect, it's better than other current
> solutions at least for our usage.

no, because it implies hush has been tested and known to *work* on nommu when 
in reality it's clearly known to not and the code clearly doesnt account for 
it
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070810/c6e34cad/attachment.pgp 

From vapier at gentoo.org  Thu Aug  9 22:00:40 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 10 Aug 2007 01:00:40 -0400
Subject: 'df' output
In-Reply-To: <011101c7d9fc$2b1dd5b0$2600a8c0@engineering5>
References: <011101c7d9fc$2b1dd5b0$2600a8c0@engineering5>
Message-ID: <200708100100.41386.vapier@gentoo.org>

On Wednesday 08 August 2007, Christopher Reder wrote:
> I am trying to figure out more information on the 'df' output and how it
> may indicate how something is setup wrong with my kernel.  If this is the
> wrong list to ask the question, I'll be glad to repost elsewhere.

df merely runs stat() on the mount points and displays the resulting 
information

that means you should run `df` through a verbose strace and verify the 
structure matches reality ... after that, you can check your libc to make 
sure the internal stat function is correctly translating the structure it got 
back from the kernel into the structure the POSIX API requires
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070810/ab9dad6a/attachment.pgp 

From vapier at gentoo.org  Thu Aug  9 22:04:28 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 10 Aug 2007 01:04:28 -0400
Subject: Busybox utils to set u-boot environment?
In-Reply-To: <8bf247760708090900v6a715520hc7fecc7d76e17cbf@mail.gmail.com>
References: <8bf247760708090900v6a715520hc7fecc7d76e17cbf@mail.gmail.com>
Message-ID: <200708100104.28599.vapier@gentoo.org>

On Thursday 09 August 2007, Ram wrote:
>      Are there any busybox utility to get and set the u-boot
> environments from linux.

no, nor will there probably ever be due to the nature of u-boot ... every 
single board can store its environment in different types of flash in 
different sectors at different offsets in different magical ways ... there is 
no common infrastructure to query such information from kernel/user space

you should setup your mtd maps to create a separate partition for your u-boot 
env sector and then use the mtd-utils package to read/write it from userspace

please seek any further help/information on the u-boot-usesr mailing list
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20070810/8146ec0d/attachment.pgp 

From hamish at cloud.net.au  Thu Aug  9 22:58:25 2007
From: hamish at cloud.net.au (Hamish Moffatt)
Date: Fri, 10 Aug 2007 15:58:25 +1000
Subject: use /proc for more of procps
Message-ID: <20070810055825.GA19283@cloud.net.au>

Has anyone looked at using /proc entries for more of the functionality
in the procps tools? For example, original procps's "free" command reports
more stuff, such as the amount of memory used by cache.

(Given the name "PROCps" it's a bit odd that eg free does not use /proc.
Real procps's free certainly does.)


thanks,
Hamish
-- 
Hamish Moffatt VK3SB <hamish at debian.org> <hamish at cloud.net.au>

From levend.sayar at karel.com.tr  Thu Aug  9 22:54:32 2007
From: levend.sayar at karel.com.tr (Levend Sayar)
Date: Fri, 10 Aug 2007 08:54:32 +0300
Subject: Shell problem reloaded and RESOLVED
References: <000501c7ad80$153e6be0$6402a8c0@nucleus>
Message-ID: <003a01c7db12$f395e610$6402a8c0@nucleus>

Hi,all

I was trying to port Linux on a 386EX based embedded board and stucked in
getting a working busybox shell. I investigate many tty code. After many
observation, I noticed that when the scheduler jumps to idle task,
everything stops. No interrupt, nothing. Just because of "default_idle"
which calls "hlt" instruction. I know kernel checks hlt during bootup
sequence, but I commented that code. Because my cpu hlt problematic. It
really halts !

As a result, that little "hlt" instruction caused me many hours. Giving
"no-hlt" at the commandline is what you have to do.

Have a nice day ...

_lvnd_
 (^_^)


From natanael.copa at gmail.com  Thu Aug  9 23:34:21 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 10 Aug 2007 08:34:21 +0200
Subject: [patch][BusyBox] Domain assignment support for
	SELinux/AppArmor/LIDS
In-Reply-To: <200708080438.l784cj4N015640@mbox.iijmio-mail.jp>
References: <200708080438.l784cj4N015640@mbox.iijmio-mail.jp>
Message-ID: <1186727661.2715.13.camel@nc.nor.wtbts.org>

On Wed, 2007-08-08 at 13:38 +0900, himainu-ynakam at miomio.jp wrote:
> Hello.
> 
> We would like to suggest Secure OSes(such as SELinux/AppArmor/LIDS) domain
> assignment support for BusyBox. This work is done by Hiroshi Shinji.

...

> For example, in the case of SELinux, /sbin/syslogd is assigned syslogd_t
> domain at the execution time of /sbin/syslogd. syslogd_t are allowed to
> read syslogd.conf, write log files, etc.
> 
> However, current BusyBox does not suitable for assigning domains.
> Because BusyBox is a single file that is called through a lot of links.
> 
> Secure OS treats "/sbin/syslogd" and "/sbin/httpd" as "/bin/busybox".
> So, /sbin/syslogd and /sbin/httpd run as the same domain.

This is a problem for start-stop-daemon too. IT would solve issues with
SUID bit programs too (like passwd, su ...)

> 2. Our solution
> Shinji came up with one idea. He thought "script wrappper" like below.

while I agree it would be nice to have every applet as a separate
executable, I'm not sure I like the idea of executing shell for every
command. It *feels* hackish.

> Assigning domain is critical to secure OSes.
> We want way to assign to domains to busybox applets.
> Please review this patch and consider merging.

The patch is the shortest way to accomplish this. I would believe the
"correct" way would be to compile every applet as a standalone, linked
to a libbb.so. I think its even mentioned in the TODO.

Natanael Copa


From marc.leeman at gmail.com  Thu Aug  9 23:59:29 2007
From: marc.leeman at gmail.com (Marc Leeman)
Date: Fri, 10 Aug 2007 08:59:29 +0200
Subject: Busybox utils to set u-boot environment?
In-Reply-To: <200708100104.28599.vapier@gentoo.org>
References: <8bf247760708090900v6a715520hc7fecc7d76e17cbf@mail.gmail.com>
	<200708100104.28599.vapier@gentoo.org>
Message-ID: <20070810065929.GO6335@chiana.homelinux.org>

> no, nor will there probably ever be due to the nature of u-boot ... every 
> single board can store its environment in different types of flash in 
> different sectors at different offsets in different magical ways ... there is 
> no common infrastructure to query such information from kernel/user space
> 
> you should setup your mtd maps to create a separate partition for your u-boot 
> env sector and then use the mtd-utils package to read/write it from userspace

I do not fully agree with you: U-Boot already contains a firmware
version (fw_setenv and fw_printenv) of the U-Boot setenv and the
printenv commands.

[mleeman at neo u-boot-1.2.0]$ find . -name fw_env.c
./tools/env/fw_env.c

It even operates similarly as busybox (tm) with argv[0] to distinguish
between setenv and printenv (I added a editenv to set multiple variables
at one pass only erasing one time the sector).

As for the querying of the information, strictly speaking, there is not
really a need for this since the developer needs to specify it in a
config file:

[mleeman at neo u-boot-1.2.0]$ cat ../../flashfs/etc/fw_env.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.

# MTD device name       Device offset   Env. size       Flash sector
# size
/dev/mtd1               0x0000          0x20000         0x20000
/dev/mtd2               0x0000          0x20000         0x20000

That's not really different as e.g. httpd.conf...

Finally, strictly speaking, you don't need a seperate mtd sector for
your environment, you could e.g. store it at the end of you U-Boot
sectors. If that is wise, that's an entirely different matter of course.

-- 
  greetz, marc
Is everybody aboard this ship kinkoid?
	Chiana - A Bug's Life
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 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/20070810/cb839486/attachment.pgp 

From genepi at sympatico.ca  Fri Aug 10 12:41:19 2007
From: genepi at sympatico.ca (Pierre =?iso-8859-1?q?M=E9tras?=)
Date: Fri, 10 Aug 2007 15:41:19 -0400
Subject: [PATCH] - httpd: support for kernel sendfile() call
Message-ID: <200708101541.19945.genepi@sympatico.ca>

Hi,

Here is a small patch to enable the use of the linux kernel function 
sendfile() in the httpd server (the last remaining TODO in network/httpd.c). 
This is enabled by a configuration option, disabled by default.


Without enabling sendfile feature:
$ make bloatcheck
function                                             old     new   delta
sendFile                                             252     247      -5
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5)               Total: -5 bytes
   text    data     bss     dec     hex filename
  87684    1068   10280   99032   182d8 busybox_old
  87668    1068   10280   99016   182c8 busybox_unstripped

With sendfile feature enabled:
$ make bloatcheck
function                                             old     new   delta
sendFile                                             252     294     +42
.rodata                                             9715    9747     +32
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 74/0)               Total: 74 bytes
   text    data     bss     dec     hex filename
  87684    1068   10280   99032   182d8 busybox_old
  87805    1072   10280   99157   18355 busybox_unstripped

-- Pierre M?tras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpd_sendfile.patch
Type: text/x-diff
Size: 2864 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070810/f85ac76e/attachment.bin 

From genepi at sympatico.ca  Fri Aug 10 12:42:38 2007
From: genepi at sympatico.ca (Pierre =?iso-8859-1?q?M=E9tras?=)
Date: Fri, 10 Aug 2007 15:42:38 -0400
Subject: [PATCH] httpd - User defined error pages
Message-ID: <200708101542.39107.genepi@sympatico.ca>

Hi,

Here is the third revision of my patch to add support for user defined error 
pages in httpd. I've integrated most of the comments from Denis Vlasenko, but 
one. During development, I was surprised to get a larger executable. The 
parse_conf() function got the biggest code size increase.

After a few tests, it seems the culprit is the suggested bb_strtoi() call. The 
following line adds 97 bytes (on PIV with gcc):
	int status = bb_strtoi(p0 + 1, &p0, 10)
function                                             old     new   delta
parse_conf                                          1201    1448    +247

compared with originally:
	c = strchr(++p0, ':');
	*c = 0;
	int status = xatoi(p0);
	p0 = ++c;
function                                             old     new   delta
parse_conf                                          1201    1337    +136

I couldn't explain why such a difference...


This patch includes:
- Support for definition of error pages in httpd.conf (it was the main goal!). 
This is enabled by a configuration option, default no.
- Reports of simple errors in httpd.conf when they are detected. It does not 
check that the error page exists. Reports of memory exhausted.
- Support for comments and empty lines in httpd.conf. End of line comments 
where already supported and not documented.


In the end, with error pages enabled:

$ make bloatcheck
function                                             old     new   delta
parse_conf                                          1201    1427    +226
sendHeaders                                          461     571    +110
httpResponseNames                                    108     144     +36
sendFile                                             252     269     +17
handleIncoming                                      2094    2100      +6
.rodata                                             9715    9619     -96
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 5/1 up/down: 395/-96)           Total: 299 bytes
   text    data     bss     dec     hex filename
  87684    1068   10280   99032   182d8 busybox_old
  87940    1228   10280   99448   18478 busybox_unstripped


And without error pages enabled:

$ make bloatcheck
function                                             old     new   delta
parse_conf                                          1201    1309    +108
.rodata                                             9715    9747     +32
sendFile                                             252     269     +17
sendHeaders                                          461     469      +8
handleIncoming                                      2094    2100      +6
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 5/0 up/down: 171/0)             Total: 171 bytes
   text    data     bss     dec     hex filename
  87684    1068   10280   99032   182d8 busybox_old
  87844    1068   10280   99192   18378 busybox_unstripped


-- Pierre M?tras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpd.error_pages
Type: text/x-diff
Size: 11551 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070810/ef2ba2c2/attachment.bin 

From masta at perlgolf.de  Sat Aug 11 01:59:21 2007
From: masta at perlgolf.de (Nico Erfurth)
Date: Sat, 11 Aug 2007 10:59:21 +0200
Subject: Patch for broken xbind in ping.c [busybox 1.6.1]
Message-ID: <46BD7A69.60407@perlgolf.de>

Hi,

networking/ping.c seems to be broken for some time now. When  used with
the -I option, it tries to bind to the address in lsa, instead of
source_lsa. Well, this won't work unless you ping your own machine. ;)

Appended is a patch to fix that, I've tested it with ipv4 only.
It seems like the bug was introduced with this revision:
http://busybox.net/cgi-bin/viewcvs.cgi?rev=17842&view=rev

Nico

-------------------------------------------
--- busybox-1.6.1/networking/ping.c     2007-06-30 17:06:31.000000000 +0200
+++ busybox-1.6.1-ping-bind/networking/ping.c   2007-08-11
10:43:35.000000000 +0200
@@ -505,7 +505,7 @@
        pingsock = create_icmp_socket();
        pingaddr.sin = lsa->sin;
        if (source_lsa)
-               xbind(pingsock, &lsa->sa, lsa->len);
+               xbind(pingsock, &source_lsa->sa, source_lsa->len);

        /* enable broadcast pings */
        setsockopt_broadcast(pingsock);
@@ -552,7 +552,7 @@
        pingaddr.sin6 = lsa->sin6;
        /* untested whether "-I addr" really works for IPv6: */
        if (source_lsa)
-               xbind(pingsock, &lsa->sa, lsa->len);
+               xbind(pingsock, &source_lsa->sa, source_lsa->len);

 #ifdef ICMP6_FILTER
        {

From vda.linux at googlemail.com  Sat Aug 11 10:52:52 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sat, 11 Aug 2007 18:52:52 +0100
Subject: Again, troubles with uploading files using busybox httpd
In-Reply-To: <46B85EC8.1030800@lkh-vil.or.at>
References: <46B85EC8.1030800@lkh-vil.or.at>
Message-ID: <200708111852.52138.vda.linux@googlemail.com>

On Tuesday 07 August 2007 13:00, Alexander Griesser wrote:
> This one seems to be a duplicate of a previous bug report for bb
> 1.3.1/1.4.1, here's the link:
>
> http://www.busybox.net/lists/busybox/2007-February/026289.html
>
> Currently (latest svn version), I'm unable to upload files onto my
> busybox installation running busybox httpd.
>
> The problem is, that the `cat` command never finishes after it wrote
> the uploaded file successfully to the temporary location, that means
> uploading works, but after the upload has finished, `cat` doesn't quit.

Yes, it's a bug. Fix:

                xmove_fd(toCgi[0], 0);  /* replace stdin with the pipe */
                xmove_fd(fromCgi[1], 1);  /* replace stdout with the pipe */
                close(fromCgi[0]);
-               close(fromCgi[1]);
+               close(toCgi[1]);

We were leaving toCgi[1] open, and when parent was closing it,
we still had another copy of open file descriptor. read()
inside cat does not return "0 bytes read (EOF)", but blocks,
waiting for more data.

Can you confirm that this fix works for you?
--
vda

From vda.linux at googlemail.com  Sat Aug 11 13:14:19 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sat, 11 Aug 2007 21:14:19 +0100
Subject: [PATCH] httpd: Support "Status: " header in CGI script
In-Reply-To: <937796.3923.qm@web62503.mail.re1.yahoo.com>
References: <937796.3923.qm@web62503.mail.re1.yahoo.com>
Message-ID: <200708112114.19874.vda.linux@googlemail.com>

On Wednesday 08 August 2007 13:09, Alex Landau wrote:
> Hi,
>
> The attached patch adds to httpd support for a Status header.
> This header (as per the CGI spec) is used by CGI scripts to ask the server
> to send an HTTP response different than 200. Why is it needed, and why the
> script can't send the "HTTP/1.0 302 Found" (or similar) by itself is beyond
> me...
> PHP (at least in CGI mode) sends "Status: 302" and the appropriate Location
> when running header('Location: something'). That was my motivation for the
> patch.
>
> Due to efficiency and space considerations, when httpd receives a "Status:
> xxx" header it sends "HTTP/1.0 xxx" without the textual code representation
> (e.g. "HTTP/1.0 302" instead of "HTTP/1.0 302 Found"). This works at least
> with Firefox 2.0.0.6 on Linux and IE 6 on, well..., Windows.
> If you think it's worth it, I can add proper message ("Found" etc.)
> handling.

I committed a bit simpler version:


        /* "Status" header format is: "Status: 302 Redirected\r\n" */
        if (buf_count >= 8 && memcmp(rbuf, "Status: ", 8) == 0) {
                /* send "HTTP/1.0 " */
                if (full_write(s, HTTP_200, 9) != 9)
                        break;
                rbuf += 8; /* skip "Status: " */
                count = buf_count - 8;
                buf_count = -1; /* buffering off */
        } else if (buf_count >= 4) {

Can you test whether it works for you?
--
vda

From landau_alex at yahoo.com  Sat Aug 11 22:28:56 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Sat, 11 Aug 2007 22:28:56 -0700 (PDT)
Subject: [PATCH] httpd: Support "Status: " header in CGI script
In-Reply-To: <200708112114.19874.vda.linux@googlemail.com>
Message-ID: <3603.62218.qm@web62513.mail.re1.yahoo.com>


--- Denys Vlasenko <vda.linux at googlemail.com> wrote:

> On Wednesday 08 August 2007 13:09, Alex Landau wrote:
> > Hi,
> >
> > The attached patch adds to httpd support for a Status header.
> > This header (as per the CGI spec) is used by CGI scripts to ask the server
> > to send an HTTP response different than 200. Why is it needed, and why the
> > script can't send the "HTTP/1.0 302 Found" (or similar) by itself is beyond
> > me...
> > PHP (at least in CGI mode) sends "Status: 302" and the appropriate Location
> > when running header('Location: something'). That was my motivation for the
> > patch.
> >
> > Due to efficiency and space considerations, when httpd receives a "Status:
> > xxx" header it sends "HTTP/1.0 xxx" without the textual code representation
> > (e.g. "HTTP/1.0 302" instead of "HTTP/1.0 302 Found"). This works at least
> > with Firefox 2.0.0.6 on Linux and IE 6 on, well..., Windows.
> > If you think it's worth it, I can add proper message ("Found" etc.)
> > handling.
> 
> I committed a bit simpler version:
> 
> 
>         /* "Status" header format is: "Status: 302 Redirected\r\n" */
>         if (buf_count >= 8 && memcmp(rbuf, "Status: ", 8) == 0) {
>                 /* send "HTTP/1.0 " */
>                 if (full_write(s, HTTP_200, 9) != 9)
>                         break;
>                 rbuf += 8; /* skip "Status: " */
>                 count = buf_count - 8;
>                 buf_count = -1; /* buffering off */
>         } else if (buf_count >= 4) {
> 
> Can you test whether it works for you?
> --
> vda
> 

Yes it does.
Thanks,
Alex


       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

From vda.linux at googlemail.com  Sun Aug 12 12:37:36 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 12 Aug 2007 20:37:36 +0100
Subject: Patch for broken xbind in ping.c [busybox 1.6.1]
In-Reply-To: <46BD7A69.60407@perlgolf.de>
References: <46BD7A69.60407@perlgolf.de>
Message-ID: <200708122037.36905.vda.linux@googlemail.com>

On Saturday 11 August 2007 09:59, Nico Erfurth wrote:
> Hi,
>
> networking/ping.c seems to be broken for some time now. When  used with
> the -I option, it tries to bind to the address in lsa, instead of
> source_lsa. Well, this won't work unless you ping your own machine. ;)
>
> Appended is a patch to fix that, I've tested it with ipv4 only.
> It seems like the bug was introduced with this revision:
> http://busybox.net/cgi-bin/viewcvs.cgi?rev=17842&view=rev

It's already fixed in svn.
--
vda

From vda.linux at googlemail.com  Sun Aug 12 13:47:41 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 12 Aug 2007 21:47:41 +0100
Subject: Rewritten autoconf and build directory
In-Reply-To: <1186681343.4744.78.camel@Blue2net-mats.bellman.mea>
References: <1186681343.4744.78.camel@Blue2net-mats.bellman.mea>
Message-ID: <200708122147.41676.vda.linux@googlemail.com>

On Thursday 09 August 2007 18:42, Mats Erik Andersson wrote:
> Hello all,
>
> I stumbled on a possible issue with today's
> svn edition of Busybox. There was no problem
> whatsoever to build Busybox 1.6.1 fresh out of the
> box into a separate build directory, but when I tried
> the same with svn trunk of today, the changed autoconf
> handling gives a warning and then an error is caused
> by applets/usage.c and include/applets.h, thus breaking
> an chance of progress early on. I am not sure whether the
> fault is mine or not, but I thought it best to point
> it out anyway. I will revert to 1.6.1 for the moment,
> since I have no time to spare in the near future.

applets/usage.c:

-#include "autoconf.h"
+/* Just #include "autoconf.h" doesn't work for builds in separate
+ * object directory */
+#include "../include/autoconf.h"

Fixed in svn. Can you verify that this one was your problem?
--
vda

From vda.linux at googlemail.com  Sun Aug 12 13:53:31 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 12 Aug 2007 21:53:31 +0100
Subject: [PATCH] - httpd: support for kernel sendfile() call
In-Reply-To: <200708101541.19945.genepi@sympatico.ca>
References: <200708101541.19945.genepi@sympatico.ca>
Message-ID: <200708122153.31606.vda.linux@googlemail.com>

On Friday 10 August 2007 20:41, Pierre M?tras wrote:
> Hi,
>
> Here is a small patch to enable the use of the linux kernel function
> sendfile() in the httpd server (the last remaining TODO in
> network/httpd.c). This is enabled by a configuration option, disabled by
> default.

It's not totally flawless but not that bad either.

        f = open(url, O_RDONLY);
        if (f >= 0) {
+               sendHeaders(HTTP_OK);
+               int fd = accepted_socket;

You mix up statements and declarations. Busybox build system issues warnings.

+               if (fd == 0) fd++; /* write to fd #1 in inetd mode */
+#if ENABLE_FEATURE_HTTPD_USE_SENDFILE
+               struct stat f_stat;
+               if (fstat(f, &f_stat)) {
+                       bb_perror_msg("cannot stat file '%s'", url);
+               }
+               off_t offset = 0;
+               sendfile(fd, f, &offset, f_stat.st_size);

What will happen if f_stat.st_size > INT_MAX (2 gb) ?

+#else
                int count;
                char *buf = iobuf;
-
-               sendHeaders(HTTP_OK);
-               /* TODO: sendfile() */
                while ((count = full_read(f, buf, MAX_MEMORY_BUFF)) > 0) {
-                       int fd = accepted_socket;
-                       if (fd == 0) fd++; /* write to fd# 1 in inetd mode */
                        if (full_write(fd, buf, count) != count)
                                break;
                }
+#endif
                close(f);

I applied it with some changes, please test current svn.

Thanks!
--
vda

From vda.linux at googlemail.com  Sun Aug 12 14:13:55 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 12 Aug 2007 22:13:55 +0100
Subject: [PATCH] httpd - User defined error pages
In-Reply-To: <200708101542.39107.genepi@sympatico.ca>
References: <200708101542.39107.genepi@sympatico.ca>
Message-ID: <200708122213.55773.vda.linux@googlemail.com>

On Friday 10 August 2007 20:42, Pierre M?tras wrote:
> Here is the third revision of my patch to add support for user defined
> error pages in httpd. I've integrated most of the comments from Denis
> Vlasenko, but one. During development, I was surprised to get a larger
> executable. The parse_conf() function got the biggest code size increase.
>
> After a few tests, it seems the culprit is the suggested bb_strtoi() call.
> The following line adds 97 bytes (on PIV with gcc):
> 	int status = bb_strtoi(p0 + 1, &p0, 10)
> function                                             old     new   delta
> parse_conf                                          1201    1448    +247
>
> compared with originally:
> 	c = strchr(++p0, ':');
> 	*c = 0;
> 	int status = xatoi(p0);
> 	p0 = ++c;
> function                                             old     new   delta
> parse_conf                                          1201    1337    +136
>
> I couldn't explain why such a difference...
>
> This patch includes:
> - Support for definition of error pages in httpd.conf (it was the main
> goal!). This is enabled by a configuration option, default no.
> - Reports of simple errors in httpd.conf when they are detected. It does
> not check that the error page exists. Reports of memory exhausted.

Please rediff against current svn and resend. Unfortunately it collides with
your other patch (sendfile support) which I just applied with changes.

> - Support for comments and empty lines in httpd.conf. End of line comments
> where already supported and not documented.

Can you submit it as separate patch? (Two patches in one mail is ok with me).

Review:


-static const HttpEnumString httpResponseNames[] = {
-       { HTTP_OK, "OK", NULL },
-       { HTTP_MOVED_TEMPORARILY, "Found", "Directories must end with a slash." },
+static SKIP_FEATURE_HTTPD_ERROR_PAGES(const) HttpEnumString httpResponseNames[] = {
+       { HTTP_OK, "OK", NULL USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },
+       { HTTP_MOVED_TEMPORARILY, "Found", "Directories must end with a slash." USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },
                                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
IIRC you can simply omit NULL/0 trailing members in struct initializer.
Will look much less ugly here.


@@ -488,22 +508,30 @@
 #endif
        /* This could stand some work */
        while ((p0 = fgets(buf, sizeof(buf), f)) != NULL) {
+               /* Comments: '#' as first character of the line */
+               if (*p0 == '#' || *p0 == '\n')
+                       continue;
+               
                c = NULL;
                for (p = p0; *p0 != 0 && *p0 != '#'; p0++) {
                        if (!isspace(*p0)) {
                                *p++ = *p0;
                                if (*p0 == ':' && c == NULL)
-                               c = p;
+                                       c = p;
                        }
                }
                *p = 0;
 
-               /* test for empty or strange line */
-               if (c == NULL || *c == 0)
+               /* test for empty or strange line
+                  ':' is present on all syntaxes 
+                  and c points at the char after it */
+               if (c == NULL || *c == 0) {
+                       bb_error_msg("config error '%s' in '%s'", buf, cf);
                        continue;
+               }
                p0 = buf;
                if (*p0 == 'd')
-                               *p0 = 'D';
+                       *p0 = 'D';
                if (*c == '*') {
                        if (*p0 == 'D') {
                                /* memorize deny all */
@@ -515,18 +543,6 @@
 
                if (*p0 == 'a')
                        *p0 = 'A';
-               else if (*p0 != 'D' && *p0 != 'A'
-#if ENABLE_FEATURE_HTTPD_BASIC_AUTH
-                        && *p0 != '/'
-#endif
-#if ENABLE_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES
-                        && *p0 != '.'
-#endif
-#if ENABLE_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR
-                        && *p0 != '*'
-#endif
-                       )
-                        continue;
                if (*p0 == 'A' || *p0 == 'D') {
                        /* storing current config IP line */
                        pip = xzalloc(sizeof(Htaccess_IP));

Above two hunks are not immediately obvious. What do they do?
If it's unrelated to error pages support, submit separately.
--
vda

From vda.linux at googlemail.com  Sun Aug 12 14:20:44 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 12 Aug 2007 22:20:44 +0100
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not moved
	forward
In-Reply-To: <413FEEF1743111439393FB76D0221E4807C8B2EE@leopard.zoo.q9networks.com>
References: <413FEEF1743111439393FB76D0221E4807C8B2EE@leopard.zoo.q9networks.com>
Message-ID: <200708122220.44407.vda.linux@googlemail.com>

On Thursday 09 August 2007 21:04, Jari Takkala wrote:
> Hello,
>
> The following patch fixes the circular log buffer in syslogd. Currently the
> head pointer is never moved forward. The 'logread' command will always read
> from the beginning of the buffer, even if the log buffer wraps.
>
> The head pointer is not moved forward because it is 0 by default, so the
> comparison (old_tail < shbuf->head) never evaluates to true.
>
> I have only been able to test this patch on Busybox 1.4.2. I've included a
> patch for 1.6.0 as well, if someone would please test and commit it. Thank
> you!
>
> --- busybox-1.6.1/sysklogd/syslogd.c	2007-06-30 11:06:35.000000000 -0400
> +++ busybox-1.6.1/sysklogd/syslogd.c	2007-08-09 15:16:33.000000000 -0400
> @@ -253,7 +253,7 @@
>  	if (new_tail < G.shbuf->size) {
>  		/* No need to move head if shbuf->head <= old_tail,
>  		 * else... */
> -		if (old_tail < G.shbuf->head && G.shbuf->head <= new_tail) {
> +		if (old_tail <= G.shbuf->head && G.shbuf->head <= new_tail) {
>  			/* ...need to move head forward */
>  			c = memchr(G.shbuf->data + new_tail, '\0',
>  					   G.shbuf->size - new_tail);

Unfortunately, this fix is incorrect. If tail == head, it means
that log buffer is empty and head should NOT be moved forward.

I spent an hour looking at this unholy mess of IPC shared buffer
which I don't like one iota. Oh well.

While I know how to fix it properly as-is, I'm in for more radical surgery.
head pointer is nuked, as it is used precisely in one place.

Please take a look at current svn. I tested and it works for me,
but extra testing is always good.

If it doesn't work, describe how I can reproduce it.
--
vda

From farmatito at tiscali.it  Sun Aug 12 15:34:43 2007
From: farmatito at tiscali.it (Tito)
Date: Mon, 13 Aug 2007 00:34:43 +0200
Subject: [PATCH] new expand / unexpand applets
Message-ID: <200708130034.43994.farmatito@tiscali.it>

Hi to all,
this patch adds 2 new applets to coreutils: expand and unexpand
They are turned off by default and can be turned on independently.
There are also some tests added to the testsuite to ensure
that they work like their GNU counterparts.
The applets are tested but more testing by the community would not be bad. 
Hints, improvements, optimizations and critics are wellcome.

bloat-o-meter says:
1) busybox defconfig + expand (with long opts)
function                                             old     new   delta
expand_main                                            -     456    +456
.rodata                                           120397  120525    +128
packed_usage                                       22558   22660    +102
xputchar                                               -      25     +25
static.expand_longopts                                 -      18     +18
applets                                             3108    3120     +12
------------------------------------------------------------------------------
(add/remove: 3/0 grow/shrink: 3/0 up/down: 741/0)             Total: 741 bytes

2)  busybox defconfig + unexpand (with long opts)
function                                             old     new   delta
expand_main                                            -     554    +554
.rodata                                           120397  120557    +160
packed_usage                                       22558   22652     +94
static.unexpand_longopts                               -      27     +27
xputchar                                               -      25     +25
applets                                             3108    3120     +12
------------------------------------------------------------------------------
(add/remove: 3/0 grow/shrink: 3/0 up/down: 872/0)             Total: 872 bytes

3)  busybox defconfig + expand (with long opts) + unexpand (with long opts)
function                                             old     new   delta
expand_main                                            -     772    +772
.rodata                                           120397  120621    +224
packed_usage                                       22558   22717    +159
static.unexpand_longopts                               -      27     +27
xputchar                                               -      25     +25
applets                                             3108    3132     +24
static.expand_longopts                                 -      18     +18
------------------------------------------------------------------------------
(add/remove: 4/0 grow/shrink: 3/0 up/down: 1249/0)           Total: 1249 bytes

3)  busybox defconfig + expand (without long opts) + unexpand (without long opts)
function                                             old     new   delta
expand_main                                            -     752    +752
.rodata                                           120397  120589    +192
packed_usage                                       22558   22717    +159
xputchar                                               -      25     +25
applets                                             3108    3132     +24
------------------------------------------------------------------------------
(add/remove: 2/0 grow/shrink: 3/0 up/down: 1152/0)           Total: 1152 bytes


Ciao,
Tito
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expand_unexpand.patch
Type: text/x-diff
Size: 12501 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070813/3d74aae9/attachment-0001.bin 

From busybox at lists.lammerts.org  Sun Aug 12 16:42:54 2007
From: busybox at lists.lammerts.org (Eric Lammerts)
Date: Sun, 12 Aug 2007 19:42:54 -0400
Subject: [PATCH] - httpd: support for kernel sendfile() call
In-Reply-To: <200708122153.31606.vda.linux@googlemail.com>
References: <200708101541.19945.genepi@sympatico.ca>
	<200708122153.31606.vda.linux@googlemail.com>
Message-ID: <46BF9AFE.20204@lists.lammerts.org>

Denys Vlasenko wrote:
> +               off_t offset = 0;
> +               sendfile(fd, f, &offset, f_stat.st_size);
> 
> What will happen if f_stat.st_size > INT_MAX (2 gb) ?

If busybox was compiled with large file support, both off_t and 
f_stat.st_size should be 64-bit, no? And if busybox was compiled without 
large file support, the open() would have failed already with EFBIG.

I noticed the return status of sendfile isn't checked at all, and that is 
bad. Sendfile fails with EINVAL on filesystems without mmap() support 
(for example unionfs), and in that case busybox should fall back to the 
old method. And I think sendfile() is also allowed to return with a value 
less than f_stat.st_size, but I'm not sure if that ever happens in practice.

Eric

From colin at realtek.com.tw  Mon Aug 13 01:35:43 2007
From: colin at realtek.com.tw (colin)
Date: Mon, 13 Aug 2007 16:35:43 +0800
Subject: e2fsprogs is missing and what should we do?
Message-ID: <03db01c7dd84$efe5e0f0$106215ac@realtek.com.tw>


Hi all,
I just moved busybox from 1.1.3 to 1.6.1. Yes, it's a very big advance.
After I almost finished it, I found that e2fsprogs is removed because it's
too bloated.
I really need it. How can I do with late busybox?
I've tried e2fsprogs in http://e2fsprogs.sourceforge.net/ and found that
e2fsck and mke2fs take about 700k.
They are much more bloated than those, which have been complained of being
bloated, in busybox 1.1.3.

Thanks and regards,
Colin


From vda.linux at googlemail.com  Mon Aug 13 03:54:36 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 13 Aug 2007 11:54:36 +0100
Subject: [PATCH] - httpd: support for kernel sendfile() call
In-Reply-To: <46BF9AFE.20204@lists.lammerts.org>
References: <200708101541.19945.genepi@sympatico.ca>
	<200708122153.31606.vda.linux@googlemail.com>
	<46BF9AFE.20204@lists.lammerts.org>
Message-ID: <200708131154.36375.vda.linux@googlemail.com>

On Monday 13 August 2007 00:42, Eric Lammerts wrote:
> Denys Vlasenko wrote:
> > +               off_t offset = 0;
> > +               sendfile(fd, f, &offset, f_stat.st_size);
> >
> > What will happen if f_stat.st_size > INT_MAX (2 gb) ?
>
> If busybox was compiled with large file support, both off_t and
> f_stat.st_size should be 64-bit, no? And if busybox was compiled without
> large file support, the open() would have failed already with EFBIG.

manpage disagrees with you. While offset is indeed a ptr to off_t,
byte count is not:

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
^^^^^^^                                                ^^^^^^^^^^^^

> I noticed the return status of sendfile isn't checked at all, and that is
> bad. Sendfile fails with EINVAL on filesystems without mmap() support
> (for example unionfs), and in that case busybox should fall back to the
> old method.

Implemented in current svn, but not tested.

> And I think sendfile() is also allowed to return with a value 
> less than f_stat.st_size, but I'm not sure if that ever happens in
> practice.

Yes it happens. I saw it yesterday.
Current svn loops until sendfile returns <= 0.
--
vda


From Jari.Takkala at Q9.com  Mon Aug 13 06:33:08 2007
From: Jari.Takkala at Q9.com (Jari Takkala)
Date: Mon, 13 Aug 2007 09:33:08 -0400
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not
	movedforward
In-Reply-To: <413FEEF1743111439393FB76D0221E4807C8B2EE@leopard.zoo.q9networks.com>
Message-ID: <413FEEF1743111439393FB76D0221E4807DBD618@leopard.zoo.q9networks.com>

On Thursday, August 09, 2007 4:04 PM, busybox-bounces at busybox.net wrote:
> Hello,
> 
> The following patch fixes the circular log buffer in syslogd.
> Currently the head pointer is never moved forward. The
> 'logread' command will always read from the beginning of the
> buffer, even if the log buffer wraps.

> I have only been able to test this patch on Busybox 1.4.2.
> I've included a patch for 1.6.0 as well, if someone would
> please test and commit it. Thank you!

Any comment on this patch?

Regards,

Jari

From vda.linux at googlemail.com  Mon Aug 13 06:55:28 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 13 Aug 2007 14:55:28 +0100
Subject: e2fsprogs is missing and what should we do?
In-Reply-To: <03db01c7dd84$efe5e0f0$106215ac@realtek.com.tw>
References: <03db01c7dd84$efe5e0f0$106215ac@realtek.com.tw>
Message-ID: <200708131455.28327.vda.linux@googlemail.com>

On Monday 13 August 2007 09:35, colin wrote:
> Hi all,
> I just moved busybox from 1.1.3 to 1.6.1. Yes, it's a very big advance.
> After I almost finished it, I found that e2fsprogs is removed because it's
> too bloated.
> I really need it. How can I do with late busybox?

Some parts are still present (chattr.c, lsattr.c, fsck).

You can take that part of old_e2fsprogs in busybox tree which you
really can't live without, put it back one directory higher,
debloating it in the process.

A lot of bitching about maintainers is optional part of exercise.

Then send a patch to bbox mailing list.
--
vda

From vda.linux at googlemail.com  Mon Aug 13 06:58:14 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 13 Aug 2007 14:58:14 +0100
Subject: [PATCH] new expand / unexpand applets
In-Reply-To: <200708130034.43994.farmatito@tiscali.it>
References: <200708130034.43994.farmatito@tiscali.it>
Message-ID: <200708131458.14857.vda.linux@googlemail.com>

On Sunday 12 August 2007 23:34, Tito wrote:
> Hi to all,
> this patch adds 2 new applets to coreutils: expand and unexpand
> They are turned off by default and can be turned on independently.
> There are also some tests added to the testsuite to ensure
> that they work like their GNU counterparts.
> The applets are tested but more testing by the community would not be bad.
> Hints, improvements, optimizations and critics are wellcome.

Applied with small changes.

This applet was tested to really report I/O errors on stdin and stdout
and can be considered an example how to properly do it.

Thanks!
--
vda

From vda.linux at googlemail.com  Mon Aug 13 07:47:19 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 13 Aug 2007 15:47:19 +0100
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not
	movedforward
In-Reply-To: <413FEEF1743111439393FB76D0221E4807DBD618@leopard.zoo.q9networks.com>
References: <413FEEF1743111439393FB76D0221E4807DBD618@leopard.zoo.q9networks.com>
Message-ID: <200708131547.19237.vda.linux@googlemail.com>

On Monday 13 August 2007 14:33, Jari Takkala wrote:
> On Thursday, August 09, 2007 4:04 PM, busybox-bounces at busybox.net wrote:
> > The following patch fixes the circular log buffer in syslogd.
> > Currently the head pointer is never moved forward. The
> > 'logread' command will always read from the beginning of the
> > buffer, even if the log buffer wraps.
> >
> > I have only been able to test this patch on Busybox 1.4.2.
> > I've included a patch for 1.6.0 as well, if someone would
> > please test and commit it. Thank you!
>
> Any comment on this patch?

A more radical solution is applied to svn. Can you test it?
--
vda

From Jari.Takkala at Q9.com  Mon Aug 13 08:08:42 2007
From: Jari.Takkala at Q9.com (Jari Takkala)
Date: Mon, 13 Aug 2007 11:08:42 -0400
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not
	movedforward
In-Reply-To: <200708131547.19237.vda.linux@googlemail.com>
Message-ID: <413FEEF1743111439393FB76D0221E4807DBD6BC@leopard.zoo.q9networks.com>

On Monday, August 13, 2007 10:47 AM, Denys Vlasenko wrote:

> A more radical solution is applied to svn. Can you test it?

Thank you Denys. I won't be able to test it though. We're still running 1.4.2 here and it may be a few months before we move to the latest stable code. I'm glad to know that it should be fixed once we move to it though. Thanks!

Jari

From vda.linux at googlemail.com  Mon Aug 13 12:29:57 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 13 Aug 2007 20:29:57 +0100
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not
	movedforward
In-Reply-To: <413FEEF1743111439393FB76D0221E4807DBD6BC@leopard.zoo.q9networks.com>
References: <413FEEF1743111439393FB76D0221E4807DBD6BC@leopard.zoo.q9networks.com>
Message-ID: <200708132029.57188.vda.linux@googlemail.com>

On Monday 13 August 2007 16:08, Jari Takkala wrote:
> On Monday, August 13, 2007 10:47 AM, Denys Vlasenko wrote:
> > A more radical solution is applied to svn. Can you test it?
>
> Thank you Denys. I won't be able to test it though. We're still running
> 1.4.2 here and it may be a few months before we move to the latest stable

you can build latest svn with only syslogd and logread,
while all other /bin/applet links are symlinked to "stable" busybox.

> code. I'm glad to know that it should be fixed once we move to it though.
> Thanks!
--
vda

From Jari.Takkala at Q9.com  Mon Aug 13 13:00:05 2007
From: Jari.Takkala at Q9.com (Jari Takkala)
Date: Mon, 13 Aug 2007 16:00:05 -0400
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not
	movedforward
In-Reply-To: <200708132029.57188.vda.linux@googlemail.com>
Message-ID: <413FEEF1743111439393FB76D0221E4807DBD83B@leopard.zoo.q9networks.com>

On Monday, August 13, 2007 3:30 PM, Denys Vlasenko wrote:
> 
> you can build latest svn with only syslogd and logread,
> while all other /bin/applet links are symlinked to "stable" busybox.

Don't know why I didn't think about that. :)

Ok, I tested it with the latest SVN trunk and the problem appears to be fixed.

On a related note, shouldn't the permissions for the shared memory segment be 755? I think currently any unprivileged user could overwrite the log buffer or edit log messages.

Jari

From vda.linux at googlemail.com  Mon Aug 13 13:12:46 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 13 Aug 2007 21:12:46 +0100
Subject: Please resend patches
Message-ID: <200708132112.46477.vda.linux@googlemail.com>

Hi people,

I finished moving to new place. I suspect that I missed some patches.
Never hesitate to resend them. ;)

Internet is not yet working in my new flat. Will take a few weeks.

Prices for accommodation in Dublin make me wonder whether my new salary
really _is_ big enough... :-/
--
vda

From vda.linux at googlemail.com  Tue Aug 14 03:11:28 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 14 Aug 2007 11:11:28 +0100
Subject: [PATCH] Fix syslogd circular log buffer: head pointer not
	movedforward
In-Reply-To: <413FEEF1743111439393FB76D0221E4807DBD83B@leopard.zoo.q9networks.com>
References: <413FEEF1743111439393FB76D0221E4807DBD83B@leopard.zoo.q9networks.com>
Message-ID: <200708141111.28774.vda.linux@googlemail.com>

On Monday 13 August 2007 21:00, Jari Takkala wrote:
> On Monday, August 13, 2007 3:30 PM, Denys Vlasenko wrote:
> > you can build latest svn with only syslogd and logread,
> > while all other /bin/applet links are symlinked to "stable" busybox.
>
> Don't know why I didn't think about that. :)
>
> Ok, I tested it with the latest SVN trunk and the problem appears to be
> fixed.
>
> On a related note, shouldn't the permissions for the shared memory segment
> be 755? I think currently any unprivileged user could overwrite the log
> buffer or edit log messages.

Yup.

-        G.shmid = shmget(KEY_ID, G.shm_size, IPC_CREAT | 1023);
+        G.shmid = shmget(KEY_ID, G.shm_size, IPC_CREAT | 0644);

That was really weird way to say "0777".
--
vda

From vda.linux at googlemail.com  Tue Aug 14 10:08:43 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 14 Aug 2007 18:08:43 +0100
Subject: e2fsprogs is missing and what should we do?
In-Reply-To: <042901c7de21$d5f1d030$106215ac@realtek.com.tw>
References: <03db01c7dd84$efe5e0f0$106215ac@realtek.com.tw>
	<200708131455.28327.vda.linux@googlemail.com>
	<042901c7de21$d5f1d030$106215ac@realtek.com.tw>
Message-ID: <200708141808.43874.vda.linux@googlemail.com>

On Tuesday 14 August 2007 04:18, colin wrote:
> > On Monday 13 August 2007 09:35, colin wrote:
> > > Hi all,
> > > I just moved busybox from 1.1.3 to 1.6.1. Yes, it's a very big advance.
> > > After I almost finished it, I found that e2fsprogs is removed because it's
> > > too bloated.
> > > I really need it. How can I do with late busybox?
> >
> > Some parts are still present (chattr.c, lsattr.c, fsck).
> >
> > You can take that part of old_e2fsprogs in busybox tree which you
> > really can't live without, put it back one directory higher,
> > debloating it in the process.
>
> I put old_e2fsprogs back and make again.
> It can almost work but at last a linking problem happens.

Well, simply copying them wouldn't work.

*debloating it in the process* is a key phrase.

> I've never seen this kind of errror message. The message is in the
> attachment.

It's a link map. Current svn is fixed so that link map
is not output along with error message.

The actual error is:

e2fsprogs/lib.a(fsck.o): In function `interpret_type':
fsck.c:(.text.interpret_type+0x44): undefined reference to `blkid_get_tag_value'
e2fsprogs/lib.a(fsck.o): In function `fsck_main':
fsck.c:(.text.fsck_main+0x94): undefined reference to `blkid_get_cache'
fsck.c:(.text.fsck_main+0x1c4): undefined reference to `blkid_get_devname'
fsck.c:(.text.fsck_main+0xb78): undefined reference to `blkid_get_devname'
fsck.c:(.text.fsck_main+0x1024): undefined reference to `blkid_put_cache'

--
vda

From tpkschme at engmail.uwaterloo.ca  Tue Aug 14 21:46:05 2007
From: tpkschme at engmail.uwaterloo.ca (Tristan Schmelcher)
Date: Tue, 14 Aug 2007 21:46:05 -0700
Subject: Patch for a better "more"
Message-ID: <1187153165.4806.202.camel@localhost>

Hello,

I recently used BusyBox extensively in an embedded device product and
ended up making some improvements to the "more" command. Attached is a
patch against BB 1.6.1. The changes are:

- Fixed a number of deficiencies in the line wrapping.
- Fixed a bug where the page could scroll multiple times per keypress.
(The fix is to only scroll on spacebar, as with other "more"
implementations. If an invalid character is pressed, we print a brief
usage message.)
- Made us re-read the terminal dimensions after user input, in case they
resized the terminal while we were waiting.
- Added an 'R' key to print the rest of the file without prompting.
- Made us crudely support tabs in the line-wrapping code by converting
them to 8 spaces (not great, but better than messing up the screen; make
it a compile-time option if you don't like it).

With this patch, the line-wrapping code now scrolls the screen correctly
for any combination of normal characters, newlines, and tabs. And I
think the change in code size is probably fairly small.

Enjoy. I hope to see this in the next release. :)

Thanks for the great program,

Tristan Schmelcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070814/1a450776/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-1.6.1-more-patch.diff
Type: text/x-patch
Size: 5025 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070814/1a450776/attachment.bin 

From copelco at gmail.com  Wed Aug 15 08:40:02 2007
From: copelco at gmail.com (Colin Copeland)
Date: Wed, 15 Aug 2007 11:40:02 -0400
Subject: crond, dropbear, remote script, capturing output
Message-ID: <4dc8f8080708150840k472f67d7gb29de2f805c9f990@mail.gmail.com>

Hello,

So I'm having trouble with dropbear and crond (part of busybox).
Basically, I'm having trouble scheduling an invocation of ssh with a
command for a remote machine and catching the output on the local
machine. I can manually invoke ssh with a command for a remote machine
and catch the output (e.g. using perl back tics and redirect <<) just
fine. In other words, I need a small embedded machine to periodically
ssh to my sever, run a script, and grep the output.

Below I tried two tests to catch output:
 1) Run a local script manually and in cron, both worked
 2) ssh and run a script manually and in cron -- doesn't work in cron

===== Local script: =====

-- without crond --

client$ cat /root/say_hello.sh
#!/bin/sh
echo "hello"
client$ /root/say_hello.sh >>/mnt/ramdisk/hello.log 2>>/mnt/ramdisk/hello.err
client$ cat /mnt/ramdisk/hello.err
client$ cat /mnt/ramdisk/hello.log
hello

-- with crond --

client$ cat /etc/crontab
* * * * *  /root/say_hello.sh >>/mnt/ramdisk/hello.log
2>>/mnt/ramdisk/hello.err
-- 1 minute later --
client$ cat /mnt/ramdisk/hello.err
client$ cat /mnt/ramdisk/hello.log
hello

WORKS!

===== Remote script: =====

A script on my server, /home/infobomb/say_hello.sh, also echo's "hello".

-- without crond --

client$ /usr/bin/ssh -i /root/.ssh/eeapnode1.rsa
infobomb at my.server.edu "/home/infobomb/say_hello.sh"
>>/mnt/ramdisk/hello.log 2>>/mnt/ramdisk/hello.err
client$ cat /mnt/ramdisk/hello.err
client$ cat /mnt/ramdisk/hello.log
hello

-- with crond --

client$ cat /etc/crontab
* * * * * /usr/bin/ssh -i /root/.ssh/eeapnode1.rsa
infobomb at my.server.edu "/home/infobomb/say_hello.sh"
>>/mnt/ramdisk/hello.log 2>>/mnt/ramdisk/hello.err
-- 1 minute later --
client$ cat /mnt/ramdisk/hello.err
client$ cat /mnt/ramdisk/hello.log

EMPTY

Just in case, I edited my server side script to write to a temporary
file whenever it's accessed. The remote script with crond successfully
accessed the file, but nothing was ever grep'd from the output (as
hello.log is always empty).

Anyways, not sure where to go from here. This seems to be a problem
associated with dropbear too, because it works in openssh on my linux
desktop.

Any ideas?

  colin

From genepi at sympatico.ca  Wed Aug 15 13:19:44 2007
From: genepi at sympatico.ca (Pierre =?iso-8859-15?q?M=E9tras?=)
Date: Wed, 15 Aug 2007 16:19:44 -0400
Subject: [PATCH] httpd - User defined error pages
In-Reply-To: <200708122213.55773.vda.linux@googlemail.com>
References: <200708101542.39107.genepi@sympatico.ca>
	<200708122213.55773.vda.linux@googlemail.com>
Message-ID: <200708151619.44686.genepi@sympatico.ca>

Hi Denis,

> > This patch includes:
> > - Support for definition of error pages in httpd.conf (it was the main
> > goal!). This is enabled by a configuration option, default no.
> > - Reports of simple errors in httpd.conf when they are detected. It does
> > not check that the error page exists. Reports of memory exhausted.
>
> Please rediff against current svn and resend. Unfortunately it collides
> with your other patch (sendfile support) which I just applied with changes.


Before I reapply the patch to the current SVN sources and do some changes, I 
want to answer your concerns about the changes:

> > - Support for comments and empty lines in httpd.conf. End of line
> > comments where already supported and not documented.
>
> Can you submit it as separate patch? (Two patches in one mail is ok with
> me).

20-30% of the changes in the patch file are about reformating of the code 
(missing tab after a {-less if) or adding comments to document the code. Full 
support for comments in httpd.conf is only 4 extra lines, after I discovered 
that this feature was already implemented but not documented.
Syntax error messages are also 2 added lines...

>
> Review:
>
> -static const HttpEnumString httpResponseNames[] = {
> -       { HTTP_OK, "OK", NULL },
> -       { HTTP_MOVED_TEMPORARILY, "Found", "Directories must end with a
> slash." }, +static SKIP_FEATURE_HTTPD_ERROR_PAGES(const) HttpEnumString
> httpResponseNames[] = { +       { HTTP_OK, "OK", NULL
> USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) }, +       { HTTP_MOVED_TEMPORARILY,
> "Found", "Directories must end with a slash."
> USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ IIRC you can simply omit NULL/0
> trailing members in struct initializer. Will look much less ugly here.

I know, but without the USE_FEATURE_HTTPD_ERROR_PAGES macro, we could have 
compilation error (best case) or bugs in the future if someone adds a new 
member to the struct. That's the reason I've used it, but I can remove it 
from the patch if you want...

>
>
> @@ -488,22 +508,30 @@
>  #endif
>         /* This could stand some work */
>         while ((p0 = fgets(buf, sizeof(buf), f)) != NULL) {
> +               /* Comments: '#' as first character of the line */
> +               if (*p0 == '#' || *p0 == '\n')
> +                       continue;
> +

The 4 lines talked about before, for comment lines.

>                 c = NULL;
>                 for (p = p0; *p0 != 0 && *p0 != '#'; p0++) {
>                         if (!isspace(*p0)) {
>                                 *p++ = *p0;
>                                 if (*p0 == ':' && c == NULL)
> -                               c = p;
> +                                       c = p;

Reformating the source...

>                         }
>                 }
>                 *p = 0;
>
> -               /* test for empty or strange line */
> -               if (c == NULL || *c == 0)
> +               /* test for empty or strange line
> +                  ':' is present on all syntaxes
> +                  and c points at the char after it */
> +               if (c == NULL || *c == 0) {
> +                       bb_error_msg("config error '%s' in '%s'", buf, cf);
>                         continue;
> +               }

A better syntax error message when an error is discovered in httpd.conf 
instead of silently ignoring it.

>                 p0 = buf;
>                 if (*p0 == 'd')
> -                               *p0 = 'D';
> +                       *p0 = 'D';
>                 if (*c == '*') {
>                         if (*p0 == 'D') {
>                                 /* memorize deny all */
> @@ -515,18 +543,6 @@
>
>                 if (*p0 == 'a')
>                         *p0 = 'A';
> -               else if (*p0 != 'D' && *p0 != 'A'
> -#if ENABLE_FEATURE_HTTPD_BASIC_AUTH
> -                        && *p0 != '/'
> -#endif
> -#if ENABLE_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES
> -                        && *p0 != '.'
> -#endif
> -#if ENABLE_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR
> -                        && *p0 != '*'
> -#endif
> -                       )
> -                        continue;

These checks are already done later in the code, so I think we can safely 
remove them. In that block, we are parsing the Allow/Deny lines, and we don't 
need to check for the other type of lines (MIME types, user authorizations, 
etc).

>                 if (*p0 == 'A' || *p0 == 'D') {
>                         /* storing current config IP line */
>                         pip = xzalloc(sizeof(Htaccess_IP));
>
> Above two hunks are not immediately obvious. What do they do?
> If it's unrelated to error pages support, submit separately.
> --
> vda

In the end, my patch was 80% about support for error pages, and 20% about 
adding comments/documentation/reformating of the code.
Do you prefer splitted patches: one for error pages strictly, one for 
comments, one for reformated source?

-- Pierre M?tras

From akennedy at techmoninc.com  Wed Aug 15 13:16:51 2007
From: akennedy at techmoninc.com (Andy Kennedy)
Date: Wed, 15 Aug 2007 15:16:51 -0500
Subject: kexec in Busybox
Message-ID: <46C35F33.4080401@techmoninc.com>

After doing a quick look in the BusyBox archives, I didn't see if anyone 
has ever asked:

Is there plans to add (or has it been added) kexec in busybox?

Sorry if I missed something,
Andy

From vda.linux at googlemail.com  Wed Aug 15 13:30:06 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 15 Aug 2007 21:30:06 +0100
Subject: Patch for a better "more"
In-Reply-To: <1187153165.4806.202.camel@localhost>
References: <1187153165.4806.202.camel@localhost>
Message-ID: <200708152130.06416.vda.linux@googlemail.com>

On Wednesday 15 August 2007 05:46, Tristan Schmelcher wrote:
> Hello,
>
> I recently used BusyBox extensively in an embedded device product and
> ended up making some improvements to the "more" command. Attached is a
> patch against BB 1.6.1. The changes are:
>
> - Fixed a number of deficiencies in the line wrapping.
> - Fixed a bug where the page could scroll multiple times per keypress.
> (The fix is to only scroll on spacebar, as with other "more"
> implementations. If an invalid character is pressed, we print a brief
> usage message.)
> - Made us re-read the terminal dimensions after user input, in case they
> resized the terminal while we were waiting.
> - Added an 'R' key to print the rest of the file without prompting.
> - Made us crudely support tabs in the line-wrapping code by converting
> them to 8 spaces (not great, but better than messing up the screen; make
> it a compile-time option if you don't like it).
>
> With this patch, the line-wrapping code now scrolls the screen correctly
> for any combination of normal characters, newlines, and tabs. And I
> think the change in code size is probably fairly small.
>
> Enjoy. I hope to see this in the next release. :)

Applied, thanks!
--
vda

From vda.linux at googlemail.com  Wed Aug 15 13:33:54 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 15 Aug 2007 21:33:54 +0100
Subject: crond, dropbear, remote script, capturing output
In-Reply-To: <4dc8f8080708150840k472f67d7gb29de2f805c9f990@mail.gmail.com>
References: <4dc8f8080708150840k472f67d7gb29de2f805c9f990@mail.gmail.com>
Message-ID: <200708152133.54216.vda.linux@googlemail.com>

On Wednesday 15 August 2007 16:40, Colin Copeland wrote:
> Hello,
>
> So I'm having trouble with dropbear and crond (part of busybox).
> Basically, I'm having trouble scheduling an invocation of ssh with a
> command for a remote machine and catching the output on the local
> machine. I can manually invoke ssh with a command for a remote machine
> and catch the output (e.g. using perl back tics and redirect <<) just
> fine. In other words, I need a small embedded machine to periodically
> ssh to my sever, run a script, and grep the output.
>
> Below I tried two tests to catch output:
>  1) Run a local script manually and in cron, both worked
>  2) ssh and run a script manually and in cron -- doesn't work in cron

consider running ssh in cron under strace:

strace -f -o /tmp/ssh.log ssh ....

Wild guess: ssh tries to open controlling tty ("/dev/tty")
which doesn't work in cron.

--
vda

From vda.linux at googlemail.com  Thu Aug 16 04:20:53 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 16 Aug 2007 12:20:53 +0100
Subject: [patch] busybox kill strings.h include
In-Reply-To: <20070815164103.GD18069@stro.at>
References: <20070815164103.GD18069@stro.at>
Message-ID: <200708161220.53562.vda.linux@googlemail.com>

On Wednesday 15 August 2007 17:41, maximilian attems wrote:
> klibc has no strings.h and to quote hpa:
> "Including <strings.h> is a bug in the upstream source;
> <strings.h> has been obsolete since at least 1989"
>
>
> Index: e2fsprogs/old_e2fsprogs/ext2fs/bitops.h
> ===================================================================
> --- e2fsprogs/old_e2fsprogs/ext2fs/bitops.h	(revision 19515)
> +++ e2fsprogs/old_e2fsprogs/ext2fs/bitops.h	(working copy)
> @@ -15,7 +15,6 @@
>   */
>
>  #include <string.h>
> -#include <strings.h>
>
>  extern int ext2fs_set_bit(unsigned int nr,void * addr);
>  extern int ext2fs_clear_bit(unsigned int nr, void * addr);
> Index: include/libbb.h
> ===================================================================
> --- include/libbb.h	(revision 19515)
> +++ include/libbb.h	(working copy)
> @@ -26,7 +26,6 @@
>  #include <stdarg.h>
>  #include <stddef.h>
>  #include <string.h>
> -#include <strings.h>
>  #include <sys/ioctl.h>
>  #include <sys/mman.h>
>  #include <sys/socket.h>

Done, thanks.
--
vda

From vda.linux at googlemail.com  Thu Aug 16 04:23:57 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 16 Aug 2007 12:23:57 +0100
Subject: [PATCH] httpd - User defined error pages
In-Reply-To: <200708151619.44686.genepi@sympatico.ca>
References: <200708101542.39107.genepi@sympatico.ca>
	<200708122213.55773.vda.linux@googlemail.com>
	<200708151619.44686.genepi@sympatico.ca>
Message-ID: <200708161223.57533.vda.linux@googlemail.com>

On Wednesday 15 August 2007 21:19, Pierre M?tras wrote:
> In the end, my patch was 80% about support for error pages, and 20% about
> adding comments/documentation/reformating of the code.
> Do you prefer splitted patches: one for error pages strictly, one for
> comments, one for reformated source?

Yes. You can mail them separately or as one email with three attachments, 
whichever is more convenient to you.
--
vda

From genepi at sympatico.ca  Thu Aug 16 07:01:52 2007
From: genepi at sympatico.ca (Pierre =?iso-8859-15?q?M=E9tras?=)
Date: Thu, 16 Aug 2007 10:01:52 -0400
Subject: How to debug httpd?
In-Reply-To: <200708161223.57533.vda.linux@googlemail.com>
References: <200708101542.39107.genepi@sympatico.ca>
	<200708151619.44686.genepi@sympatico.ca>
	<200708161223.57533.vda.linux@googlemail.com>
Message-ID: <200708161001.53103.genepi@sympatico.ca>

Hi,

I've found a strange behavior in httpd, from current SVN version, but I don't 
know how to debug it.

When you run httpd with the new verbose -v option, it shows you the headers 
sent back to the client. From time to time, and probably depending on the 
browser used, httpd sends an extra 404 response.

For instance, in the following session example, I requested an existing page 
which was successfully displayed in FireFox (HTTPD status 200 OK + extra 
404), and then requested to view the content of httpd.conf (HTTPD status 403 
forbidden + extra 404). Then I requested again the existing page twice and 
got two 404 instead of 200!

$ ./busybox httpd -v -f -c httpd.conf -p 9090
127.0.0.1:39080 response:200	<-- test.html
127.0.0.1:39081 response:404
127.0.0.1:39089 response:403	<-- httpd.conf
127.0.0.1:39090 response:404
127.0.0.1:39091 response:404	<-- test.html
127.0.0.1:39092 response:404	<-- test.html

If I trace the browser-server dialog with telnet, everything is fine:
$ telnet localhost 9090
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.html HTTP/1.0

HTTP/1.0 200 OK
Content-type: text/html
Date: Thu, 16 Aug 2007 13:53:49 GMT
Connection: close
Last-Modified: Thu, 16 Aug 2007 11:45:13 GMT
Content-length: 83

<html><head><title>TEST</title></head>
<body><h1>?a fonctionne!</h1></body></html>
Connection closed by foreign host.


It looks like an extra child process is created which generates the 404.
As I'm not a gdb guru, I can find a way to put a breakpoint on the 
sendHeaders() function and explore the context of the call: I set the 
breakpoint but the thread of execution doesn't stop on it.

Could someone explain me how to debug this or correct this bug before I upload 
my patch for custom error pages?

Thanks

-- Pierre M?tras

From vda.linux at googlemail.com  Thu Aug 16 07:06:26 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 16 Aug 2007 15:06:26 +0100
Subject: Mysterious code in httpd.c
Message-ID: <200708161506.26909.vda.linux@googlemail.com>

Hi people,

In handle_incoming_and_exit() we used to do this
just before exit:

        /* Properly wait for remote to closed */
        int retval;
        shutdown(accepted_socket, SHUT_WR);
        do {
                fd_set s_fd;
                struct timeval tv;
                FD_ZERO(&s_fd);
                FD_SET(accepted_socket, &s_fd);
                tv.tv_sec = 2;
                tv.tv_usec = 0;
                retval = select(accepted_socket + 1, &s_fd, NULL, NULL, &tv);
        } while (retval > 0 && read(accepted_socket, iobuf, sizeof(iobuf) > 0));
        shutdown(accepted_socket, SHUT_RD);
        close(accepted_socket);
        exit(0);

Apparently we first inform peer that we are not going to write anything
anymore, and then we drain any remaining input.

Question - why is this needed? What bad things can happen if we just exit(0)
without doing all this?

For the time being, I commented it out.
--
vda

From s.avtar at gmail.com  Thu Aug 16 07:37:45 2007
From: s.avtar at gmail.com (Avtar Singh)
Date: Thu, 16 Aug 2007 20:07:45 +0530
Subject: tftp client error
Message-ID: <f19fadc60708160737q346a317dkd90d99f12d5d5fe8@mail.gmail.com>

Hello,

I have busybox 1.6.0 running on an embedded system powered by i.MX21
(ARM9 core) and running Kernel vanilla 2.6.22 with a few board
specific patches. I can do a tftp get from my desktop system connected
to the embedded board without any issues. However, tftp put throws up
the following error repeatedly:

# tftp -p -l sm.txt 222.222.101.117
tftp: server error: (1) File not found

The file is located in the root directory and I am issuing the command
from the root directory.

I have tried several versions (below) but all result in the same error:

# tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117

# tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117, ensuring that
there is a sm.txt in the server tftpboot directory.

Is my usage correct? Is "put" buggy in busybox-tftp?

Thanks,
Avtar

From vda.linux at googlemail.com  Thu Aug 16 10:59:17 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 16 Aug 2007 18:59:17 +0100
Subject: How to debug httpd?
In-Reply-To: <200708161001.53103.genepi@sympatico.ca>
References: <200708101542.39107.genepi@sympatico.ca>
	<200708161223.57533.vda.linux@googlemail.com>
	<200708161001.53103.genepi@sympatico.ca>
Message-ID: <200708161859.17690.vda.linux@googlemail.com>

On Thursday 16 August 2007 15:01, Pierre M?tras wrote:
> Hi,
>
> I've found a strange behavior in httpd, from current SVN version, but I
> don't know how to debug it.
>
> When you run httpd with the new verbose -v option, it shows you the headers
> sent back to the client. From time to time, and probably depending on the
> browser used, httpd sends an extra 404 response.
>
> For instance, in the following session example, I requested an existing
> page which was successfully displayed in FireFox (HTTPD status 200 OK +
> extra 404), and then requested to view the content of httpd.conf (HTTPD
> status 403 forbidden + extra 404). Then I requested again the existing page
> twice and got two 404 instead of 200!
>
> $ ./busybox httpd -v -f -c httpd.conf -p 9090
> 127.0.0.1:39080 response:200	<-- test.html
> 127.0.0.1:39081 response:404
> 127.0.0.1:39089 response:403	<-- httpd.conf
> 127.0.0.1:39090 response:404
> 127.0.0.1:39091 response:404	<-- test.html
> 127.0.0.1:39092 response:404	<-- test.html

It's probably favicon.ico or something like that. Run httpd -vv,
it will show URLs too.
--
vda

From vda.linux at googlemail.com  Thu Aug 16 11:04:06 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 16 Aug 2007 19:04:06 +0100
Subject: tftp client error
In-Reply-To: <f19fadc60708160737q346a317dkd90d99f12d5d5fe8@mail.gmail.com>
References: <f19fadc60708160737q346a317dkd90d99f12d5d5fe8@mail.gmail.com>
Message-ID: <200708161904.06331.vda.linux@googlemail.com>

On Thursday 16 August 2007 15:37, Avtar Singh wrote:
> Hello,
>
> I have busybox 1.6.0 running on an embedded system powered by i.MX21
> (ARM9 core) and running Kernel vanilla 2.6.22 with a few board
> specific patches. I can do a tftp get from my desktop system connected
> to the embedded board without any issues. However, tftp put throws up
> the following error repeatedly:
>
> # tftp -p -l sm.txt 222.222.101.117
> tftp: server error: (1) File not found

Due to security considerations, many tfpt servers allow puts
only if target file is already exists on server and is world-writable.

It looks like server says "I don't have sm.txt, therefore I won't allow
you to create one".

> The file is located in the root directory and I am issuing the command
> from the root directory.
>
> I have tried several versions (below) but all result in the same error:
>
> # tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117
>
> # tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117, ensuring that
> there is a sm.txt in the server tftpboot directory.

Is it world-writable? Can you strace the server? (strace -f -p <server's PID>)

> Is my usage correct? Is "put" buggy in busybox-tftp?

Don't know.
If you have other tftp client which is able to put file, then definitely yes.
--
vda

From genepi at sympatico.ca  Thu Aug 16 13:50:00 2007
From: genepi at sympatico.ca (Pierre =?iso-8859-15?q?M=E9tras?=)
Date: Thu, 16 Aug 2007 16:50:00 -0400
Subject: How to debug httpd?
In-Reply-To: <200708161859.17690.vda.linux@googlemail.com>
References: <200708101542.39107.genepi@sympatico.ca>
	<200708161001.53103.genepi@sympatico.ca>
	<200708161859.17690.vda.linux@googlemail.com>
Message-ID: <200708161650.00770.genepi@sympatico.ca>

Hi,

Le 16 Ao?t 2007 13:59, Denys Vlasenko a ?crit?:
>
> It's probably favicon.ico or something like that. Run httpd -vv,
> it will show URLs too.

Thanks Denys, that were actually requests for favicon.ico. And it depends on 
the browser: FireFox 1.x asks for it for every requests as long as it doesn't 
get it; Konqueror never asks it after the first failure...

127.0.0.1:40218 url:/favicon.ico
127.0.0.1:40218 response:404

-- Pierre M?tras

From kylix13 at 163.com  Thu Aug 16 17:08:24 2007
From: kylix13 at 163.com (kylix)
Date: Fri, 17 Aug 2007 08:08:24 +0800
Subject: udhcpd  get  DNS address  dynamic
Message-ID: <46C4E70B.00CAD1.30676@m12-12.163.com>

Hi,all

    I want to build a DHCP server on my embedded linux system.  
My busybox version is v1.3. 
    when udhcpd running, it will get the configure infomation from 
"udhcpd.conf", and then send the offer to client 
with IP, Gateway, DNS, Mask. 
    But My machine has two ethernet interface, It be 
configure as gateway. the first one run udhcpc, and 
the second run udhcpd.
    udhcpd send the offer message include DNS address,
this address in static, I want to get the DNS  option
from "/etc/reslov.conf" , because this file is configued
dynamic by udhcpc.
    How will I do ?

    I had try to modify the "busybox/networking/udhcp/serverpacket.c",
but no success.  I add two function in it, and add a call in
the line 174: addDnsOption( packet.options );

**********************************************************************************
static int  getDnsAddr(  uint8_t *dbuf, uint32_t seq )
{
	FILE  *fp;
	uint8_t  *ptr1, *ptr2, rebuf[256];
	memset( dbuf, 0, 32 );
	fp = fopen( "/etc/resolv.conf", "r");
	if( fp==NULL )
		return -1;

	fread( rebuf, 255 , 1, fp );
	fclose( fp );

	if( seq == 1 )
		ptr1 = strstr( rebuf, "nameserver " );
	else if( seq == 2 ) {
		if( ptr1 = strstr( rebuf, "nameserver " ))
			ptr1 = strstr( ptr1+11,  "nameserver " );
	}
	else
		return -1;
	
	if( ptr1 != NULL)
		if( (ptr2 = strchr( ptr1, '\n' )) != NULL ) {
			*ptr2 = '\0';
			strncpy( dbuf, ptr1+11, 15 );
		}
		
	return 0;
}


static int addDnsOption( uint8_t *options )
{
	uint8_t  dns1[32], dns2[32], *ptr;
	
	memset( dns1, 0, 32 );
	memset( dns2, 0, 32 );
	
	if( getDnsAddr( dns1, 1 )< 0 )
		strcpy( dns1, "208.67.222.222" );
	if( getDnsAddr( dns2, 2 ) < 0 )
		strcpy( dns2, "208.67.220.220" );
	
	ptr = options;
	
	ptr[OPT_CODE] = DHCP_DNS_SERVER;
	ptr[OPT_LEN]    = 4;
	*((uint32_t *)(ptr+OPT_DATA)) = inet_addr( dns1 );
	ptr += 6;
	ptr[OPT_CODE] = DHCP_DNS_SERVER;
	ptr[OPT_LEN]    = 4;
	*((uint32_t *)(ptr+OPT_DATA)) = inet_addr( dns2 );	
	ptr += 6;
	*ptr = DHCP_END;
	
	return 0;

}
*****************************************************************************************      

	
   Then I compiled busybox,  I got the error without detail information.
***********************************************************************************************************
  CC      networking/udhcp/arpping.o
  CC      networking/udhcp/clientpacket.o
  CC      networking/udhcp/dhcpc.o
  CC      networking/udhcp/dhcpd.o
  CC      networking/udhcp/dhcprelay.o
  CC      networking/udhcp/dumpleases.o
  CC      networking/udhcp/files.o
  CC      networking/udhcp/leases.o
  CC      networking/udhcp/options.o
  CC      networking/udhcp/packet.o
  CC      networking/udhcp/script.o
  CC      networking/udhcp/serverpacket.o
networking/udhcp/serverpacket.c: In function `getDnsAddr':
networking/udhcp/serverpacket.c:118: warning: suggest parentheses around assignment used as truth value
make[1]: *** [networking/udhcp/serverpacket.o] error 1
make: *** [networking/udhcp] error 2

***********************************************************************************************************
???????

???????
    Best regards
 				

????????kylix
????????kylix13 at 163.com
??????????2007-08-17

From jhnlui at gmail.com  Thu Aug 16 18:04:56 2007
From: jhnlui at gmail.com (Jenson Lui)
Date: Fri, 17 Aug 2007 09:04:56 +0800
Subject: tftp client error
In-Reply-To: <200708161904.06331.vda.linux@googlemail.com>
References: <f19fadc60708160737q346a317dkd90d99f12d5d5fe8@mail.gmail.com>
	<200708161904.06331.vda.linux@googlemail.com>
Message-ID: <e350fd010708161804s537dfeb9wc300739e6efa938b@mail.gmail.com>

Hello,

      I suggest you check your tftp server if it allows upload of file.
I have experienced the same before and found out that my tftp server
default option does not allow upload of new file.

Regards,
H. N. Lui

On 8/17/07, Denys Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Thursday 16 August 2007 15:37, Avtar Singh wrote:
> > Hello,
> >
> > I have busybox 1.6.0 running on an embedded system powered by i.MX21
> > (ARM9 core) and running Kernel vanilla 2.6.22 with a few board
> > specific patches. I can do a tftp get from my desktop system connected
> > to the embedded board without any issues. However, tftp put throws up
> > the following error repeatedly:
> >
> > # tftp -p -l sm.txt 222.222.101.117
> > tftp: server error: (1) File not found
>
> Due to security considerations, many tfpt servers allow puts
> only if target file is already exists on server and is world-writable.
>
> It looks like server says "I don't have sm.txt, therefore I won't allow
> you to create one".
>
> > The file is located in the root directory and I am issuing the command
> > from the root directory.
> >
> > I have tried several versions (below) but all result in the same error:
> >
> > # tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117
> >
> > # tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117, ensuring that
> > there is a sm.txt in the server tftpboot directory.
>
> Is it world-writable? Can you strace the server? (strace -f -p <server's
> PID>)
>
> > Is my usage correct? Is "put" buggy in busybox-tftp?
>
> Don't know.
> If you have other tftp client which is able to put file, then definitely
> yes.
> --
> 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/20070817/f60420c5/attachment.htm 

From s.avtar at gmail.com  Thu Aug 16 22:42:04 2007
From: s.avtar at gmail.com (Avtar Singh)
Date: Fri, 17 Aug 2007 11:12:04 +0530
Subject: tftp client error
In-Reply-To: <200708161904.06331.vda.linux@googlemail.com>
References: <f19fadc60708160737q346a317dkd90d99f12d5d5fe8@mail.gmail.com>
	<200708161904.06331.vda.linux@googlemail.com>
Message-ID: <f19fadc60708162242t6dbb0411sc1f8954b9d7472fc@mail.gmail.com>

Thanks, Denys. It worked! The file in question had to be made world writable.

On 8/16/07, Denys Vlasenko <vda.linux at googlemail.com> wrote:
> On Thursday 16 August 2007 15:37, Avtar Singh wrote:
> > Hello,
> >
> > I have busybox 1.6.0 running on an embedded system powered by i.MX21
> > (ARM9 core) and running Kernel vanilla 2.6.22 with a few board
> > specific patches. I can do a tftp get from my desktop system connected
> > to the embedded board without any issues. However, tftp put throws up
> > the following error repeatedly:
> >
> > # tftp -p -l sm.txt 222.222.101.117
> > tftp: server error: (1) File not found
>
> Due to security considerations, many tfpt servers allow puts
> only if target file is already exists on server and is world-writable.
>
> It looks like server says "I don't have sm.txt, therefore I won't allow
> you to create one".
>
> > The file is located in the root directory and I am issuing the command
> > from the root directory.
> >
> > I have tried several versions (below) but all result in the same error:
> >
> > # tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117
> >
> > # tftp -p -l sm.txt -r /tftpboot/sm.txt 222.222.101.117, ensuring that
> > there is a sm.txt in the server tftpboot directory.
>
> Is it world-writable? Can you strace the server? (strace -f -p <server's PID>)
>
> > Is my usage correct? Is "put" buggy in busybox-tftp?
>
> Don't know.
> If you have other tftp client which is able to put file, then definitely yes.
> --
> vda
>

From farmatito at tiscali.it  Fri Aug 17 08:13:43 2007
From: farmatito at tiscali.it (Tito)
Date: Fri, 17 Aug 2007 17:13:43 +0200
Subject: udhcpd  get  DNS address  dynamic
In-Reply-To: <46C4E70B.00CAD1.30676@m12-12.163.com>
References: <46C4E70B.00CAD1.30676@m12-12.163.com>
Message-ID: <200708171713.44070.farmatito@tiscali.it>

On Friday 17 August 2007 02:08:24 kylix wrote:
> Hi,all
> 
>     I want to build a DHCP server on my embedded linux system.  
> My busybox version is v1.3. 
>     when udhcpd running, it will get the configure infomation from 
> "udhcpd.conf", and then send the offer to client 
> with IP, Gateway, DNS, Mask. 
>     But My machine has two ethernet interface, It be 
> configure as gateway. the first one run udhcpc, and 
> the second run udhcpd.
>     udhcpd send the offer message include DNS address,
> this address in static, I want to get the DNS  option
> from "/etc/reslov.conf" , because this file is configued
> dynamic by udhcpc.
>     How will I do ?
> 
>     I had try to modify the "busybox/networking/udhcp/serverpacket.c",
> but no success.  I add two function in it, and add a call in
> the line 174: addDnsOption( packet.options );
> 
> **********************************************************************************
> static int  getDnsAddr(  uint8_t *dbuf, uint32_t seq )
> {
> 	FILE  *fp;
> 	uint8_t  *ptr1, *ptr2, rebuf[256];
> 	memset( dbuf, 0, 32 );
> 	fp = fopen( "/etc/resolv.conf", "r");
> 	if( fp==NULL )
> 		return -1;
> 
> 	fread( rebuf, 255 , 1, fp );
> 	fclose( fp );
> 
> 	if( seq == 1 )
> 		ptr1 = strstr( rebuf, "nameserver " );
> 	else if( seq == 2 ) {
> 		if( ptr1 = strstr( rebuf, "nameserver " ))

		if ((ptr1 = strstr(rebuf, "nameserver"))

> 			ptr1 = strstr( ptr1+11,  "nameserver " );
> 	}
> 	else
> 		return -1;
> 	
 snip

Ciao,
Tito

From farmatito at tiscali.it  Fri Aug 17 11:51:58 2007
From: farmatito at tiscali.it (Tito)
Date: Fri, 17 Aug 2007 20:51:58 +0200
Subject: udhcpd  get  DNS address  dynamic
In-Reply-To: <200708171713.44070.farmatito@tiscali.it>
References: <46C4E70B.00CAD1.30676@m12-12.163.com>
	<200708171713.44070.farmatito@tiscali.it>
Message-ID: <200708172051.58113.farmatito@tiscali.it>

On Friday 17 August 2007 17:13:43 Tito wrote:
> On Friday 17 August 2007 02:08:24 kylix wrote:
> > Hi,all
> > 
> >     I want to build a DHCP server on my embedded linux system.  
> > My busybox version is v1.3. 
> >     when udhcpd running, it will get the configure infomation from 
> > "udhcpd.conf", and then send the offer to client 
> > with IP, Gateway, DNS, Mask. 
> >     But My machine has two ethernet interface, It be 
> > configure as gateway. the first one run udhcpc, and 
> > the second run udhcpd.
> >     udhcpd send the offer message include DNS address,
> > this address in static, I want to get the DNS  option
> > from "/etc/reslov.conf" , because this file is configued
> > dynamic by udhcpc.
> >     How will I do ?
> > 
> >     I had try to modify the "busybox/networking/udhcp/serverpacket.c",
> > but no success.  I add two function in it, and add a call in
> > the line 174: addDnsOption( packet.options );
> > 
> > **********************************************************************************
> > static int  getDnsAddr(  uint8_t *dbuf, uint32_t seq )
> > {
> > 	FILE  *fp;
> > 	uint8_t  *ptr1, *ptr2, rebuf[256];
> > 	memset( dbuf, 0, 32 );
> > 	fp = fopen( "/etc/resolv.conf", "r");
> > 	if( fp==NULL )
> > 		return -1;
> > 
> > 	fread( rebuf, 255 , 1, fp );
> > 	fclose( fp );
> > 
> > 	if( seq == 1 )
> > 		ptr1 = strstr( rebuf, "nameserver " );
> > 	else if( seq == 2 ) {
> > 		if( ptr1 = strstr( rebuf, "nameserver " ))
> 
> 		if ((ptr1 = strstr(rebuf, "nameserver"))  ops....

		if ((ptr1 = strstr(rebuf, "nameserver")) != NULL)  ;-)

This should fix the compiling error....

> 
> > 			ptr1 = strstr( ptr1+11,  "nameserver " );
> > 	}
> > 	else
> > 		return -1;
> > 	
>  snip
> 
Ciao,
Tito


From vda.linux at googlemail.com  Fri Aug 17 12:35:17 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 17 Aug 2007 20:35:17 +0100
Subject: udhcpd  get  DNS address  dynamic
In-Reply-To: <46C4E70B.00CAD1.30676@m12-12.163.com>
References: <46C4E70B.00CAD1.30676@m12-12.163.com>
Message-ID: <200708172035.18057.vda.linux@googlemail.com>

On Friday 17 August 2007 01:08, kylix wrote:
> Hi,all
>
>     I want to build a DHCP server on my embedded linux system.
> My busybox version is v1.3.
>     when udhcpd running, it will get the configure infomation from
> "udhcpd.conf", and then send the offer to client
> with IP, Gateway, DNS, Mask.
>     But My machine has two ethernet interface, It be
> configure as gateway. the first one run udhcpc, and
> the second run udhcpd.
>     udhcpd send the offer message include DNS address,
> this address in static, I want to get the DNS  option
> from "/etc/reslov.conf" , because this file is configued
> dynamic by udhcpc.
>     How will I do ?

Write a script which reads DNS address off /etc/resolv.conf and inserts
it into udhcpd configuration file. Then (re)start udhcpd.

Or just add updating of udhcpd.conf to you udhcpc script, along
with updatind of /etc/resolv.conf which you already have there.

>     I had try to modify the "busybox/networking/udhcp/serverpacket.c",
> but no success.  I add two function in it, and add a call in
> the line 174: addDnsOption( packet.options );

Hacking on C code for that is a wrong approach.
--
vda

From privateinf at gmail.com  Sun Aug 19 03:52:38 2007
From: privateinf at gmail.com (Private Inf)
Date: Sun, 19 Aug 2007 13:52:38 +0300
Subject: PATCH: path rename suggestion
In-Reply-To: <3569c7ef0708180610y27801135ne1ff09599601af1f@mail.gmail.com>
References: <3569c7ef0708180610y27801135ne1ff09599601af1f@mail.gmail.com>
Message-ID: <3569c7ef0708190352v392a305dgd42607fde5d9d3e9@mail.gmail.com>

Hello, All

Thank you for the great program! It is extremely helpful!

I am using busybox as a core to build the Hard Real time linux based
distributive for usage in embedded systems. I use T2 project (
http://www.t2-project.org/) to prepare my distributive.

There is a patch in T2 for busybox which fixes the installation path from
root to /sbin.
The developers of T2 consider that installation of programs  in the
top-level is not nice and against the FHS (Filesystem Hirarchy Standard).

Here is the code of patch (the patch is also attached to this email).
This patch is also applicable to the latest version 1.6.1 of busybox.

--- busybox-1.6.0/include/applets.h.vanilla     2007-06-14 09:17:
12.000000000 +0000
+++ busybox-1.6.0/include/applets.h     2007-06-14 09:17:21.000000000 +0000
@@ -204,3 +204,3 @@
 USE_SETARCH(APPLET_NOUSAGE(linux64, setarch, _BB_DIR_BIN, _BB_SUID_NEVER))
-USE_FEATURE_INITRD(APPLET_NOUSAGE(linuxrc, init, _ BB_DIR_ROOT,
_BB_SUID_NEVER))
+USE_FEATURE_INITRD(APPLET_NOUSAGE(linuxrc, init, _BB_DIR_SBIN ,
_BB_SUID_NEVER))
 USE_LN(APPLET_NOEXEC(ln, ln, _BB_DIR_BIN, _BB_SUID_NEVER, ln))

Once again,
Thank you for the great job!!!
Keep it this way :)

Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070819/1a7623f3/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxrc-location.patch
Type: application/octet-stream
Size: 1199 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070819/1a7623f3/attachment.obj 

From bernd at firmix.at  Sun Aug 19 04:57:53 2007
From: bernd at firmix.at (Bernd Petrovitsch)
Date: Sun, 19 Aug 2007 13:57:53 +0200
Subject: Mysterious code in httpd.c
In-Reply-To: <200708161506.26909.vda.linux@googlemail.com>
References: <200708161506.26909.vda.linux@googlemail.com>
Message-ID: <1187524673.3986.64.camel@gimli.at.home>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://busybox.net/lists/busybox/attachments/20070819/86c27670/attachment.diff 

From vda.linux at googlemail.com  Sun Aug 19 12:03:42 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 19 Aug 2007 20:03:42 +0100
Subject: Mysterious code in httpd.c
In-Reply-To: <1187524673.3986.64.camel@gimli.at.home>
References: <200708161506.26909.vda.linux@googlemail.com>
	<1187524673.3986.64.camel@gimli.at.home>
Message-ID: <200708192003.42516.vda.linux@googlemail.com>

On Sunday 19 August 2007 12:57, Bernd Petrovitsch wrote:
> On Thu, 2007-08-16 at 15:06 +0100, Denys Vlasenko wrote:
> > In handle_incoming_and_exit() we used to do this
> > just before exit:
> >
> >         /* Properly wait for remote to closed */
> >         int retval;
> >         shutdown(accepted_socket, SHUT_WR);
> >         do {
> >                 fd_set s_fd;
> >                 struct timeval tv;
> >                 FD_ZERO(&s_fd);
> >                 FD_SET(accepted_socket, &s_fd);
> >                 tv.tv_sec = 2;
> >                 tv.tv_usec = 0;
> >                 retval = select(accepted_socket + 1, &s_fd, NULL, NULL,
> > &tv); } while (retval > 0 && read(accepted_socket, iobuf, sizeof(iobuf) >
> > 0));
>
>                                Actually this looks like a bug
> ^^^^^^^^^^^^^^^^^ and the line should have been:
>           } while (retval > 0 && read(accepted_socket, iobuf,
> sizeof(iobuf)) > 0);
>
> >         shutdown(accepted_socket, SHUT_RD);
> >         close(accepted_socket);
> >         exit(0);
> >
> > Apparently we first inform peer that we are not going to write anything
> > anymore, and then we drain any remaining input.
> >
> > Question - why is this needed? What bad things can happen if we just
> > exit(0) without doing all this?
>
> The "shutdown(accepted_socket, SHUT_RD)" and "close(accepted_socket)" is
> superfluous since exit() closes all file descriptors anyway.
>
> The exit() (or a close() instead of the "shutdown(accepted_socket,
> SHUT_WR)") can produce an error on the sending side if there are byte
> left in some buffer there.
> And IE5/IE5.5 (I don't know about more recent IEs) delivered an
> confusing and misleading (IIRC) error window, if that happens.
>
> This was especially annoying (read: it happened pretty every time) since
> several versions had a bug where IE sent 2 more bytes than actually told
> the server in the HTTP request.

Thanks for explanation.

> Perhaps the above can be reduced by simply having a blocking read() and
> avoid the select():
> ----  snip  ----
>     while (read(accepted_socket, iobuf, sizeof(iobuf)) > 0) {
>          /* do nothing */;
>     }
> ----  snip  ----

Well, we can block indefinitely if peer just sits there, doing nothing.
I prefer nonblocking reads in this case. I will do this:

/*
 * Log the connection closure and exit.
 */
static void log_and_exit(void) ATTRIBUTE_NORETURN;
static void log_and_exit(void)
{
        /* Paranoia. IE said to be buggy. It may send some extra data
         * or be confused by us just exiting without SHUT_WR. Oh well. */
        shutdown(1, SHUT_WR);
        ndelay_on(0);
        while (read(0, iobuf, IOBUF_SIZE) > 0)
                continue;

        if (verbose > 2)
                bb_error_msg("closed");
        _exit(xfunc_error_retval);
}

(In current svn, httpd inevitably exits only thru this function).
--
vda

From bernd at firmix.at  Sun Aug 19 12:42:01 2007
From: bernd at firmix.at (Bernd Petrovitsch)
Date: Sun, 19 Aug 2007 21:42:01 +0200
Subject: Mysterious code in httpd.c
In-Reply-To: <200708192003.42516.vda.linux@googlemail.com>
References: <200708161506.26909.vda.linux@googlemail.com>
	<1187524673.3986.64.camel@gimli.at.home>
	<200708192003.42516.vda.linux@googlemail.com>
Message-ID: <1187552521.3986.101.camel@gimli.at.home>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://busybox.net/lists/busybox/attachments/20070819/163f0fe1/attachment.diff 

From genepi at sympatico.ca  Mon Aug 20 06:39:04 2007
From: genepi at sympatico.ca (Pierre =?iso-8859-1?q?M=E9tras?=)
Date: Mon, 20 Aug 2007 09:39:04 -0400
Subject: [PATCH] httpd - User defined error pages
Message-ID: <200708200939.04540.genepi@sympatico.ca>

Hi,

Here is my patch to support user defined error pages only in httpd, applied to 
the current SVN version. There were a lot of refactoring of httpd.c code in 
the last days and it's becoming more and more difficult for me to track the 
changes.

make bloatcheck
function                                             old     new   delta
parse_conf                                          1170    1367    +197
send_headers                                         477     569     +92
httpResponseNames                                    108     144     +36
send_file_and_exit                                   338     352     +14
handle_incoming_and_exit                            1810    1812      +2
.rodata                                             4921    4825     -96
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 5/1 up/down: 341/-96)           Total: 245 bytes


-- Pierre M?tras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.error_pages
Type: text/x-diff
Size: 8910 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070820/5847c3d1/attachment.bin 

From genepi at sympatico.ca  Mon Aug 20 12:02:48 2007
From: genepi at sympatico.ca (Pierre =?iso-8859-1?q?M=E9tras?=)
Date: Mon, 20 Aug 2007 15:02:48 -0400
Subject: [PATCH] httpd - User defined error pages
In-Reply-To: <200708201807.33038.vda.linux@googlemail.com>
References: <200708200939.04540.genepi@sympatico.ca>
	<200708201807.33038.vda.linux@googlemail.com>
Message-ID: <200708201502.49033.genepi@sympatico.ca>

Hi Denys,

Le 20 Ao?t 2007 13:07, Denys Vlasenko a ?crit?:
> On Monday 20 August 2007 14:39, Pierre M?tras wrote:
> > Hi,
> >
> > Here is my patch to support user defined error pages only in httpd,
> > applied to the current SVN version.
>
> +static SKIP_FEATURE_HTTPD_ERROR_PAGES(const) HttpEnumString
> httpResponseNames[] = { +       { HTTP_OK, "OK", NULL
> USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },
>
> Removal of "const" enlarged data segment by 144 bytes:
>
> $ size */*/httpd.o
>    text    data     bss     dec     hex filename
>    9075       0       0    9075    2373 busybox.t4/networking/httpd.o
>    9247     144       0    9391    24af busybox.t5/networking/httpd.o
>
> It's possible to avoid this by converting httpResponseNames[] array
> into separate arrays for type, strings, and error page names,
> and putting error page names into "struct globals".

I wanted this change to have the less impact on existing code, because not 
everybody needs to have custom error pages support (in my case, that's for 
adds removal on my router). That's why I used the existing struct array and 
moved from const to data segment, conditionnaly when this feature was used. 
When this feature is not set, there is no impact on the program size:

function                                             old     new   delta
send_file_and_exit                                   338     352     +14
handle_incoming_and_exit                            1810    1812      +2
parse_conf                                          1170    1160     -10
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 16/-10)              Total: 6 bytes

But that's even better with your changes!

>
> That's what I did in attached version of httpd.c.
>
> Can you confirm that it still works for you?
>

It works fine on my side with my small test case.

Thanks

-- Pierre M?tras

From vda.linux at googlemail.com  Mon Aug 20 10:07:32 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 20 Aug 2007 18:07:32 +0100
Subject: [PATCH] httpd - User defined error pages
In-Reply-To: <200708200939.04540.genepi@sympatico.ca>
References: <200708200939.04540.genepi@sympatico.ca>
Message-ID: <200708201807.33038.vda.linux@googlemail.com>

On Monday 20 August 2007 14:39, Pierre M?tras wrote:
> Hi,
>
> Here is my patch to support user defined error pages only in httpd, applied
> to the current SVN version.

+static SKIP_FEATURE_HTTPD_ERROR_PAGES(const) HttpEnumString httpResponseNames[] = {
+       { HTTP_OK, "OK", NULL USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },
+       { HTTP_MOVED_TEMPORARILY, "Found", "Directories must end with a slash." USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },

I still don't like USE_FEATURE_HTTPD_ERROR_PAGES(, NULL),
which just make code even more unreadable than it was.

Removal of "const" enlarged data segment by 144 bytes:

$ size */*/httpd.o
   text    data     bss     dec     hex filename
   9075       0       0    9075    2373 busybox.t4/networking/httpd.o
   9247     144       0    9391    24af busybox.t5/networking/httpd.o

It's possible to avoid this by converting httpResponseNames[] array
into separate arrays for type, strings, and error page names,
and putting error page names into "struct globals".

That's what I did in attached version of httpd.c.

Can you confirm that it still works for you?

> There were a lot of refactoring of httpd.c code
> in the last days and it's becoming more and more difficult for me to track
> the changes.

Sorry :(
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpd.c
Type: text/x-csrc
Size: 58335 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070820/248e9545/attachment-0001.c 

From Gary.Leong at nasdaq.com  Mon Aug 20 12:22:00 2007
From: Gary.Leong at nasdaq.com (Leong, Gary)
Date: Mon, 20 Aug 2007 15:22:00 -0400
Subject: help
In-Reply-To: <mailman.1072.1187638352.1110.busybox@busybox.net>
References: <mailman.1072.1187638352.1110.busybox@busybox.net>
Message-ID: <FD98A53269F5F74082DFBB12E8AA60320B0DF3F1@TRM-EXCH1.CORP.NASDAQ.COM>



-----Original Message-----
From: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net]
On Behalf Of busybox-request at busybox.net
Sent: Monday, August 20, 2007 3:33 PM
To: busybox at busybox.net
Subject: busybox Digest, Vol 25, Issue 28

Send busybox mailing list submissions to
	busybox at busybox.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://busybox.net/cgi-bin/mailman/listinfo/busybox
or, via email, send a message with subject or body 'help' to
	busybox-request at busybox.net

You can reach the person managing the list at
	busybox-owner at busybox.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of busybox digest..."


Today's Topics:

   1. Re: [PATCH] httpd - User defined error pages (Pierre M?tras)
   2. Re: [PATCH] httpd - User defined error pages (Denys Vlasenko)


----------------------------------------------------------------------

Message: 1
Date: Mon, 20 Aug 2007 15:02:48 -0400
From: Pierre M?tras <genepi at sympatico.ca>
Subject: Re: [PATCH] httpd - User defined error pages
To: Denys Vlasenko <vda.linux at googlemail.com>
Cc: busybox at busybox.net
Message-ID: <200708201502.49033.genepi at sympatico.ca>
Content-Type: text/plain; charset=iso-8859-1

Hi Denys,

Le 20 Ao?t 2007 13:07, Denys Vlasenko a ?crit?:
> On Monday 20 August 2007 14:39, Pierre M?tras wrote:
> > Hi,
> >
> > Here is my patch to support user defined error pages only in httpd,
> > applied to the current SVN version.
>
> +static SKIP_FEATURE_HTTPD_ERROR_PAGES(const) HttpEnumString
> httpResponseNames[] = { +       { HTTP_OK, "OK", NULL
> USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },
>
> Removal of "const" enlarged data segment by 144 bytes:
>
> $ size */*/httpd.o
>    text    data     bss     dec     hex filename
>    9075       0       0    9075    2373 busybox.t4/networking/httpd.o
>    9247     144       0    9391    24af busybox.t5/networking/httpd.o
>
> It's possible to avoid this by converting httpResponseNames[] array
> into separate arrays for type, strings, and error page names,
> and putting error page names into "struct globals".

I wanted this change to have the less impact on existing code, because
not 
everybody needs to have custom error pages support (in my case, that's
for 
adds removal on my router). That's why I used the existing struct array
and 
moved from const to data segment, conditionnaly when this feature was
used. 
When this feature is not set, there is no impact on the program size:

function                                             old     new   delta
send_file_and_exit                                   338     352     +14
handle_incoming_and_exit                            1810    1812      +2
parse_conf                                          1170    1160     -10
------------------------------------------------------------------------
------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 16/-10)              Total: 6
bytes

But that's even better with your changes!

>
> That's what I did in attached version of httpd.c.
>
> Can you confirm that it still works for you?
>

It works fine on my side with my small test case.

Thanks

-- Pierre M?tras


------------------------------

Message: 2
Date: Mon, 20 Aug 2007 18:07:32 +0100
From: Denys Vlasenko <vda.linux at googlemail.com>
Subject: Re: [PATCH] httpd - User defined error pages
To: busybox at busybox.net
Cc: Pierre M?tras <genepi at sympatico.ca>
Message-ID: <200708201807.33038.vda.linux at googlemail.com>
Content-Type: text/plain; charset="iso-8859-15"

On Monday 20 August 2007 14:39, Pierre M?tras wrote:
> Hi,
>
> Here is my patch to support user defined error pages only in httpd,
applied
> to the current SVN version.

+static SKIP_FEATURE_HTTPD_ERROR_PAGES(const) HttpEnumString
httpResponseNames[] = {
+       { HTTP_OK, "OK", NULL USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },
+       { HTTP_MOVED_TEMPORARILY, "Found", "Directories must end with a
slash." USE_FEATURE_HTTPD_ERROR_PAGES(, NULL) },

I still don't like USE_FEATURE_HTTPD_ERROR_PAGES(, NULL),
which just make code even more unreadable than it was.

Removal of "const" enlarged data segment by 144 bytes:

$ size */*/httpd.o
   text    data     bss     dec     hex filename
   9075       0       0    9075    2373 busybox.t4/networking/httpd.o
   9247     144       0    9391    24af busybox.t5/networking/httpd.o

It's possible to avoid this by converting httpResponseNames[] array
into separate arrays for type, strings, and error page names,
and putting error page names into "struct globals".

That's what I did in attached version of httpd.c.

Can you confirm that it still works for you?

> There were a lot of refactoring of httpd.c code
> in the last days and it's becoming more and more difficult for me to
track
> the changes.

Sorry :(
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpd.c
Type: text/x-csrc
Size: 58335 bytes
Desc: not available
Url :
http://busybox.net/lists/busybox/attachments/20070820/248e9545/attachmen
t.c 

------------------------------

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

End of busybox Digest, Vol 25, Issue 28
***************************************



From ynakam at hitachisoft.jp  Mon Aug 20 16:34:43 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Tue, 21 Aug 2007 08:34:43 +0900
Subject: [patch][BusyBox] Domain assignment support for
	SELinux/AppArmor/LIDS
In-Reply-To: <1186727661.2715.13.camel@nc.nor.wtbts.org>
References: <200708080438.l784cj4N015640@mbox.iijmio-mail.jp>
	<1186727661.2715.13.camel@nc.nor.wtbts.org>
Message-ID: <20070821082833.7ABE.YNAKAM@hitachisoft.jp>


On Fri, 10 Aug 2007 08:34:21 +0200
Natanael Copa  wrote:
> On Wed, 2007-08-08 at 13:38 +0900, himainu-ynakam at miomio.jp wrote:
> > Hello.
> > 
> > We would like to suggest Secure OSes(such as SELinux/AppArmor/LIDS) domain
> > assignment support for BusyBox. This work is done by Hiroshi Shinji.
> 
> ...
> 
> > For example, in the case of SELinux, /sbin/syslogd is assigned syslogd_t
> > domain at the execution time of /sbin/syslogd. syslogd_t are allowed to
> > read syslogd.conf, write log files, etc.
> > 
> > However, current BusyBox does not suitable for assigning domains.
> > Because BusyBox is a single file that is called through a lot of links.
> > 
> > Secure OS treats "/sbin/syslogd" and "/sbin/httpd" as "/bin/busybox".
> > So, /sbin/syslogd and /sbin/httpd run as the same domain.
> 
> This is a problem for start-stop-daemon too. IT would solve issues with
> SUID bit programs too (like passwd, su ...)
> 
> > 2. Our solution
> > Shinji came up with one idea. He thought "script wrappper" like below.
> 
> while I agree it would be nice to have every applet as a separate
> executable, I'm not sure I like the idea of executing shell for every
> command. It *feels* hackish.
Yes, as you say, it may be tricky,
but there are other tricky things like treatment of global value 
in busybox I think.

> > Assigning domain is critical to secure OSes.
> > We want way to assign to domains to busybox applets.
> > Please review this patch and consider merging.
> 
> The patch is the shortest way to accomplish this. I would believe the
> "correct" way would be to compile every applet as a standalone, linked
> to a libbb.so. I think its even mentioned in the TODO.
Standalone executable is bigger, 
even simple "hello world" executable consumes 2940 byte.
This wrapper uses only 15 byte for one applet.

> Natanael Copa


Regards,
-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
SELinux Policy Editor: http://seedit.sourceforge.net/


From ynakam at hitachisoft.jp  Mon Aug 20 16:38:47 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Tue, 21 Aug 2007 08:38:47 +0900
Subject: [patch][resend] Domain assignment support for SELinux/AppArmor/LIDS
Message-ID: <20070821083522.7AC0.YNAKAM@hitachisoft.jp>

Hello.
Denis said please resend patches, 
So we would like to send this mail again.

We would like to suggest Secure OSes(such as SELinux/AppArmor/LIDS) domain
assignment support for BusyBox. This work is done by Hiroshi Shinji.

1. Background

Secure OSes such as SELinux, AppArmor and LIDS can assign domain to processes.
"Domain" means set of access rights.
Domain is assinged to processes at the time of "exec" system call.
# This is a little similar to "suid" feature of Linux.

For example, in the case of SELinux, /sbin/syslogd is assigned syslogd_t
domain at the execution time of /sbin/syslogd. syslogd_t are allowed to
read syslogd.conf, write log files, etc.

However, current BusyBox does not suitable for assigning domains.
Because BusyBox is a single file that is called through a lot of links.

Secure OS treats "/sbin/syslogd" and "/sbin/httpd" as "/bin/busybox".
So, /sbin/syslogd and /sbin/httpd run as the same domain.

Known solutions to this problem is preparing wrapper program that calls
applet.
? For example, /sbin/syslogd is a small C program that calls
"/bin/busybox syslogd". Then, at the execution of /sbin/syslogd,
syslogd_t domain is assigned and "/bin/busybox syslogd" is called
and inherits assinged domain(syslogd_t).
However, such wrapper consumes storage(more than 1k byte per wrapper).
For detailed description about this problem,
Yusuke Sato wrote documentation:
http://www.selinux.gr.jp/LIDS-JP/LIDS_en/document/general/web_lids_busybox/main.html

2. Our solution
Shinji came up with one idea. He thought "script wrappper" like below.

If you enabled "INSTALL_APPLET_SCRIPT_WRAPPERS", wrappers like below are
installed.

The contents of "/sbin/syslogd" is following.

#!/bin/busybox

It is only 15 byte.

When /sbin/syslogd is executed, "/bin/busybox /sbin/syslogd <other arguments>" is called.

To achive above, we had to modify applets.c

-       applet_name = argv[0];
-       run_applet_and_exit(argv[0], argv);
+       applet_name = bb_get_last_path_component(argv[0]);
+       run_applet_and_exit(applet_name, argv);

We tried the patch for SELinux and AppArmor.
And domains were assigned sucessfully!

3. Limitation
Programs that are used as interpreter can not be installed as script wrapper.
It is due to limitation of exec(interpreter can not be called twice).
For example, /bin/sh can not be installed as script wrapper.
If /bin/sh is installed as script wrapper, shell scripts do not run.
In interpreting #!/bin/sh

-> /bin/sh is #!/bin/busybox,
-> #! is called twice
-> exec system call fails(limitation of exec system call).

In our patch, sh is installed as symlink or hard link by default
(you can install it as script wrapper if you still need).

Assigning domain is critical to secure OSes.
We want way to assign to domains to busybox applets.
Please review this patch and consider merging.

Regards,
-- 
Yuichi Nakamura
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: domain_assign.patch
Type: application/octet-stream
Size: 5261 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070821/bba0bcc6/attachment.obj 

From rolf at elektronix.no  Tue Aug 21 02:16:47 2007
From: rolf at elektronix.no (Rolf Blindheim)
Date: Tue, 21 Aug 2007 11:16:47 +0200
Subject: inittab/getty problems
Message-ID: <200708211116.52265.rolf@elektronix.no>

Hello.
I've built a rootfs from buildroot-20070616 snapshot, and encountered
some problems to make to rootfs compile.. I'm booting from initramfs and
the rootfs is intended to work as an embedded system. 
My current problems are that all the device nodes are not created upon
boot, so tty1 wont spawn.. I've tried to make a workaround script which 
creates the required device nodes in a script called from rcS, which works
good. but even it I've got nodes as console, tty1, tty2 etc, inittab wont 
spawn the login...
I really need some hints on this..

my inittab:

# /etc/inittab
#
# Copyright (C) 2001 Erik Andersen <andersen at codepoet.org>
#
# Note: BusyBox init doesn't support runlevels.  The runlevels field is
# completely ignored by BusyBox init. If you want runlevels, use
# sysvinit.
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# id        == tty to run on, or empty for /dev/console
# runlevels == ignored
# action    == one of sysinit, respawn, askfirst, wait, and once
# process   == program to run

# Startup the system
::sysinit:/bin/mount -t proc none /proc
::sysinit:/bin/mount -t sysfs none /sys
::sysinit:/bin/mount -t tmpfs -o size=64k,mode=0755 none /dev
::sysinit:/bin/mkdir /dev/pts
::sysinit:/bin/mount -t devpts devpts /dev/pts
::sysinit:/bin/echo /sbin/mdev > /proc/sys/kernel/hotplug
::sysinit:/sbin/mdev -s
::sysinit:/bin/mount -o remount,rw /
::sysinit:/bin/mount -a
::sysinit:/bin/hostname -F /etc/hostname
::sysinit:/sbin/ifconfig lo 127.0.0.1 up
::sysinit:/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
# now run any rc scripts
::sysinit:/etc/init.d/rcS
::sysinit:/bin/bash				#Just to get a shell to debug

# Set up a couple of getty's
::respawn:/sbin/getty 38400 tty1
tty2::respawn:/sbin/getty 38400 tty2

# Put a getty on the serial port
#ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100

# Logging junk
null::sysinit:/bin/touch /var/log/messages
null::respawn:/sbin/syslogd -n
null::respawn:/sbin/klogd -n
tty3::respawn:/usr/bin/tail -f /var/log/messages

# Stuff to do for the 3-finger salute
::ctrlaltdel:/sbin/reboot

# Stuff to do before rebooting
null::shutdown:/usr/bin/killall klogd
null::shutdown:/usr/bin/killall syslogd
null::shutdown:/bin/umount -a -r
null::shutdown:/sbin/swapoff -a

Hope somebody can enlighten me abit
Thanks


-- 
Rolf Blindheim
<rolf at elektronix.no>
-------------- 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/20070821/80ed0ece/attachment.pgp 

From vda.linux at googlemail.com  Tue Aug 21 03:25:36 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 21 Aug 2007 11:25:36 +0100
Subject: inittab/getty problems
In-Reply-To: <200708211116.52265.rolf@elektronix.no>
References: <200708211116.52265.rolf@elektronix.no>
Message-ID: <200708211125.36292.vda.linux@googlemail.com>

On Tuesday 21 August 2007 10:16, Rolf Blindheim wrote:
> Hello.
> I've built a rootfs from buildroot-20070616 snapshot, and encountered
> some problems to make to rootfs compile.. I'm booting from initramfs and
> the rootfs is intended to work as an embedded system.
> My current problems are that all the device nodes are not created upon
> boot, so tty1 wont spawn.. I've tried to make a workaround script which
> creates the required device nodes in a script called from rcS, which works
> good. but even it I've got nodes as console, tty1, tty2 etc, inittab wont
> spawn the login...
> I really need some hints on this..
>
> my inittab:
>
> # /etc/inittab
...
> # Set up a couple of getty's
>
> ::respawn:/sbin/getty 38400 tty1
> tty2::respawn:/sbin/getty 38400 tty2

Replace /sbin/getty with /sbin/getty_debug.sh, along the lines of:

/sbin/getty_debug.sh
====================
#!/bin/sh
echo "Started: $0 $*" >/dev/console
"$0" "$@"
echo "Exited with $?: $0 $*" >/dev/console

What do you see on /dev/console?
--
vda

From vgupta at marvell.com  Tue Aug 21 07:09:49 2007
From: vgupta at marvell.com (Vivek-Kumar Gupta)
Date: Tue, 21 Aug 2007 07:09:49 -0700
Subject: disable network module at boot time
Message-ID: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>

Hi Everybody,

 

I am using busy box for embedded device.

I am facing a peculiar problem.

 

I want to my board to boot with network module. 

When kernel starts uncompressing, messages on console comes like

====

NET: Registered protocol family 2

 IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

 TCP established hash table entries: 2048 (order: 1, 8192 bytes)

 TCP bind hash table entries: 1024 (order: 0, 4096 bytes)

 TCP: Hash tables configured (established 2048 bind 1024)

 TCP reno registered

....

 

NET: Registered protocol family 1

NET: Registered protocol family 10

 NET: Registered protocol family 17

NET: Registered protocol family 15

====

 

This suggests that network module is being loaded by kernel.

I have compiled Ethernet as module. I want to enable network module
after kernel boots ( post kernel) via some script.

I have modified the /etc/modprobe.conf, rc.sysinit so that init process
don't load network module, but this modification stopped the network
services.

 

Can any one help me how to disable network module while kernel is
booting and enable it again after kernel boots.

Thanks in advance.

 

Regards,

Vivek Kumar Gupta

Marvell Semiconductor | 77A, IFFCO ROAD | SECTOR 18 | GURGAON - 122 015
| India.

*: (Work) +91-124-4516954 | 7: (Fax) +91-124-4516970 | *:
vgupta at marvell.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070821/91a67e7c/attachment.htm 

From brian.austin at cirrus.com  Tue Aug 21 08:07:47 2007
From: brian.austin at cirrus.com (Brian Austin)
Date: Tue, 21 Aug 2007 10:07:47 -0500
Subject: disable network module at boot time
In-Reply-To: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>
References: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>
Message-ID: <1187708867.21367.6.camel@localhost.localdomain>

That means your network subsystem drivers are loading.  Not the physical
Ethernet Device.

For a device you should see something like this.

ep93xx-eth version 0.1 loading
eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.


what you are seeing is networking support, not device support.

Like 
Packet Socket
IP: tunneling

and what not.



On Tue, 2007-08-21 at 07:09 -0700, Vivek-Kumar Gupta wrote:
> Hi Everybody,
> 
>  
> 
> I am using busy box for embedded device.
> 
> I am facing a peculiar problem.
> 
>  
> 
> I want to my board to boot with network module. 
> 
> When kernel starts uncompressing, messages on console comes like
> 
> ====
> 
> NET: Registered protocol family 2
> 
>  IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> 
>  TCP established hash table entries: 2048 (order: 1, 8192 bytes)
> 
>  TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> 
>  TCP: Hash tables configured (established 2048 bind 1024)
> 
>  TCP reno registered
> 
> ?.
> 
>  
> 
> NET: Registered protocol family 1
> 
> NET: Registered protocol family 10
> 
>  NET: Registered protocol family 17
> 
> NET: Registered protocol family 15
> 
> ====
> 
>  
> 
> This suggests that network module is being loaded by kernel.
> 
> I have compiled Ethernet as module. I want to enable network module
> after kernel boots ( post kernel) via some script.
> 
> I have modified the /etc/modprobe.conf, rc.sysinit so that init
> process don?t load network module, but this modification stopped the
> network services.
> 
>  
> 
> Can any one help me how to disable network module while kernel is
> booting and enable it again after kernel boots.
> 
> Thanks in advance.
> 
>  
> 
> Regards,
> 
> Vivek Kumar Gupta
> 
> Marvell Semiconductor | 77A, IFFCO ROAD | SECTOR 18 | GURGAON - 122
> 015 | India.
> 
> (: (Work) +91-124-4516954 | 7: (Fax) +91-124-4516970 |
> *: vgupta at marvell.com
> 
>  
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox



From vgupta at marvell.com  Tue Aug 21 20:31:43 2007
From: vgupta at marvell.com (Vivek-Kumar Gupta)
Date: Tue, 21 Aug 2007 20:31:43 -0700
Subject: disable network module at boot time
References: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>
	<1187708867.21367.6.camel@localhost.localdomain>
Message-ID: <36B0F7CCEC523942ACBB99209FBB3C2F79C2BF@sc-exch02.marvell.com>

Hi Brian,
I have never seen these lines in console logs
ep93xx-eth version 0.1 loading
eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.
Well I searched "ep93xx-eth" a lot in the scripts where it is loaded but
I can't figure out.

I just want to Disable Network Support at boot time so that boot time
can be Reduced. Then enable it again after boot.

If you can provide me some more insight, that will be great.


Regards,
Vivek :-
-----Original Message-----
From: Brian Austin [mailto:brian.austin at cirrus.com] 
Sent: Tuesday, August 21, 2007 8:38 PM
To: Vivek-Kumar Gupta
Cc: busybox at busybox.net
Subject: Re: disable network module at boot time

That means your network subsystem drivers are loading.  Not the physical
Ethernet Device.

For a device you should see something like this.

ep93xx-eth version 0.1 loading
eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.


what you are seeing is networking support, not device support.

Like 
Packet Socket
IP: tunneling

and what not.



On Tue, 2007-08-21 at 07:09 -0700, Vivek-Kumar Gupta wrote:
> Hi Everybody,
> 
>  
> 
> I am using busy box for embedded device.
> 
> I am facing a peculiar problem.
> 
>  
> 
> I want to my board to boot with network module. 
> 
> When kernel starts uncompressing, messages on console comes like
> 
> ====
> 
> NET: Registered protocol family 2
> 
>  IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> 
>  TCP established hash table entries: 2048 (order: 1, 8192 bytes)
> 
>  TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> 
>  TCP: Hash tables configured (established 2048 bind 1024)
> 
>  TCP reno registered
> 
> ....
> 
>  
> 
> NET: Registered protocol family 1
> 
> NET: Registered protocol family 10
> 
>  NET: Registered protocol family 17
> 
> NET: Registered protocol family 15
> 
> ====
> 
>  
> 
> This suggests that network module is being loaded by kernel.
> 
> I have compiled Ethernet as module. I want to enable network module
> after kernel boots ( post kernel) via some script.
> 
> I have modified the /etc/modprobe.conf, rc.sysinit so that init
> process don't load network module, but this modification stopped the
> network services.
> 
>  
> 
> Can any one help me how to disable network module while kernel is
> booting and enable it again after kernel boots.
> 
> Thanks in advance.
> 
>  
> 
> Regards,
> 
> Vivek Kumar Gupta
> 
> Marvell Semiconductor | 77A, IFFCO ROAD | SECTOR 18 | GURGAON - 122
> 015 | India.
> 
> (: (Work) +91-124-4516954 | 7: (Fax) +91-124-4516970 |
> *: vgupta at marvell.com
> 
>  
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox



From jcurlnews at arcor.de  Wed Aug 22 03:22:07 2007
From: jcurlnews at arcor.de (Jason Curl)
Date: Wed, 22 Aug 2007 12:22:07 +0200
Subject: disable network module at boot time
In-Reply-To: <36B0F7CCEC523942ACBB99209FBB3C2F79C2BF@sc-exch02.marvell.com>
References: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>	<1187708867.21367.6.camel@localhost.localdomain>
	<36B0F7CCEC523942ACBB99209FBB3C2F79C2BF@sc-exch02.marvell.com>
Message-ID: <46CC0E4F.3070106@arcor.de>

I've adjusted the mail for top-posting.. And please don't put email 
addresses in plaintext...

Vivek-Kumar Gupta wrote:
>> That means your network subsystem drivers are loading.  Not the physical
>> Ethernet Device.
>>
>> For a device you should see something like this.
>>
>> ep93xx-eth version 0.1 loading
>> eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.
>>     
> I have never seen these lines in console logs
> ep93xx-eth version 0.1 loading
> eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.
> Well I searched "ep93xx-eth" a lot in the scripts where it is loaded but
> I can't figure out.
>
> I just want to Disable Network Support at boot time so that boot time
> can be Reduced. Then enable it again after boot.
>
> If you can provide me some more insight, that will be great.
>   
Brian just gave an example. On my embedded system it's Intel and another 
is SMC. And I've got modules loading in afterwards for these network 
cards. Don't look explicitly for these strings.

By removing NET support you may cause problems during the boot phase. 
But you should try to build the TCP/IP stack as a module (I haven't 
checked if it's possible, mine's in the kernel by default as I use 
TCP/IP on localhost to communicate).

Find some articles about the Linux Kernel and embedded systems with 
Linux in general. This topic isn't really about BusyBox. comp.realtime 
or some other embedded newsgroups specific to linux might be more useful 
to you.
>
>> what you are seeing is networking support, not device support.
>>
>> Like 
>> Packet Socket
>> IP: tunneling
>>
>> and what not.
>>
>>
>>
>> On Tue, 2007-08-21 at 07:09 -0700, Vivek-Kumar Gupta wrote:
>>     
>>> Hi Everybody,
>>>
>>>  
>>>
>>> I am using busy box for embedded device.
>>>
>>> I am facing a peculiar problem.
>>>
>>>  
>>>
>>> I want to my board to boot with network module. 
>>>
>>> When kernel starts uncompressing, messages on console comes like
>>>
>>> ====
>>>
>>> NET: Registered protocol family 2
>>>
>>>  IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
>>>
>>>  TCP established hash table entries: 2048 (order: 1, 8192 bytes)
>>>
>>>  TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
>>>
>>>  TCP: Hash tables configured (established 2048 bind 1024)
>>>
>>>  TCP reno registered
>>>
>>> ....
>>>
>>>  
>>>
>>> NET: Registered protocol family 1
>>>
>>> NET: Registered protocol family 10
>>>
>>>  NET: Registered protocol family 17
>>>
>>> NET: Registered protocol family 15
>>>
>>> ====
>>>
>>>  
>>>
>>> This suggests that network module is being loaded by kernel.
>>>
>>> I have compiled Ethernet as module. I want to enable network module
>>> after kernel boots ( post kernel) via some script.
>>>
>>> I have modified the /etc/modprobe.conf, rc.sysinit so that init
>>> process don't load network module, but this modification stopped the
>>> network services.
>>>
>>>  
>>>
>>> Can any one help me how to disable network module while kernel is
>>> booting and enable it again after kernel boots.
>>>
>>> Thanks in advance.
>>>
>>>  


From vgupta at marvell.com  Wed Aug 22 04:27:34 2007
From: vgupta at marvell.com (Vivek-Kumar Gupta)
Date: Wed, 22 Aug 2007 04:27:34 -0700
Subject: disable network module at boot time
References: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>	<1187708867.21367.6.camel@localhost.localdomain>
	<36B0F7CCEC523942ACBB99209FBB3C2F79C2BF@sc-exch02.marvell.com>
	<46CC0E4F.3070106@arcor.de>
Message-ID: <36B0F7CCEC523942ACBB99209FBB3C2F79C35F@sc-exch02.marvell.com>

Regarding ep93xx-eth, I just mean to say that, I am using Cirrus logic
board, and I have also seen ep93xx_eth.c, which generates ep93xx-eth
driver.
I am searching ep93xx-eth in booting scripts to turn OFF the Network
Support from kernel boot. Well my doubt is cleared by Brian, thanks.
Well now I am looking for some way for disabling Network Support in boot
time then enable it after kernel boot.

As far as compiling TCP/IP stack as a module, is a good suggestion, but
I have checked (#make ep=9307a linux-config => opens linux
configurations) that, but it seems that there is no such option.

I really don't know who's cup of tea is this, busybox or linux kernel ?
I suppose busy box provides basic infrastructure for kernel to run.

Regards,
Vivek:-
-----Original Message-----
From: Jason Curl [mailto:jcurlnews at arcor.de] 
Sent: Wednesday, August 22, 2007 3:52 PM
To: Vivek-Kumar Gupta
Cc: Brian Austin; busybox at busybox.net
Subject: Re: disable network module at boot time

I've adjusted the mail for top-posting.. And please don't put email 
addresses in plaintext...

Vivek-Kumar Gupta wrote:
>> That means your network subsystem drivers are loading.  Not the
physical
>> Ethernet Device.
>>
>> For a device you should see something like this.
>>
>> ep93xx-eth version 0.1 loading
>> eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.
>>     
> I have never seen these lines in console logs
> ep93xx-eth version 0.1 loading
> eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.
> Well I searched "ep93xx-eth" a lot in the scripts where it is loaded
but
> I can't figure out.
>
> I just want to Disable Network Support at boot time so that boot time
> can be Reduced. Then enable it again after boot.
>
> If you can provide me some more insight, that will be great.
>   
Brian just gave an example. On my embedded system it's Intel and another

is SMC. And I've got modules loading in afterwards for these network 
cards. Don't look explicitly for these strings.

By removing NET support you may cause problems during the boot phase. 
But you should try to build the TCP/IP stack as a module (I haven't 
checked if it's possible, mine's in the kernel by default as I use 
TCP/IP on localhost to communicate).

Find some articles about the Linux Kernel and embedded systems with 
Linux in general. This topic isn't really about BusyBox. comp.realtime 
or some other embedded newsgroups specific to linux might be more useful

to you.
>
>> what you are seeing is networking support, not device support.
>>
>> Like 
>> Packet Socket
>> IP: tunneling
>>
>> and what not.
>>
>>
>>
>> On Tue, 2007-08-21 at 07:09 -0700, Vivek-Kumar Gupta wrote:
>>     
>>> Hi Everybody,
>>>
>>>  
>>>
>>> I am using busy box for embedded device.
>>>
>>> I am facing a peculiar problem.
>>>
>>>  
>>>
>>> I want to my board to boot with network module. 
>>>
>>> When kernel starts uncompressing, messages on console comes like
>>>
>>> ====
>>>
>>> NET: Registered protocol family 2
>>>
>>>  IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
>>>
>>>  TCP established hash table entries: 2048 (order: 1, 8192 bytes)
>>>
>>>  TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
>>>
>>>  TCP: Hash tables configured (established 2048 bind 1024)
>>>
>>>  TCP reno registered
>>>
>>> ....
>>>
>>>  
>>>
>>> NET: Registered protocol family 1
>>>
>>> NET: Registered protocol family 10
>>>
>>>  NET: Registered protocol family 17
>>>
>>> NET: Registered protocol family 15
>>>
>>> ====
>>>
>>>  
>>>
>>> This suggests that network module is being loaded by kernel.
>>>
>>> I have compiled Ethernet as module. I want to enable network module
>>> after kernel boots ( post kernel) via some script.
>>>
>>> I have modified the /etc/modprobe.conf, rc.sysinit so that init
>>> process don't load network module, but this modification stopped the
>>> network services.
>>>
>>>  
>>>
>>> Can any one help me how to disable network module while kernel is
>>> booting and enable it again after kernel boots.
>>>
>>> Thanks in advance.
>>>
>>>  


From tefyxcegmkow at spammotel.com  Wed Aug 22 06:06:24 2007
From: tefyxcegmkow at spammotel.com (wimpunk)
Date: Wed, 22 Aug 2007 15:06:24 +0200
Subject: run-parts problem on busybox 1.6.1
Message-ID: <gvotp4-101.ln1@l29.abba.lin.vlaanderen.be>

I get this error:
 > run-parts: unrecognized option `--arg=start'
> BusyBox v1.6.1 (2007-08-22 14:49:37 CEST) multi-call binary
> 
> Usage: run-parts [-t] [-a ARG] [-u MASK] DIRECTORY
> 
> Run a bunch of scripts in a directory
> 
> Options:
>         -t      Prints what would be run, but does not actually run anything
>         -a ARG  Pass ARG as an argument for every program invoked
>         -u MASK Set the umask to MASK before executing every program
> 
when trying to run run-parts as:
> run-parts -a start /etc/rc.d
with long arguments disabled.

anyone a suggestion what's going wrong?

kind regards,

wimpunk.


From rep.dot.nop at gmail.com  Wed Aug 22 06:29:33 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Wed, 22 Aug 2007 15:29:33 +0200
Subject: disable network module at boot time
In-Reply-To: <36B0F7CCEC523942ACBB99209FBB3C2F79C35F@sc-exch02.marvell.com>
References: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>
	<1187708867.21367.6.camel@localhost.localdomain>
	<36B0F7CCEC523942ACBB99209FBB3C2F79C2BF@sc-exch02.marvell.com>
	<46CC0E4F.3070106@arcor.de>
	<36B0F7CCEC523942ACBB99209FBB3C2F79C35F@sc-exch02.marvell.com>
Message-ID: <20070822132933.GA10289@aon.at>

On Wed, Aug 22, 2007 at 04:27:34AM -0700, Vivek-Kumar Gupta wrote:
>Regarding ep93xx-eth, I just mean to say that, I am using Cirrus logic
>board, and I have also seen ep93xx_eth.c, which generates ep93xx-eth
>driver.
>I am searching ep93xx-eth in booting scripts to turn OFF the Network
>Support from kernel boot. Well my doubt is cleared by Brian, thanks.
>Well now I am looking for some way for disabling Network Support in boot
>time then enable it after kernel boot.
>
>As far as compiling TCP/IP stack as a module, is a good suggestion, but
>I have checked (#make ep=9307a linux-config => opens linux
>configurations) that, but it seems that there is no such option.
>
>I really don't know who's cup of tea is this, busybox or linux kernel ?
>I suppose busy box provides basic infrastructure for kernel to run.

Unless you plugged a libc which is able to run on bare metal into
busybox (i demand to see that patch ;) it's just the opposite:
The kernel provides infrastructure for busybox so userspace (e.g.
busybox) can do various things.

Obviously anything before "Freeing unused kernel memory:" is done by the
kernel. Then userspace takes over.

PS: Last time i looked, you couldn't build ipv4 support modular, lkml
would be the right place to ask (or send patches to) about this.
HTH,

From sh4d0wstr1f3 at yahoo.com  Wed Aug 22 06:37:35 2007
From: sh4d0wstr1f3 at yahoo.com (S H)
Date: Wed, 22 Aug 2007 06:37:35 -0700 (PDT)
Subject: busybox cp -R sub sub
Message-ID: <179566.73981.qm@web50406.mail.re2.yahoo.com>

I've been following bug 0001412 ("cp -a allows copy of a directory into self"), and was wondering if anyone on the list could shed light on what problems were introduced by Chris Larson's r8517 that led Erik Andersen to revert it in r8547. In a list message
(http://www.busybox.net/lists/busybox/2004-February/010884.html)
andersen indicated that the change caused many problems, but didn't specify what they were.

The test case:

% busybox-cp [ -R | -a ] sub sub 

Results in a repeatedly created subdirectory hierarchy until getcwd(2) runs out of space, too many files are open, etc. This behavior is identical to cp in FreeBSD 6.2 (likely earlier and later as well).

% coreutils-cp [-R | -a ] sub sub

Results in the message:
"cannot copy a directory `sub' into itself `sub/sub' "

The directory 'sub/sub' was created, but no 'sub/sub/sub/sub' ...

I think this behavior is more desirible. I'll be the first to agree that the coreutils logic is non-trivial (I've been walking both sets of code for a couple of days now). coreutils cp seems to prevent:

% cp dir dir
% cp dir dir/sub/dir
% cp dir (link->dir)

r8517 patch also seems to prevent the same things. In my testing, I haven't
encountered any problems yet; so I'm hoping someone could point out at
least one problem with the r8517 patch.



Thanks for your time.



      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

From glhs329 at gmail.com  Wed Aug 22 07:10:35 2007
From: glhs329 at gmail.com (glhs329 at gmail.com)
Date: Wed, 22 Aug 2007 10:10:35 -0400
Subject: telnetd doesn't provide REMOTEHOST environment variable?
Message-ID: <7a95bc7b0708220710y666da9b2k7ae279b2ccda1032@mail.gmail.com>

My application wants/needs to know the address of the host that's
connected via telnet, but the REMOTEHOST variable doesn't seem to be
provided. Was this an active decision? Oversight? On the TODO list?

I've written a patch that works for my situation. Is this something
the group might be interested in? If it is of interest, should it be a
configurable option?

From brian.austin at cirrus.com  Wed Aug 22 08:06:15 2007
From: brian.austin at cirrus.com (Brian Austin)
Date: Wed, 22 Aug 2007 10:06:15 -0500
Subject: disable network module at boot time
In-Reply-To: <36B0F7CCEC523942ACBB99209FBB3C2F79C2BF@sc-exch02.marvell.com>
References: <36B0F7CCEC523942ACBB99209FBB3C2F79BEEA@sc-exch02.marvell.com>
	<1187708867.21367.6.camel@localhost.localdomain>
	<36B0F7CCEC523942ACBB99209FBB3C2F79C2BF@sc-exch02.marvell.com>
Message-ID: <1187795175.21367.22.camel@localhost.localdomain>

Are you building network support as modules?


On Tue, 2007-08-21 at 20:31 -0700, Vivek-Kumar Gupta wrote:
> Hi Brian,
> I have never seen these lines in console logs
> ep93xx-eth version 0.1 loading
> eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.
> Well I searched "ep93xx-eth" a lot in the scripts where it is loaded but
> I can't figure out.
> 
> I just want to Disable Network Support at boot time so that boot time
> can be Reduced. Then enable it again after boot.
> 
> If you can provide me some more insight, that will be great.
> 
> 
> Regards,
> Vivek :-
> -----Original Message-----
> From: Brian Austin [mailto:brian.austin at cirrus.com] 
> Sent: Tuesday, August 21, 2007 8:38 PM
> To: Vivek-Kumar Gupta
> Cc: busybox at busybox.net
> Subject: Re: disable network module at boot time
> 
> That means your network subsystem drivers are loading.  Not the physical
> Ethernet Device.
> 
> For a device you should see something like this.
> 
> ep93xx-eth version 0.1 loading
> eth0: ep93xx on-chip ethernet, IRQ 39, 00:0e:3a:11:22:33.
> 
> 
> what you are seeing is networking support, not device support.
> 
> Like 
> Packet Socket
> IP: tunneling
> 
> and what not.
> 
> 
> 
> On Tue, 2007-08-21 at 07:09 -0700, Vivek-Kumar Gupta wrote:
> > Hi Everybody,
> > 
> >  
> > 
> > I am using busy box for embedded device.
> > 
> > I am facing a peculiar problem.
> > 
> >  
> > 
> > I want to my board to boot with network module. 
> > 
> > When kernel starts uncompressing, messages on console comes like
> > 
> > ====
> > 
> > NET: Registered protocol family 2
> > 
> >  IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> > 
> >  TCP established hash table entries: 2048 (order: 1, 8192 bytes)
> > 
> >  TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> > 
> >  TCP: Hash tables configured (established 2048 bind 1024)
> > 
> >  TCP reno registered
> > 
> > ....
> > 
> >  
> > 
> > NET: Registered protocol family 1
> > 
> > NET: Registered protocol family 10
> > 
> >  NET: Registered protocol family 17
> > 
> > NET: Registered protocol family 15
> > 
> > ====
> > 
> >  
> > 
> > This suggests that network module is being loaded by kernel.
> > 
> > I have compiled Ethernet as module. I want to enable network module
> > after kernel boots ( post kernel) via some script.
> > 
> > I have modified the /etc/modprobe.conf, rc.sysinit so that init
> > process don't load network module, but this modification stopped the
> > network services.
> > 
> >  
> > 
> > Can any one help me how to disable network module while kernel is
> > booting and enable it again after kernel boots.
> > 
> > Thanks in advance.
> > 
> >  
> > 
> > Regards,
> > 
> > Vivek Kumar Gupta
> > 
> > Marvell Semiconductor | 77A, IFFCO ROAD | SECTOR 18 | GURGAON - 122
> > 015 | India.
> > 
> > (: (Work) +91-124-4516954 | 7: (Fax) +91-124-4516970 |
> > *: vgupta at marvell.com
> > 
> >  
> > 
> > 
> > _______________________________________________
> > busybox mailing list
> > busybox at busybox.net
> > http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
> 
> 



From simon at alcove.fr  Thu Aug 23 03:05:41 2007
From: simon at alcove.fr (simon at alcove.fr)
Date: Thu, 23 Aug 2007 12:05:41 +0200 (CEST)
Subject: [PATCH] ifupdown and allow-hotplug
Message-ID: <15056.62.39.9.251.1187863541.squirrel@webmail.alcove.fr>

Hello,

Here a small patch for the ifupdown applet. It add support for the
allow-hotplug option.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-svn-r19659-ifupdown-allow-hotplug.patch
Type: text/x-c
Size: 5896 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070823/8a779510/attachment.bin 

From rep.dot.nop at gmail.com  Thu Aug 23 04:46:07 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 23 Aug 2007 13:46:07 +0200
Subject: [PATCH] ifupdown and allow-hotplug
In-Reply-To: <15056.62.39.9.251.1187863541.squirrel@webmail.alcove.fr>
References: <15056.62.39.9.251.1187863541.squirrel@webmail.alcove.fr>
Message-ID: <20070823114607.GM11697@aon.at>

On Thu, Aug 23, 2007 at 12:05:41PM +0200, simon at alcove.fr wrote:
>Hello,
>
>Here a small patch for the ifupdown applet. It add support for the
>allow-hotplug option.
>
>Simon
>diff -r a75029f7bc4b include/usage.h
>--- a/include/usage.h	Thu Aug 23 11:47:23 2007 +0200
>+++ b/include/usage.h	Thu Aug 23 11:47:40 2007 +0200
>@@ -1423,13 +1423,14 @@
>        "[-ahinv] ifaces..."
> #define ifup_full_usage \
>        "Options:\n" \
>-       "	-a	De/configure all interfaces automatically\n" \
>-       "	-i FILE	Use FILE for interface definitions\n" \
>-       "	-n	Print out what would happen, but don't do it\n" \
>-       "		(note that this option doesn't disable mappings)\n" \
>-       "	-v	Print out what would happen before doing it\n" \
>-       "	-m	Don't run any mappings\n" \
>-       "	-f	Force de/configuration"
>+       "	-a		De/configure all interfaces automatically\n" \
>+       "	-i FILE		Use FILE for interface definitions\n" \
>+       "	-n		Print out what would happen, but don't do it\n" \
>+       "			(note that this option doesn't disable mappings)\n" \
>+       "	-v		Print out what would happen before doing it\n" \
>+       "	-m		Don't run any mappings\n" \
>+       "	-f		Force de/configuration\n" \
>+       "	--allow CLASS 	ignore non-\"allow-CLASS\" interfaces"

The long form should only be in the help-text if IFUPDOWN_LONG_OPTIONS
are set, -A otherwise (see below).
> 
> #define ifdown_trivial_usage \
>        "[-ahinv] ifaces..."
>@@ -1441,7 +1442,8 @@
>        "		(note that this option doesn't disable mappings)\n" \
>        "	-v	Print out what would happen before doing it\n" \
>        "	-m	Don't run any mappings\n" \
>-       "	-f	Force de/configuration"
>+       "	-f	Force de/configuration\n" \
>+       "	--allow CLASS 	ignore non-\"allow-CLASS\" interfaces"

Ditto.
> 
> #define inetd_trivial_usage \
>        "[-f] [-q len] [conf]"
>diff -r a75029f7bc4b networking/Config.in
>--- a/networking/Config.in	Thu Aug 23 11:47:23 2007 +0200
>+++ b/networking/Config.in	Thu Aug 23 11:47:40 2007 +0200
>@@ -333,6 +333,14 @@ config FEATURE_IFUPDOWN_EXTERNAL_DHCP
> 	  Otherwise, if udhcpc applet is enabled, it is used.
> 	  Otherwise, ifup/ifdown will have no support for DHCP.
> 
>+config FEATURE_IFUPDOWN_LONG_OPTIONS
>+	bool "Enable long options support"
>+	default n
>+	depends on IFUPDOWN

depends on IFUPDOWN && GETOPT_LONG

Please add "-A" as short option for --allow here and to the upstream
version for consistency.
>+	help
>+	  This enables the long options upport for the ifup and ifdown 
>+	  utilities.
>+
> config INETD
> 	bool "inetd"
> 	default n
>diff -r a75029f7bc4b networking/ifupdown.c
>--- a/networking/ifupdown.c	Thu Aug 23 11:47:23 2007 +0200
>+++ b/networking/ifupdown.c	Thu Aug 23 11:47:40 2007 +0200
>@@ -769,7 +783,7 @@ static struct interfaces_file_t *read_in
> 
> 			debug_noise("iface %s %s %s\n", currif->iface, address_family_name, method_name);
> 			currently_processing = IFACE;
>-		} else if (strcmp(firstword, "auto") == 0) {
>+		} else if ((strcmp(firstword, "auto") == 0) || (strcmp(firstword, "allow-auto") == 0)) {

Please convert all these strcmp to index_in_strings()
> 			while ((firstword = next_word(&buf_ptr)) != NULL) {
> 
> 				/* Check the interface isnt already listed */
>@@ -1232,8 +1273,9 @@ int ifupdown_main(int argc, char **argv)
> 			}
> 		}
> #endif
>-
>+		

The above adds superflous whitespace, please drop this.
> 		iface_list = defn->ifaces;
>+
> 		while (iface_list) {
> 			currif = (struct interface_defn_t *) iface_list->data;
> 			if (strcmp(liface, currif->iface) == 0) {

From joe.ogulin at baesystems.com  Thu Aug 23 11:34:00 2007
From: joe.ogulin at baesystems.com (Joe Ogulin)
Date: Thu, 23 Aug 2007 14:34:00 -0400
Subject: Incorrect error reported by "cp"
Message-ID: <1187894042.13474.10.camel@icerink.xts.bae-it.na.baesystems.com>

Everything's here:

http://bugs.busybox.net/view.php?id=1412

-- 
Joe Ogulin
Sr. Secure Systems Analyst
BAE Systems IT

Environmental statement:
This message is made of 100% recycled electrons.

Disclaimer:  This message is purely my fault.


From joe.ogulin at baesystems.com  Thu Aug 23 11:35:09 2007
From: joe.ogulin at baesystems.com (Joe Ogulin)
Date: Thu, 23 Aug 2007 14:35:09 -0400
Subject: cp reports incorrect error (resend with correction)
Message-ID: <1187894109.13474.12.camel@icerink.xts.bae-it.na.baesystems.com>

Sorry... grabbed the wrong link in the previous message

This is the correct one:
http://bugs.busybox.net/view.php?id=1470

-- 
Joe Ogulin
Sr. Secure Systems Analyst
BAE Systems IT

Environmental statement:
This message is made of 100% recycled electrons.

Disclaimer:  This message is purely my fault.


From sh4d0wstr1f3 at yahoo.com  Thu Aug 23 14:16:00 2007
From: sh4d0wstr1f3 at yahoo.com (S H)
Date: Thu, 23 Aug 2007 14:16:00 -0700 (PDT)
Subject: [PATCH] (against 1.4.2)  prevent cp of dir into itself (reprise)
Message-ID: <313979.36450.qm@web50402.mail.re2.yahoo.com>

cp -R sub sub results in a nasty subdirectory tree (see http://bugs.busybox.net/view.php?id=1412). coreutils cp stops it before it goes out of control. FreeBSD ignores it. I prefer the coreutils behavior.

This patch approximates the coreutils behavior to the best of my knowledge, without some of the issues found in r8517.  It works by recording the source directories which are visited;
because no parent of dest can occur in source. This will only happen
with directories; and since there can't be hardlinks to directories,
this should never cause problems with the other code that uses the
ino_dev_hashtable.


The patch is against 1.4.2; if anyone is seriously interested in this, I'm happy to port it up to svn HEAD. I'm primarily seeking comments that this is on a better path than the original solution, and whether or not developers are genuinely interested in emulating the coreutils behavior in this case.

Thanks for your time.




      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.quintessence.r2446M.2
Type: application/octet-stream
Size: 1355 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070823/a6983725/attachment.obj 

From simon at alcove.fr  Fri Aug 24 03:17:48 2007
From: simon at alcove.fr (simon at alcove.fr)
Date: Fri, 24 Aug 2007 12:17:48 +0200 (CEST)
Subject: [PATCH] ifupdown and allow-hotplug (with corrections)
Message-ID: <12859.62.39.9.251.1187950668.squirrel@webmail.alcove.fr>

Hello,

A new patch version to add the allow-hotplug support to the ifupdown applet.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-svn-r19673-ifupdown-allow-hotplug.patch
Type: text/x-c
Size: 6136 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070824/7dd05a7d/attachment.bin 

From vda.linux at googlemail.com  Fri Aug 24 03:59:26 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 24 Aug 2007 11:59:26 +0100
Subject: 1.7.0 is out
Message-ID: <200708241159.26505.vda.linux@googlemail.com>

Hi people,

I uploaded 1.7.0 earlier today. Enjoy.

GPG signatures are not there yet, will create them tomorrow.

===========================================================
24 August 2007 -- BusyBox 1.7.0 (unstable)

BusyBox 1.7.0. (svn, patches, how to add a patch)

Applets which had many changes since 1.6.x:

httpd:

    * works in standalone mode on NOMMU machines now (partly by Alex Landau <landau_alex at yahoo.com>)
    * indexer example is rewritten in C
    * optional support for error pages (by Pierre Metras <genepi at sympatico.ca>)
    * stop reading headers using 1-byte reads
    * new option -v[v]: prints client addresses, HTTP codes returned, URLs
    * extended -p PORT to -p [IP[v6]:]PORT
    * sendfile support
    * add support for Status: CGI header
    * fix CGI handling bug (we were closing wrong fd)
    * CGI I/O loop still doesn't look 100% ok to me... 

udhcp[cd]:

    * add -f "foreground" and -S "syslog" options
    * fixed "ifupdown + udhcpc_without_pidpile_creation" bug
    * new config option "Rewrite the lease file at every new acknowledge" (Mats Erik Andersson <mats at blue2net.com> (Blue2Net AB))
    * consistently treat server_config.start/end IPs as host-order
    * fix IP parsing for 64bit machines
    * fix unsafe hton macro usage in read_opt()
    * do not chdir to / when daemonizing 

top, ps, killall, pidof

    * simpler loadavg processing
    * truncate usernames to 8 chars
    * fix non-CONFIG_DESKTOP ps -ww (by rockeychu)
    * improve /proc/PID/cmdinfo reading code
    * use cmdline, not comm field (fixes problems with re-execed applets showing as processes with name "exe", and not being found by pidof/killall by applet name)
    * reduce CPU usage in decimal conversion (optional) (corresponding speedup on kernel side is accepted in mainline Linux kernel, yay!)
    * make percentile (0.1%) calculations configurable
    * add config option and code for global CPU% display
    * reorder columns, so that [P]PIDs are together and VSZ/%MEM are together - makes more sense 

Build system improvements: doesn't link against libraries we don't need,
generates verbose link output and map file, allows for custom
link stripts (useful for removing extra padding, among other things).

Code and data size in comparison with 1.6.1:

Equivalent .config, i386 glibc dynamic builds:
   text    data     bss     dec     hex filename
 672671    2768   16808  692247   a9017 busybox-1.6.1/busybox
 662948    2660   13528  679136   a5ce0 busybox-1.7.0/busybox
 662783    2631   13416  678830   a5bae busybox-1.7.0/busybox.customld

Same .config built against static uclibc:
 765021    1059   11020  777100   bdb8c busybox-1.7.0/busybox_uc

Code/data shrink done in applets: crond, hdparm, dd, cal, od, nc, expr,
uuencode, test, slattach, diff, ping, tr, syslogd, hwclock, zcip, find,
pidof, ash, uudecode, runit/*, in libbb.

New applets:

    * pscan, expand, unexpand (from Tito <farmatito at tiscali.it>)
    * setfiles, restorecon (by Yuichi Nakamura <ynakam at hitachisoft.jp>)
    * chpasswd (by Alexander Shishkin <virtuoso at slind.org>)
    * slattach, ttysize 

Unfortunately, not much work is done on shells. This was mostly stalled
by lack of time (read: laziness) on my part to learn how to adapt
existing qemu-runnable image for a NOMMU architechture (available
on qemu website) for local testing of cross-compiled busybox on my machine.

Other changes since previous release (abridged):

    * addgroup: disallow addgroup -g num user group; make -g 0 work (Tito <farmatito at tiscali.it>)
    * adduser: close /etc/{passwd,shadow} before calling passwd etc. Spotted by Natanael Copa <natanael.copa at gmail.com>
    * arping: -i should be -I, fixed
    * ash: make "jobs | cat" work like in bash (was giving empty output)
    * ash: recognize -l as --login equivalent; do not recognize +-login
    * ash: fix buglet in DEBUG code (Nguyen Thai Ngoc Duy <pclouds at gmail.com>)
    * ash: fix SEGV if type has zero parameters
    * awk: fix -F 'regex' bug (miscounted fields if last field is empty)
    * catv: catv without arguments was trying to use environ as argv (Alex Landau <landau_alex at yahoo.com>)
    * catv: don't die on open error (emit warning)
    * chown/chgrp: completely match coreutils 6.8 wrt symlink handling
    * correct_password: do not print "no shadow passwd..." message
    * crond: don't start sendmail with absolute path, don't report obsolete version (report true bbox version)
    * dd: fix bug where we assume count=INT_MAX when count is unspecified
    * devfsd: sanitization by Tito <farmatito at tiscali.it>
    * echo: fix non-fancy echo
    * fdisk: make it work with big disks (read: typical today's disks) even if CONFIG_LFS is unset
    * find: -context support for SELinux (KaiGai Kohei <kaigai at kaigai.gr.jp>)
    * find: add conditional support for -maxdepth and -regex, make -size match GNU find
    * find: fix build failure on certain configs (found by Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com>)
    * fsck_minix: make it print bb version, not it's own (outdated/irrelevant) one
    * grep: implement -m MAX_MATCHES, fix buglets with context printing
    * grep: fix selection done by FEATURE_GREP_EGREP_ALIAS (Maxime Bizon <mbizon at freebox.fr> (Freebox))
    * hush: add missing dependencies (Maxime Bizon <mbizon at freebox.fr> (Freebox))
    * hush: fix read builtin to not read ahead past EOL and to not use insane amounts of stack
    * ifconfig: make it work with ifaces with interface no. > 255
    * ifup/ifdown: make location of ifstate configurable
    * ifupdown: make netmask parsing smaller and more strict (was accepting 255.0.255.0, 255.1234.0.0 etc...)
    * install: fix -s (strip) option, fix install a b /a/link/to/dir
    * libbb: consolidate ARRAY_SIZE macro (Walter Harms <wharms at bfs.de>)
    * libbb: make /etc/network parsing configurable. -200 bytes when off
    * libbb: nuke BB_GETOPT_ERROR, always die if there are mutually exclusive options
    * libbb: xioctl and friends by Tito <farmatito at tiscali.it>
    * login: optional support for PAM
    * login: make /etc/nologin support configurable (-240 bytes)
    * login: ask passwords even for wrong usernames
    * md5_sha1_sum: fix mishandling when run as /bin/md5sum
    * mdev: add support for firmware loading
    * mdev: work even when CONFIG_SYSFS_DEPRECATED in kernel is off
    * modprobe: add scanning of /lib/modules/`uname -r`/modules.symbols (by Yann E. MORIN)
    * more: fixes by Tristan Schmelcher <tpkschme at engmail.uwaterloo.ca>
    * nc: make connecting to IPv4 from IPv6-enabled hosts easier (was requiring -s local_addr)
    * passwd: fix bug "updating shadow even if user's record is in passwd"
    * patch: fix -p -1 handling
    * patch: fix bad line ending handling (Nguyen Thai Ngoc Duy <pclouds at gmail.com>)
    * ping: display roundtrip times with 1/1000th of ms, not 1/10 ms precision.
    * ping: fix incorrect handling of -I (Iouri Kharon <bc-info at styx.cabel.net>>)
    * ping: fix non-fancy ping6
    * printenv: fix "printenv VAR1 VAR2" bug (spotted by Kalyanatejaswi Balabhadrapatruni <kalyanatejaswi at yahoo.co.in>)
    * ps: fix -Z (by Yuichi Nakamura <ynakam at hitachisoft.jp>)
    * rpm: add optional support for bz2 data. +50 bytes of code
    * rpm: fix bogus "package is not installed" case
    * sed: fix 'q' command handling (by Nguyen Thai Ngoc Duy <pclouds at gmail.com>)
    * start_stop_daemon: NOMMU fixes by Alex Landau <landau_alex at yahoo.com>
    * stat: fix option -Z SEGV
    * strings: strings a b was processing a twice, fix that
    * svlogd: fix timestamping, do not warn if config is missing
    * syslogd, logread: get rid of head pointer, fix logread bug in the process
    * syslogd: do not convert tabs to ^I, set syslog IPC buffer to mode 0644
    * tar: improve OLDGNU compat, make old SUN compat configurable
    * test: fix testing primary expressions like '"-u" = "-u"'
    * uudecode: fix to base64 decode by Jorgen Cederlof <jcz at google.com>
    * vi: multiple fixes by Natanael Copa <natanael.copa at gmail.com>
    * wget: fix bug in base64 encoding (bug 1404). +10 bytes
    * wget: lift 256 chars limitation on terminal width
    * wget, zcip: use monotonic_sec instead of gettimeofday
--
vda

From vda.linux at googlemail.com  Fri Aug 24 07:07:21 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 24 Aug 2007 15:07:21 +0100
Subject: cp reports incorrect error (resend with correction)
In-Reply-To: <1187894109.13474.12.camel@icerink.xts.bae-it.na.baesystems.com>
References: <1187894109.13474.12.camel@icerink.xts.bae-it.na.baesystems.com>
Message-ID: <200708241507.21274.vda.linux@googlemail.com>

On Thursday 23 August 2007 19:35, Joe Ogulin wrote:
> Sorry... grabbed the wrong link in the previous message
>
> This is the correct one:
> http://bugs.busybox.net/view.php?id=1470


> Run this sequence of commands:
> 
> touch /tmp/foo
> busybox cp /tmp/foo /tmp/nonexistent/path/foo
> 
> This is the error message you get:
> cp: cannot remove '/tmp/nonexistent/path/foo': No such file or directory

Which is true. cp couldn't create it. cp decided to try unlink,
and creating again. unlink didn't work either. cp lets you know that.

> What Linux's cp will say is:
> cp: cannot create regular file `/tmp/nonexistent/path/foo': No such file or directory

Read it again.

Do you really think that "I can't create 'foo', it doesn't exist" is better?
From naive point of view it is silly too: "of course it doesn't exist
before you create it!"

I undoubtedly can fix bbox cp to match GNU message, but code will be bigger
and GNU message is still semi-stupid.

For the record: fix should be here:

static int ask_and_unlink(const char *dest, int flags)
{
        ...
        if (unlink(dest) < 0) {

===> if errno == ENOENT or ENOTDIR, explain that *path* is invalid, not filename <===

                bb_perror_msg("cannot remove '%s'", dest);
                return -1; // error
        }
        return 1; // ok (to try again)
}


> If you have DO_POSIX_CP enabled, you will get:
> '/tmp/nonexistent/path/foo' exists

Okay, that will be fixed like this:

--- libbb/copy_file.c   (revision 19673)
+++ libbb/copy_file.c   (working copy)
@@ -22,25 +22,25 @@

 #define DO_POSIX_CP 0  /* 1 - POSIX behavior, 0 - safe behavior */

-
+// errno must be set to relevant value ("why we cannot create dest?")
+// for POSIX mode to give reasonable error message
 static int ask_and_unlink(const char *dest, int flags)
 {
-       // If !DO_POSIX_CP, act as if -f is always in effect - we don't want
-       // "'file' exists" msg, we want unlink to be done (silently unless -i
-       // is also in effect).
-       // This prevents safe way from asking more questions than POSIX does.
 #if DO_POSIX_CP
        if (!(flags & (FILEUTILS_FORCE|FILEUTILS_INTERACTIVE))) {
-               fprintf(stderr, "'%s' exists\n", dest);
+               // Either it exists, or the *path* doesnt exist
+               bb_perror_msg("cannot create '%s'", dest);
                return -1;
        }
 #endif
+       // If !DO_POSIX_CP, act as if -f is always in effect - we don't want
+       // "cannot create" msg, we want unlink to be done (silently unless -i).

        // TODO: maybe we should do it only if ctty is present?
        if (flags & FILEUTILS_INTERACTIVE) {
                // We would not do POSIX insanity. -i asks,
                // then _unlinks_ the offender. Presto.
-               // (No opening without O_EXCL, no unlinks only if -f)
+               // (No "opening without O_EXCL", no "unlink only if -f")
                // Or else we will end up having 3 open()s!
                fprintf(stderr, "%s: overwrite '%s'? ", applet_name, dest);
                if (!bb_ask_confirmation())
@@ -280,6 +280,7 @@
        ) {
                // We are lazy here, a bit lax with races...
                if (dest_exists) {
+                       errno = EEXIST;
                        ovr = ask_and_unlink(dest, flags);
                        if (ovr <= 0)
                                return ovr;

--
vda

From stephane.billiart at gmail.com  Fri Aug 24 06:45:13 2007
From: stephane.billiart at gmail.com (Stephane Billiart)
Date: Fri, 24 Aug 2007 09:45:13 -0400
Subject: 1.7.0 is out
In-Reply-To: <200708241159.26505.vda.linux@googlemail.com>
References: <200708241159.26505.vda.linux@googlemail.com>
Message-ID: <20070824134513.GA25747@salusa.home.net>

On 24/08/07 ? ? 11:59, Denys Vlasenko wrote:
> Hi people,
> 
> I uploaded 1.7.0 earlier today. Enjoy.

[...]

>     * fdisk: make it work with big disks (read: typical today's disks) even if CONFIG_LFS is unset

No, the build fails if LFS is not enabled (my uClibc does not have lseek64).
Attached patch fixes the problem.

-- 
St?phane Billiart                      http://perso.orange.fr/billiart/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdisk.patch
Type: text/x-diff
Size: 491 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070824/ddfcfe55/attachment.bin 

From vda.linux at googlemail.com  Fri Aug 24 08:30:31 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 24 Aug 2007 16:30:31 +0100
Subject: 1.7.0 is out
In-Reply-To: <20070824134513.GA25747@salusa.home.net>
References: <200708241159.26505.vda.linux@googlemail.com>
	<20070824134513.GA25747@salusa.home.net>
Message-ID: <200708241630.31898.vda.linux@googlemail.com>

On Friday 24 August 2007 14:45, Stephane Billiart wrote:
> On 24/08/07 ? ? 11:59, Denys Vlasenko wrote:
> > Hi people,
> >
> > I uploaded 1.7.0 earlier today. Enjoy.
>
> [...]
>
> >     * fdisk: make it work with big disks (read: typical today's disks)
> > even if CONFIG_LFS is unset
>
> No, the build fails if LFS is not enabled (my uClibc does not have
> lseek64). Attached patch fixes the problem.

But we need to seek past 2 GB there. 2 GB is to small even for USB sticks
these days. People who don't need to support media > 2GB probably don't
compile in fdisk anyway ==> people who do compile in fdisk mosk likely
_do_ want to handle media > 2 GB.

Does your uclibc have _any_ means of doing that seek? _llseek?

Please share your uclibc .config (probably bz2 it to fit under
ml size limit).
--
vda

From stephane.billiart at gmail.com  Fri Aug 24 11:06:49 2007
From: stephane.billiart at gmail.com (Stephane Billiart)
Date: Fri, 24 Aug 2007 14:06:49 -0400
Subject: 1.7.0 is out
In-Reply-To: <200708241630.31898.vda.linux@googlemail.com>
References: <200708241159.26505.vda.linux@googlemail.com>
	<20070824134513.GA25747@salusa.home.net>
	<200708241630.31898.vda.linux@googlemail.com>
Message-ID: <20070824180649.GB25747@salusa.home.net>

On 24/08/07 ? ? 16:30, Denys Vlasenko wrote:
> On Friday 24 August 2007 14:45, Stephane Billiart wrote:
> > On 24/08/07 ? ? 11:59, Denys Vlasenko wrote:
> > > Hi people,
> > >
> > > I uploaded 1.7.0 earlier today. Enjoy.
> >
> > [...]
> >
> > >     * fdisk: make it work with big disks (read: typical today's disks)
> > > even if CONFIG_LFS is unset
> >
> > No, the build fails if LFS is not enabled (my uClibc does not have
> > lseek64). Attached patch fixes the problem.
> 
> But we need to seek past 2 GB there. 2 GB is to small even for USB sticks
> these days. People who don't need to support media > 2GB probably don't
> compile in fdisk anyway ==> people who do compile in fdisk mosk likely
> _do_ want to handle media > 2 GB.

You're right. I only compiled fdisk in busybox on one of my embedded
servers because I wanted to partition some USB keys but they are < 1GB.

> 
> Does your uclibc have _any_ means of doing that seek? _llseek?
> 
> Please share your uclibc .config (probably bz2 it to fit under
> ml size limit).

I do not have my .config online, I might have it on an old CD
backup at home but I cannot be sure (HD crash last year).
One thing I am sure of is that my toolchain is old, gcc 3.3 and uClibc
0.9.27 built in Jan. 2005 without large file support.
It has llseek but not llseek64.

So maybe my patch is only relevant to a few people after all.
I don't mind maitaining it in my own tree as I do for some other software,
it is pretty simple anyway.

-- 
St?phane Billiart                      http://perso.orange.fr/billiart/

From yann.morin.1998 at anciens.enib.fr  Fri Aug 24 12:34:39 2007
From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN)
Date: Fri, 24 Aug 2007 21:34:39 +0200
Subject: 1.7.0 is out
In-Reply-To: <200708241159.26505.vda.linux@googlemail.com>
References: <200708241159.26505.vda.linux@googlemail.com>
Message-ID: <200708242134.39292.yann.morin.1998@anciens.enib.fr>

Hello All!

On Friday 24 August 2007 12:59, Denys Vlasenko wrote:
> I uploaded 1.7.0 earlier today. Enjoy.

GOOD! I'll have something to work on this WE! As if it was not loaded enough!

Thanks, and keep up the good work at maintaining busybox, Denys!
And thanks to all others for your contributions, of course! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< ?_? >==-- ?------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
?------------------------------?-------?------------------?--------------------?


From yann.morin.1998 at anciens.enib.fr  Fri Aug 24 12:39:19 2007
From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN)
Date: Fri, 24 Aug 2007 21:39:19 +0200
Subject: svn commit: trunk/busybox/docs/busybox.net
In-Reply-To: <20070824143100.761C1A65F4@busybox.net>
References: <20070824143100.761C1A65F4@busybox.net>
Message-ID: <200708242139.19794.yann.morin.1998@anciens.enib.fr>

Hello!

On Friday 24 August 2007 16:31, aldot at busybox.net wrote:
> Author: aldot
> Date: 2007-08-24 07:30:59 -0700 (Fri, 24 Aug 2007)
> New Revision: 19688
> Log:
> - obfuscate addrs a little bit
[--SNIP--]
>  	<li>modprobe: add scanning of /lib/modules/`uname -r`/modules.symbols (by Yann E. MORIN)

While you are at it, would you mind adding my email address, please?

Regards,
Yann E. MORIN.

PS. Can't remember who aldot is. I think it's you, Bernhard.
    Apologies if I have it wrong...
YEM.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< ?_? >==-- ?------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
?------------------------------?-------?------------------?--------------------?


From rep.dot.nop at gmail.com  Sat Aug 25 04:01:10 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 25 Aug 2007 13:01:10 +0200
Subject: svn commit: trunk/busybox/docs/busybox.net
In-Reply-To: <200708242139.19794.yann.morin.1998@anciens.enib.fr>
References: <20070824143100.761C1A65F4@busybox.net>
	<200708242139.19794.yann.morin.1998@anciens.enib.fr>
Message-ID: <20070825110110.GP11697@aon.at>

On Fri, Aug 24, 2007 at 09:39:19PM +0200, Yann E. MORIN wrote:
>Hello!
>
>On Friday 24 August 2007 16:31, aldot at busybox.net wrote:
>> Author: aldot
>> Date: 2007-08-24 07:30:59 -0700 (Fri, 24 Aug 2007)
>> New Revision: 19688
>> Log:
>> - obfuscate addrs a little bit
>[--SNIP--]
>>  	<li>modprobe: add scanning of /lib/modules/`uname -r`/modules.symbols (by Yann E. MORIN)
>
>While you are at it, would you mind adding my email address, please?

done.

>PS. Can't remember who aldot is. I think it's you, Bernhard.
>    Apologies if I have it wrong...
>YEM.

yes, that's me.

cheers,

From rep.dot.nop at gmail.com  Sat Aug 25 06:58:31 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 25 Aug 2007 15:58:31 +0200
Subject: 1.7.0 is out
In-Reply-To: <200708241630.31898.vda.linux@googlemail.com>
References: <200708241159.26505.vda.linux@googlemail.com>
	<20070824134513.GA25747@salusa.home.net>
	<200708241630.31898.vda.linux@googlemail.com>
Message-ID: <20070825135831.GR11697@aon.at>

On Fri, Aug 24, 2007 at 04:30:31PM +0100, Denys Vlasenko wrote:
>On Friday 24 August 2007 14:45, Stephane Billiart wrote:
>> On 24/08/07 ? ? 11:59, Denys Vlasenko wrote:
>> > Hi people,
>> >
>> > I uploaded 1.7.0 earlier today. Enjoy.
>>
>> [...]
>>
>> >     * fdisk: make it work with big disks (read: typical today's disks)
>> > even if CONFIG_LFS is unset
>>
>> No, the build fails if LFS is not enabled (my uClibc does not have
>> lseek64). Attached patch fixes the problem.
>
>But we need to seek past 2 GB there. 2 GB is to small even for USB sticks

No, we don't. LFS is turned off, so we *know* that we only support <2GB.

>these days. People who don't need to support media > 2GB probably don't
>compile in fdisk anyway ==> people who do compile in fdisk mosk likely
>_do_ want to handle media > 2 GB.

Of course i want to use fdisk on my 1GB block-device and of course i
don't use LFS on it (nor NFS or any other networked filesystem since i'd
have LFS on for those anyway).

>
>Does your uclibc have _any_ means of doing that seek? _llseek?

No, because i (the user) turned LFS off explicitely.
>
>Please share your uclibc .config (probably bz2 it to fit under
>ml size limit).

Just turn off LFS support (see buildroot for such configs that i use).

From vda.linux at googlemail.com  Sat Aug 25 11:13:26 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sat, 25 Aug 2007 19:13:26 +0100
Subject: [patch][resend] Domain assignment support for
	SELinux/AppArmor/LIDS
In-Reply-To: <20070821083522.7AC0.YNAKAM@hitachisoft.jp>
References: <20070821083522.7AC0.YNAKAM@hitachisoft.jp>
Message-ID: <200708251913.26851.vda.linux@googlemail.com>

On Tuesday 21 August 2007 00:38, Yuichi Nakamura wrote:
> Hello.
> Denis said please resend patches,
> So we would like to send this mail again.

Applied, thanks!

> 3. Limitation
> Programs that are used as interpreter can not be installed as script
> wrapper. It is due to limitation of exec(interpreter can not be called
> twice). For example, /bin/sh can not be installed as script wrapper.
> If /bin/sh is installed as script wrapper, shell scripts do not run.
> In interpreting #!/bin/sh

Interpreters are not typically assigned non-default domain, right?
So this is not a big problem.

Otherwise, you may try to "fix" this on kernel level, by allowing
"recursive" #!/path/interpreter (with a limit on depth, of course).
--
vda

From vda.linux at googlemail.com  Sat Aug 25 11:37:22 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sat, 25 Aug 2007 19:37:22 +0100
Subject: fdisk with big disks (was Re: 1.7.0 is out)
In-Reply-To: <20070825135831.GR11697@aon.at>
References: <200708241159.26505.vda.linux@googlemail.com>
	<200708241630.31898.vda.linux@googlemail.com>
	<20070825135831.GR11697@aon.at>
Message-ID: <200708251937.22299.vda.linux@googlemail.com>

On Saturday 25 August 2007 14:58, Bernhard Fischer wrote:
> >> No, the build fails if LFS is not enabled (my uClibc does not have
> >> lseek64). Attached patch fixes the problem.
> >
> >But we need to seek past 2 GB there. 2 GB is too small even for USB sticks
>
> No, we don't. LFS is turned off, so we *know* that we only support <2GB.
>
> >these days. People who don't need to support media > 2GB probably don't
> >compile in fdisk anyway ==> people who do compile in fdisk mosk likely
> >_do_ want to handle media > 2 GB.
>
> Of course i want to use fdisk on my 1GB block-device and of course i
> don't use LFS on it (nor NFS or any other networked filesystem since i'd
> have LFS on for those anyway).
>
> >Does your uclibc have _any_ means of doing that seek? _llseek?
>
> No, because i (the user) turned LFS off explicitely.

Please see:

http://bugs.busybox.net/view.php?id=1333

The problem is that CONFIG_LFS are too coarse. It's possible
(and I'd say "typical") that people turn off LFS, but want
*some* utilities to be special. Come on, admit that < 2 GB disk
size is a real limitation.

The solution is simple: introduce CONFIG_FEATURE_FDISK_LFS
which overrides CONFIG_LFS just for fdisk.

This way you *and* submitter of bug 1333 will be happy.
--
vda

From vda.linux at googlemail.com  Sat Aug 25 14:03:57 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sat, 25 Aug 2007 22:03:57 +0100
Subject: [PATCH] (against 1.4.2)  prevent cp of dir into itself (reprise)
In-Reply-To: <313979.36450.qm@web50402.mail.re2.yahoo.com>
References: <313979.36450.qm@web50402.mail.re2.yahoo.com>
Message-ID: <200708252203.57639.vda.linux@googlemail.com>

On Thursday 23 August 2007 22:16, S H wrote:
> cp -R sub sub results in a nasty subdirectory tree (see
> http://bugs.busybox.net/view.php?id=1412). coreutils cp stops it before it
> goes out of control. FreeBSD ignores it. I prefer the coreutils behavior.
>
> This patch approximates the coreutils behavior to the best of my knowledge,
> without some of the issues found in r8517.  It works by recording the
> source directories which are visited; because no parent of dest can occur
> in source. This will only happen with directories; and since there can't be
> hardlinks to directories, this should never cause problems with the other
> code that uses the ino_dev_hashtable.
>
>
> The patch is against 1.4.2; if anyone is seriously interested in this, I'm
> happy to port it up to svn HEAD. I'm primarily seeking comments that this
> is on a better path than the original solution, and whether or not
> developers are genuinely interested in emulating the coreutils behavior in
> this case.

I would rather no use inode_hashtable. Who knows how deep that tree is,
and inode hashtable actually remembers *each pathname*!!

Please download svn version (yes, it has changed since 1.7.0 in that area),
apply attached patch and try your testcases. Does that work?

The solution is a hack (need to avoid using static), but the basic idea is
to remember a dev and inode of top-level created directory,
and refuse to copy it if it turns up as a source later.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5.patch
Type: text/x-diff
Size: 928 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070825/c3c44b7c/attachment.bin 

From vda.linux at googlemail.com  Sat Aug 25 14:27:52 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sat, 25 Aug 2007 22:27:52 +0100
Subject: [PATCH] ifupdown and allow-hotplug (with corrections)
In-Reply-To: <12859.62.39.9.251.1187950668.squirrel@webmail.alcove.fr>
References: <12859.62.39.9.251.1187950668.squirrel@webmail.alcove.fr>
Message-ID: <200708252227.52363.vda.linux@googlemail.com>

On Friday 24 August 2007 11:17, simon at alcove.fr wrote:
> Hello,
>
> A new patch version to add the allow-hotplug support to the ifupdown
> applet.

Can you write up a rationale why do you continue to use and patch up
ifupdown to try to handle even more of zillions of possible network
configurations?

It's a "mission impossible" and I suggest to step back from keyboard
for an hour and re-think how do you handle network
(re,de)configuration in general.

But don't think about *your* particular configuration only.
Don't devise ad-hoc solutions, they don't pay off long-term.

Throw in openvpn tunnels, pppd interfaces and other things which tend
to pop up and vanish in random order, and also imagine that you have
some web-driven firewall reconfiguration interface which allows you
to block/upblock traffic to selected IP address(es) and ports.
It should be operable at anytime and take effect withint few seconds
after pressing [Apply] on a web page, not after the box is rebooted.

I had it working on one of my machines sometime in the past, and
I still have it all sitting in a backup.
--
vda

From cristian.ionescu-idbohrn at axis.com  Sat Aug 25 15:10:33 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sun, 26 Aug 2007 00:10:33 +0200 (CEST)
Subject: [rfc] sed option `-i' (edit in place)
Message-ID: <0708252315150.8632@somehost>

AFAICS, that option creates a temporary file on the same fs as the edited
file resides on.  And that is indeed optimal, but at the same time
somewhat unfortunate for embedded systems.

Embedded systems usualy place editable files on flash fs and those fs get
used out very much faster compared to real hdfs.  IMO, a better solution
for such cases would be to place the temporary files on a ramfs (usualy
tmpfs) and overrite the original file at the end of the editing session.
This operation is indeed more complicated, but the infrastructure is
available (libbb/copy_file and libbb/remove_file.c).  Obviously this
should be optional and configurable.

What do you think?


Cheers,

-- 
Cristian

From vda.linux at googlemail.com  Sun Aug 26 07:48:12 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 26 Aug 2007 15:48:12 +0100
Subject: [rfc] sed option `-i' (edit in place)
In-Reply-To: <0708252315150.8632@somehost>
References: <0708252315150.8632@somehost>
Message-ID: <200708261548.12518.vda.linux@googlemail.com>

On Saturday 25 August 2007 23:10, Cristian Ionescu-Idbohrn wrote:
> AFAICS, that option creates a temporary file on the same fs as the edited
> file resides on.  And that is indeed optimal, but at the same time
> somewhat unfortunate for embedded systems.
>
> Embedded systems usualy place editable files on flash fs and those fs get
> used out very much faster compared to real hdfs.  IMO, a better solution
> for such cases would be to place the temporary files on a ramfs (usualy
> tmpfs) and overrite the original file at the end of the editing session.
> This operation is indeed more complicated, but the infrastructure is
> available (libbb/copy_file and libbb/remove_file.c).  Obviously this
> should be optional and configurable.
>
> What do you think?

I think you mean

sed ... <"$file" >/ramfs/tmp-$$ && mv /ramfs/tmp-$$ "$file"

This is what shells are for - to avoid bloating programs with all imaginable 
small improvements.
--
vda

From cristian.ionescu-idbohrn at axis.com  Sun Aug 26 08:00:19 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sun, 26 Aug 2007 17:00:19 +0200 (CEST)
Subject: [rfc] sed option `-i' (edit in place)
In-Reply-To: <200708261548.12518.vda.linux@googlemail.com>
References: <0708252315150.8632@somehost>
	<200708261548.12518.vda.linux@googlemail.com>
Message-ID: <0708261649490.9465@somehost>

On Sun, 26 Aug 2007, Denys Vlasenko wrote:

> On Saturday 25 August 2007 23:10, Cristian Ionescu-Idbohrn wrote:
> > AFAICS, that option creates a temporary file on the same fs as the edited
> > file resides on.  And that is indeed optimal, but at the same time
> > somewhat unfortunate for embedded systems.
> >
> > Embedded systems usualy place editable files on flash fs and those fs get
> > used out very much faster compared to real hdfs.  IMO, a better solution
> > for such cases would be to place the temporary files on a ramfs (usualy
> > tmpfs) and overrite the original file at the end of the editing session.
> > This operation is indeed more complicated, but the infrastructure is
> > available (libbb/copy_file and libbb/remove_file.c).  Obviously this
> > should be optional and configurable.
> >
> > What do you think?
>
> I think you mean
>
> sed ... <"$file" >/ramfs/tmp-$$ && mv /ramfs/tmp-$$ "$file"

If one would prefer using mktemp (mkstemp) instead of tmp-$$, it would get
more complicated and inefficient.

> This is what shells are for - to avoid bloating programs with all
> imaginable small improvements.

But of course.  That is one way to do it, but is it as efficient as having
sed do it in one go?  What about combining sed and mv code to achieve the
same?


Cheers,

-- 
Cristian

From vda.linux at googlemail.com  Sun Aug 26 09:37:21 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Sun, 26 Aug 2007 17:37:21 +0100
Subject: [rfc] sed option `-i' (edit in place)
In-Reply-To: <0708261649490.9465@somehost>
References: <0708252315150.8632@somehost>
	<200708261548.12518.vda.linux@googlemail.com>
	<0708261649490.9465@somehost>
Message-ID: <200708261737.22136.vda.linux@googlemail.com>

On Sunday 26 August 2007 16:00, Cristian Ionescu-Idbohrn wrote:
> > > Embedded systems usualy place editable files on flash fs and those fs
> > > get used out very much faster compared to real hdfs.

I think that sed creates new file, fills it and and then renames
new file into old file so fast that first metadata update doesn't
even have time to hit the disk storage before it's all done.

What exactly are you trying to optimize out here?
Why do you think your solution will be any different from what
sed does now wrt storage wear?

> > > IMO, a better 
> > > solution for such cases would be to place the temporary files on a
> > > ramfs (usualy tmpfs) and overrite the original file at the end of the
> > > editing session. This operation is indeed more complicated, but the
> > > infrastructure is available (libbb/copy_file and libbb/remove_file.c). 
> > > Obviously this should be optional and configurable.
> > >
> > > What do you think?
> >
> > I think you mean
> >
> > sed ... <"$file" >/ramfs/tmp-$$ && mv /ramfs/tmp-$$ "$file"
>
> If one would prefer using mktemp (mkstemp) instead of tmp-$$, it would get
> more complicated and inefficient.
>
> > This is what shells are for - to avoid bloating programs with all
> > imaginable small improvements.
>
> But of course.  That is one way to do it, but is it as efficient as having
> sed do it in one go?  What about combining sed and mv code to achieve the
> same?

Well, what about -R option - do it recursively over a directory?
and -find_name '*pattern*' to act only on a subset of files?

I don't like this kind of creeping featuritis.

Does stock sed do this?
--
vda

From cristian.ionescu-idbohrn at axis.com  Sun Aug 26 14:20:39 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sun, 26 Aug 2007 23:20:39 +0200 (CEST)
Subject: [rfc] sed option `-i' (edit in place)
In-Reply-To: <200708261737.22136.vda.linux@googlemail.com>
References: <0708252315150.8632@somehost>
	<200708261548.12518.vda.linux@googlemail.com>
	<0708261649490.9465@somehost>
	<200708261737.22136.vda.linux@googlemail.com>
Message-ID: <0708262138460.9465@somehost>

On Sun, 26 Aug 2007, Denys Vlasenko wrote:

> On Sunday 26 August 2007 16:00, Cristian Ionescu-Idbohrn wrote:
> > > > Embedded systems usualy place editable files on flash fs and those
> > > > fs get used out very much faster compared to real hdfs.
>
> I think that sed creates new file, fills it and and then renames
> new file into old file so fast that first metadata update doesn't
> even have time to hit the disk storage before it's all done.

I believe that may be the case with most fs, but not jffs2.  But don't
take my word for it.

> What exactly are you trying to optimize out here?

The shell?

> Why do you think your solution will be any different from what sed does
> now wrt storage wear?

I can't say I _have_ a solution.  I'm just thinking loud ;)

> > > I think you mean
> > >
> > > sed ... <"$file" >/ramfs/tmp-$$ && mv /ramfs/tmp-$$ "$file"
> >
> > If one would prefer using mktemp (mkstemp) instead of tmp-$$, it would
> > get more complicated and inefficient.
> >
> > > This is what shells are for - to avoid bloating programs with all
> > > imaginable small improvements.
> >
> > But of course.  That is one way to do it, but is it as efficient as
> > having sed do it in one go?  What about combining sed and mv code to
> > achieve the same?
>
> Well, what about -R option - do it recursively over a directory?
> and -find_name '*pattern*' to act only on a subset of files?

Sorry, I don't follow.  "-R option" to what?

> I don't like this kind of creeping featuritis.

I agree.  Still, there are a lot of embeded systems out there using
busybox and flash storage.

> Does stock sed do this?

No.  GNU sed is doing something similar to bb-sed (or the other way
around):

,----
| open("lines", O_RDONLY|O_LARGEFILE) = 3
| ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfd35068) = -1 ENOTTY (Inappropriate ioctl for device)
| fstat64(3, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
| gettimeofday({1188158729, 155778}, NULL) = 0
| getpid()                                = 19852
| open("./sedSTqTlj", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 10
| fcntl64(10, F_GETFL)                    = 0x8002 (flags O_RDWR|O_LARGEFILE)
| fstat64(10, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
| mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dfe000
| _llseek(10, 0, [0], SEEK_CUR)           = 0
| fchmod(10, 0100644)                     = 0
| fchown32(10, 1000, 1000)                = 0
| fstat64(3, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
| mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dde000
| read(3, "fxx\nbar\n", 131072)           = 8
| write(10, "fxx\n", 4)                   = 4
| write(10, "bar\n", 4)                   = 4
| read(3, "", 131072)                     = 0
| close(3)                                = 0
| munmap(0xb7dde000, 131072)              = 0
| close(10)                               = 0
| munmap(0xb7dfe000, 131072)              = 0
| rename("./sedSTqTlj", "lines")          = 0
| close(1)                                = 0
| close(2)                                = 0
`----

But I don't think GNU sed was made with embedded systems and flash storage
in mind.

To mimic the `sed -i' (but with the temp file on a ramfs) I need a shell
script (or function) doing something like this:


---8<---
# $1 - expression
# $2 - file

if tmpf=$(mktemp /tmp/${2##*/}.XXXXXX); then
	sed -e "$1" < $2 >> $tmpf && mv -f $tmpf $2 || {
		rm -f $tmpf
		echo "E: you lose" >&2
		exit 1
	}
else
	echo "E: can't create temp file" >&2
	exit 1
fi
---8<---

That, I think, may take more cycles than:

sed -i -e "$1" $2


Cheers,

-- 
Cristian

From Johan.Adolfsson at axis.com  Mon Aug 27 00:04:57 2007
From: Johan.Adolfsson at axis.com (Johan Adolfsson)
Date: Mon, 27 Aug 2007 09:04:57 +0200
Subject: [rfc] sed option `-i' (edit in place)
In-Reply-To: <0708262138460.9465@somehost>
Message-ID: <001901c7e878$93d221d0$01935e0a@se.axis.com>


> -----Original Message-----
> From: busybox-bounces at busybox.net 
> [mailto:busybox-bounces at busybox.net] On Behalf Of Cristian 
> Ionescu-Idbohrn
> Sent: den 26 augusti 2007 23:21
> To: busybox at busybox.net
> Subject: Re: [rfc] sed option `-i' (edit in place)
> 
> 
> On Sun, 26 Aug 2007, Denys Vlasenko wrote:
> 
> > On Sunday 26 August 2007 16:00, Cristian Ionescu-Idbohrn wrote:
> > > > > Embedded systems usualy place editable files on flash 
> fs and those
> > > > > fs get used out very much faster compared to real hdfs.
> >
> > I think that sed creates new file, fills it and and then renames
> > new file into old file so fast that first metadata update doesn't
> > even have time to hit the disk storage before it's all done.
> 
> I believe that may be the case with most fs, but not jffs2.  But don't
> take my word for it.
> 
> > What exactly are you trying to optimize out here?
> 
> The shell?
> 
> > Why do you think your solution will be any different from 
> what sed does
> > now wrt storage wear?
> 
> I can't say I _have_ a solution.  I'm just thinking loud ;)
> 
> > > > I think you mean
> > > >
> > > > sed ... <"$file" >/ramfs/tmp-$$ && mv /ramfs/tmp-$$ "$file"
> > >
> > > If one would prefer using mktemp (mkstemp) instead of 
> tmp-$$, it would
> > > get more complicated and inefficient.
> > >
> > > > This is what shells are for - to avoid bloating 
> programs with all
> > > > imaginable small improvements.
> > >
> > > But of course.  That is one way to do it, but is it as 
> efficient as
> > > having sed do it in one go?  What about combining sed and 
> mv code to
> > > achieve the same?
> >
> > Well, what about -R option - do it recursively over a directory?
> > and -find_name '*pattern*' to act only on a subset of files?
> 
> Sorry, I don't follow.  "-R option" to what?
> 
> > I don't like this kind of creeping featuritis.
> 
> I agree.  Still, there are a lot of embeded systems out there using
> busybox and flash storage.
> 
> > Does stock sed do this?
> 
> No.  GNU sed is doing something similar to bb-sed (or the other way
> around):
> 
> ,----
> | open("lines", O_RDONLY|O_LARGEFILE) = 3
> | ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfd35068) = -1 
> ENOTTY (Inappropriate ioctl for device)
> | fstat64(3, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
> | gettimeofday({1188158729, 155778}, NULL) = 0
> | getpid()                                = 19852
> | open("./sedSTqTlj", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 10
> | fcntl64(10, F_GETFL)                    = 0x8002 (flags 
> O_RDWR|O_LARGEFILE)
> | fstat64(10, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> | mmap2(NULL, 131072, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dfe000
> | _llseek(10, 0, [0], SEEK_CUR)           = 0
> | fchmod(10, 0100644)                     = 0
> | fchown32(10, 1000, 1000)                = 0
> | fstat64(3, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
> | mmap2(NULL, 131072, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dde000
> | read(3, "fxx\nbar\n", 131072)           = 8
> | write(10, "fxx\n", 4)                   = 4
> | write(10, "bar\n", 4)                   = 4
> | read(3, "", 131072)                     = 0
> | close(3)                                = 0
> | munmap(0xb7dde000, 131072)              = 0
> | close(10)                               = 0
> | munmap(0xb7dfe000, 131072)              = 0
> | rename("./sedSTqTlj", "lines")          = 0
> | close(1)                                = 0
> | close(2)                                = 0
> `----

Wouldn't we get reduced wearing and possibly a general speed up as well,
if we made sure sed was buffering stuff more and avoiding small writes
to the filesystem?
Then there shouldn't be much difference in flash wearing compared to a copy.

Just a thought.
/Johan



From xiao.liang at cn.alps.com  Mon Aug 27 00:48:08 2007
From: xiao.liang at cn.alps.com (xiao.liang at cn.alps.com)
Date: Mon, 27 Aug 2007 15:48:08 +0800
Subject: mount:nfsmount failed: Bad file descriptor
Message-ID: <OF73C1BED4.2CF4B4DC-ON48257344.0029C992-48257344.002A6061@alps.com.hk>

Hi,
   I have encoutered a problem when mount a nfs filesystem. The nfs 
server's ip is 192.168.1.6 and busybox version is 1.1.3. All the must 
configure features in busybox and kernel is turn on. 
CONFIG_FEATURE_MOUNT_NFS is set to y. And kernel's config CONFIG_NFS_FS, 
CONFIG_NFS_V3 are set to y. The command i use is

 "mount -t nfs -o nolock,vers=2 102.168.1.6:/home/tom /home/tom", 

the error message is "

mount:RPC: Timed out
mount: nfsmount failed: Bad file descriptor
mount :mounting ......................on /hom/tom failed:Bad file 
descriptor

I have tried remove vers=2 and sth stupid of the command but that does not 
work, any suggestion is appreciate!
 
Best Wishes,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070827/fd2b8064/attachment.htm 

From hinko.kocevar at cetrtapot.si  Mon Aug 27 04:39:04 2007
From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si)
Date: Mon, 27 Aug 2007 13:39:04 +0200
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <OF73C1BED4.2CF4B4DC-ON48257344.0029C992-48257344.002A6061@alps.com.hk>
References: <OF73C1BED4.2CF4B4DC-ON48257344.0029C992-48257344.002A6061@alps.com.hk>
Message-ID: <46D2B7D8.4090503@cetrtapot.si>

xiao.liang at cn.alps.com wrote:
> 
> Hi,
>    I have encoutered a problem when mount a nfs filesystem. The nfs 
> server's ip is 192.168.1.6 and busybox version is 1.1.3. All the must 
> configure features in busybox and kernel is turn on. 
> CONFIG_FEATURE_MOUNT_NFS is set to y. And kernel's config CONFIG_NFS_FS, 
> CONFIG_NFS_V3 are set to y. The command i use is
> 
>  "mount -t nfs -o nolock,vers=2 102.168.1.6:/home/tom /home/tom",
> 
> the error message is "
> 
> mount:RPC: Timed out
> mount: nfsmount failed: Bad file descriptor
> mount :mounting ......................on /hom/tom failed:Bad file 
> descriptor

What does NFS servers log say? See dmesg or /var/log/messages.

> 
> I have tried remove vers=2 and sth stupid of the command but that does 
> not work, any suggestion is appreciate!

Can you mount the NFS share from another machine? Or even from the same 
machine that NFS server runs on?

I've mounted NFS share on my setup with no problems - this is on busybox 
1.1.2 though:
# uname -a
Linux cpot-0016F9000000 2.6.19-cpot-car2-R1 #20 Tue Aug 7 09:54:47 CEST 
2007 cris unknown
# zcat /proc/config.gz | grep NFS
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_NFS_COMMON=y
# mount -t nfs -o nolock 10.0.0.1:/home/hinkok/servisnfs /mnt
# mount
/dev/root on / type jffs2 (rw)
proc on /proc type proc (rw)
tmpfs on /var type tmpfs (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
10.0.0.1:/home/hinkok/servisnfs on /mnt type nfs 
(rw,vers=3,rsize=32768,wsize=32768,hard,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=10.0.0.1)

HTH,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si


From vda.linux at googlemail.com  Mon Aug 27 04:39:45 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 27 Aug 2007 12:39:45 +0100
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <OF73C1BED4.2CF4B4DC-ON48257344.0029C992-48257344.002A6061@alps.com.hk>
References: <OF73C1BED4.2CF4B4DC-ON48257344.0029C992-48257344.002A6061@alps.com.hk>
Message-ID: <200708271239.45279.vda.linux@googlemail.com>

On Monday 27 August 2007 08:48, xiao.liang at cn.alps.com wrote:
> Hi,
>    I have encoutered a problem when mount a nfs filesystem. The nfs
> server's ip is 192.168.1.6 and busybox version is 1.1.3. All the must
> configure features in busybox and kernel is turn on.
> CONFIG_FEATURE_MOUNT_NFS is set to y. And kernel's config CONFIG_NFS_FS,
> CONFIG_NFS_V3 are set to y. The command i use is
>
>  "mount -t nfs -o nolock,vers=2 102.168.1.6:/home/tom /home/tom",
>
> the error message is "
>
> mount:RPC: Timed out
> mount: nfsmount failed: Bad file descriptor
> mount :mounting ......................on /hom/tom failed:Bad file
> descriptor
>
> I have tried remove vers=2 and sth stupid of the command but that does not
> work, any suggestion is appreciate!

Try something more recent than 1.1.3.

Do "strace -o mount.log mount ....." and post mount.log to the mailing list.
--
vda

From sh4d0wstr1f3 at yahoo.com  Mon Aug 27 06:52:58 2007
From: sh4d0wstr1f3 at yahoo.com (S H)
Date: Mon, 27 Aug 2007 06:52:58 -0700 (PDT)
Subject: [PATCH] (against 1.4.2)  prevent cp of dir into itself (reprise)
Message-ID: <567731.38413.qm@web50410.mail.re2.yahoo.com>

vda:

The patch you proposed handles most test cases, but leads to the creation of many-nested directories under the following scenario:

% mkdir -p sub/dir dir
% ln -s sub/dir dir/ldir
% busybox_vda cp -R dir sub sub [XXX]
cp: skipping 'dir/lsub/lsub' - recursive copying detected
cp: skipping 'sub/dir/lsub' - recursive copying detected

(long delay while sub/sub/sub/sub/sub/sub ... etc. is created)

sub/sub/sub/sub/sub/sub/.../sub/sub/sub: No such file or directory

It works fine for the other test cases I have:

% busybox_vda cp -R sub sub  [OK]
% busybox_vda cp -R dir sub [OK]
% busybox_vda cp -R sub lsub [OK]
% busybox_vda cp -R lsub sub [OK]
% busybox_vda cp -R sub dir [OK]

I think the patch you provided doesn't work in this situation because it remembers only the top level directory; in this case, dir has a subdirectory that points to within the destination -- which was not remembered?

The patch that I provided against 1.4.2 is resiliant against the above scenario. I think that the "tree depth" problem would apply to the normal use for the hashtable as well (i.e., the link table). You're right -- my patch should definitely not try to copy every single pathname into the hashtable. I intended only to copy directory paths.

Attached is a revised patch against trunk svn (r19704) which only copies dir pathnames into the ino_dev_hashtable; it was tested against the previous testcases I've mentioned and the scenarios described above.

Thanks for your time.

----- Original Message ----
From: Denys Vlasenko <vda.linux at googlemail.com>
To: busybox at busybox.net
Cc: S H <sh4d0wstr1f3 at yahoo.com>
Sent: Saturday, August 25, 2007 5:03:57 PM
Subject: Re: [PATCH] (against 1.4.2)  prevent cp of dir into itself (reprise)

On Thursday 23 August 2007 22:16, S H wrote:
> cp -R sub sub results in a nasty subdirectory tree (see
> http://bugs.busybox.net/view.php?id=1412). coreutils cp stops it before it
> goes out of control. FreeBSD ignores it. I prefer the coreutils behavior.

...

I would rather no use inode_hashtable. Who knows how deep that tree is,
and inode hashtable actually remembers *each pathname*!!

Please download svn version (yes, it has changed since 1.7.0 in that area),
apply attached patch and try your testcases. Does that work?

The solution is a hack (need to avoid using static), but the basic idea is
to remember a dev and inode of top-level created directory,
and refuse to copy it if it turns up as a source later.
--
vda





       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.quintessence.r19704M.2
Type: application/octet-stream
Size: 1428 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070827/d8772e55/attachment.obj 

From vda.linux at googlemail.com  Mon Aug 27 09:47:34 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Mon, 27 Aug 2007 17:47:34 +0100
Subject: [PATCH] (against 1.4.2)  prevent cp of dir into itself (reprise)
In-Reply-To: <567731.38413.qm@web50410.mail.re2.yahoo.com>
References: <567731.38413.qm@web50410.mail.re2.yahoo.com>
Message-ID: <200708271747.35254.vda.linux@googlemail.com>

On Monday 27 August 2007 14:52, S H wrote:
> vda:
>
> The patch you proposed handles most test cases, but leads to the creation
> of many-nested directories under the following scenario:
>
> % mkdir -p sub/dir dir
> % ln -s sub/dir dir/ldir
> % busybox_vda cp -R dir sub sub [XXX]
> cp: skipping 'dir/lsub/lsub' - recursive copying detected
> cp: skipping 'sub/dir/lsub' - recursive copying detected
>
> (long delay while sub/sub/sub/sub/sub/sub ... etc. is created)
>
> sub/sub/sub/sub/sub/sub/.../sub/sub/sub: No such file or directory
>
> It works fine for the other test cases I have:
>
> % busybox_vda cp -R sub sub  [OK]
> % busybox_vda cp -R dir sub [OK]
> % busybox_vda cp -R sub lsub [OK]
> % busybox_vda cp -R lsub sub [OK]
> % busybox_vda cp -R sub dir [OK]
>
> I think the patch you provided doesn't work in this situation because it
> remembers only the top level directory; in this case, dir has a
> subdirectory that points to within the destination -- which was not
> remembered?
>
> The patch that I provided against 1.4.2 is resiliant against the above
> scenario. I think that the "tree depth" problem would apply to the normal
> use for the hashtable as well (i.e., the link table). You're right -- my
> patch should definitely not try to copy every single pathname into the
> hashtable. I intended only to copy directory paths.
>
> Attached is a revised patch against trunk svn (r19704) which only copies
> dir pathnames into the ino_dev_hashtable; it was tested against the
> previous testcases I've mentioned and the scenarios described above.

Applied with minor changes, thanks. Can you test current svn?
--
vda

From steven at nchc.org.tw  Mon Aug 27 18:15:16 2007
From: steven at nchc.org.tw (Steven Shiau)
Date: Tue, 28 Aug 2007 09:15:16 +0800
Subject: Add an option to assign server/client port in udhcp[cd] ?
Message-ID: <46D37724.6030107@nchc.org.tw>

Hi,
Just noticed that busybox 1.7 is released, and some new functions added
. IMHO, I'd like to suggest that an option should be added to assign the
server and client port in udhcp[cd], i.e.
These two ports
#define SERVER_PORT     67
#define CLIENT_PORT     68
can be assigned when run udhcpc and udhcpd. This is very useful when
there is an existing dhcp service in the network subnet, and if people
would like to put another dhcp service with customized port.

My two cents.
Steven.
-- 
Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org>
National Center for High-performance Computing, Taiwan.
http://www.nchc.org.tw
Public Key Server PGP Key ID: 9762755A
Fingerprint -- A2A1 08B7 C22C 3D06 34DB  F4BC 08B3 E3D7 9762 755A

From xiao.liang at cn.alps.com  Mon Aug 27 20:33:45 2007
From: xiao.liang at cn.alps.com (xiao.liang at cn.alps.com)
Date: Tue, 28 Aug 2007 11:33:45 +0800
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <200708271239.45279.vda.linux@googlemail.com>
Message-ID: <OFE9901A6F.8D8C3C82-ON48257345.001280A5-48257345.00131621@alps.com.hk>

When use strace the log is look like this:

root# cat mount.log
execve("/bin/mount", ["mount", "-t", "nfs", "192.168.1.6:/opt/Qtopia_2", 
"/opt/Qtopia_2"], [/* 10 vars */]) = 0
uname({sys="Linux", node="imx21", ...}) = 0
brk(0)                                  = 0xabeec
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x40015000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY)      = -1 ENOENT (No such file or 
directory)
open("/lib/v5EJl/fast-mult/half/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No 
such file or directory)
stat64("/lib/v5EJl/fast-mult/half", 0xbffff2bc) = -1 ENOENT (No such file 
or directory)
open("/lib/v5EJl/fast-mult/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64("/lib/v5EJl/fast-mult", 0xbffff2bc) = -1 ENOENT (No such file or 
directory)
open("/lib/v5EJl/half/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/lib/v5EJl/half", 0xbffff2bc)   = -1 ENOENT (No such file or 
directory)
open("/lib/v5EJl/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64("/lib/v5EJl", 0xbffff2bc)        = -1 ENOENT (No such file or 
directory)
open("/lib/fast-mult/half/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64("/lib/fast-mult/half", 0xbffff2bc) = -1 ENOENT (No such file or 
directory)
open("/lib/fast-mult/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/lib/fast-mult", 0xbffff2bc)    = -1 ENOENT (No such file or 
directory)
open("/lib/half/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64("/lib/half", 0xbffff2bc)         = -1 ENOENT (No such file or 
directory)
open("/lib/libcrypt.so.1", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\354\t\0\000"..., 
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=19048, ...}) = 0
old_mmap(NULL, 210528, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 
0x4001d000
mprotect(0x40022000, 190048, PROT_NONE) = 0
old_mmap(0x40025000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 
3, 0) = 0x40025000
old_mmap(0x4002a000, 157280, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4002a000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\304{\1\000"..., 
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1149532, ...}) = 0
old_mmap(NULL, 1186360, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 
0x40051000
mprotect(0x40164000, 59960, PROT_NONE)  = 0
old_mmap(0x40169000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 
3, 0x110000) = 0x40169000
old_mmap(0x40170000, 10808, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40170000
close(3)                                = 0
stat64("/etc/busybox.conf", {st_mode=S_IFREG|0644, st_size=50, ...}) = 0
brk(0)                                  = 0xabeec
brk(0xaceec)                            = 0xaceec
brk(0)                                  = 0xaceec
brk(0xad000)                            = 0xad000
open("/etc/busybox.conf", O_RDONLY)     = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=50, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x40016000
read(3, "[SUID]\n#su = ssx root.root\npassw"..., 4096) = 50
open("/etc/passwd", O_RDONLY)           = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=1629, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x40017000
read(4, "root:x:0:0:root:/root:/bin/sh\nbi"..., 4096) = 1629
close(4)                                = 0
munmap(0x40017000, 4096)                = 0
open("/etc/group", O_RDONLY)            = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=652, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x40017000
read(4, "root::0:root\nbin::1:root,bin,dae"..., 4096) = 652
close(4)                                = 0
munmap(0x40017000, 4096)                = 0
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40016000, 4096)                = 0
getuid32()                              = 0
getgid32()                              = 0
setgid32(0)                             = 0
setuid32(0)                             = 0
uname({sys="Linux", node="imx21", ...}) = 0
time(NULL)                              = 197
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
getpid()                                = 60
bind(3, {sa_family=AF_INET, sin_port=htons(660), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111), 
sin_addr=inet_addr("192.168.1.6")}, 16) = -1 ETIMEDOUT (Connection timed 
out)
close(3)                                = 0
brk(0)                                  = 0xad000
brk(0xb1000)                            = 0xb1000
gettimeofday({386, 767720}, NULL)       = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(661), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, FIONBIO, [1])                  = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
uname({sys="Linux", node="imx21", ...}) = 0
geteuid32()                             = 0
getegid32()                             = 0
getgroups32(0x20, 0xbffff0bc)           = 0
gettimeofday({386, 811220}, NULL)       = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
write(2, "mount: RPC: Timed out\n", 22) = 22
close(3)                                = 0
close(3)                                = -1 EBADF (Bad file descriptor)
write(2, "mount: ", 7)                  = 7
write(2, "nfsmount failed", 15)         = 15
write(2, ": Bad file descriptor\n", 22) = 22
write(2, "mount: ", 7)                  = 7
write(2, "Mounting 192.168.1.6:/opt/Qtopia"..., 58) = 58
write(2, ": Bad file descriptor\n", 22) = 22
_exit(1)                                = ?

When I use the same kernel and same busybox on an different board which is 
capable of mount nfs sucessfully, it mounts success !And I copy the libc 
and libcrypt library from the successful board to this failed board. With 
just the same kernel and busybox, it failed. I am confused! Help!

The nfs server say nothing when failed. And the NFS server seems to be 
version4. My kernel version is 2.4.20.




Denys Vlasenko <vda.linux at googlemail.com> 
08/27/2007 07:39 PM

??
busybox at busybox.net
cc
xiao.liang at cn.alps.com
??
Re: mount:nfsmount failed: Bad file descriptor






On Monday 27 August 2007 08:48, xiao.liang at cn.alps.com wrote:
> Hi,
>    I have encoutered a problem when mount a nfs filesystem. The nfs
> server's ip is 192.168.1.6 and busybox version is 1.1.3. All the must
> configure features in busybox and kernel is turn on.
> CONFIG_FEATURE_MOUNT_NFS is set to y. And kernel's config CONFIG_NFS_FS,
> CONFIG_NFS_V3 are set to y. The command i use is
>
>  "mount -t nfs -o nolock,vers=2 102.168.1.6:/home/tom /home/tom",
>
> the error message is "
>
> mount:RPC: Timed out
> mount: nfsmount failed: Bad file descriptor
> mount :mounting ......................on /hom/tom failed:Bad file
> descriptor
>
> I have tried remove vers=2 and sth stupid of the command but that does 
not
> work, any suggestion is appreciate!

Try something more recent than 1.1.3.

Do "strace -o mount.log mount ....." and post mount.log to the mailing 
list.
--
vda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070828/441b681d/attachment-0001.htm 

From xiao.liang at cn.alps.com  Tue Aug 28 01:14:39 2007
From: xiao.liang at cn.alps.com (xiao.liang at cn.alps.com)
Date: Tue, 28 Aug 2007 16:14:39 +0800
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <200708271239.45279.vda.linux@googlemail.com>
Message-ID: <OFFA888127.3416A058-ON48257345.002D0CD6-48257345.002CCDD8@alps.com.hk>

BTW, I find there is must sth wrong, I can ping through the host with NFS 
Server,say 192.168.1.6. But when I try to use ftp or mount nfs,it fails. I 
don't know where  the problem is??? 




Denys Vlasenko <vda.linux at googlemail.com> 
08/27/2007 07:39 PM

??
busybox at busybox.net
cc
xiao.liang at cn.alps.com
??
Re: mount:nfsmount failed: Bad file descriptor






On Monday 27 August 2007 08:48, xiao.liang at cn.alps.com wrote:
> Hi,
>    I have encoutered a problem when mount a nfs filesystem. The nfs
> server's ip is 192.168.1.6 and busybox version is 1.1.3. All the must
> configure features in busybox and kernel is turn on.
> CONFIG_FEATURE_MOUNT_NFS is set to y. And kernel's config CONFIG_NFS_FS,
> CONFIG_NFS_V3 are set to y. The command i use is
>
>  "mount -t nfs -o nolock,vers=2 102.168.1.6:/home/tom /home/tom",
>
> the error message is "
>
> mount:RPC: Timed out
> mount: nfsmount failed: Bad file descriptor
> mount :mounting ......................on /hom/tom failed:Bad file
> descriptor
>
> I have tried remove vers=2 and sth stupid of the command but that does 
not
> work, any suggestion is appreciate!

Try something more recent than 1.1.3.

Do "strace -o mount.log mount ....." and post mount.log to the mailing 
list.
--
vda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070828/3c666972/attachment.htm 

From vda.linux at googlemail.com  Tue Aug 28 03:56:11 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Tue, 28 Aug 2007 11:56:11 +0100
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <OFE9901A6F.8D8C3C82-ON48257345.001280A5-48257345.00131621@alps.com.hk>
References: <OFE9901A6F.8D8C3C82-ON48257345.001280A5-48257345.00131621@alps.com.hk>
Message-ID: <200708281156.11581.vda.linux@googlemail.com>

On Tuesday 28 August 2007 04:33, xiao.liang at cn.alps.com wrote:
> When use strace the log is look like this:
>
> root# cat mount.log
> execve("/bin/mount", ["mount", "-t", "nfs", "192.168.1.6:/opt/Qtopia_2",
> "/opt/Qtopia_2"], [/* 10 vars */]) = 0
> uname({sys="Linux", node="imx21", ...}) = 0
> brk(0)                                  = 0xabeec
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x40015000
> open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)      = -1 ENOENT (No such file or
> directory)
> open("/lib/v5EJl/fast-mult/half/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/v5EJl/fast-mult/half", 0xbffff2bc) = -1 ENOENT (No such file
> or directory)
> open("/lib/v5EJl/fast-mult/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such
> file or directory)
...
> sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"...,
> 88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
> poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
> ioctl(3, 0x8912, 0xbfffcecc)            = 0
> ioctl(3, 0x8913, 0xbfffced4)            = 0
> sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"...,
> 88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
> poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
> ioctl(3, 0x8912, 0xbfffcecc)            = 0
> ioctl(3, 0x8913, 0xbfffced4)            = 0
> write(2, "mount: RPC: Timed out\n", 22) = 22
> close(3)                                = 0
> close(3)                                = -1 EBADF (Bad file descriptor)
> write(2, "mount: ", 7)                  = 7
> write(2, "nfsmount failed", 15)         = 15
> write(2, ": Bad file descriptor\n", 22) = 22
> write(2, "mount: ", 7)                  = 7
> write(2, "Mounting 192.168.1.6:/opt/Qtopia"..., 58) = 58
> write(2, ": Bad file descriptor\n", 22) = 22
> _exit(1)                                = ?


Thank you for this wonderfully linewrapped listing.
It was a real joy fixing it up ;)

Ok, Im serious again. Is this 1.6.1?
if it is not, please try 1.6.1.
If it is, please try adding "msock = -1" in mount.c:

                        /* Connection refused */
                        if (!daemonized && prevt == 0) /* print just once */
                                error_msg_rpc(clnt_sperror(mclient, " "));
                        auth_destroy(mclient->cl_auth);
                        clnt_destroy(mclient);
                        mclient = 0;
                        close(msock);
+                       msock = -1;

and here:

        /* clean up */

        auth_destroy(mclient->cl_auth);
        clnt_destroy(mclient);
        close(msock);
+       msock = -1;

This may fix extra close() and prevent bogus error message about
"Bad file descriptor". In reality you are seeing timeout:


time(NULL) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?= 197
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
getpid() ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?= 60
bind(3, {sa_family=AF_INET, sin_port=htons(660), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111), 
sin_addr=inet_addr("192.168.1.6")}, 16) = -1 ETIMEDOUT (Connection timed out)
close(3) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?= 0
brk(0) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?= 0xad000
brk(0xb1000) ? ? ? ? ? ? ? ? ? ? ? ? ? ?= 0xb1000
gettimeofday({386, 767720}, NULL) ? ? ? = 0

See? Connection to portmapper failed after almost 200 seconds of trying.
And then attempts to use default port and reach mount directly time out too
(poll() waits for 3 seconds and returns 0 -> no reply received):

socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(661), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, FIONBIO, [1]) ? ? ? ? ? ? ? ? ?= 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
uname({sys="Linux", node="imx21", ...}) = 0
geteuid32() ? ? ? ? ? ? ? ? ? ? ? ? ? ? = 0
getegid32() ? ? ? ? ? ? ? ? ? ? ? ? ? ? = 0
getgroups32(0x20, 0xbffff0bc) ? ? ? ? ? = 0
gettimeofday({386, 811220}, NULL) ? ? ? = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000) ?= 0
ioctl(3, 0x8912, 0xbfffcecc) ? ? ? ? ? ?= 0
ioctl(3, 0x8913, 0xbfffced4) ? ? ? ? ? ?= 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000) ?= 0
ioctl(3, 0x8912, 0xbfffcecc) ? ? ? ? ? ?= 0
ioctl(3, 0x8913, 0xbfffced4) ? ? ? ? ? ?= 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000) ?= 0
ioctl(3, 0x8912, 0xbfffcecc) ? ? ? ? ? ?= 0
ioctl(3, 0x8913, 0xbfffced4) ? ? ? ? ? ?= 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000) ?= 0
ioctl(3, 0x8912, 0xbfffcecc) ? ? ? ? ? ?= 0
ioctl(3, 0x8913, 0xbfffced4) ? ? ? ? ? ?= 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000) ?= 0
ioctl(3, 0x8912, 0xbfffcecc) ? ? ? ? ? ?= 0
ioctl(3, 0x8913, 0xbfffced4) ? ? ? ? ? ?= 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000) ?= 0
ioctl(3, 0x8912, 0xbfffcecc) ? ? ? ? ? ?= 0
ioctl(3, 0x8913, 0xbfffced4) ? ? ? ? ? ?= 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000) ?= 0
ioctl(3, 0x8912, 0xbfffcecc) ? ? ? ? ? ?= 0
ioctl(3, 0x8913, 0xbfffced4) ? ? ? ? ? ?= 0
write(2, "mount: RPC: Timed out\n", 22) = 22
close(3) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?= 0
close(3) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?= -1 EBADF (Bad file descriptor)
write(2, "mount: ", 7) ? ? ? ? ? ? ? ? ?= 7
write(2, "nfsmount failed", 15) ? ? ? ? = 15
write(2, ": Bad file descriptor\n", 22) = 22


Apart from bogus close() screwing up error code, I dont see
any problem on client side. It simply cannot reach the server.
--
vda

From xiao.liang at cn.alps.com  Tue Aug 28 04:11:01 2007
From: xiao.liang at cn.alps.com (xiao.liang at cn.alps.com)
Date: Tue, 28 Aug 2007 19:11:01 +0800
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <200708281156.11581.vda.linux@googlemail.com>
Message-ID: <OF57549AB1.89E8E2BB-ON48257345.003CCD76-48257345.003CF376@alps.com.hk>

Hi,
        thank you very much for you response! The busybox is 1.3.1. I will 
try 1.6.1 tomorrow. But i use ethereal to catch logs on the server side 
and found that the server can receive the TCP packets from client and 
response. But when it receive the mount service based on RPC, RPC version 
is 2. Mount service program version is 1. But  it just does not reponse. 
So, i think this must be sth wrong, i will catch a successful nfs/mount 
log tomorrow.Thanks again!




Denys Vlasenko <vda.linux at googlemail.com> 
08/28/2007 06:56 PM

??
xiao.liang at cn.alps.com
cc
busybox at busybox.net
"hinko.kocevar at cetrtapot.si" <hinko.kocevar at cetrtapot.si>
??
Re: mount:nfsmount failed: Bad file descriptor






On Tuesday 28 August 2007 04:33, xiao.liang at cn.alps.com wrote:
> When use strace the log is look like this:
>
> root# cat mount.log
> execve("/bin/mount", ["mount", "-t", "nfs", "192.168.1.6:/opt/Qtopia_2",
> "/opt/Qtopia_2"], [/* 10 vars */]) = 0
> uname({sys="Linux", node="imx21", ...}) = 0
> brk(0)                                  = 0xabeec
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1,
> 0) = 0x40015000
> open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)      = -1 ENOENT (No such file or
> directory)
> open("/lib/v5EJl/fast-mult/half/libcrypt.so.1", O_RDONLY) = -1 ENOENT 
(No
> such file or directory)
> stat64("/lib/v5EJl/fast-mult/half", 0xbffff2bc) = -1 ENOENT (No such 
file
> or directory)
> open("/lib/v5EJl/fast-mult/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No 
such
> file or directory)
...
> sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"...,
> 88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
> poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
> ioctl(3, 0x8912, 0xbfffcecc)            = 0
> ioctl(3, 0x8913, 0xbfffced4)            = 0
> sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"...,
> 88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
> poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
> ioctl(3, 0x8912, 0xbfffcecc)            = 0
> ioctl(3, 0x8913, 0xbfffced4)            = 0
> write(2, "mount: RPC: Timed out\n", 22) = 22
> close(3)                                = 0
> close(3)                                = -1 EBADF (Bad file descriptor)
> write(2, "mount: ", 7)                  = 7
> write(2, "nfsmount failed", 15)         = 15
> write(2, ": Bad file descriptor\n", 22) = 22
> write(2, "mount: ", 7)                  = 7
> write(2, "Mounting 192.168.1.6:/opt/Qtopia"..., 58) = 58
> write(2, ": Bad file descriptor\n", 22) = 22
> _exit(1)                                = ?


Thank you for this wonderfully linewrapped listing.
It was a real joy fixing it up ;)

Ok, Im serious again. Is this 1.6.1?
if it is not, please try 1.6.1.
If it is, please try adding "msock = -1" in mount.c:

                        /* Connection refused */
                        if (!daemonized && prevt == 0) /* print just once 
*/
                                error_msg_rpc(clnt_sperror(mclient, " "));
                        auth_destroy(mclient->cl_auth);
                        clnt_destroy(mclient);
                        mclient = 0;
                        close(msock);
+                       msock = -1;

and here:

        /* clean up */

        auth_destroy(mclient->cl_auth);
        clnt_destroy(mclient);
        close(msock);
+       msock = -1;

This may fix extra close() and prevent bogus error message about
"Bad file descriptor". In reality you are seeing timeout:


time(NULL)                              = 197
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
getpid()                                = 60
bind(3, {sa_family=AF_INET, sin_port=htons(660), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111), 
sin_addr=inet_addr("192.168.1.6")}, 16) = -1 ETIMEDOUT (Connection timed 
out)
close(3)                                = 0
brk(0)                                  = 0xad000
brk(0xb1000)                            = 0xb1000
gettimeofday({386, 767720}, NULL)       = 0

See? Connection to portmapper failed after almost 200 seconds of trying.
And then attempts to use default port and reach mount directly time out 
too
(poll() waits for 3 seconds and returns 0 -> no reply received):

socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(661), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, FIONBIO, [1])                  = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
uname({sys="Linux", node="imx21", ...}) = 0
geteuid32()                             = 0
getegid32()                             = 0
getgroups32(0x20, 0xbffff0bc)           = 0
gettimeofday({386, 811220}, NULL)       = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
write(2, "mount: RPC: Timed out\n", 22) = 22
close(3)                                = 0
close(3)                                = -1 EBADF (Bad file descriptor)
write(2, "mount: ", 7)                  = 7
write(2, "nfsmount failed", 15)         = 15
write(2, ": Bad file descriptor\n", 22) = 22


Apart from bogus close() screwing up error code, I dont see
any problem on client side. It simply cannot reach the server.
--
vda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070828/5a1e6e4b/attachment-0001.htm 

From tomas at slax.org  Tue Aug 28 09:13:17 2007
From: tomas at slax.org (Tomas M)
Date: Tue, 28 Aug 2007 16:13:17 +0000
Subject: mount patch
Message-ID: <46D4499D.2010604@slax.org>

Hello,
this is a patch for mount.c in busybox, to simply ignore -i option.

-i is used in GNU mount for this purpose:
      Don't call the /sbin/mount.<filesystem> helper even if it exists.

But BusyBox doesn't call this anyway (IMHO) so it's safe to silently 
ignore it.

This is my first busybox modification ever, so please review the patch 
if it is correct! It should be.


Thank you


Tomas M
slax.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox.mount.patch
Url: http://busybox.net/lists/busybox/attachments/20070828/0a458a87/attachment.diff 

From xiao.liang at cn.alps.com  Tue Aug 28 19:42:12 2007
From: xiao.liang at cn.alps.com (xiao.liang at cn.alps.com)
Date: Wed, 29 Aug 2007 10:42:12 +0800
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <200708281156.11581.vda.linux@googlemail.com>
Message-ID: <OFD075E021.25D51D4E-ON48257346.000ACE96-48257346.000E5E3C@alps.com.hk>

After I try busbox 1.6.1, the bad file descriptor error disappear, but 
still got RPC timeout error. And the mount service is still V1. I think it 
is due to the failed nfs mount use a very early verion 1 of mount service. 
Anyone who knows how to update the mount servce version?




Denys Vlasenko <vda.linux at googlemail.com> 
08/28/2007 06:56 PM

??
xiao.liang at cn.alps.com
cc
busybox at busybox.net
"hinko.kocevar at cetrtapot.si" <hinko.kocevar at cetrtapot.si>
??
Re: mount:nfsmount failed: Bad file descriptor






On Tuesday 28 August 2007 04:33, xiao.liang at cn.alps.com wrote:
> When use strace the log is look like this:
>
> root# cat mount.log
> execve("/bin/mount", ["mount", "-t", "nfs", "192.168.1.6:/opt/Qtopia_2",
> "/opt/Qtopia_2"], [/* 10 vars */]) = 0
> uname({sys="Linux", node="imx21", ...}) = 0
> brk(0)                                  = 0xabeec
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1,
> 0) = 0x40015000
> open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)      = -1 ENOENT (No such file or
> directory)
> open("/lib/v5EJl/fast-mult/half/libcrypt.so.1", O_RDONLY) = -1 ENOENT 
(No
> such file or directory)
> stat64("/lib/v5EJl/fast-mult/half", 0xbffff2bc) = -1 ENOENT (No such 
file
> or directory)
> open("/lib/v5EJl/fast-mult/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No 
such
> file or directory)
...
> sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"...,
> 88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
> poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
> ioctl(3, 0x8912, 0xbfffcecc)            = 0
> ioctl(3, 0x8913, 0xbfffced4)            = 0
> sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"...,
> 88, 0, {sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
> poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
> ioctl(3, 0x8912, 0xbfffcecc)            = 0
> ioctl(3, 0x8913, 0xbfffced4)            = 0
> write(2, "mount: RPC: Timed out\n", 22) = 22
> close(3)                                = 0
> close(3)                                = -1 EBADF (Bad file descriptor)
> write(2, "mount: ", 7)                  = 7
> write(2, "nfsmount failed", 15)         = 15
> write(2, ": Bad file descriptor\n", 22) = 22
> write(2, "mount: ", 7)                  = 7
> write(2, "Mounting 192.168.1.6:/opt/Qtopia"..., 58) = 58
> write(2, ": Bad file descriptor\n", 22) = 22
> _exit(1)                                = ?


Thank you for this wonderfully linewrapped listing.
It was a real joy fixing it up ;)

Ok, Im serious again. Is this 1.6.1?
if it is not, please try 1.6.1.
If it is, please try adding "msock = -1" in mount.c:

                        /* Connection refused */
                        if (!daemonized && prevt == 0) /* print just once 
*/
                                error_msg_rpc(clnt_sperror(mclient, " "));
                        auth_destroy(mclient->cl_auth);
                        clnt_destroy(mclient);
                        mclient = 0;
                        close(msock);
+                       msock = -1;

and here:

        /* clean up */

        auth_destroy(mclient->cl_auth);
        clnt_destroy(mclient);
        close(msock);
+       msock = -1;

This may fix extra close() and prevent bogus error message about
"Bad file descriptor". In reality you are seeing timeout:


time(NULL)                              = 197
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
getpid()                                = 60
bind(3, {sa_family=AF_INET, sin_port=htons(660), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111), 
sin_addr=inet_addr("192.168.1.6")}, 16) = -1 ETIMEDOUT (Connection timed 
out)
close(3)                                = 0
brk(0)                                  = 0xad000
brk(0xb1000)                            = 0xb1000
gettimeofday({386, 767720}, NULL)       = 0

See? Connection to portmapper failed after almost 200 seconds of trying.
And then attempts to use default port and reach mount directly time out 
too
(poll() waits for 3 seconds and returns 0 -> no reply received):

socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(661), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, FIONBIO, [1])                  = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
uname({sys="Linux", node="imx21", ...}) = 0
geteuid32()                             = 0
getegid32()                             = 0
getgroups32(0x20, 0xbffff0bc)           = 0
gettimeofday({386, 811220}, NULL)       = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
sendto(3, "]\234\333\177\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\1\0\0\0"..., 
88, 0, 
{sa_family=AF_INET, sin_port=htons(635), sin_addr=inet_addr8
poll([{fd=3, events=POLLIN}], 1, 3000)  = 0
ioctl(3, 0x8912, 0xbfffcecc)            = 0
ioctl(3, 0x8913, 0xbfffced4)            = 0
write(2, "mount: RPC: Timed out\n", 22) = 22
close(3)                                = 0
close(3)                                = -1 EBADF (Bad file descriptor)
write(2, "mount: ", 7)                  = 7
write(2, "nfsmount failed", 15)         = 15
write(2, ": Bad file descriptor\n", 22) = 22


Apart from bogus close() screwing up error code, I dont see
any problem on client side. It simply cannot reach the server.
--
vda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070829/86d1e3df/attachment.htm 

From vda.linux at googlemail.com  Wed Aug 29 03:37:31 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 29 Aug 2007 11:37:31 +0100
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <OFD075E021.25D51D4E-ON48257346.000ACE96-48257346.000E5E3C@alps.com.hk>
References: <OFD075E021.25D51D4E-ON48257346.000ACE96-48257346.000E5E3C@alps.com.hk>
Message-ID: <200708291137.32093.vda.linux@googlemail.com>

On Wednesday 29 August 2007 03:42, xiao.liang at cn.alps.com wrote:
> After I try busbox 1.6.1, the bad file descriptor error disappear, but
> still got RPC timeout error. And the mount service is still V1. I think it

Yes, strace was clearly showing that server doesn't respond.
If you still unsure what's going on, use tcpdump to see
what happens on the wire.

(If you send tcpdump outout to the list, use attachment - linewrapped
tcpdump would be totally unreadable)

> is due to the failed nfs mount use a very early verion 1 of mount service.
> Anyone who knows how to update the mount servce version?

busybox mount doesn't know about NFS version 1, only 2 and 3
are supported.

If you mean that your NFS server is version 1, well, you
need to install newer one.
--
vda

From tomas at slax.org  Wed Aug 29 05:50:09 2007
From: tomas at slax.org (Tomas M)
Date: Wed, 29 Aug 2007 12:50:09 +0000
Subject: mount patch
In-Reply-To: <46D4499D.2010604@slax.org>
References: <46D4499D.2010604@slax.org>
Message-ID: <46D56B81.3060008@slax.org>

Tomas M wrote:
> Hello,
> this is a patch for mount.c in busybox, to simply ignore -i option.
> 
> -i is used in GNU mount for this purpose:
>      Don't call the /sbin/mount.<filesystem> helper even if it exists.
> 
> But BusyBox doesn't call this anyway (IMHO) so it's safe to silently 
> ignore it.
> 
> This is my first busybox modification ever, so please review the patch 
> if it is correct! It should be.

I forgot to tell you why the patch is needed at all.

It's useful for newest FUSE (filesystem in userspace), where fuse forces 
to use -i option. This causes new fuse (2.7+) to stop working with 
busybox's mount. One is not able to mount any fuse filesystem without -i.


Thank you for your consideration.

Tomas M



From vda.linux at googlemail.com  Wed Aug 29 04:32:35 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 29 Aug 2007 12:32:35 +0100
Subject: mount patch
In-Reply-To: <46D4499D.2010604@slax.org>
References: <46D4499D.2010604@slax.org>
Message-ID: <200708291232.35843.vda.linux@googlemail.com>

On Tuesday 28 August 2007 17:13, Tomas M wrote:
> Hello,
> this is a patch for mount.c in busybox, to simply ignore -i option.
>
> -i is used in GNU mount for this purpose:
>       Don't call the /sbin/mount.<filesystem> helper even if it exists.
>
> But BusyBox doesn't call this anyway (IMHO) so it's safe to silently
> ignore it.
>
> This is my first busybox modification ever, so please review the patch
> if it is correct! It should be.

Applied, thanks!
--
vda

From vda.linux at googlemail.com  Wed Aug 29 04:41:38 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 29 Aug 2007 12:41:38 +0100
Subject: [rfc] sed option `-i' (edit in place)
In-Reply-To: <001901c7e878$93d221d0$01935e0a@se.axis.com>
References: <001901c7e878$93d221d0$01935e0a@se.axis.com>
Message-ID: <200708291241.38877.vda.linux@googlemail.com>

On Monday 27 August 2007 08:04, Johan Adolfsson wrote:
> > -----Original Message-----
> > From: busybox-bounces at busybox.net
> > [mailto:busybox-bounces at busybox.net] On Behalf Of Cristian
> > Ionescu-Idbohrn
> > Sent: den 26 augusti 2007 23:21
> > To: busybox at busybox.net
> > Subject: Re: [rfc] sed option `-i' (edit in place)
> >
> > > Does stock sed do this?
> >
> > No.  GNU sed is doing something similar to bb-sed (or the other way
> > around):
> >
> > ,----
> >
> > | open("lines", O_RDONLY|O_LARGEFILE) = 3
> > | ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfd35068) = -1
> >
> > ENOTTY (Inappropriate ioctl for device)
> >
> > | fstat64(3, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
> > | gettimeofday({1188158729, 155778}, NULL) = 0
> > | getpid()                                = 19852
> > | open("./sedSTqTlj", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 10
> > | fcntl64(10, F_GETFL)                    = 0x8002 (flags
> >
> > O_RDWR|O_LARGEFILE)
> >
> > | fstat64(10, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> > | mmap2(NULL, 131072, PROT_READ|PROT_WRITE,
> >
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dfe000
> >
> > | _llseek(10, 0, [0], SEEK_CUR)           = 0
> > | fchmod(10, 0100644)                     = 0
> > | fchown32(10, 1000, 1000)                = 0
> > | fstat64(3, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
> > | mmap2(NULL, 131072, PROT_READ|PROT_WRITE,
> >
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dde000
> >
> > | read(3, "fxx\nbar\n", 131072)           = 8
> > | write(10, "fxx\n", 4)                   = 4
> > | write(10, "bar\n", 4)                   = 4
> > | read(3, "", 131072)                     = 0
> > | close(3)                                = 0
> > | munmap(0xb7dde000, 131072)              = 0
> > | close(10)                               = 0
> > | munmap(0xb7dfe000, 131072)              = 0
> > | rename("./sedSTqTlj", "lines")          = 0
> > | close(1)                                = 0
> > | close(2)                                = 0
> >
> > `----
>
> Wouldn't we get reduced wearing and possibly a general speed up as well,
> if we made sure sed was buffering stuff more and avoiding small writes
> to the filesystem?

Yes, small writes are undesirable, but for different reason: write syscall
overhead can take significant time, and if you pipe gigabytes of data thru
sed, you dont want that.

However, weigh speed gains against possibly bigger code and bigger buffers
(memory consumption).

> Then there shouldn't be much difference in flash wearing compared to a
> copy.

Unless you mounted the fs with O_SYNC, writes are buffered by kernel anyway.
--
vda

From vda.linux at googlemail.com  Wed Aug 29 04:46:27 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Wed, 29 Aug 2007 12:46:27 +0100
Subject: Add an option to assign server/client port in udhcp[cd] ?
In-Reply-To: <46D37724.6030107@nchc.org.tw>
References: <46D37724.6030107@nchc.org.tw>
Message-ID: <200708291246.27655.vda.linux@googlemail.com>

On Tuesday 28 August 2007 02:15, Steven Shiau wrote:
> Hi,
> Just noticed that busybox 1.7 is released, and some new functions added
> . IMHO, I'd like to suggest that an option should be added to assign the
> server and client port in udhcp[cd], i.e.
> These two ports
> #define SERVER_PORT     67
> #define CLIENT_PORT     68
> can be assigned when run udhcpc and udhcpd. This is very useful when
> there is an existing dhcp service in the network subnet, and if people
> would like to put another dhcp service with customized port.

I'm surprised that you actually want this, but it shouldn't be a problem.

Currently, letter P is not used yet in both udhcpc and udhcpd.

Introduce new option -P [ip:]port and post patch to this mailing list.
--
vda

From busybox at seifer.net  Wed Aug 29 08:03:29 2007
From: busybox at seifer.net (Jeff Seifer)
Date: Wed, 29 Aug 2007 11:03:29 -0400
Subject: undefined reference to _NR_clock_gettime
Message-ID: <46D58AC1.6080808@seifer.net>

Hi all,

I just downloaded the 1.7.0 source, ran make defconfig and compiled from 
my device (running debian on an arm9 board).
Almost everything built without a hitch, but when it got to 
runit/runsv.c I got an undeclared _NR_clock_gettime.

Just curious what "_NR_clock_gettime" is and where it's supposed to be 
declared.  I tried chaning to plain old clock_gettime, but got a link 
problem with that, so I reconfigured my build to leave out runsv and it 
built everything else.

Just curious if anyone knows why I'm getting the undefined reference.

Thanks!
Jeff

From landau_alex at yahoo.com  Thu Aug 30 01:28:10 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 30 Aug 2007 01:28:10 -0700 (PDT)
Subject: fork() on NOMMU
Message-ID: <607058.63854.qm@web62504.mail.re1.yahoo.com>

Hi,

It's a pity I haven't spotted this earlier...
1.7.0 contains in libbb.h:
#define fork() BUG_fork_is_unavailable_on_nommu()
Last time I checked (1.4.1) this define wasn't there.

The problem I see is the following: fork() is used in several places, notably
util-linux/mount.c:731
archival/libunarchive/open_transformer.c:18

With the above #define, the build fails on my NOMMU board, despite not reaching the code
path using fork(). (e.g. in 1.4.1 I couldn't use "tar -czf" - it bailed out at runtime
with "fork() - not supported" or something similar, but could use "tar -xzf", and "mount"
worked too).

Any thoughts of the "right" way to solve this?
Removing the #define may be the easiest solution until all code using fork() is audited.

Thanks,
Alex


       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 

From xiao.liang at cn.alps.com  Thu Aug 30 02:46:58 2007
From: xiao.liang at cn.alps.com (xiao.liang at cn.alps.com)
Date: Thu, 30 Aug 2007 17:46:58 +0800
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <200708291137.32093.vda.linux@googlemail.com>
Message-ID: <OF3BAE08C7.3C375EA7-ON48257347.00352D18-48257347.003541B2@alps.com.hk>

Thank you! Now I do not think it is version problem. Actually, I found 
that the TCP connection is never complete between my nfs client and 
server. The server reply the SYN,ACK but the client just do not respond. 
As for UDP is the same . I use inetd and portmap on client side , I think 
there must be sth wrong on my client side.
packets :
from client to server:
src port : 794, dest port:111
from server to client:
src port:111 dest port:794

the tcpdump on the client side is look like this

10.25.16.160.794 > 10.25.16.130.sunrpc: S, cksum 0x5740 (correct), 
31406388

 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x79e6 (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x79e6 (correct), 
2533961748:2
 60) 10.25.16.160.794 > 10.25.16.130.sunrpc: S, cksum 0x5614 (correct), 
31406388
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76ff (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76ff (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76f8 (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76f8 (correct), 
2533961748:2


 60) 10.25.16.160.794 > 10.25.16.130.sunrpc: S, cksum 0x53bc (correct), 
31406388
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x7123 (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x7123 (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x711c (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x711c (correct), 
2533961748:2


 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x6563 (correct), 
2533961748:2
 60) 10.25.16.160.794 > 10.25.16.130.sunrpc: S, cksum 0x4f0c (correct), 
31406388
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x6561 (correct), 
2533961748:2
 10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x6563 (correct), 
2533961748:

Is it the portmap or inetd' problem?



Denys Vlasenko <vda.linux at googlemail.com> 
08/29/2007 06:37 PM

??
xiao.liang at cn.alps.com
cc
busybox at busybox.net
"hinko.kocevar at cetrtapot.si" <hinko.kocevar at cetrtapot.si>
??
Re: mount:nfsmount failed: Bad file descriptor






On Wednesday 29 August 2007 03:42, xiao.liang at cn.alps.com wrote:
> After I try busbox 1.6.1, the bad file descriptor error disappear, but
> still got RPC timeout error. And the mount service is still V1. I think 
it

Yes, strace was clearly showing that server doesn't respond.
If you still unsure what's going on, use tcpdump to see
what happens on the wire.

(If you send tcpdump outout to the list, use attachment - linewrapped
tcpdump would be totally unreadable)

> is due to the failed nfs mount use a very early verion 1 of mount 
service.
> Anyone who knows how to update the mount servce version?

busybox mount doesn't know about NFS version 1, only 2 and 3
are supported.

If you mean that your NFS server is version 1, well, you
need to install newer one.
--
vda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070830/bbeed4fb/attachment.htm 

From hinko.kocevar at cetrtapot.si  Thu Aug 30 06:02:23 2007
From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si)
Date: Thu, 30 Aug 2007 15:02:23 +0200
Subject: compiling busybox-1.6.1 for cris architecture fails
Message-ID: <46D6BFDF.1070602@cetrtapot.si>

Hi,

We are using rather old version of busybox (1.1.2) on our embedded
systems and would like to upgrade to the latest stable version - 1.6.1.
The applets seem to compile just fine, but linking fails to produce
busybox_unstripped. We are using uClibc.

[....]
OUTPUT(busybox_unstripped elf32-cris)
collect2: ld returned 1 exit status
echo 'cmd_busybox_unstripped :=
/home/hinkok/delo/fw/car2_R1.gen/pkg/busybox-R2/build/uclibc/static/scripts/trylink 

gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM -D_REENTRANT
-mno-mul-bug-workaround -muclibc=/fw/car2_R1.gen/stage.uclibc
-L/fw/car2_R1.gen/stage.uclibc/lib
-Wl,-rpath-link,/fw/car2_R1.gen/stage.uclibc/lib -o busybox_unstripped
-Wl,-M -Wl,--warn-common -Wl,--sort-common -Wl,--start-group
applets/built-in.o  archival/lib.a  archival/libunarchive/lib.a
console-tools/lib.a  coreutils/lib.a  coreutils/libcoreutils/lib.a
debianutils/lib.a  e2fsprogs/lib.a  editors/lib.a  findutils/lib.a
init/lib.a  ipsvd/lib.a  libbb/lib.a  libpwdgrp/lib.a  loginutils/lib.a
   miscutils/lib.a  modutils/lib.a  networking/lib.a
networking/libiproute/lib.a  networking/udhcp/lib.a  procps/lib.a
runit/lib.a  selinux/lib.a  shell/lib.a  sysklogd/lib.a
util-linux/lib.a  archival/built-in.o  archival/libunarchive/built-in.o
   console-tools/built-in.o  coreutils/built-in.o
coreutils/libcoreutils/built-in.o  debianutils/built-in.o
e2fsprogs/built-in.o  editors/built-in.o  findutils/built-in.o
init/built-in.o  ipsvd/built-in.o  libbb/built-in.o
libpwdgrp/built-in.o  loginutils/built-in.o  miscutils/built-in.o
modutils/built-in.o  networking/built-in.o
networking/libiproute/built-in.o  networking/udhcp/built-in.o
procps/built-in.o  runit/built-in.o  selinux/built-in.o
shell/built-in.o  sysklogd/built-in.o  util-linux/built-in.o
-Wl,--end-group ' > ./.busybox_unstripped.cmd
rm -f .old_version
cris-axis-linux-gnu-strip -s --remove-section=.note
--remove-section=.comment \
		busybox_unstripped -o busybox
cris-axis-linux-gnu-strip: busybox_unstripped: No such file or directory
make[3]: *** [busybox] Error 1
make[3]: Leaving directory
`/home/hinkok/delo/fw/car2_R1.gen/pkg/busybox-R2/build/uclibc/static'
make[2]: *** [/fw/car2_R1.gen/pkg/busybox-R2/build/uclibc/static/.build]
Error 2
make[2]: Leaving directory
`/home/hinkok/workspace/buildroot/trunk/products/car2'
make[1]: *** [packages] Error 2
make[1]: Leaving directory
`/home/hinkok/workspace/buildroot/trunk/products/car2'
make: *** [car2-all] Error 2


Complete build (with make V=1) is located at:

http://4thway.0catch.com/busybox-error_3.txt

Can anyone help out with that?

Thank you,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si




From vda.linux at googlemail.com  Thu Aug 30 07:57:58 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 30 Aug 2007 15:57:58 +0100
Subject: mount:nfsmount failed: Bad file descriptor
In-Reply-To: <OF3BAE08C7.3C375EA7-ON48257347.00352D18-48257347.003541B2@alps.com.hk>
References: <OF3BAE08C7.3C375EA7-ON48257347.00352D18-48257347.003541B2@alps.com.hk>
Message-ID: <200708301557.58347.vda.linux@googlemail.com>

On Thursday 30 August 2007 10:46, xiao.liang at cn.alps.com wrote:
> Thank you! Now I do not think it is version problem. Actually, I found
> that the TCP connection is never complete between my nfs client and
> server. The server reply the SYN,ACK but the client just do not respond.
> As for UDP is the same . I use inetd and portmap on client side , I think
> there must be sth wrong on my client side.
> packets :
> from client to server:
> src port : 794, dest port:111
> from server to client:
> src port:111 dest port:794
>
> the tcpdump on the client side is look like this

> 10.25.16.160.794 > 10.25.16.130.sunrpc: S, cksum 0x5740 (correct),
> 31406388
>  10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x79e6 (correct),
> 2533961748:2
>  10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x79e6 (correct),
> 2533961748:2
>  60) 10.25.16.160.794 > 10.25.16.130.sunrpc: S, cksum 0x5614 (correct),
> 31406388
>  10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76ff (correct),
> 2533961748:2
>  10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76ff (correct),
> 2533961748:2
>  10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76f8 (correct),
> 2533961748:2
>  10.25.16.130.sunrpc > 10.25.16.160.794: S, cksum 0x76f8 (correct),
> 2533961748:2

What is sunrpc?...
# cat /etc/services | grep sunrpc
sunrpc          111/tcp         portmapper      # RPC 4.0 portmapper
sunrpc          111/udp         portmapper
..aha

It seems that server's SYN/ACK does reach client, but it ignores them.

Does telnetting from client to server's port 111 work?

Do you have firewall configured?

P.S. Can you _please_ send non-linewrapped output next time?

Also for some reason you don't have timestamp in tcpdump output:

# tcpdump -nlieth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:50:16.176366 00:15:fa:60:94:46 > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
15:50:16.517619 arp who-has 172.28.3.60 tell 172.28.3.250
15:50:16.527435 arp who-has 172.28.3.159 tell 172.28.3.251
^^^^^^^^^^^^^^^
--
vda

From vda.linux at googlemail.com  Thu Aug 30 08:14:26 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Thu, 30 Aug 2007 16:14:26 +0100
Subject: compiling busybox-1.6.1 for cris architecture fails
In-Reply-To: <46D6BFDF.1070602@cetrtapot.si>
References: <46D6BFDF.1070602@cetrtapot.si>
Message-ID: <200708301614.26742.vda.linux@googlemail.com>

On Thursday 30 August 2007 14:02, hinko.kocevar at cetrtapot.si wrote:
> Hi,
>
> We are using rather old version of busybox (1.1.2) on our embedded
> systems and would like to upgrade to the latest stable version - 1.6.1.
> The applets seem to compile just fine, but linking fails to produce
> busybox_unstripped. We are using uClibc.
>
> Complete build (with make V=1) is located at:
>
> http://4thway.0catch.com/busybox-error_3.txt

Strange, I don't see error message.

Do you have busybox_ld.err file? It may contain error message.

Can you remove "-Wl,-M" from Makefile and rerun the command?
--
vda

From hinko.kocevar at cetrtapot.si  Fri Aug 31 00:36:28 2007
From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si)
Date: Fri, 31 Aug 2007 09:36:28 +0200
Subject: compiling busybox-1.6.1 for cris architecture fails
In-Reply-To: <200708301614.26742.vda.linux@googlemail.com>
References: <46D6BFDF.1070602@cetrtapot.si>
	<200708301614.26742.vda.linux@googlemail.com>
Message-ID: <46D7C4FC.9000008@cetrtapot.si>

Denys Vlasenko wrote:
> On Thursday 30 August 2007 14:02, hinko.kocevar at cetrtapot.si wrote:
>> Hi,
>>
>> We are using rather old version of busybox (1.1.2) on our embedded
>> systems and would like to upgrade to the latest stable version - 1.6.1.
>> The applets seem to compile just fine, but linking fails to produce
>> busybox_unstripped. We are using uClibc.
>>
>> Complete build (with make V=1) is located at:
>>
>> http://4thway.0catch.com/busybox-error_3.txt
> 
> Strange, I don't see error message.
> 
> Do you have busybox_ld.err file? It may contain error message.

Yes. I have uploaded it to the
http://4thway.0catch.com/busybox_ld.err

> 
> Can you remove "-Wl,-M" from Makefile and rerun the command?

I've rebuild without the "-Wl,-M" and the result seems the same but the 
busybox_ld.err is smaller. See
http://4thway.0catch.com/busybox_ld.err_nowlm

It is something about the glibc _start symbol?!

Thank you,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si


From vda.linux at googlemail.com  Fri Aug 31 04:36:12 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 31 Aug 2007 12:36:12 +0100
Subject: compiling busybox-1.6.1 for cris architecture fails
In-Reply-To: <46D7C4FC.9000008@cetrtapot.si>
References: <46D6BFDF.1070602@cetrtapot.si>
	<200708301614.26742.vda.linux@googlemail.com>
	<46D7C4FC.9000008@cetrtapot.si>
Message-ID: <200708311236.12337.vda.linux@googlemail.com>

On Friday 31 August 2007 08:36, hinko.kocevar at cetrtapot.si wrote:
> Denys Vlasenko wrote:
> > On Thursday 30 August 2007 14:02, hinko.kocevar at cetrtapot.si wrote:
> >> Hi,
> >>
> >> We are using rather old version of busybox (1.1.2) on our embedded
> >> systems and would like to upgrade to the latest stable version - 1.6.1.
> >> The applets seem to compile just fine, but linking fails to produce
> >> busybox_unstripped. We are using uClibc.
> >>
> >> Complete build (with make V=1) is located at:
> >>
> >> http://4thway.0catch.com/busybox-error_3.txt
> >
> > Strange, I don't see error message.
> >
> > Do you have busybox_ld.err file? It may contain error message.
>
> Yes. I have uploaded it to the
> http://4thway.0catch.com/busybox_ld.err
>
> > Can you remove "-Wl,-M" from Makefile and rerun the command?
>
> I've rebuild without the "-Wl,-M" and the result seems the same but the
> busybox_ld.err is smaller. See
> http://4thway.0catch.com/busybox_ld.err_nowlm

This is fixed in 1.7.0. Link map is saved into separate file,
making error message much easer to find. Sorry.

Does it make sense to you to jump to 1.7.0, since you
have to jump anyway?

> It is something about the glibc _start symbol?!

uclibc.

applets/built-in.o: In function `__negdi2':
/usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52: multiple 
definition of `_start'
/fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.text+0x0): first defined here
applets/built-in.o: In function `__negdi2':
/usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52: multiple 
definition of `__mainp'
/fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.data.rel+0x0): first defined here
applets/built-in.o: In function `__negdi2':
/usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52: multiple 
definition of `__data_start'
/fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.data+0x0): first defined here
collect2: ld returned 1 exit status

Something is messed up in the toolchain.

Does libgcc2.c in gcc you use really define _start? Why?

Can you successfully cross-compile "Hello world"?
--
vda

From hinko.kocevar at cetrtapot.si  Fri Aug 31 05:06:46 2007
From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si)
Date: Fri, 31 Aug 2007 14:06:46 +0200
Subject: compiling busybox-1.6.1 for cris architecture fails
In-Reply-To: <200708311236.12337.vda.linux@googlemail.com>
References: <46D6BFDF.1070602@cetrtapot.si>
	<200708301614.26742.vda.linux@googlemail.com>
	<46D7C4FC.9000008@cetrtapot.si>
	<200708311236.12337.vda.linux@googlemail.com>
Message-ID: <46D80456.1000009@cetrtapot.si>

Denys Vlasenko wrote:
> On Friday 31 August 2007 08:36, hinko.kocevar at cetrtapot.si wrote:
>> Denys Vlasenko wrote:
>>> On Thursday 30 August 2007 14:02, hinko.kocevar at cetrtapot.si wrote:
>>>> Hi,
>>>>
>>>> We are using rather old version of busybox (1.1.2) on our embedded
>>>> systems and would like to upgrade to the latest stable version - 1.6.1.
>>>> The applets seem to compile just fine, but linking fails to produce
>>>> busybox_unstripped. We are using uClibc.
>>>>
>>>> Complete build (with make V=1) is located at:
>>>>
>>>> http://4thway.0catch.com/busybox-error_3.txt
>>> Strange, I don't see error message.
>>>
>>> Do you have busybox_ld.err file? It may contain error message.
>> Yes. I have uploaded it to the
>> http://4thway.0catch.com/busybox_ld.err
>>
>>> Can you remove "-Wl,-M" from Makefile and rerun the command?
>> I've rebuild without the "-Wl,-M" and the result seems the same but the
>> busybox_ld.err is smaller. See
>> http://4thway.0catch.com/busybox_ld.err_nowlm
> 
> This is fixed in 1.7.0. Link map is saved into separate file,
> making error message much easer to find. Sorry.
> 
> Does it make sense to you to jump to 1.7.0, since you
> have to jump anyway?

I'll try it out. I guess it is not that of a problem, just that it is 
labeled unstable and I hesitate to break something else by introducing 
untested code in the production systems [like it is not enough that our 
own untested stuff makes it there :-/]...

> 
>> It is something about the glibc _start symbol?!
> 
> uclibc.
> 
> applets/built-in.o: In function `__negdi2':
> /usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52: multiple 
> definition of `_start'
> /fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.text+0x0): first defined here
> applets/built-in.o: In function `__negdi2':
> /usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52: multiple 
> definition of `__mainp'
> /fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.data.rel+0x0): first defined here
> applets/built-in.o: In function `__negdi2':
> /usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52: multiple 
> definition of `__data_start'
> /fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.data+0x0): first defined here
> collect2: ld returned 1 exit status
> 
> Something is messed up in the toolchain.
> 
> Does libgcc2.c in gcc you use really define _start? Why?
> 

Can't tell since the path points to non-existent source file on my 
system - it is pre-built toolchain that Axis supplies (makers of the 
cris CPU). Would have to download the toolchain source and check (maybe 
later).

> Can you successfully cross-compile "Hello world"?

Sure, it even runs:).

hinkok at genovefa /tmp $ cat hello.c
#include <stdio.h>

int main (void)
{
	printf("Hello world..\n");
	return 0;
}

hinkok at genovefa /tmp $ gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM 
-D_REENTRANT -mno-mul-bug-workaround 
-muclibc=/fw/car2_R1.gen/stage.uclibc/ hello.c
hinkok at genovefa /tmp $ scp a.out root at 10.0.0.200:/tmp
root at 10.0.0.200's password:
a.out                                         100% 2228     2.2KB/s 
00:00
hinkok at genovefa /tmp $ ssh root at 10.0.0.200 /tmp/a.out
root at 10.0.0.200's password:
Hello world..


Let me just say that I had no problems while compiling (ancient) 
busybox-1.1.2 source. I would bet my money in the linker options - but 
which?!

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si


From vda.linux at googlemail.com  Fri Aug 31 05:45:38 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 31 Aug 2007 13:45:38 +0100
Subject: compiling busybox-1.6.1 for cris architecture fails
In-Reply-To: <46D80456.1000009@cetrtapot.si>
References: <46D6BFDF.1070602@cetrtapot.si>
	<200708311236.12337.vda.linux@googlemail.com>
	<46D80456.1000009@cetrtapot.si>
Message-ID: <200708311345.39236.vda.linux@googlemail.com>

On Friday 31 August 2007 13:06, hinko.kocevar at cetrtapot.si wrote:
> Denys Vlasenko wrote:
> > On Friday 31 August 2007 08:36, hinko.kocevar at cetrtapot.si wrote:
> >> Denys Vlasenko wrote:
> >>> On Thursday 30 August 2007 14:02, hinko.kocevar at cetrtapot.si wrote:
> >>>> Hi,
> >>>>
> >>>> We are using rather old version of busybox (1.1.2) on our embedded
> >>>> systems and would like to upgrade to the latest stable version -
> >>>> 1.6.1. The applets seem to compile just fine, but linking fails to
> >>>> produce busybox_unstripped. We are using uClibc.
> >>>>
> >>>> Complete build (with make V=1) is located at:
> >>>>
> >>>> http://4thway.0catch.com/busybox-error_3.txt
> >>>
> >>> Strange, I don't see error message.
> >>>
> >>> Do you have busybox_ld.err file? It may contain error message.
> >>
> >> Yes. I have uploaded it to the
> >> http://4thway.0catch.com/busybox_ld.err
> >>
> >>> Can you remove "-Wl,-M" from Makefile and rerun the command?
> >>
> >> I've rebuild without the "-Wl,-M" and the result seems the same but the
> >> busybox_ld.err is smaller. See
> >> http://4thway.0catch.com/busybox_ld.err_nowlm
> >
> > This is fixed in 1.7.0. Link map is saved into separate file,
> > making error message much easer to find. Sorry.
> >
> > Does it make sense to you to jump to 1.7.0, since you
> > have to jump anyway?
>
> I'll try it out. I guess it is not that of a problem, just that it is
> labeled unstable and I hesitate to break something else by introducing
> untested code in the production systems [like it is not enough that our
> own untested stuff makes it there :-/]...
>
> >> It is something about the glibc _start symbol?!
> >
> > uclibc.
> >
> > applets/built-in.o: In function `__negdi2':
> > /usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52:
> > multiple definition of `_start'
> > /fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.text+0x0): first defined here
> > applets/built-in.o: In function `__negdi2':
> > /usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52:
> > multiple definition of `__mainp'
> > /fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.data.rel+0x0): first defined
> > here applets/built-in.o: In function `__negdi2':
> > /usr/src/redhat/BUILD/cris-dist-1.62/gnu-toplev/gcc/libgcc2.c:52:
> > multiple definition of `__data_start'
> > /fw/car2_R1.gen/stage.uclibc/lib/crt0.o(.data+0x0): first defined here
> > collect2: ld returned 1 exit status
> >
> > Something is messed up in the toolchain.
> >
> > Does libgcc2.c in gcc you use really define _start? Why?
>
> Can't tell since the path points to non-existent source file on my
> system - it is pre-built toolchain that Axis supplies (makers of the
> cris CPU). Would have to download the toolchain source and check (maybe
> later).
>
> > Can you successfully cross-compile "Hello world"?
>
> Sure, it even runs:).
>
> hinkok at genovefa /tmp $ cat hello.c
> #include <stdio.h>
>
> int main (void)
> {
> 	printf("Hello world..\n");
> 	return 0;
> }
>
> hinkok at genovefa /tmp $ gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM
> -D_REENTRANT -mno-mul-bug-workaround
> -muclibc=/fw/car2_R1.gen/stage.uclibc/ hello.c
> hinkok at genovefa /tmp $ scp a.out root at 10.0.0.200:/tmp
> root at 10.0.0.200's password:
> a.out                                         100% 2228     2.2KB/s
> 00:00
> hinkok at genovefa /tmp $ ssh root at 10.0.0.200 /tmp/a.out
> root at 10.0.0.200's password:
> Hello world..
>
>
> Let me just say that I had no problems while compiling (ancient)
> busybox-1.1.2 source. I would bet my money in the linker options - but
> which?!

According to your logs trylink script is started with:

/home/hinkok/delo/fw/car2_R1.gen/pkg/busybox-R2/build/uclibc/static/scripts/trylink 
gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM -D_REENTRANT
-mno-mul-bug-workaround -muclibc=/fw/car2_R1.gen/stage.uclibc
-L/fw/car2_R1.gen/stage.uclibc/lib
-Wl,-rpath-link,/fw/car2_R1.gen/stage.uclibc/lib
-o busybox_unstripped
-Wl,-M
-Wl,--warn-common -Wl,--sort-common -Wl,--start-group
applets/built-in.o  archival/lib.a  archival/libunarchive/lib.a  
console-tools/lib.a  coreutils/lib.a  coreutils/libcoreutils/lib.a  
debianutils/lib.a  e2fsprogs/lib.a  editors/lib.a  findutils/lib.a  
init/lib.a  ipsvd/lib.a  libbb/lib.a  libpwdgrp/lib.a  login
utils/lib.a  miscutils/lib.a  modutils/lib.a  networking/lib.a  
networking/libiproute/lib.a  networking/udhcp/lib.a  procps/lib.a  
runit/lib.a  selinux/lib.a  shell/lib.a  sysklogd/lib.a  util-linux/lib.a  
archival/built-in.o  archival/libunarchive/built-in.o  
console-tools/built-in.o  coreutils/built-in.o  
coreutils/libcoreutils/built-in.o  debianutils/built-in.o  
e2fsprogs/built-in.o  editors/built-in.o
findutils/built-in.o  init/built-in.o  ipsvd/built-in.o  libbb/built-in.o  
libpwdgrp/built-in.o  loginutils/built-in.o  miscutils/built-in.o  
modutils/built-in.o  networking/built-in.o  networking/libiproute/built-in.o
networking/udhcp/built-in.o  procps/built-in.o  runit/built-in.o  
selinux/built-in.o  shell/built-in.o  sysklogd/built-in.o  
util-linux/built-in.o -Wl,--end-group

Nothing especially interesting.

You may go into trylink and set debug=true, you will make
trylink report commands it tries to run.

Do gcc -v hello_world.c and compare linker flags used for it and for bbox.

And btw, note that gcc commands which compile .c files into .o contains
-static-libgcc - maybe this is the problem?

Makefile.flags
==============
CFLAGS += $(call cc-option,-funsigned-char -static-libgcc,)
                                           ^^^^^^^^^^^^^^
--
vda

From roberto.foglietta at gmail.com  Fri Aug 31 08:02:13 2007
From: roberto.foglietta at gmail.com (Roberto A. Foglietta)
Date: Fri, 31 Aug 2007 17:02:13 +0200
Subject: [OT] keep memory under control
Message-ID: <e4c675870708310802q21729675p6a07723f4c66505f@mail.gmail.com>

Hi to all folks,

 sorry for the OT but I hope these scripts will be usefull for you too

 If I would keep trace of memory (in order to find some naqsty memory
leaks) amount used this script for bb-ash would work in your opinion?


getrssmem() {
local rss=0 lst="$(ls -1 /proc/*/statm | grep -v $$)"
local val="$(for i in $lst; do cat $i 2>/dev/null | cut -d\  -f2; done)"
for i in $val; do let rss+=$i; done
echo $rss
}

getkrnmem() {
local str x y z krn
str=$(free | head -n2 | tail -n1)
x=$(echo $str | cut -d\  -f3)
y=$(echo $str | cut -d\  -f5)
z=$(echo $str | cut -d\  -f6)
let krn=$x-$y-$z-$1
echo $krn
}

waituntilminute() {
local x
let x=$(date +%s)%60
let x=60-$x
sleep $x
}

while true; do
waituntilminute
rss=$(getrssmem); echo -n "$rss "; getkrnmem $rss
done

 Cheers,
-- 
/roberto

From vda.linux at googlemail.com  Fri Aug 31 09:25:19 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 31 Aug 2007 17:25:19 +0100
Subject: undefined reference to _NR_clock_gettime
In-Reply-To: <46D58AC1.6080808@seifer.net>
References: <46D58AC1.6080808@seifer.net>
Message-ID: <200708311725.19772.vda.linux@googlemail.com>

On Wednesday 29 August 2007 16:03, Jeff Seifer wrote:
> Hi all,
> 
> I just downloaded the 1.7.0 source, ran make defconfig and compiled from 
> my device (running debian on an arm9 board).
> Almost everything built without a hitch, but when it got to 
> runit/runsv.c I got an undeclared _NR_clock_gettime.
> 
> Just curious what "_NR_clock_gettime" is and where it's supposed to be 
> declared.  I tried chaning to plain old clock_gettime, but got a link 
> problem with that, so I reconfigured my build to leave out runsv and it 
> built everything else.
> 
> Just curious if anyone knows why I'm getting the undefined reference.

My fault, I was a bit lazy and hadrcoded clock_gettinm when I was removing
some unneeded time abstractions in runit/*

Try attached patch, does it makes you happy?
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 2527 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070831/83d85ddf/attachment.bin 

From vda.linux at googlemail.com  Fri Aug 31 09:34:45 2007
From: vda.linux at googlemail.com (Denys Vlasenko)
Date: Fri, 31 Aug 2007 17:34:45 +0100
Subject: fork() on NOMMU
In-Reply-To: <607058.63854.qm@web62504.mail.re1.yahoo.com>
References: <607058.63854.qm@web62504.mail.re1.yahoo.com>
Message-ID: <200708311734.45379.vda.linux@googlemail.com>

On Thursday 30 August 2007 09:28, Alex Landau wrote:
> Hi,
> 
> It's a pity I haven't spotted this earlier...
> 1.7.0 contains in libbb.h:
> #define fork() BUG_fork_is_unavailable_on_nommu()
> Last time I checked (1.4.1) this define wasn't there.
> 
> The problem I see is the following: fork() is used in several places, notably
> util-linux/mount.c:731
> archival/libunarchive/open_transformer.c:18
> 
> With the above #define, the build fails on my NOMMU board, despite not reaching the code
> path using fork(). (e.g. in 1.4.1 I couldn't use "tar -czf" - it bailed out at runtime
> with "fork() - not supported" or something similar, but could use "tar -xzf", and "mount"
> worked too).

So you had some dead code in your busybox binary. Not good.
 
> Any thoughts of the "right" way to solve this?

To ifdef out things that do not work on NOMMU (for example,
mount's NFS-related option to auto-background should be disabled).

You already did it for httpd by adding #ifdefs which basically
enforced httpd -i. Send similar patches for tar/mount/whatever.

Note that this is not a best solution. More like as
a stopgap fix.

For example, in 1.7.0 httpd goes further and actually
does NOMMU specific things to retain ability to run
in standalone mode: it vforks + re-exec itself as child.
--
vda

From qexing at gmail.com  Wed Aug  1 03:08:28 2007
From: qexing at gmail.com (Zhiming Zhou)
Date: Wed, 1 Aug 2007 11:08:28 +0800
Subject: BusyBox poweroff problem with SMP kernel
Message-ID: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>

I compiled a smp linux kernel to support multiple processors, and use
busybox 1.6.1 as root filesystem.
The compiled linux system can be successfully started, and busybox ash is
started, while I typed "poweroff" in ash,

If the system run in computer with single processor; system stopped while
"Sending SIGTERM to all processes" was printed,
and I found in busybox source directory/init/init.c, function
shutdown_system(void):

message(L_CONSOLE | L_LOG, "Sending SIG%s to all processes", "TERM");
kill(-1, SIGTERM);

but kill function can not be proceeded, and system stopped.

But while the system run in computer with multiple processors; system
stopped while "Power down system" was printed, it seems out of busybox, and
acpi_power_off is not called.

And if I compiled my linux kernel without CONFIG_SMP configed, and use the
same busybox root file system, there was none poweroff problems in my
system.

------------------------------------------------------------------------------
So, I want to know is there someone successfully use busybox to poweroff
computer with SMP kernel? And what is the possible reason of my problem?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070801/f10849ae/attachment-0002.htm 

From vapier at gentoo.org  Wed Aug  1 09:23:12 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 1 Aug 2007 05:23:12 -0400
Subject: BusyBox poweroff problem with SMP kernel
In-Reply-To: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
References: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
Message-ID: <200708010523.12629.vapier@gentoo.org>

On Tuesday 31 July 2007, Zhiming Zhou wrote:
> So, I want to know is there someone successfully use busybox to poweroff 
> computer with SMP kernel? And what is the possible reason of my problem?

sounds like a kernel problem, not a busybox problem
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070801/31c34880/attachment-0002.pgp 

From strange at nsk.no-ip.org  Wed Aug  1 13:09:14 2007
From: strange at nsk.no-ip.org (Luciano Rocha)
Date: Wed, 1 Aug 2007 14:09:14 +0100
Subject: BusyBox poweroff problem with SMP kernel
In-Reply-To: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
References: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
Message-ID: <20070801130913.GA10643@bit.office.eurotux.com>

On Wed, Aug 01, 2007 at 11:08:28AM +0800, Zhiming Zhou wrote:
<snip>
> But while the system run in computer with multiple processors; system
> stopped while "Power down system" was printed, it seems out of busybox, and
> acpi_power_off is not called.
> 
> And if I compiled my linux kernel without CONFIG_SMP configed, and use the
> same busybox root file system, there was none poweroff problems in my
> system.
> 
> ------------------------------------------------------------------------------
> So, I want to know is there someone successfully use busybox to poweroff
> computer with SMP kernel? And what is the possible reason of my problem?

That's a kernel problem, not a busybox one.

If you're using APM, the kernel disables it at boot when it's running
with more than one processor. You can force it on, only for
powering-off, with the option apm=power-off to the kernel.

If you're using ACPI, then I don't know why it isn't powering down. It
could be because of an older BIOS, blacklisted when in SMP mode. But
then you can try activating apm like above.

-- 
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/20070801/1d013e64/attachment-0002.pgp 

From tefyxcegmkow at spammotel.com  Wed Aug  1 15:07:54 2007
From: tefyxcegmkow at spammotel.com (wimpunk)
Date: Wed, 01 Aug 2007 17:07:54 +0200
Subject: reboot/poweroff/halt commands not working
In-Reply-To: <1185560429.3596.3.camel@localhost>
References: <1185560429.3596.3.camel@localhost>
Message-ID: <47k6o4-c5c.ln1@l29.abba.lin.vlaanderen.be>

Dallas Clement wrote:
> I'm using 1.6.1 and none of these commands seem to work all by
> themselves.  If I provide the -f option, they all work just fine.  I'm
> not sure if this is a regression problem or it has always been this way.
> 
> I thought things were working properly in previous versions.  I'm pretty
> sure I did not have to supply the -f option.

I have the same problem with 1.5.* and 1.4.2.  It fails on ARM but it
works on i386.

wimpunk.



From tefyxcegmkow at spammotel.com  Wed Aug  1 15:13:28 2007
From: tefyxcegmkow at spammotel.com (wimpunk)
Date: Wed, 01 Aug 2007 17:13:28 +0200
Subject: BusyBox poweroff problem with SMP kernel
In-Reply-To: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
References: <a837b0ef0707312008x1ad5e07fn56acc2ca4d419466@mail.gmail.com>
Message-ID: <jhk6o4-j8c.ln1@l29.abba.lin.vlaanderen.be>

Zhiming Zhou wrote:
> I compiled a smp linux kernel to support multiple processors, and use 
> busybox 1.6.1 as root filesystem.
> The compiled linux system can be successfully started, and busybox ash 
> is started, while I typed "poweroff" in ash,
> 
> If the system run in computer with single processor; system stopped 
> while "Sending SIGTERM to all processes" was printed,
> and I found in busybox source directory/init/init.c, function 
> shutdown_system(void):
> 
> message(L_CONSOLE | L_LOG, "Sending SIG%s to all processes", "TERM");
> kill(-1, SIGTERM);
> 
> but kill function can not be proceeded, and system stopped.
> 
> But while the system run in computer with multiple processors; system 
> stopped while "Power down system" was printed, it seems out of busybox, 
> and acpi_power_off is not called.
> 
> And if I compiled my linux kernel without CONFIG_SMP configed, and use 
> the same busybox root file system, there was none poweroff problems in 
> my system.
> 
> ------------------------------------------------------------------------------ 
> 
> So, I want to know is there someone successfully use busybox to poweroff 
> computer with SMP kernel? And what is the possible reason of my problem?
> 
> Thanks
> 
> 


Referring to a previous post: try the -f option.  I'm just curious if
that one works...

wimpunk.



From vrashtchi at yahoo.com  Wed Aug  1 21:59:25 2007
From: vrashtchi at yahoo.com (vahid rashtchi)
Date: Wed, 1 Aug 2007 14:59:25 -0700 (PDT)
Subject: I/O difficulties
Message-ID: <867947.64675.qm@web53106.mail.re2.yahoo.com>

I am using KB9202b evaluation board for developing a real time control system project.  I am using c++ for programming and use buildroot compiler.I have difficulties  in input /output operation and configuring interupt routin under busybox.
  I can't perform I/O operation and see "permission  denied"  error. Does anyone have sample source code for these propose ?
   
  with best regard
  V.Rashtchi

       
---------------------------------
Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070801/20863f8c/attachment-0002.htm 

From vda.linux at googlemail.com  Wed Aug  1 22:49:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Wed, 1 Aug 2007 23:49:19 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <866511.5093.qm@web62501.mail.re1.yahoo.com>
References: <866511.5093.qm@web62501.mail.re1.yahoo.com>
Message-ID: <200708012349.19564.vda.linux@googlemail.com>

On Tuesday 24 July 2007 10:54, Alex Landau wrote:
> Hi,
> 
> The attached patch fixes a compilation error:
>    undefined reference to `_BUG_bb_daemonize_is_unavailable_on_nommu
> and makes start-stop-daemon usable on no-MMU by using bb_daemonize only if BB_MMU and
> emulating it if !BB_MMU.
> 
> This is a bit hackish, since after vfork(), the child does all the work and exec()s the
> daemon, rather than execing right away, as the vfork paradigma says. Still I think this
> is better than re-execing start-stop-daemon and only then execing the daemon itself since
> this approach requires removing the -b (or --background) arguments from the command line,
> which is not fun (what if there are several -b options? etc.),

For the record: no, you don't need that. You can just re-exec with entire
command line intact. -b option will be seen again, and re-exec will be
seemingly done again... but second re-exec will actually NOT be done
because of this:

void forkexit_or_rexec(char **argv)
{
        pid_t pid;
        /* Maybe we are already re-execed and come here again? */
        if (re_execed)     <===================
                return;    <===================

The magic is in re_execed variable. grep for it.

BTW does current svn work for you?
--
vda


From vda.linux at googlemail.com  Wed Aug  1 23:21:26 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 00:21:26 +0100
Subject: editors/patch.c is broken
In-Reply-To: <fcaeb9bf0707311230v1aaff203n60f67a9e3d958a1d@mail.gmail.com>
References: <fcaeb9bf0707311230v1aaff203n60f67a9e3d958a1d@mail.gmail.com>
Message-ID: <200708020021.26709.vda.linux@googlemail.com>

On Tuesday 31 July 2007 20:30, Nguyen Thai Ngoc Duy wrote:
> src/dest file names are read by xmalloc_fgets which include trailing
> \n characters. Therefore patch either reads from wrong source file or
> write to wrong destination file. The attached patch should fix it.
> I'm not sure about the rest of xmalloc_fgets used in patch, though.

Applied, thanks
--
vda


From dallas.a.clement at gmail.com  Thu Aug  2 02:35:52 2007
From: dallas.a.clement at gmail.com (Dallas Clement)
Date: Wed, 1 Aug 2007 21:35:52 -0500
Subject: reboot/poweroff/halt commands not working
In-Reply-To: <47k6o4-c5c.ln1@l29.abba.lin.vlaanderen.be>
References: <1185560429.3596.3.camel@localhost>
	<47k6o4-c5c.ln1@l29.abba.lin.vlaanderen.be>
Message-ID: <46b1430a.38f8220a.3e1b.721a@mx.google.com>

It's failing on a i686 for me.  Version 1.6.1.  Haven't retried 1.6.0, but
as far as I recall it was working in that version.

> -----Original Message-----
> From: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net]
> On Behalf Of wimpunk
> Sent: Wednesday, August 01, 2007 10:08 AM
> To: busybox at busybox.net
> Subject: Re: reboot/poweroff/halt commands not working
> 
> Dallas Clement wrote:
> > I'm using 1.6.1 and none of these commands seem to work all by
> > themselves.  If I provide the -f option, they all work just fine.
> I'm
> > not sure if this is a regression problem or it has always been this
> way.
> >
> > I thought things were working properly in previous versions.  I'm
> pretty
> > sure I did not have to supply the -f option.
> 
> I have the same problem with 1.5.* and 1.4.2.  It fails on ARM but it
> works on i386.
> 
> wimpunk.
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox



From vapier at gentoo.org  Thu Aug  2 04:18:04 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 2 Aug 2007 00:18:04 -0400
Subject: I/O difficulties
In-Reply-To: <867947.64675.qm@web53106.mail.re2.yahoo.com>
References: <867947.64675.qm@web53106.mail.re2.yahoo.com>
Message-ID: <200708020018.05315.vapier@gentoo.org>

On Wednesday 01 August 2007, vahid rashtchi wrote:
> I am using KB9202b evaluation board for developing a real time control
> system project.  I am using c++ for programming and use buildroot
> compiler.I have difficulties  in input /output operation and configuring
> interupt routin under busybox. I can't perform I/O operation and see
> "permission  denied"  error. Does anyone have sample source code for these
> propose ?

this question isnt appropriate for the busybox lists.  please try a generic 
embedded forum (like ucdot.org) or the kernel mailing list for whatever 
architecture you're developing for.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070802/1b8111b2/attachment-0002.pgp 

From natanael.copa at gmail.com  Thu Aug  2 04:42:46 2007
From: natanael.copa at gmail.com (Natanael copa)
Date: Thu, 02 Aug 2007 06:42:46 +0200
Subject: [PATCH] sendmail/ssmtp applet
Message-ID: <1186029766.14577.2.camel@nat-desktop>

Hi,

Here is a crude sendmail applet based on ssmtp:
http://dev.alpinelinux.org/~ncopa/busybox-initial-sendmail.patch

(It is bigger than 40k so I was not allowed to post it on the mailing list)

It is an initial version but I post it anyway so experienced busybox'ers
can give hits and give the opportunity for volunteers (with more time
than me) to continue work on it.

Some issues I saw while preparing it:
* fix Copyright
* fix include files
* we will probably never want ssl support so that part can simply be
cutted
* argument parsing could use getopt32
* unused options could be cutted. Maybe have an config option for
sendmail compatibility.
* bool_t should be bool
* many of the global bool vars can be compressed into a "flags" variable
where every bool represent a bit.
* base64 code can probably be reuse from previous busybox code.
* md5 auth?
* logging could be handled with something from libbb?

I'm sure there are more things. The size is not too bad anyway and it
can only become smaller from here :-)

I do intend to fix those things (if there are enough interest) but by
posting it here early i give interested ppl a chance to give a hand.


function                                             old     new   delta
ssmtp                                                  -    2962   +2962
sendmail_main                                          -    1160   +1160
die                                                    -     565    +565
header_parse                                           -     545    +545
smtp_write                                             -     352    +352
rcpt_parse                                             -     334    +334
smtp_open                                              -     240    +240
log_event                                              -     223    +223
to64frombits                                           -     222    +222
TimeoutJmpBuf                                          -     200    +200
smtp_read                                              -     183    +183
paq                                                    -     161    +161
append_domain                                          -     152    +152
addr_parse                                             -     141    +141
packed_usage                                         318     446    +128
standardise                                            -      90     +90
rcpt_remap                                             -      84     +84
base64digits                                           -      65     +65
hostname                                               -      64     +64
strip_post_ws                                          -      37     +37
strip_pre_ws                                           -      32     +32
arpadate                                               -      32     +32
smtp_okay                                              -      20     +20
handler                                                -      19     +19
rcpt_list                                              -      16     +16
headers                                                -      16     +16
applets                                               48      64     +16
uad                                                    -       8      +8
static.stdin@@GLIBC_2                                  -       8      +8
rt                                                     -       8      +8
root                                                   -       8      +8
minus_f                                                -       8      +8
minus_F                                                -       8      +8
mailhost                                               -       8      +8
ht                                                     -       8      +8
gecos                                                  -       8      +8
from                                                   -       8      +8
auth_user                                              -       8      +8
auth_pass                                              -       8      +8
auth_method                                            -       8      +8
static.Version                                         -       7      +7
use_starttls                                           -       4      +4
port                                                   -       4      +4
override_from                                          -       4      +4
minus_v                                                -       4      +4
minus_t                                                -       4      +4
log_level                                              -       4      +4
have_from                                              -       4      +4
have_date                                              -       4      +4
------------------------------------------------------------------------------
(add/remove: 47/0 grow/shrink: 2/0 up/down: 8202/0)          Total: 8202
bytes
   text    data     bss     dec     hex filename
  14827     816    8280   23923    5d73 busybox_old
  27764    1155    8728   37647    930f busybox_unstripped



Natanael Copa



From landau_alex at yahoo.com  Thu Aug  2 06:26:58 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Wed, 1 Aug 2007 23:26:58 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0707311000w6a977564ncfd8c2f23e666594@mail.gmail.com>
Message-ID: <899460.68656.qm@web62503.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> Applied with some other minor changes added, please check svn
> and yell if you see something bad.
> 
> vda
> 

Yelling! I found several problems, the attached patch fixes them.

1. pid_is_exec(): you changed the return to (~n) from something akin to (!n). This works
fine if n==0, but then n!=0, the returned value is also non-zero, and it breaks the
calling code.
2. When vfork()ing, the parent should exit(0) and not return(0), since the child has run
quite some time and may have changed the return address in stack. So, no returns in the
parent, only function calls. Added a comment about that. Better safe than sorry.
3. After vfork(), the check of (pid==0) to see if I'm the parent is wrong. It should be
(pid!=0).
4. Added a setsid() call just before daemonize_or_rexec.

Alex


      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: start-stop-daemon-round2.patch
Type: text/x-patch
Size: 979 bytes
Desc: 660604078-start-stop-daemon-round2.patch
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070801/0c02bdcd/attachment-0002.bin 

From vapier at gentoo.org  Thu Aug  2 06:45:08 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 2 Aug 2007 02:45:08 -0400
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <899460.68656.qm@web62503.mail.re1.yahoo.com>
References: <899460.68656.qm@web62503.mail.re1.yahoo.com>
Message-ID: <200708020245.10367.vapier@gentoo.org>

On Thursday 02 August 2007, Alex Landau wrote:
> +???????????????if (pid != 0) /* parent */
> +???????????????????????exit(0); /* the child may have changed the stack,
> so no return possible, only function calls */ /* child */

i havent read the code, but gut feeling says that should be _exit(0) ... or do 
i need to read the code ? :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070802/9403e96b/attachment-0002.pgp 

From landau_alex at yahoo.com  Thu Aug  2 07:48:10 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 00:48:10 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <200708020245.10367.vapier@gentoo.org>
Message-ID: <868676.99832.qm@web62505.mail.re1.yahoo.com>


--- Mike Frysinger <vapier at gentoo.org> wrote:

> On Thursday 02 August 2007, Alex Landau wrote:
> > +               if (pid != 0) /* parent */
> > +                       exit(0); /* the child may have changed the stack,
> > so no return possible, only function calls */ /* child */
> 
> i havent read the code, but gut feeling says that should be _exit(0) ... or do 
> i need to read the code ? :)
> -mike
> 

You do need to read the code :-)
It's the parent who runs exit(), not the child, so it should be exit() and not _exit().
The child merely execv()s.

Alex


       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 


From Devinim.SOLEN at motiontrue.com  Thu Aug  2 08:25:14 2007
From: Devinim.SOLEN at motiontrue.com (=?iso-8859-9?Q?Devinim_=DE=D6LEN?=)
Date: Thu, 2 Aug 2007 11:25:14 +0300
Subject: NFS Support
Message-ID: <7D23D3548EC1874CBA41E02F76963A614B36EB8B30@MTEX01.motiontrue.entp>

Hi;

I am using BusyBox version 1.6.1 and have a NFS mounting problem.  When I try to mount NFS external point getting this error;

mount -t nfs 192.168.10.64:/ /mnt
mount: mounting 192.168.10.64:/ on /mnt failed

can anybody help ?

Best Regards

Devinim SOLEN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070802/6ba1bf43/attachment-0002.htm 

From vda.linux at googlemail.com  Thu Aug  2 10:03:31 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 11:03:31 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <868676.99832.qm@web62505.mail.re1.yahoo.com>
References: <200708020245.10367.vapier@gentoo.org>
	<868676.99832.qm@web62505.mail.re1.yahoo.com>
Message-ID: <1158166a0708020303k3c00b435qd72a8c3e00d0b9a0@mail.gmail.com>

On 8/2/07, Alex Landau <landau_alex at yahoo.com> wrote:
> --- Mike Frysinger <vapier at gentoo.org> wrote:
>
> > On Thursday 02 August 2007, Alex Landau wrote:
> > > +               if (pid != 0) /* parent */
> > > +                       exit(0); /* the child may have changed the stack,
> > > so no return possible, only function calls */ /* child */
> >
> > i havent read the code, but gut feeling says that should be _exit(0) ... or do
> > i need to read the code ? :)
> > -mike

Thanks for testing Alex, I am applying the patch.
I am also reusing write_pidfile() from libbb here:

        if (opt & OPT_MAKEPID) {
                /* user wants _us_ to make the pidfile */
                write_pidfile(pidfile);
        }

In the process I (hopefully) fixed that nasty
"ifupdown + udhcpc_without_pidpile_creation" fsckup...

> You do need to read the code :-)
> It's the parent who runs exit(), not the child, so it should be exit() and not _exit().

Mike is implying that _exit() is mucking around much less that exit()
and for paranoid
reasons we are better off using it. So I changed exit to _exit in that spot.
We don't even need to fflush() before that, we did no output yet.

> The child merely execv()s.

So on NOMMU execv() basically creates another process in another
memory region, and
terminates current one, unless there is a parent sitting in vfork and waiting
(in which case parent is woken up instead of exit)?
--
vda


From strange at nsk.no-ip.org  Thu Aug  2 10:13:18 2007
From: strange at nsk.no-ip.org (Luciano Rocha)
Date: Thu, 2 Aug 2007 11:13:18 +0100
Subject: I/O difficulties
In-Reply-To: <867947.64675.qm@web53106.mail.re2.yahoo.com>
References: <867947.64675.qm@web53106.mail.re2.yahoo.com>
Message-ID: <20070802101318.GB28023@bit.office.eurotux.com>

On Wed, Aug 01, 2007 at 02:59:25PM -0700, vahid rashtchi wrote:
> I am using KB9202b evaluation board for developing a real time control system project.  I am using c++ for programming and use buildroot compiler.I have difficulties  in input /output operation and configuring interupt routin under busybox.
>   I can't perform I/O operation and see "permission  denied"  error. Does anyone have sample source code for these propose ?

For the low-level I/O instructions (inb, inw, outb, outw, ...), you need
to explicitly enable them with ioperm or iopl. See their manual pages.

However, you can't change the interrupt routing table. You need to
develop a kernel driver instead. See the book Linux Device Drivers:
http://lwn.net/Kernel/LDD3/

(also http://www.kroah.com/log/linux/ddk.html)

-- 
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/20070802/39b54895/attachment-0002.pgp 

From landau_alex at yahoo.com  Thu Aug  2 10:32:10 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 03:32:10 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0708020303k3c00b435qd72a8c3e00d0b9a0@mail.gmail.com>
Message-ID: <810692.43452.qm@web62509.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> On 8/2/07, Alex Landau <landau_alex at yahoo.com> wrote:
> > --- Mike Frysinger <vapier at gentoo.org> wrote:
> >
> > > On Thursday 02 August 2007, Alex Landau wrote:
> > > > +               if (pid != 0) /* parent */
> > > > +                       exit(0); /* the child may have changed the stack,
> > > > so no return possible, only function calls */ /* child */
> > >
> > > i havent read the code, but gut feeling says that should be _exit(0) ... or do
> > > i need to read the code ? :)
> > > -mike
> 
> Thanks for testing Alex, I am applying the patch.
> I am also reusing write_pidfile() from libbb here:
> 
>         if (opt & OPT_MAKEPID) {
>                 /* user wants _us_ to make the pidfile */
>                 write_pidfile(pidfile);
>         }
> 
> In the process I (hopefully) fixed that nasty
> "ifupdown + udhcpc_without_pidpile_creation" fsckup...
> 

Tested, working.

> > You do need to read the code :-)
> > It's the parent who runs exit(), not the child, so it should be exit() and not
> _exit().
> 
> Mike is implying that _exit() is mucking around much less that exit()
> and for paranoid
> reasons we are better off using it. So I changed exit to _exit in that spot.
> We don't even need to fflush() before that, we did no output yet.

I'm still not sure _exit is better in this case, but I'm not 100% sure it's wrong too...
Anyway it's currently working.

> 
> > The child merely execv()s.
> 
> So on NOMMU execv() basically creates another process in another
> memory region, and
> terminates current one, unless there is a parent sitting in vfork and waiting
> (in which case parent is woken up instead of exit)?

No, execve works exactly it does on an MMU system. It loads a new executable into the
current process. The difference is with vfork: on vfork, the parent is suspended, and the
child shares it's whole address space with the parent (the stack is shared too - that's
why this is so tricky!). The parent is resumed when the child either execve()s or
_exit()s.

> --
> vda
> 

Alex


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 


From vda.linux at googlemail.com  Thu Aug  2 10:36:46 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 11:36:46 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <810692.43452.qm@web62509.mail.re1.yahoo.com>
References: <1158166a0708020303k3c00b435qd72a8c3e00d0b9a0@mail.gmail.com>
	<810692.43452.qm@web62509.mail.re1.yahoo.com>
Message-ID: <1158166a0708020336r261e714hc3d3d443c8fdb30@mail.gmail.com>

> > > The child merely execv()s.
> >
> > So on NOMMU execv() basically creates another process in another
> > memory region, and
> > terminates current one, unless there is a parent sitting in vfork and waiting
> > (in which case parent is woken up instead of exit)?
>
> No, execve works exactly it does on an MMU system. It loads a new executable into the
> current process.

...trashing all memory area occupied by the process? how parent is
able to run then?

> The difference is with vfork: on vfork, the parent is suspended, and the
> child shares it's whole address space with the parent (the stack is shared too - that's
> why this is so tricky!). The parent is resumed when the child either execve()s or
> _exit()s.

I don't understand how parent is able to run if execve just nuked
parent's text segment
with unrelated code of execed program.
--
vda


From landau_alex at yahoo.com  Thu Aug  2 11:02:18 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 04:02:18 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0708020336r261e714hc3d3d443c8fdb30@mail.gmail.com>
Message-ID: <867356.54135.qm@web62509.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> > > > The child merely execv()s.
> > >
> > > So on NOMMU execv() basically creates another process in another
> > > memory region, and
> > > terminates current one, unless there is a parent sitting in vfork and waiting
> > > (in which case parent is woken up instead of exit)?
> >
> > No, execve works exactly it does on an MMU system. It loads a new executable into the
> > current process.
> 
> ...trashing all memory area occupied by the process? how parent is
> able to run then?

And what about the normal fork and execve? With fork, the text vmas are shared too, and,
I guess, on execve they are unshared. Not sure, but I guess the same happens here. Well,
not the same, since there is a difference between a shared vma and a shared
address_space, but it's the same idea.
Anyway, that's my understanding.

Alx

> 
> > The difference is with vfork: on vfork, the parent is suspended, and the
> > child shares it's whole address space with the parent (the stack is shared too -
> that's
> > why this is so tricky!). The parent is resumed when the child either execve()s or
> > _exit()s.
> 
> I don't understand how parent is able to run if execve just nuked
> parent's text segment
> with unrelated code of execed program.
> --
> vda
> 



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  


From landau_alex at yahoo.com  Thu Aug  2 11:37:21 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 04:37:21 -0700 (PDT)
Subject: [PATCH] Fix udhcpc on no-MMU
Message-ID: <798831.68564.qm@web62515.mail.re1.yahoo.com>

Hi,
Now it's udhcpc's turn. Actually a tiny patch that only changes the #ifdef which decides
whether we have an MMU or not.
Alex

Index: networking/udhcp/dhcpc.c
===================================================================
--- networking/udhcp/dhcpc.c	(revision 19396)
+++ networking/udhcp/dhcpc.c	(working copy)
@@ -109,7 +109,7 @@
 
 static void client_background(void)
 {
-#ifdef __uClinux__
+#if !BB_MMU
 	bb_error_msg("cannot background in uclinux (yet)");
 /* ... mainly because udhcpc calls client_background()
  * in _the _middle _of _udhcpc _run_, not at the start!



       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433


From landau_alex at yahoo.com  Thu Aug  2 12:08:09 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 05:08:09 -0700 (PDT)
Subject: msh and functions
Message-ID: <320731.69074.qm@web62514.mail.re1.yahoo.com>

Hi,

The Blackfin uClinux distribution at blackfin.uclinux.org includes a patch to busybox's
msh that adds support for functions. It's a bit outdated (the last time I checked), but I
integrated it into busybox 1.4.1 and it works (for me) fine. msh hasn't changed
considerably since then, so I think with small effort the patch could be integrated into
trunk.
I'm willing to volunteer to do that, but I'm having some concerns mainly do to the fact
that I'm not the author of the original patch.
The patch does not contain copyright information, but a readme is included with it
saying:
--START--
                README for hacked msh

                Mickael.Kang (blackfin.kang at gmail.com)

                        Dec. 13th 2005

This patch is for enhancement of msh.  After apply this patch, msh can support
function recursive call.  So it is more like bash than before.  Many
applications under uClinux maybe need this patch to run some bash script under
msh, such as oprofile.
--END--

What can you say about that? Can someone from blackfin.uclinux.org (Mike?) check the
issue and integrate the patch / approve the integration by someone else (e.g. me) /
reject it?

Thanks,
Alex


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 


From landau_alex at yahoo.com  Thu Aug  2 13:54:38 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Thu, 2 Aug 2007 06:54:38 -0700 (PDT)
Subject: [PATCH] Add Blackfin to scripts/checkstack.pl
Message-ID: <342715.31112.qm@web62502.mail.re1.yahoo.com>

Hi,
The patch below adds support for Blackfin to scripts/checkstack.pl.
Please apply, if it seems appropriate.
Alex

Index: scripts/checkstack.pl
===================================================================
--- scripts/checkstack.pl	(revision 19396)
+++ scripts/checkstack.pl	(working copy)
@@ -39,6 +39,9 @@
 	if ($arch eq 'arm') {
 		#c0008ffc:	e24dd064	sub	sp, sp, #100	; 0x64
 		$re = qr/.*sub.*sp, sp, #(([0-9]{2}|[3-9])[0-9]{2})/o;
+	} elsif ($arch eq 'blackfin') {
+		#      52:       00 e8 03 00     LINK 0xc;
+		$re = qr/.*LINK (0x$x{1,5});$/o;
 	} elsif ($arch =~ /^i[3456]86$/) {
 		#c0105234:       81 ec ac 05 00 00       sub    $0x5ac,%esp
 		$re = qr/^.*[as][du][db]    \$(0x$x{1,8}),\%esp$/o;



       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC


From vda.linux at googlemail.com  Thu Aug  2 17:52:46 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 18:52:46 +0100
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <867356.54135.qm@web62509.mail.re1.yahoo.com>
References: <1158166a0708020336r261e714hc3d3d443c8fdb30@mail.gmail.com>
	<867356.54135.qm@web62509.mail.re1.yahoo.com>
Message-ID: <1158166a0708021052o1a6123f7j5d1dbdb3c7f7a56f@mail.gmail.com>

On 8/2/07, Alex Landau <landau_alex at yahoo.com> wrote:
> > > > > The child merely execv()s.
> > > >
> > > > So on NOMMU execv() basically creates another process in another
> > > > memory region, and
> > > > terminates current one, unless there is a parent sitting in vfork and waiting
> > > > (in which case parent is woken up instead of exit)?
> > >
> > > No, execve works exactly it does on an MMU system. It loads a new executable into the
> > > current process.
> >
> > ...trashing all memory area occupied by the process? how parent is
> > able to run then?
>
> And what about the normal fork and execve?

That's MMU, and there it's all crystal clear.

I was specifically thinking how our trick is working on _NOMMU_.
Mostly for self-education. So, after execve on NOMMU old process
is not destroyed, but "returned" to parent-after-vfork, and
while parent does something, new process is already has memory
allocated for it?

OIW: at execve, does kernel do something like this?

 if (vfork_was_done) {
    create_and_start_new_process();
    wake_up_parent_in_vfork();
 } else {
    destroy_current_process();
    create_and_start_new_process();
 }


--
vda


From Gary.Leong at nasdaq.com  Thu Aug  2 20:26:02 2007
From: Gary.Leong at nasdaq.com (Leong, Gary)
Date: Thu, 2 Aug 2007 16:26:02 -0400
Subject: pivot_root, switch_root, initramfs and kexec
Message-ID: <FD98A53269F5F74082DFBB12E8AA603208D1E34C@TRM-EXCH1.CORP.NASDAQ.COM>

I have an unsual situation.

 

 

The first OS, a busybox OS, boots up through PXE.  This first OS has
"kexec" which is used to boot up a second OS.  The second OS (also a
busybox OS) boots up find as long as the system is diskless.  However,
when I try to do a switch_root onto the disk (which contains the second
OS binaries), it craps out saying, "switch_root: not rootfs."
But....when I replaced the switch_root with pivot_root style, it works
fine.

 

So I figure switch_root is checking to see process kicking it off is PID
1, and craps out if it isn't.  And pivot_root doesn't check as
thoroughly, or doesn't care if the process kicking it off is  PID 1?
How do I find out f the process kicking off is PID 1?

 

To make it more interesting.  I'm using initramfs, not initrd style, but
using pivot_root that is suppose to be used only for initrd style.  So
another questions, is there really any harm using pivot_root with
initramfs?  It works. Or is pivot_root now able to be used with
initramfs. 

 

Thanks in advance!

 

Gary

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070802/2ffd7a50/attachment-0002.htm 

From vda.linux at googlemail.com  Thu Aug  2 22:48:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 2 Aug 2007 23:48:19 +0100
Subject: [PATCH] Fix udhcpc on no-MMU
In-Reply-To: <798831.68564.qm@web62515.mail.re1.yahoo.com>
References: <798831.68564.qm@web62515.mail.re1.yahoo.com>
Message-ID: <200708022348.19496.vda.linux@googlemail.com>

On Thursday 02 August 2007 12:37, Alex Landau wrote:
> Hi,
> Now it's udhcpc's turn. Actually a tiny patch that only changes the #ifdef which decides
> whether we have an MMU or not.
> Alex
> 
> Index: networking/udhcp/dhcpc.c
> ===================================================================
> --- networking/udhcp/dhcpc.c	(revision 19396)
> +++ networking/udhcp/dhcpc.c	(working copy)
> @@ -109,7 +109,7 @@
>  
>  static void client_background(void)
>  {
> -#ifdef __uClinux__
> +#if !BB_MMU
>  	bb_error_msg("cannot background in uclinux (yet)");
>  /* ... mainly because udhcpc calls client_background()
>   * in _the _middle _of _udhcpc _run_, not at the start!

Applied, thanks.

udhcp still needs more love. For one, the plan is to make
udhcpc NOMMU-friendly someday.
--
vda


From ynakam at hitachisoft.jp  Fri Aug  3 00:15:35 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 03 Aug 2007 09:15:35 +0900
Subject: [patch] setfiles update
Message-ID: <20070803091304.54C4.YNAKAM@hitachisoft.jp>

Hi.

This is a patch for setfiles applet.
Following is change.
* Bug fix: -f option did not work.
* Using bb_simplify_path to remove extra slash for smaller code.

Regards,
-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
SELinux Policy Editor: http://seedit.sourceforge.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setfiles_update.patch
Type: application/octet-stream
Size: 1511 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070803/ab1b900d/attachment-0002.obj 

From vda.linux at googlemail.com  Fri Aug  3 08:31:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 3 Aug 2007 09:31:33 +0100
Subject: NFS Support
In-Reply-To: <7D23D3548EC1874CBA41E02F76963A614B36EB8B30@MTEX01.motiontrue.entp>
References: <7D23D3548EC1874CBA41E02F76963A614B36EB8B30@MTEX01.motiontrue.entp>
Message-ID: <200708030931.33706.vda.linux@googlemail.com>

On Thursday 02 August 2007 09:25, Devinim ??LEN wrote:
> Hi;
> 
> I am using BusyBox version 1.6.1 and have a NFS mounting problem.  When I try to mount NFS external point getting this error;
> 
> mount -t nfs 192.168.10.64:/ /mnt
> mount: mounting 192.168.10.64:/ on /mnt failed
> 
> can anybody help ?

* Please find the following line in mount.c:
  bb_error_msg("mounting %s on %s failed", mp->mnt_fsname, mp->mnt_dir);
  and replace "_error_" with "_perror_". What does it print now?

* Do "strace -o mnt.log mount -t nfs 192.168.10.64:/ /mnt" and post log

* Do "tcpdump -nl -iethN -s0 -vvv host 192.168.10.64 and host <NFS client IP>"
  and post log here (bzip2 it if it's big)
--
vda


From ynakam at hitachisoft.jp  Thu Aug  2 23:58:52 2007
From: ynakam at hitachisoft.jp (Yuichi Nakamura)
Date: Fri, 03 Aug 2007 08:58:52 +0900
Subject: [patch]setfiles/restorecon applet
In-Reply-To: <200707251807.58814.farmatito@tiscali.it>
References: <20070724085858.41D8.YNAKAM@hitachisoft.jp>
	<200707251807.58814.farmatito@tiscali.it>
Message-ID: <20070803084348.54BD.YNAKAM@hitachisoft.jp>

Hi.

Sorry for late reply.

On Wed, 25 Jul 2007 18:07:58 +0200
Tito  wrote:
> On Tuesday 24 July 2007 02:08:24 Yuichi Nakamura wrote:
> > Hi.
> > 
> 
> snip
> 
> > 
> > About sanitize_path, it is pending.
> > Removing extra slashes is done only there in setfiles.c .
> > Is removing extra slashes done in other applets?
> 
> Yes in devfsd, removing extra slashes at the end of filename:
> 
> in one earlier revision there was:
> 
>  /* strip last / from mount point, so we don't need to check for it later */
>          while (argv[1][1] != '\0' && argv[1][strlen(argv[1]) - 1] == '/') 	 
>                  argv[1][strlen(argv[1]) - 1] = '\0';
> 
> later it changed to
> 
>          mount_point = bb_simplify_path(argv[1]);
> 
> so far nobody complained.....
I looked at setfiles.c again,
and I found I can use bb_simplify_path, then code gets smaller.
I will use bb_simplify_path.
I will send patch soon.


> > If so, should it be in libbb?
> 
> Could be useful......
> just my 0,02 ?
> 
> Ciao,
> Tito
> > I've found bb_simplify_path, but it is expanding "." .
> > 
> > > >
> > > > [snipping the rest of you patch for now]
> > > > HTH,
> > > --
> > > vda
> > 
> > Attached is update.
> 

Regards,
-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
SELinux Policy Editor: http://seedit.sourceforge.net/



From landau_alex at yahoo.com  Fri Aug  3 09:14:45 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Fri, 3 Aug 2007 02:14:45 -0700 (PDT)
Subject: [PATCH] Fix start-stop-daemon on no-MMU
In-Reply-To: <1158166a0708021052o1a6123f7j5d1dbdb3c7f7a56f@mail.gmail.com>
Message-ID: <879819.8242.qm@web62513.mail.re1.yahoo.com>


--- Denis Vlasenko <vda.linux at googlemail.com> wrote:

> I was specifically thinking how our trick is working on _NOMMU_.
> Mostly for self-education. So, after execve on NOMMU old process
> is not destroyed, but "returned" to parent-after-vfork, and
> while parent does something, new process is already has memory
> allocated for it?
> 
> OIW: at execve, does kernel do something like this?
> 
>  if (vfork_was_done) {
>     create_and_start_new_process();
>     wake_up_parent_in_vfork();
>  } else {
>     destroy_current_process();
>     create_and_start_new_process();
>  }
> 
> 
> --
> vda
> 

No, vfork creates a new process (just like fork). I mean it creates a new struct
task_struct, copies the kernel stack, and so on. So the child is an entirely new process
with its own PID. What it does not copy is the mm_struct, but instead the child's one
points to the parent's one. So now the parent and child are different processes sharing
the same address space (due to CLONE_VM).
vfork on Blackfin calls do_fork() with flags CLONE_VFORK | CLONE_VM | SIGCHLD, see
kernel/fork.c for do_fork().
Inside do_fork(), if CLONE_VFORK is set, the parent waits on a completion variable until
the child signals it, which happens on execve() and on exit().

On execve(), the child detaches from the parent mm_struct (flush_old_exec() which calls
exec_mmap(), and itself called from the binary handler, e.g. load_flat_file() in
fs/binfmt_flat.c for FLAT), and sets the child's mm to point to a newly allocated
mm_struct (do_execve() does the allocation).
mm_release() called from exec_mmap() (on execve) and from exit_mm() (called itself from
do_exit()) checks whether the parent wait for a vfork completion, and if yes, signals it.

I hope that helps.
Regards,
Alex


      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 


From kalyanatejaswi at yahoo.co.in  Fri Aug  3 16:44:33 2007
From: kalyanatejaswi at yahoo.co.in (kalyanatejaswi balabhadrapatruni)
Date: Fri, 3 Aug 2007 17:44:33 +0100 (BST)
Subject: bug in coreutils/printenv.c
Message-ID: <6823.69286.qm@web8605.mail.in.yahoo.com>

Hi all,
"printenv" command prints argv[1] and exits, doesnt
run through rest of the elements of argv[].
---------------
Example:
#busybox printenv SHELL PWD
/bin/sh
#
Doesnt print PWD
----------------

No great deal, small patch attached.

regards
kalyan


      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: printenv-patch.txt
Url: http://lists.busybox.net/pipermail/busybox/attachments/20070803/690f37b4/attachment-0002.txt 

From pclouds at gmail.com  Fri Aug  3 21:58:12 2007
From: pclouds at gmail.com (Nguyen Thai Ngoc Duy)
Date: Fri, 3 Aug 2007 17:58:12 -0400
Subject: [PATCH] patch: extract_filename should strip all dirs if patch_level
	is -1
Message-ID: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>

It is also documented in the comment above the function but not implemented
-- 
Duy


From pclouds at gmail.com  Sat Aug  4 00:45:32 2007
From: pclouds at gmail.com (Nguyen Thai Ngoc Duy)
Date: Fri, 3 Aug 2007 20:45:32 -0400
Subject: [PATCH] sed: save the last regex for use later
Message-ID: <fcaeb9bf0708031745u59d7d2b0gb3086a83b6550bcc@mail.gmail.com>

I'm not really get into sed source code, so I might be wrong. Please recheck it.
With this patch, the following command should return 'abc' (GNU sed
does but busybox did not):
echo 'URL: abc'|busybox sed -ne '/^URL: */{ s///p; q }'
-- 
Duy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-sed-save-the-last-regex-for-use-later-with-s.patch
Type: text/x-patch
Size: 1116 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070803/0feb4696/attachment-0002.bin 

From cristian.ionescu-idbohrn at axis.com  Sat Aug  4 11:07:23 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sat, 4 Aug 2007 13:07:23 +0200 (CEST)
Subject: just a few more compilation warnings
Message-ID: <0708041302530.10759@somehost>

Please find attached a sorted list of "declared with attribute
warn_unused_result" warnings.


Cheers,

-- 
Cristian
-------------- next part --------------
init/init.c:923:				warning: ignoring return value of 'chdir',	declared with attribute warn_unused_result
procps/fuser.c:278:				warning: ignoring return value of 'chdir',	declared with attribute warn_unused_result
archival/rpm.c:366:				warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
loginutils/getty.c:329:				warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
miscutils/crontab.c:169:			warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
util-linux/mdev.c:185:				warning: ignoring return value of 'chown',	declared with attribute warn_unused_result
loginutils/sulogin.c:63:			warning: ignoring return value of 'dup',	declared with attribute warn_unused_result
loginutils/sulogin.c:65:			warning: ignoring return value of 'dup',	declared with attribute warn_unused_result
sysklogd/syslogd.c:538:				warning: ignoring return value of 'fchdir',	declared with attribute warn_unused_result
libbb/update_passwd.c:56:			warning: ignoring return value of 'fchown',	declared with attribute warn_unused_result
loginutils/login.c:346:				warning: ignoring return value of 'fchown',	declared with attribute warn_unused_result
coreutils/comm.c:101:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
coreutils/comm.c:103:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
coreutils/comm.c:55:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
coreutils/comm.c:95:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
editors/ed.c:244:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/arp.c:381:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/interface.c:567:			warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/interface.c:568:			warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/libiproute/iptunnel.c:447:		warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/libiproute/iptunnel.c:448:		warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
networking/wget.c:447:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
procps/top.c:265:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
util-linux/fbset.c:183:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
util-linux/fbset.c:195:				warning: ignoring return value of 'fgets',	declared with attribute warn_unused_result
modutils/lsmod.c:32:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:267:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:283:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:292:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
procps/top.c:293:				warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
util-linux/mkfs_minix.c:528:			warning: ignoring return value of 'fscanf',	declared with attribute warn_unused_result
sysklogd/syslogd.c:378:				warning: ignoring return value of 'ftruncate',	declared with attribute warn_unused_result
coreutils/fold.c:117:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/fold.c:135:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/fold.c:144:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/fold.c:94:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/tee.c:68:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
debianutils/pipe_progress.c:30:			warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
runit/svlogd.c:899:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
runit/svlogd.c:927:				warning: ignoring return value of 'fwrite',	declared with attribute warn_unused_result
coreutils/test.c:574:				warning: ignoring return value of 'getgroups',	declared with attribute warn_unused_result
archival/libunarchive/data_extract_all.c:115:	warning: ignoring return value of 'lchown',	declared with attribute warn_unused_result
miscutils/less.c:745:				warning: ignoring return value of 'read',	declared with attribute warn_unused_result
modutils/insmod.c:3673:				warning: ignoring return value of 'read',	declared with attribute warn_unused_result
networking/inetd.c:1597:			warning: ignoring return value of 'read',	declared with attribute warn_unused_result
debianutils/start_stop_daemon.c:45:		warning: ignoring return value of 'readlink',	declared with attribute warn_unused_result
util-linux/umount.c:96:				warning: ignoring return value of 'realpath',	declared with attribute warn_unused_result
console-tools/resize.c:54:			warning: ignoring return value of 'scanf',	declared with attribute warn_unused_result
util-linux/mdev.c:183:				warning: ignoring return value of 'symlink',	declared with attribute warn_unused_result
loginutils/adduser.c:76:			warning: ignoring return value of 'system',	declared with attribute warn_unused_result
networking/udhcp/files.c:410:			warning: ignoring return value of 'system',	declared with attribute warn_unused_result
procps/watch.c:76:				warning: ignoring return value of 'system',	declared with attribute warn_unused_result
console-tools/dumpkmap.c:37:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
console-tools/dumpkmap.c:46:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
console-tools/dumpkmap.c:59:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
editors/ed.c:979:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
ipsvd/tcpudp.c:314:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:549:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:557:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:569:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:795:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
loginutils/getty.c:848:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/crontab.c:279:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/crontab.c:281:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:105:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:211:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:232:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:239:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/rx.c:81:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/watchdog.c:19:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
miscutils/watchdog.c:53:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
modutils/insmod.c:3677:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/inetd.c:1719:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/inetd.c:1758:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:117:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:148:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:195:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:269:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:430:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:656:			warning: ignoring return value of 'write',	declared with attribute warn_unused_result
networking/telnet.c:98:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
procps/sysctl.c:53:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:104:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:149:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:189:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsv.c:98:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
runit/runsvdir.c:300:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
util-linux/dmesg.c:45:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
util-linux/mdev.c:278:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result
util-linux/mdev.c:280:				warning: ignoring return value of 'write',	declared with attribute warn_unused_result

From cristian.ionescu-idbohrn at axis.com  Sat Aug  4 11:43:45 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sat, 4 Aug 2007 13:43:45 +0200 (CEST)
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
Message-ID: <0708041341350.10759@somehost>

...which is the latest distributed.

  CC      miscutils/readahead.o
miscutils/readahead.c: In function `readahead_main':
miscutils/readahead.c:27: warning: implicit declaration of function `readahead'


  CC      miscutils/taskset.o
miscutils/taskset.c:17: error: syntax error before '*' token
miscutils/taskset.c:18: warning: function declaration isn't a prototype
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.)
miscutils/taskset.c:26: warning: implicit declaration of function `CPU_ISSET'
miscutils/taskset.c:26: error: `mask' undeclared (first use in this function)
miscutils/taskset.c: In function `taskset_main':
miscutils/taskset.c:47: error: `cpu_set_t' undeclared (first use in this function)
miscutils/taskset.c:47: error: syntax error before "mask"
miscutils/taskset.c:68: warning: implicit declaration of function `CPU_ZERO'
miscutils/taskset.c:68: error: `new_mask' undeclared (first use in this function)
miscutils/taskset.c:69: error: `CPU_SETSIZE' undeclared (first use in this function)
miscutils/taskset.c:71: warning: implicit declaration of function `CPU_SET'
miscutils/taskset.c:78: warning: implicit declaration of function `sched_getaffinity'
miscutils/taskset.c:78: error: `mask' undeclared (first use in this function)
miscutils/taskset.c:86: warning: implicit declaration of function `sched_setaffinity'
make[1]: *** [miscutils/taskset.o] Error 1
make: *** [miscutils] Error 2


Cheers,

-- 
Cristian


From Alexander at Kriegisch.name  Sat Aug  4 13:22:08 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 04 Aug 2007 15:22:08 +0200
Subject: ash - exit code for a piped process
Message-ID: <46B47D80.7040909@Kriegisch.name>

I would like to determine the exit code of 'foo' in
foo | bar

I bash there is the PIPESTATUS array, but in ash (which I must use)
there is no such thing as PIPESTATUS or arrays. Is there any canonical
way or at least a workaround to achieve both piping the foo's output
into bar unconditionally *and* determining foo's exit code?

Thanks
-- 
Alexander Kriegisch


From vapier at gentoo.org  Sat Aug  4 13:48:43 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 4 Aug 2007 09:48:43 -0400
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
In-Reply-To: <0708041341350.10759@somehost>
References: <0708041341350.10759@somehost>
Message-ID: <200708040948.44414.vapier@gentoo.org>

On Saturday 04 August 2007, Cristian Ionescu-Idbohrn wrote:
> ...which is the latest distributed.

no it isnt, Debian is out of date

>   CC      miscutils/readahead.o
>   CC      miscutils/taskset.o

if the applets fail, dont enable them
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070804/c8a52132/attachment-0002.pgp 

From loic.grenie at gmail.com  Sat Aug  4 13:45:56 2007
From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=)
Date: Sat, 4 Aug 2007 13:45:56 +0000
Subject: ash - exit code for a piped process
In-Reply-To: <46B47D80.7040909@Kriegisch.name>
References: <46B47D80.7040909@Kriegisch.name>
Message-ID: <9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>

2007/8/4, Alexander Kriegisch <Alexander at kriegisch.name>:
> I would like to determine the exit code of 'foo' in
> foo | bar
>
> I bash there is the PIPESTATUS array, but in ash (which I must use)
> there is no such thing as PIPESTATUS or arrays. Is there any canonical
> way or at least a workaround to achieve both piping the foo's output
> into bar unconditionally *and* determining foo's exit code?

x=`((( foo 3>&- 4>&- ); echo $? >&3)| bar >&4  3>&- 4>&-) 3>&1` 4>&1

  should do the trick. The exit code of foo is in x, the output of bar
  goes to the output of the command.

      Hope this helps.

         Lo?c


From Alexander at Kriegisch.name  Sat Aug  4 14:16:44 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sat, 04 Aug 2007 16:16:44 +0200
Subject: ash - exit code for a piped process
In-Reply-To: <9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
References: <46B47D80.7040909@Kriegisch.name>
	<9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
Message-ID: <46B48A4C.8060001@Kriegisch.name>

> x=`((( foo 3>&- 4>&- ); echo $? >&3)| bar >&4  3>&- 4>&-) 3>&1` 4>&1

Thanks, Lo?c. I will consider your solution if I ever have a case like
this again, but my current workaround is rather simple to read and uses
a text buffer for the first command's output. I can do this because I
know that foo's output has a limited size which can be easily handled in
memory. So I choose this way for the sake of readability:

output=$(foo)
result=$?
echo "$output" | bar

I know the solution is somewhat limited, but a feasibly workaround in my
special case. Yours is more refined and really uses pipes.
--
Alexander Kriegisch





From farmatito at tiscali.it  Sat Aug  4 14:24:18 2007
From: farmatito at tiscali.it (Tito)
Date: Sat, 4 Aug 2007 16:24:18 +0200
Subject: ash - exit code for a piped process
In-Reply-To: <9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
References: <46B47D80.7040909@Kriegisch.name>
	<9b06e8d20708040645j10272777p6e5ee7bf29e9c36c@mail.gmail.com>
Message-ID: <200708041624.18065.farmatito@tiscali.it>

On Saturday 04 August 2007 15:45:56 Lo?c Greni? wrote:
> 2007/8/4, Alexander Kriegisch <Alexander at kriegisch.name>:
> > I would like to determine the exit code of 'foo' in
> > foo | bar
> >
> > I bash there is the PIPESTATUS array, but in ash (which I must use)
> > there is no such thing as PIPESTATUS or arrays. Is there any canonical
> > way or at least a workaround to achieve both piping the foo's output
> > into bar unconditionally *and* determining foo's exit code?
> 
> x=`((( foo 3>&- 4>&- ); echo $? >&3)| bar >&4  3>&- 4>&-) 3>&1` 4>&1
> 
>   should do the trick. The exit code of foo is in x, the output of bar
>   goes to the output of the command.
> 
>       Hope this helps.
> 
>          Lo?c

foo > out.file
ret=$?
cat out.file | bar
# rm out.file

Untested. Just an idea...........

Ciao,
Tito


From cristian.ionescu-idbohrn at axis.com  Sun Aug  5 07:48:41 2007
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Sun, 5 Aug 2007 09:48:41 +0200 (CEST)
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
In-Reply-To: <200708040948.44414.vapier@gentoo.org>
References: <0708041341350.10759@somehost>
	<200708040948.44414.vapier@gentoo.org>
Message-ID: <0708050905310.9234@somehost>

On Sat, 4 Aug 2007, Mike Frysinger wrote:

> On Saturday 04 August 2007, Cristian Ionescu-Idbohrn wrote:
> > ...which is the latest distributed.
>
> no it isnt,

yes, it is :) the latest debian distributed uclibc-toolchain.

> Debian is out of date

of course.

> >   CC      miscutils/readahead.o
> >   CC      miscutils/taskset.o
>
> if the applets fail, dont enable them

right. my message was just meant to provide some information, nothing
else.


Cheers,

-- 
Cristian


From rep.dot.nop at gmail.com  Sun Aug  5 11:33:14 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 5 Aug 2007 13:33:14 +0200
Subject: just a few more compilation warnings
In-Reply-To: <0708041302530.10759@somehost>
References: <0708041302530.10759@somehost>
Message-ID: <20070805113314.GN11697@aon.at>

On Sat, Aug 04, 2007 at 01:07:23PM +0200, Cristian Ionescu-Idbohrn wrote:
>Please find attached a sorted list of "declared with attribute
>warn_unused_result" warnings.

See
$ svn log -r18877


From rep.dot.nop at gmail.com  Sun Aug  5 11:36:52 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 5 Aug 2007 13:36:52 +0200
Subject: won't build with debian uclibc-toolchain 0.9.27-1...
In-Reply-To: <0708050905310.9234@somehost>
References: <0708041341350.10759@somehost>
	<200708040948.44414.vapier@gentoo.org>
	<0708050905310.9234@somehost>
Message-ID: <20070805113652.GO11697@aon.at>

On Sun, Aug 05, 2007 at 09:48:41AM +0200, Cristian Ionescu-Idbohrn wrote:
>On Sat, 4 Aug 2007, Mike Frysinger wrote:
>
>> On Saturday 04 August 2007, Cristian Ionescu-Idbohrn wrote:
>> > ...which is the latest distributed.
>>
>> no it isnt,
>
>yes, it is :) the latest debian distributed uclibc-toolchain.

No, it isn't. About any toolchain that may be downloadable from
uClibc.org or busybox.net is outdated.
Nowadays, you should either use emdebian, buildroot or gentoo or one of
the dozend other distros that come with native uClibc support.

>> if the applets fail, dont enable them
>
>right. my message was just meant to provide some information, nothing
>else.

Thanks, but as you can see from the archives (and even some help-texts
of one of the abovementioned applets) this is a non-issue since you're
using an outdated toolchain :)


From ml at zastrow4u.de  Sun Aug  5 17:40:12 2007
From: ml at zastrow4u.de (Alfred Zastrow)
Date: Sun, 05 Aug 2007 19:40:12 +0200
Subject: applet-request: expand
Message-ID: <46B60B7C.6080108@zastrow4u.de>

Hello list,

glibc-2.6.1 compiles fine by using most of the applets of busybox-1.6.1,
but "expand" of coreutils is still missing:

----------snip----------------
sed -e 's,[{}],@&,g'				\
	    -e 's,/\*\(@.*\)\*/,\1,g'			\
	    -e 's,/\*  *,/* @r{,g' -e 's,  *\*/,} */,'	\
	    -e 's/\(@[a-z][a-z]*\)@{\([^}]*\)@}/\1{\2}/g'\
	    examples/stpcpy.c | expand > stpcpy.c.texi.new
/bin/sh: line 4: expand: command not found
make[2]: *** [stpcpy.c.texi] Error 127
make[2]: Leaving directory `/build/glibc-2.6.1/manual'
make[1]: *** [manual/subdir_install] Error 2
make[1]: Leaving directory `/build/glibc-2.6.1'
make: *** [install] Fehler 2
----------snap----------------

Is there any chance to get this in?

cu
Alfred



From jako at grand.com.tw  Mon Aug  6 01:05:56 2007
From: jako at grand.com.tw (Grandtec Jako)
Date: Mon, 6 Aug 2007 09:05:56 +0800
Subject: httpd question
Message-ID: <002601c7d7c5$f1eb7e60$d3a8a8c0@GRANDTECJACKY>

Hi,

I use busybox v1.00 version at PC board.
I use "ifconfig eth0 192.168.168.214 up" , and "httpd -p 80 -h /cgi-bin -c /etc/httpd.conf -r "Web Server Authentication" &" commands.
Then I open webpage at http://192.168.168.214.
Now, I have two questions.

Q1. If I open webpage at first http://192.168.168.214, I will not open Web Page at second http://192.168.168.214. 
       But it have displayed login-in (input id and password) pup-up.

Q2. When I open webpage at first http://192.168.168.214, the index.html can't link to other Web Pages.

About httpd.conf file:
------------------------------
A:*
/:root:admin
/cgi-bin:foo:bar
/adm:admin:setup
/adm:toor:PaSsWd
.htm:text/html
.html:text/html
-------------------------------

Can you give me some suggestions ?
Thanks.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070806/0c609b59/attachment-0002.htm 

From vda.linux at googlemail.com  Mon Aug  6 02:26:16 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 03:26:16 +0100
Subject: [patch] setfiles update
In-Reply-To: <20070803091304.54C4.YNAKAM@hitachisoft.jp>
References: <20070803091304.54C4.YNAKAM@hitachisoft.jp>
Message-ID: <200708060326.16357.vda.linux@googlemail.com>

On Friday 03 August 2007 01:15, Yuichi Nakamura wrote:
> This is a patch for setfiles applet.
> Following is change.
> * Bug fix: -f option did not work.
> * Using bb_simplify_path to remove extra slash for smaller code.

Applied, thanks
--
vda


From vda.linux at googlemail.com  Mon Aug  6 02:46:09 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 03:46:09 +0100
Subject: bug in coreutils/printenv.c
In-Reply-To: <6823.69286.qm@web8605.mail.in.yahoo.com>
References: <6823.69286.qm@web8605.mail.in.yahoo.com>
Message-ID: <200708060346.09171.vda.linux@googlemail.com>

On Friday 03 August 2007 17:44, kalyanatejaswi balabhadrapatruni wrote:
> Hi all,
> "printenv" command prints argv[1] and exits, doesnt
> run through rest of the elements of argv[].
> ---------------
> Example:
> #busybox printenv SHELL PWD
> /bin/sh
> #
> Doesnt print PWD
> ----------------
> 
> No great deal, small patch attached.

I am replacing open-coded environ[] scan there with getenv:

+               while ((arg = *++argv) != NULL) {
+                       env = getenv(arg);
+                       if (env)
+                               puts(env);
+               }

Saves ~75 bytes too.

Please test svn, should be fixed now. Thanks.
--
vda


From vda.linux at googlemail.com  Mon Aug  6 02:47:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 03:47:32 +0100
Subject: [PATCH] patch: extract_filename should strip all dirs if
	patch_level is -1
In-Reply-To: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
References: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
Message-ID: <200708060347.32312.vda.linux@googlemail.com>

On Friday 03 August 2007 22:58, Nguyen Thai Ngoc Duy wrote:
> It is also documented in the comment above the function but not implemented

No patch is attached to your mail...
--
vda


From vda.linux at googlemail.com  Mon Aug  6 03:31:02 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 04:31:02 +0100
Subject: [PATCH] sed: save the last regex for use later
In-Reply-To: <fcaeb9bf0708031745u59d7d2b0gb3086a83b6550bcc@mail.gmail.com>
References: <fcaeb9bf0708031745u59d7d2b0gb3086a83b6550bcc@mail.gmail.com>
Message-ID: <200708060431.02810.vda.linux@googlemail.com>

On Saturday 04 August 2007 01:45, Nguyen Thai Ngoc Duy wrote:
> I'm not really get into sed source code, so I might be wrong. Please recheck it.
> With this patch, the following command should return 'abc' (GNU sed
> does but busybox did not):
> echo 'URL: abc'|busybox sed -ne '/^URL: */{ s///p; q }'

Applied, thanks. Seems to not break any of testsuite entry.
--
vda


From vapier at gentoo.org  Mon Aug  6 08:14:55 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 6 Aug 2007 04:14:55 -0400
Subject: @mail.com users are now banned in bugs
Message-ID: <200708060414.56144.vapier@gentoo.org>

we've seen ~40 spam accounts registered this last week (a few every day) and 
each one was @mail.com so ive tweaked mantis to silently ignore registrations 
for @mail.com addresses.

not a big deal since of the ~1200 registered people, 0 are using this 
craptastic webmail service.

if it starts to be a problem with random addresses, we can look at requiring 
captchas, but i personally hate those goddamn things ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070806/d9b8c7f7/attachment-0002.pgp 

From per.hallsmark at t2data.se  Mon Aug  6 08:21:50 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Mon, 06 Aug 2007 10:21:50 +0200
Subject: hush in arm nommu environment
Message-ID: <46B6DA1E.1090502@t2data.se>

Hi all,

I've tried out the hush shell in busybox 1.6.1.
Seems to work fairly well with the patch last in
this mail.

The only(?) thing that doesn't work however, is
backspace... or to be more correct, it do backspace
in the commandline but it isn't displayed correctly.
If I have fancy editing enabling then the character
is moved to the RIGHT instead of LEFT when I backspace.
If I don't have fancy editing enabled, it prints out
some garbage (same all time) like:

~ # lsUP!) UP!)UP!) UP!)
(backspace pressed twice)

The only string I can find that looks like UP!) is:

[per at phlap3 busybox-1.6.1]$ grep -r UP\! *
networking/ping.c:      const char *dupmsg = " (DUP!)";
[per at phlap3 busybox-1.6.1]$

So it seems like a weird pointer issue...

I use busybox 1.6.1, gcc 4.1.2 and kernel 2.6.19-uc1 on
a arm7tdmi'ish mcu.

Anyone encountered this behaviour?

/Per

--- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
+++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
@@ -658,7 +658,11 @@
         pid_t pid;

         debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
+#if BB_MMU
         pid = fork();
+#else
+       pid = vfork();
+#endif
         if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
                 return;
         ctrl_z_flag = 1;



From per.hallsmark at t2data.se  Mon Aug  6 09:35:41 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Mon, 06 Aug 2007 11:35:41 +0200
Subject: hush in arm nommu environment
In-Reply-To: <46B6DA1E.1090502@t2data.se>
References: <46B6DA1E.1090502@t2data.se>
Message-ID: <46B6EB6D.8000300@t2data.se>

well... sometimes one can answer oneself... :)

--- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
+++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
@@ -165,10 +165,12 @@

         if (cmdedit_x >= num) {
                 cmdedit_x -= num;
+#if 0
                 if (num <= 4) {
                         printf("\b\b\b\b" + (4-num));
                         return;
                 }
+#endif
                 printf("\033[%uD", num);
                 return;
         }


With above patch backspace works ok.

The \b\b... printf looks rather mystic... guess the author
perhaps wanted something like this instead?

switch (num) {
   case 4:
     printf("\b");
     /* fall trough */
   case 3:
     printf("\b");
     /* fall trough */
   case 2:
     printf("\b");
     /* fall trough */
   case 1:
     printf("\b");
     return;
   default:
}

but I wonder what the benefits are...

Per Hallsmark wrote:
> Hi all,
> 
> I've tried out the hush shell in busybox 1.6.1.
> Seems to work fairly well with the patch last in
> this mail.
> 
> The only(?) thing that doesn't work however, is
> backspace... or to be more correct, it do backspace
> in the commandline but it isn't displayed correctly.
> If I have fancy editing enabling then the character
> is moved to the RIGHT instead of LEFT when I backspace.
> If I don't have fancy editing enabled, it prints out
> some garbage (same all time) like:
> 
> ~ # lsUP!) UP!)UP!) UP!)
> (backspace pressed twice)
> 
> The only string I can find that looks like UP!) is:
> 
> [per at phlap3 busybox-1.6.1]$ grep -r UP\! *
> networking/ping.c:      const char *dupmsg = " (DUP!)";
> [per at phlap3 busybox-1.6.1]$
> 
> So it seems like a weird pointer issue...
> 
> I use busybox 1.6.1, gcc 4.1.2 and kernel 2.6.19-uc1 on
> a arm7tdmi'ish mcu.
> 
> Anyone encountered this behaviour?
> 
> /Per
> 
> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
> @@ -658,7 +658,11 @@
>          pid_t pid;
> 
>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
> +#if BB_MMU
>          pid = fork();
> +#else
> +       pid = vfork();
> +#endif
>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>                  return;
>          ctrl_z_flag = 1;
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox




From per.hallsmark at t2data.se  Mon Aug  6 09:35:52 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Mon, 06 Aug 2007 11:35:52 +0200
Subject: hush in arm nommu environment
In-Reply-To: <46B6DA1E.1090502@t2data.se>
References: <46B6DA1E.1090502@t2data.se>
Message-ID: <46B6EB78.7040204@t2data.se>

well... sometimes one can answer oneself... :)

--- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
+++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
@@ -165,10 +165,12 @@

         if (cmdedit_x >= num) {
                 cmdedit_x -= num;
+#if 0
                 if (num <= 4) {
                         printf("\b\b\b\b" + (4-num));
                         return;
                 }
+#endif
                 printf("\033[%uD", num);
                 return;
         }


With above patch backspace works ok.

The \b\b... printf looks rather mystic... guess the author
perhaps wanted something like this instead?

switch (num) {
   case 4:
     printf("\b");
     /* fall trough */
   case 3:
     printf("\b");
     /* fall trough */
   case 2:
     printf("\b");
     /* fall trough */
   case 1:
     printf("\b");
     return;
   default:
}

but I wonder what the benefits are...

Per Hallsmark wrote:
> Hi all,
> 
> I've tried out the hush shell in busybox 1.6.1.
> Seems to work fairly well with the patch last in
> this mail.
> 
> The only(?) thing that doesn't work however, is
> backspace... or to be more correct, it do backspace
> in the commandline but it isn't displayed correctly.
> If I have fancy editing enabling then the character
> is moved to the RIGHT instead of LEFT when I backspace.
> If I don't have fancy editing enabled, it prints out
> some garbage (same all time) like:
> 
> ~ # lsUP!) UP!)UP!) UP!)
> (backspace pressed twice)
> 
> The only string I can find that looks like UP!) is:
> 
> [per at phlap3 busybox-1.6.1]$ grep -r UP\! *
> networking/ping.c:      const char *dupmsg = " (DUP!)";
> [per at phlap3 busybox-1.6.1]$
> 
> So it seems like a weird pointer issue...
> 
> I use busybox 1.6.1, gcc 4.1.2 and kernel 2.6.19-uc1 on
> a arm7tdmi'ish mcu.
> 
> Anyone encountered this behaviour?
> 
> /Per
> 
> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
> @@ -658,7 +658,11 @@
>          pid_t pid;
> 
>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
> +#if BB_MMU
>          pid = fork();
> +#else
> +       pid = vfork();
> +#endif
>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>                  return;
>          ctrl_z_flag = 1;
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox




From landau_alex at yahoo.com  Mon Aug  6 11:23:01 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Mon, 6 Aug 2007 04:23:01 -0700 (PDT)
Subject: Bug in lastest commit of scripts/trylink (r19409)
Message-ID: <586940.66267.qm@web62504.mail.re1.yahoo.com>

Hi,

At the very end, when doing the final link it's written:
try <some text> && exit 1
which should be:
try <some text> || exit 1

Currently busybox is not being built from busybox_unstripped.

Alex


      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 


From pclouds at gmail.com  Mon Aug  6 11:33:58 2007
From: pclouds at gmail.com (Nguyen Thai Ngoc Duy)
Date: Mon, 6 Aug 2007 07:33:58 -0400
Subject: [PATCH] patch: extract_filename should strip all dirs if
	patch_level is -1
In-Reply-To: <200708060347.32312.vda.linux@googlemail.com>
References: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
	<200708060347.32312.vda.linux@googlemail.com>
Message-ID: <fcaeb9bf0708060433h580742f3ve1ecd203d0801694@mail.gmail.com>

Oops, sorry.  Here coms the patch.

On 8/5/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> On Friday 03 August 2007 22:58, Nguyen Thai Ngoc Duy wrote:
> > It is also documented in the comment above the function but not implemented
>
> No patch is attached to your mail...
> --
> vda
>


-- 
Duy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-strip.patch
Type: text/x-patch
Size: 589 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070806/9c39a5a5/attachment-0002.bin 

From landau_alex at yahoo.com  Mon Aug  6 11:50:43 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Mon, 6 Aug 2007 04:50:43 -0700 (PDT)
Subject: [PATCH] catv wrong behaviour when no arguments passed
Message-ID: <514417.87596.qm@web62503.mail.re1.yahoo.com>

Hi,

When catv gets no files on the command line (argv[0] == NULL after getopt), after doing
its work it increments argv to point to the next argument, but since argv is already
NULL, catv tries to open files whose names are the environment strings (e.g.
"HOME=/home/user", "PATH=...").
The fix/workaround below is to pre-decrement argv in this case, so that when it is
incremented later it will be NULL and the loop will break.

Alex

Index: coreutils/catv.c
===================================================================
--- coreutils/catv.c	(revision 19409)
+++ coreutils/catv.c	(working copy)
@@ -27,8 +27,10 @@
 
 	/* Read from stdin if there's nothing else to do. */
 	fd = 0;
-	if (!argv[0])
+	if (!argv[0]) {
+		argv--;
 		goto jump_in;
+	}
 	do {
 		fd = open_or_warn(*argv, O_RDONLY);
 		if (fd < 0) {



       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433


From vda.linux at googlemail.com  Mon Aug  6 12:07:54 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 13:07:54 +0100
Subject: Bug in lastest commit of scripts/trylink (r19409)
In-Reply-To: <586940.66267.qm@web62504.mail.re1.yahoo.com>
References: <586940.66267.qm@web62504.mail.re1.yahoo.com>
Message-ID: <200708061307.54607.vda.linux@googlemail.com>

On Monday 06 August 2007 12:23, Alex Landau wrote:
> At the very end, when doing the final link it's written:
> try <some text> && exit 1
> which should be:
> try <some text> || exit 1
> 
> Currently busybox is not being built from busybox_unstripped.

Thanks, fixed.
--
vda


From vda.linux at googlemail.com  Mon Aug  6 12:26:16 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 13:26:16 +0100
Subject: [PATCH] patch: extract_filename should strip all dirs if
	patch_level is -1
In-Reply-To: <fcaeb9bf0708060433h580742f3ve1ecd203d0801694@mail.gmail.com>
References: <fcaeb9bf0708031458v36a2fe26jb8782b1e64cc74a9@mail.gmail.com>
	<200708060347.32312.vda.linux@googlemail.com>
	<fcaeb9bf0708060433h580742f3ve1ecd203d0801694@mail.gmail.com>
Message-ID: <200708061326.16666.vda.linux@googlemail.com>

On Monday 06 August 2007 12:33, Nguyen Thai Ngoc Duy wrote:
> Oops, sorry.  Here coms the patch.
> 
> On 8/5/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
> > On Friday 03 August 2007 22:58, Nguyen Thai Ngoc Duy wrote:
> > > It is also documented in the comment above the function but not implemented
> >
> > No patch is attached to your mail...
> > --
> > vda

Fixed in svn, thanks
--
vda


From vda.linux at googlemail.com  Mon Aug  6 13:23:49 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:23:49 +0100
Subject: [PATCH] Add Blackfin to scripts/checkstack.pl
In-Reply-To: <342715.31112.qm@web62502.mail.re1.yahoo.com>
References: <342715.31112.qm@web62502.mail.re1.yahoo.com>
Message-ID: <200708061423.49765.vda.linux@googlemail.com>

On Thursday 02 August 2007 14:54, Alex Landau wrote:
> Hi,
> The patch below adds support for Blackfin to scripts/checkstack.pl.
> Please apply, if it seems appropriate.
> Alex

Applied, thanks.
--
vda


From vda.linux at googlemail.com  Mon Aug  6 13:25:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:25:03 +0100
Subject: [PATCH] catv wrong behaviour when no arguments passed
In-Reply-To: <514417.87596.qm@web62503.mail.re1.yahoo.com>
References: <514417.87596.qm@web62503.mail.re1.yahoo.com>
Message-ID: <200708061425.03178.vda.linux@googlemail.com>

On Monday 06 August 2007 12:50, Alex Landau wrote:
> Hi,
> 
> When catv gets no files on the command line (argv[0] == NULL after getopt), after doing
> its work it increments argv to point to the next argument, but since argv is already
> NULL, catv tries to open files whose names are the environment strings (e.g.
> "HOME=/home/user", "PATH=...").
> The fix/workaround below is to pre-decrement argv in this case, so that when it is
> incremented later it will be NULL and the loop will break.

Applied, thanks
--
vda


From vda.linux at googlemail.com  Mon Aug  6 13:26:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:26:40 +0100
Subject: [PATCH-suggestion] The pidfile problem of udhcpc
In-Reply-To: <1183388051.4000.45.camel@Blue2net-mats.bellman.mea>
References: <1183388051.4000.45.camel@Blue2net-mats.bellman.mea>
Message-ID: <200708061426.40949.vda.linux@googlemail.com>

On Monday 02 July 2007 15:54, Mats Erik Andersson wrote:
> Hi again,
> 
> I have analyzed and located the problem with udhcpc
> for todays snapshot of Busybox when one uses
> 
> # CONFIG_FEATURE_PIDFILE is not set

It should be fixed now.
If it's not, let me know.
--
vda


From vda.linux at googlemail.com  Mon Aug  6 13:28:19 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 14:28:19 +0100
Subject: httpd question
In-Reply-To: <002601c7d7c5$f1eb7e60$d3a8a8c0@GRANDTECJACKY>
References: <002601c7d7c5$f1eb7e60$d3a8a8c0@GRANDTECJACKY>
Message-ID: <200708061428.19752.vda.linux@googlemail.com>

On Monday 06 August 2007 02:05, Grandtec Jako wrote:
> Hi,
> 
> I use busybox v1.00 version at PC board.
> I use "ifconfig eth0 192.168.168.214 up" , and "httpd -p 80 -h /cgi-bin -c /etc/httpd.conf -r "Web Server Authentication" &" commands.
> Then I open webpage at http://192.168.168.214.
> Now, I have two questions.
> 
> Q1. If I open webpage at first http://192.168.168.214, I will not open Web Page at second http://192.168.168.214. 
>        But it have displayed login-in (input id and password) pup-up.
> 
> Q2. When I open webpage at first http://192.168.168.214, the index.html can't link to other Web Pages.

I failed to understand both questions.

http://catb.org/~esr/faqs/smart-questions.html
--
vda


From vda.linux at googlemail.com  Mon Aug  6 14:07:26 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 15:07:26 +0100
Subject: hush in arm nommu environment
In-Reply-To: <46B6EB78.7040204@t2data.se>
References: <46B6DA1E.1090502@t2data.se> <46B6EB78.7040204@t2data.se>
Message-ID: <200708061507.26107.vda.linux@googlemail.com>

On Monday 06 August 2007 10:35, Per Hallsmark wrote:
> well... sometimes one can answer oneself... :)
> 
> --- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
> +++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
> @@ -165,10 +165,12 @@
> 
>          if (cmdedit_x >= num) {
>                  cmdedit_x -= num;
> +#if 0
>                  if (num <= 4) {
>                          printf("\b\b\b\b" + (4-num));
>                          return;
>                  }
> +#endif
>                  printf("\033[%uD", num);
>                  return;
>          }
> 
> 
> With above patch backspace works ok.
> 
> The \b\b... printf looks rather mystic... guess the author
> perhaps wanted something like this instead?
> 
> switch (num) {
>    case 4:
>      printf("\b");
>      /* fall trough */
>    case 3:
>      printf("\b");
>      /* fall trough */
>    case 2:
>      printf("\b");
>      /* fall trough */
>    case 1:
>      printf("\b");
>      return;
>    default:
> }
> 
> but I wonder what the benefits are...

printf("\b\b\b\b" + (4-num));

does exactly the same in 4 times less code.
If num==4, it does printf("\b\b\b\b" + 0) => printf("\b\b\b\b")
If num==3, it does printf("\b\b\b\b" + 1) => printf("\b\b\b")
If num==2, it does printf("\b\b\b\b" + 2) => printf("\b\b")
If num==1, it does printf("\b\b\b\b" + 3) => printf("\b")
etc

The benefits are that we send less bytes than with printf("\033[%uD", num);
It's done primarily for the most common case: single [Backspace] key.
It's silly to send ESC [ 1 D instead of single backspace char.

Now, I wonder why \b for you does not do what it should (that is,
going back one char). Can you compile and run this test program?

int main(int argc, char **argv) {
        printf("987654321\b\b\b\b" + argc);
        fflush(0);
        sleep(3);
        puts("");
}

When I run it, I see this:

# ./a.out
87654321   <---- cursor is under '4'
# ./a.out 1
7654321    <---- cursor is under '4'
# ./a.out 1 1
654321     <---- cursor is under '4'
# ./a.out 1 1 | hexdump -vC
00000000  36 35 34 33 32 31 08 08  08 08 0a                 |654321.....|
0000000b

IOW, both printf("str" + n) and '\b' work right for me.

What do you see
--
vda


From vda.linux at googlemail.com  Mon Aug  6 14:10:25 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 15:10:25 +0100
Subject: hush in arm nommu environment
In-Reply-To: <46B6DA1E.1090502@t2data.se>
References: <46B6DA1E.1090502@t2data.se>
Message-ID: <200708061510.25873.vda.linux@googlemail.com>

On Monday 06 August 2007 09:21, Per Hallsmark wrote:
> Hi all,
> 
> I've tried out the hush shell in busybox 1.6.1.
> Seems to work fairly well with the patch last in
> this mail.
...
> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
> @@ -658,7 +658,11 @@
>          pid_t pid;
> 
>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
> +#if BB_MMU
>          pid = fork();
> +#else
> +       pid = vfork();
> +#endif
>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>                  return;
>          ctrl_z_flag = 1;

I'm afraid this maybe works for some simple scripts, but I'm sure as hell
there are nasty bugs. Code does assume that after fork() we create
new process. Simply replacing it with vfork is not going to work stably.
--
vda


From vda.linux at googlemail.com  Mon Aug  6 14:11:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Mon, 6 Aug 2007 15:11:32 +0100
Subject: applet-request: expand
In-Reply-To: <46B60B7C.6080108@zastrow4u.de>
References: <46B60B7C.6080108@zastrow4u.de>
Message-ID: <200708061511.32929.vda.linux@googlemail.com>

On Sunday 05 August 2007 18:40, Alfred Zastrow wrote:
> Hello list,
> 
> glibc-2.6.1 compiles fine by using most of the applets of busybox-1.6.1,
> but "expand" of coreutils is still missing:
> 
> ----------snip----------------
> sed -e 's,[{}],@&,g'				\
> 	    -e 's,/\*\(@.*\)\*/,\1,g'			\
> 	    -e 's,/\*  *,/* @r{,g' -e 's,  *\*/,} */,'	\
> 	    -e 's/\(@[a-z][a-z]*\)@{\([^}]*\)@}/\1{\2}/g'\
> 	    examples/stpcpy.c | expand > stpcpy.c.texi.new
> /bin/sh: line 4: expand: command not found
> make[2]: *** [stpcpy.c.texi] Error 127
> make[2]: Leaving directory `/build/glibc-2.6.1/manual'
> make[1]: *** [manual/subdir_install] Error 2
> make[1]: Leaving directory `/build/glibc-2.6.1'
> make: *** [install] Fehler 2
> ----------snap----------------
> 
> Is there any chance to get this in?

I read the expand manpage. I'd say it's not that hard. Wanna try? ;)
--
vda


From ml at zastrow4u.de  Mon Aug  6 18:56:30 2007
From: ml at zastrow4u.de (Alfred Zastrow)
Date: Mon, 06 Aug 2007 20:56:30 +0200
Subject: applet-request: expand
In-Reply-To: <200708061511.32929.vda.linux@googlemail.com>
References: <46B60B7C.6080108@zastrow4u.de>
	<200708061511.32929.vda.linux@googlemail.com>
Message-ID: <46B76EDE.5020100@zastrow4u.de>

Denis Vlasenko schrieb:
> On Sunday 05 August 2007 18:40, Alfred Zastrow wrote:
>> Hello list,
>>
>> glibc-2.6.1 compiles fine by using most of the applets of busybox-1.6.1,
>> but "expand" of coreutils is still missing:
>>
>> ----------snip----------------
>> sed -e 's,[{}],@&,g'				\
>> 	    -e 's,/\*\(@.*\)\*/,\1,g'			\
>> 	    -e 's,/\*  *,/* @r{,g' -e 's,  *\*/,} */,'	\
>> 	    -e 's/\(@[a-z][a-z]*\)@{\([^}]*\)@}/\1{\2}/g'\
>> 	    examples/stpcpy.c | expand > stpcpy.c.texi.new
>> /bin/sh: line 4: expand: command not found
>> make[2]: *** [stpcpy.c.texi] Error 127
>> make[2]: Leaving directory `/build/glibc-2.6.1/manual'
>> make[1]: *** [manual/subdir_install] Error 2
>> make[1]: Leaving directory `/build/glibc-2.6.1'
>> make: *** [install] Fehler 2
>> ----------snap----------------
>>
>> Is there any chance to get this in?
> 
> I read the expand manpage. I'd say it's not that hard. Wanna try? ;)

Yes, please.

My 1st thought was to create a shell wrapper with `tr`, but a more 
professional solution (without patching the source) would be much more 
nicer.

Regards
Alfred



From farmatito at tiscali.it  Mon Aug  6 21:00:56 2007
From: farmatito at tiscali.it (Tito)
Date: Mon, 6 Aug 2007 23:00:56 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <46B76EDE.5020100@zastrow4u.de>
References: <46B60B7C.6080108@zastrow4u.de>
	<200708061511.32929.vda.linux@googlemail.com>
	<46B76EDE.5020100@zastrow4u.de>
Message-ID: <200708062300.56120.farmatito@tiscali.it>

Hi,
this is a first attempt to implement a stripped down version of expand.
This version is only little tested so it may contain all sort of bugs.
Hints, critics and help in testing and improving it is welcome. 

bloat-o-meter (after make defconfig and enabling the expand applet) says:
function                                             old     new   delta
expand_main                                            -     437    +437
.rodata                                           121357  121485    +128
packed_usage                                       22558   22660    +102
applets                                             3108    3120     +12
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 3/0 up/down: 679/0)             Total: 679 bytes

Usage is: expand  [-i] [-t NUM] [FILE | -]

 *  Options:
 *  -t num		Convert tabs to num spaces (default 8 spaces).
 *
 *              Caveat: this version doesn't accept tab lists and
 *              therefore isn't conform to The Open Group Base 
 *              Specifications Issue 6.
 *
 *  -i			Only convert initial tabs on each line to spaces.

Ciao,
Tito
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expand.patch
Type: text/x-diff
Size: 5052 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070806/61687011/attachment-0002.bin 

From dave at cray.com  Tue Aug  7 01:26:57 2007
From: dave at cray.com (David Updegraff)
Date: Mon, 06 Aug 2007 20:26:57 -0500
Subject: udhcp lease bug
Message-ID: <f98hp2$7c8$1@sea.gmane.org>

Hi.

udhcp keeps sending out same IPs to diff. macs w/o this patch when a
bunch boot at the same time.  Annoying.


----------snip-----
svn diff networking/udhcp/leases.c
Index: networking/udhcp/leases.c
===================================================================
--- networking/udhcp/leases.c   (revision 19415)
+++ networking/udhcp/leases.c   (working copy)
@@ -33,7 +33,7 @@
        for (j = 0; j < 16 && !chaddr[j]; j++);

        for (i = 0; i < server_config.max_leases; i++)
-               if ((j != 16 && memcmp(leases[i].chaddr, chaddr, 16) != 0)
+               if ((j != 16 && memcmp(leases[i].chaddr, chaddr, 16) == 0)
                 || (yiaddr && leases[i].yiaddr == yiaddr)
                ) {
                        memset(&(leases[i]), 0, sizeof(struct
dhcpOfferedAddr));
-----------------snip--------



From jakolee at gmail.com  Tue Aug  7 04:51:16 2007
From: jakolee at gmail.com (Jako Lee)
Date: Tue, 7 Aug 2007 12:51:16 +0800
Subject: Httpd serve multiple pages
Message-ID: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>

Hi all,

How do I serve multiple pages using httpd for a single user?
Right now I have a main page with a link to another page on
my Linux directory. After logging in I can see the main page
but when I click on the link it tell me that it can't find
the server (both the main page and the linked page are in
the same directory). However, if the link is set to "Google"
or "Yahoo" homepage it will work fine.

I had searched about busybox at forum and I used Google to
find "busybox httpd command", "busybox httpd directives" and
 "busybox httpd.conf" on the Web, but I got no useful hits.

I am using BusyBox 1.0.0. and linux kernel is 2.6.18-1.2798.fc6xen.

Best regards
Jako
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070807/0b068163/attachment-0002.htm 

From vapier at gentoo.org  Tue Aug  7 06:39:10 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 7 Aug 2007 02:39:10 -0400
Subject: [PATCH] Add Blackfin to scripts/checkstack.pl
In-Reply-To: <200708061423.49765.vda.linux@googlemail.com>
References: <342715.31112.qm@web62502.mail.re1.yahoo.com>
	<200708061423.49765.vda.linux@googlemail.com>
Message-ID: <200708070239.11570.vapier@gentoo.org>

On Monday 06 August 2007, Denis Vlasenko wrote:
> On Thursday 02 August 2007 14:54, Alex Landau wrote:
> > Hi,
> > The patch below adds support for Blackfin to scripts/checkstack.pl.
> > Please apply, if it seems appropriate.
> > Alex
>
> Applied, thanks.

really you should just pull down the latest version from the kernel git
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070807/6e610249/attachment-0002.pgp 

From per.hallsmark at t2data.se  Tue Aug  7 07:41:31 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Tue, 07 Aug 2007 09:41:31 +0200
Subject: hush in arm nommu environment
In-Reply-To: <200708061507.26107.vda.linux@googlemail.com>
References: <46B6DA1E.1090502@t2data.se> <46B6EB78.7040204@t2data.se>
	<200708061507.26107.vda.linux@googlemail.com>
Message-ID: <46B8222B.8000000@t2data.se>

Ahhh.. yes I see it know, how could I ever miss :)

Well, the testapp works same here, both in my host and
target.

The hexdump is also same:

00000000  36 35 34 33 32 31 08 08  08 08 0a      |654321.....|
0000000b

Busybox though behaves different. Extremely odd.
It seems then as some offset errors in busybox datasegment
for some reasons, since I get some text out from a completely
different string.

Denis Vlasenko wrote:
> On Monday 06 August 2007 10:35, Per Hallsmark wrote:
>> well... sometimes one can answer oneself... :)
>>
>> --- busybox-1.6.1.orig/libbb/lineedit.c 2007-06-30 17:06:40.000000000 +0200
>> +++ busybox-1.6.1/libbb/lineedit.c      2007-08-06 11:23:57.000000000 +0200
>> @@ -165,10 +165,12 @@
>>
>>          if (cmdedit_x >= num) {
>>                  cmdedit_x -= num;
>> +#if 0
>>                  if (num <= 4) {
>>                          printf("\b\b\b\b" + (4-num));
>>                          return;
>>                  }
>> +#endif
>>                  printf("\033[%uD", num);
>>                  return;
>>          }
>>
>>
>> With above patch backspace works ok.
>>
>> The \b\b... printf looks rather mystic... guess the author
>> perhaps wanted something like this instead?
>>
>> switch (num) {
>>    case 4:
>>      printf("\b");
>>      /* fall trough */
>>    case 3:
>>      printf("\b");
>>      /* fall trough */
>>    case 2:
>>      printf("\b");
>>      /* fall trough */
>>    case 1:
>>      printf("\b");
>>      return;
>>    default:
>> }
>>
>> but I wonder what the benefits are...
> 
> printf("\b\b\b\b" + (4-num));
> 
> does exactly the same in 4 times less code.
> If num==4, it does printf("\b\b\b\b" + 0) => printf("\b\b\b\b")
> If num==3, it does printf("\b\b\b\b" + 1) => printf("\b\b\b")
> If num==2, it does printf("\b\b\b\b" + 2) => printf("\b\b")
> If num==1, it does printf("\b\b\b\b" + 3) => printf("\b")
> etc
> 
> The benefits are that we send less bytes than with printf("\033[%uD", num);
> It's done primarily for the most common case: single [Backspace] key.
> It's silly to send ESC [ 1 D instead of single backspace char.
> 
> Now, I wonder why \b for you does not do what it should (that is,
> going back one char). Can you compile and run this test program?
> 
> int main(int argc, char **argv) {
>         printf("987654321\b\b\b\b" + argc);
>         fflush(0);
>         sleep(3);
>         puts("");
> }
> 
> When I run it, I see this:
> 
> # ./a.out
> 87654321   <---- cursor is under '4'
> # ./a.out 1
> 7654321    <---- cursor is under '4'
> # ./a.out 1 1
> 654321     <---- cursor is under '4'
> # ./a.out 1 1 | hexdump -vC
> 00000000  36 35 34 33 32 31 08 08  08 08 0a                 |654321.....|
> 0000000b
> 
> IOW, both printf("str" + n) and '\b' work right for me.
> 
> What do you see
> --
> vda




From per.hallsmark at t2data.se  Tue Aug  7 07:51:38 2007
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Tue, 07 Aug 2007 09:51:38 +0200
Subject: hush in arm nommu environment
In-Reply-To: <200708061510.25873.vda.linux@googlemail.com>
References: <46B6DA1E.1090502@t2data.se>
	<200708061510.25873.vda.linux@googlemail.com>
Message-ID: <46B8248A.2050703@t2data.se>

well... the exact same style is made in other places
for nommu portability.

I only have two scripts in my target, one rc and one
upgrade, both works fine starting background stuff etc.
They do some if's, starting background processes, variabel handling
and so on.

Since, with working backspace ;-), hush is such a better
solution than sash I'd rather stick with hush and take
eventual bugs/"nommu features" as they come.

So, while not perfect, it's better than other current
solutions at least for our usage.

Denis Vlasenko wrote:
> On Monday 06 August 2007 09:21, Per Hallsmark wrote:
>> Hi all,
>>
>> I've tried out the hush shell in busybox 1.6.1.
>> Seems to work fairly well with the patch last in
>> this mail.
> ...
>> --- busybox-1.6.1.orig/shell/hush.c     2007-06-30 17:06:37.000000000 +0200
>> +++ busybox-1.6.1/shell/hush.c  2007-08-02 15:41:22.000000000 +0200
>> @@ -658,7 +658,11 @@
>>          pid_t pid;
>>
>>          debug_printf_jobs("got tty sig %d in pid %d\n", sig, getpid());
>> +#if BB_MMU
>>          pid = fork();
>> +#else
>> +       pid = vfork();
>> +#endif
>>          if (pid < 0) /* can't fork. Pretend there was no ctrl-Z */
>>                  return;
>>          ctrl_z_flag = 1;
> 
> I'm afraid this maybe works for some simple scripts, but I'm sure as hell
> there are nasty bugs. Code does assume that after fork() we create
> new process. Simply replacing it with vfork is not going to work stably.
> --
> vda




From hinko.kocevar at cetrtapot.si  Tue Aug  7 07:38:50 2007
From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si)
Date: Tue, 07 Aug 2007 09:38:50 +0200
Subject: Httpd serve multiple pages
In-Reply-To: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>
References: <7c4904020708062151o62d20a64s474398d87713e117@mail.gmail.com>
Message-ID: <46B8218A.1090306@cetrtapot.si>

Jako Lee wrote:
> Hi all,
> 
> How do I serve multiple pages using httpd for a single user?

For me it works the same as on all other web servers - put them in the 
web root (or subdirs of web root) directory and navigate to that address.

> Right now I have a main page with a link to another page on
> my Linux directory. After logging in I can see the main page
> but when I click on the link it tell me that it can't find
> the server (both the main page and the linked page are in
> the same directory). However, if the link is set to "Google"
> or "Yahoo" homepage it will work fine.

Could you post your html pages so that we can take a look?

regards,
hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si



From alexander.griesser at lkh-vil.or.at  Tue Aug  7 12:00:08 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Tue, 07 Aug 2007 14:00:08 +0200
Subject: Again, troubles with uploading files using busybox httpd
Message-ID: <46B85EC8.1030800@lkh-vil.or.at>

Hi folks!

This one seems to be a duplicate of a previous bug report for bb
1.3.1/1.4.1, here's the link:

http://www.busybox.net/lists/busybox/2007-February/026289.html

Currently (latest svn version), I'm unable to upload files onto my
busybox installation running busybox httpd.

The problem is, that the `cat` command never finishes after it wrote
the uploaded file successfully to the temporary location, that means
uploading works, but after the upload has finished, `cat` doesn't quit.

I also tried `dd of=$TMPOUT` => didn't work either (hangs after upload
has finished).

As mentioned in the above link, I had a similar problem a few months ago
and have looked at the patch posted back then from Denis, but wasn't
able to merge it to the current httpd.c (don't even know if it would
have made sense ;) ).

Any ideas, what's going wrong here?

The sample cgi-script for uploading the file follows:

----------[ uploadconfig.cgi ] -------------------------

#!/bin/sh

# parameters:
# $1 - file destination
upload_file()
{
  TMPOUT=$(mktemp /tmp/XXXXXX)

  # upload the file to $TMPOUT
  cat >$TMPOUT

  # get the line count and remove the first 4 and the last 2 lines
  # of the uploaded file (these lines contain boundery and content-type
  # information only)
  LINE_COUNT=$(wc -l $TMPOUT | awk "-F " '{ print $1 }')
  if [ $LINE_COUNT -le 6 ]; then
    RETURN=1
  else
    UPPER_BOUND=$(( $LINE_COUNT - 4 ))
    LOWER_BOUND=$(( $UPPER_BOUND - 2 ))
    tail -n $UPPER_BOUND $TMPOUT | head -n $LOWER_BOUND > $1
    RETURN=$?
  fi

  rm -f $TMPOUT

  if [ "$RETURN" = "0" ]; then
    echo "<p class=\"statusok\">Upload successful.</p>"
  else
    echo "<p class=\"statusfail\">Error while uploading the file!</p>"
  fi

  return $RETURN
}


echo "<h2>Upload configuration file</h2>"

if [ "$REQUEST_METHOD" = "POST" ]; then
  if upload_file /system/etc/lxtc-config; then
    echo "<center><pre>"
    cat /system/etc/lxtc-config
    echo "</pre></center>"
  fi
else
  echo "<form name=\"test\" method=\"post\"
action=\"/cgi-bin/uploadconfig.cgi\" enctype=\"multipart/form-data\">"
  echo "<input type=\"file\" name=\"configfile\" maxlength=\"10240\" />"
  echo "<input type=\"submit\" value=\"Upload configuration file\" />"
  echo "</form>"
fi
---------------------------------- 8< --------------------

ciao,
-- 
Alexander Griesser (Netzwerkadministration)
E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at
KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach
Tel.:   +43 4242 208 3061 | Fax.:   +43 4242 971 3061


From farmatito at tiscali.it  Tue Aug  7 13:16:28 2007
From: farmatito at tiscali.it (Tito)
Date: Tue, 7 Aug 2007 15:16:28 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <46B8671B.3030107@bfs.de>
References: <46B60B7C.6080108@zastrow4u.de>
	<200708062300.56120.farmatito@tiscali.it> <46B8671B.3030107@bfs.de>
Message-ID: <200708071516.28795.farmatito@tiscali.it>

On Tuesday 07 August 2007 14:35:39 walter harms wrote:
> do you do unexpand also ?
> re,
>  wh
Hi,
i ignored the existence of expand/unexpand  :-) till yesterday....
If there is some interest I can try, or are you volunteering?

It should be possible to merge expand/unexpand into a single
applet (as long as we don't try to do the expand -t list files stuff)
but before attempting it I would like the current code to be 
better tested, debugged and optimized, as it is mostly untested.

Ciao,
Tito


From ml at zastrow4u.de  Tue Aug  7 19:14:09 2007
From: ml at zastrow4u.de (Alfred Zastrow)
Date: Tue, 07 Aug 2007 21:14:09 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <200708062300.56120.farmatito@tiscali.it>
References: <46B60B7C.6080108@zastrow4u.de>	<200708061511.32929.vda.linux@googlemail.com>	<46B76EDE.5020100@zastrow4u.de>
	<200708062300.56120.farmatito@tiscali.it>
Message-ID: <46B8C481.4080904@zastrow4u.de>

Tito schrieb:
> Hi,
> this is a first attempt to implement a stripped down version of expand.
> This version is only little tested so it may contain all sort of bugs.
> Hints, critics and help in testing and improving it is welcome. 

Thanks a lot, it works. I didn't compare the results in detail yet, but
compiling glibc-2.6.1 doesn't break anymore.

Will this patch go into the next busybox release?

regards
Alfred




From landau_alex at yahoo.com  Wed Aug  8 12:09:27 2007
From: landau_alex at yahoo.com (Alex Landau)
Date: Wed, 8 Aug 2007 05:09:27 -0700 (PDT)
Subject: [PATCH] httpd: Support "Status: " header in CGI script
Message-ID: <937796.3923.qm@web62503.mail.re1.yahoo.com>

Hi,

The attached patch adds to httpd support for a Status header.
This header (as per the CGI spec) is used by CGI scripts to ask the server to send an
HTTP response different than 200. Why is it needed, and why the script can't send the
"HTTP/1.0 302 Found" (or similar) by itself is beyond me...
PHP (at least in CGI mode) sends "Status: 302" and the appropriate Location when running
header('Location: something'). That was my motivation for the patch.

Due to efficiency and space considerations, when httpd receives a "Status: xxx" header it
sends "HTTP/1.0 xxx" without the textual code representation (e.g. "HTTP/1.0 302" instead
of "HTTP/1.0 302 Found"). This works at least with Firefox 2.0.0.6 on Linux and IE 6 on,
well..., Windows.
If you think it's worth it, I can add proper message ("Found" etc.) handling.

Alex


       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpd.patch
Type: text/x-patch
Size: 947 bytes
Desc: 4014077785-httpd.patch
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070808/f5c26d95/attachment-0002.bin 

From creder at digitalcpt.com  Wed Aug  8 20:39:08 2007
From: creder at digitalcpt.com (Christopher Reder)
Date: Wed, 8 Aug 2007 15:39:08 -0500
Subject: 'df' output
Message-ID: <011101c7d9fc$2b1dd5b0$2600a8c0@engineering5>

I am trying to figure out more information on the 'df' output and how it may
indicate how something is setup wrong with my kernel.  If this is the wrong
list to ask the question, I'll be glad to repost elsewhere.

 

If you look at the output below, you'll see that I have 1 mtd block setup on
a nand flash.  This flash is 256 MB.  You can see that in the iomem output
and in the mtd output.  However, when I run 'df', it shows the there is 5.7
Meg. 

 

I am wondering why it is and/or what it is looking at to see that when
everything else in the kernel is showing correctly.  If anyone can direct me
in the correct spot, or tell me to repost to a kernel list, I'll be glad to
do it.

 

major minor  #blocks  name

 

  31     0     262144 mtdblock0

 254     0    1985024 mmcblk0

 254     1    1983619 mmcblk0p1

# cat iomem

00300000-003fffff : at91_ohci

  00300000-003fffff : ohci_hcd

20000000-21ffffff : System RAM

  2002c000-202a1fff : Kernel text

  202a2000-202d0fd7 : Kernel data

40000000-4fffffff : at91_nand

80000000-8017ffff : FPGA video memory

  80000000-8017ffff : dcifb mem

80800000-80800004 : FPGA video registers

  80800000-80800004 : dcifb regs

fefbc000-fefbffff : at91_ether

fefff200-fefff3ff : atmel_usart.0

  fefff200-fefff3ff : atmel_serial

fffb4000-fffb7fff : at91_mci

  fffb4000-fffb7fff : at91_mci

fffe0000-fffe3fff : at91_spi.0

  fffe0000-fffe3fff : at91_spi

# cat mtd

dev:    size   erasesize  name

mtd0: 10000000 00020000 "NAND1"

# df

Filesystem                Size      Used Available Use% Mounted on

/dev/mtdblock0            5.7M      3.3M      2.4M  58% /

#

 

 

static struct mtd_partition __initdata dci_nand_partition[] = {

{

.name   = "NAND1",

.offset   = 0,

.size     = MTDPART_SIZ_FULL,

},

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070808/da70cd00/attachment-0002.htm 

From farmatito at tiscali.it  Thu Aug  9 06:27:07 2007
From: farmatito at tiscali.it (Tito)
Date: Thu, 9 Aug 2007 08:27:07 +0200
Subject: [PATCH] applet-request: expand
In-Reply-To: <200708062300.56120.farmatito@tiscali.it>
References: <46B60B7C.6080108@zastrow4u.de> <46B76EDE.5020100@zastrow4u.de>
	<200708062300.56120.farmatito@tiscali.it>
Message-ID: <200708090827.07423.farmatito@tiscali.it>

On Monday 06 August 2007 23:00:56 Tito wrote:
> Hi,
> this is a first attempt to implement a stripped down version of expand.
> This version is only little tested so it may contain all sort of bugs.
> Hints, critics and help in testing and improving it is welcome. 
> 
> bloat-o-meter (after make defconfig and enabling the expand applet) says:
> function                                             old     new   delta
> expand_main                                            -     437    +437
> .rodata                                           121357  121485    +128
> packed_usage                                       22558   22660    +102
> applets                                             3108    3120     +12
> ------------------------------------------------------------------------------
> (add/remove: 1/0 grow/shrink: 3/0 up/down: 679/0)             Total: 679 bytes
> 
> Usage is: expand  [-i] [-t NUM] [FILE | -]
> 
>  *  Options:
>  *  -t num		Convert tabs to num spaces (default 8 spaces).
>  *
>  *              Caveat: this version doesn't accept tab lists and
>  *              therefore isn't conform to The Open Group Base 
>  *              Specifications Issue 6.
>  *
>  *  -i			Only convert initial tabs on each line to spaces.
> 
> Ciao,
> Tito
> 

Hi Denis,
please don't apply this patch fro the moment,
I'm working on an improved one with less bugs,
tests for our test suite and also unexpand.
Need a few days for it.

Ciao,
Tito



From vda.linux at googlemail.com  Thu Aug  9 07:53:02 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 9 Aug 2007 08:53:02 +0100
Subject: udhcp lease bug
In-Reply-To: <f98hp2$7c8$1@sea.gmane.org>
References: <f98hp2$7c8$1@sea.gmane.org>
Message-ID: <200708090853.02188.vda.linux@googlemail.com>

On Tuesday 07 August 2007 02:26, David Updegraff wrote:
> Hi.
> 
> udhcp keeps sending out same IPs to diff. macs w/o this patch when a
> bunch boot at the same time.  Annoying.

Thanks for finding it. Fixed in svn.
--
vda


From alexander.griesser at lkh-vil.or.at  Thu Aug  9 08:00:43 2007
From: alexander.griesser at lkh-vil.or.at (Alexander Griesser)
Date: Thu, 09 Aug 2007 10:00:43 +0200
Subject: Again, troubles with uploading files using busybox httpd
In-Reply-To: <46B85EC8.1030800@lkh-vil.or.at>
References: <46B85EC8.1030800@lkh-vil.or.at>
Message-ID: <46BAC9AB.6010600@lkh-vil.or.at>

-----BEGIN PGP SIGNED ME