On Wednesday 19 November 2008 05:17, Hamish Moffatt wrote:
> I just switched from busybox 1.11.2 to 1.13.0 for a project and now kernel
> message logging seems a bit busted. It starts ok but then goes wrong.
> Application logging seems to work ok still (see the last 5 lines of this
> example).
>
I suspect strcpy vs memmove.
Try this patch and let me know if it helps.
Cheers,
Steve
On 19/11/2008, at 2:17 PM, Hamish Moffatt wrote:
I just switched from busybox 1.11.2 to 1.13.0 for a project and now
kernel
message logging seems a bit busted. It starts ok but then goes wrong.
Applicatio
I just switched from busybox 1.11.2 to 1.13.0 for a project and now kernel
message logging seems a bit busted. It starts ok but then goes wrong.
Application logging seems to work ok still (see the last 5 lines of this
example).
I backed out rev 23583 and now it works again.
Viewing whole files o
On Tue, Nov 18, 2008 at 10:21:13AM -0700, Bernhard Reutner-Fischer wrote:
> On Tue, Nov 18, 2008 at 06:08:21PM +0100, Alexander Surma wrote:
> >Hi list,
> >
> >I'm debugging my own little distribution (if you can call it that already)
> >- the initramfs to be specific.
> >My script for the creation
On Tue, Nov 18, 2008 at 10:06:47PM +0100, Tito wrote:
>On Tuesday 18 November 2008 20:01:59 Matthew Hiles wrote:
>> Hello Busybox mailing list:
>>
>> I just joined the mailing list because I'm interested in helping out
>> with busybox.
>>
>> I've been reading TODOs and the bug tracker to find out
On Tuesday 18 November 2008 20:01:59 Matthew Hiles wrote:
> Hello Busybox mailing list:
>
> I just joined the mailing list because I'm interested in helping out
> with busybox.
>
> I've been reading TODOs and the bug tracker to find out what I can do.
> I'm not sure how opposed everyone is to fea
Hello Busybox mailing list:
I just joined the mailing list because I'm interested in helping out
with busybox.
I've been reading TODOs and the bug tracker to find out what I can do.
I'm not sure how opposed everyone is to feature creep, as I'm sure
it's an issue, but one thing that always bothere
hi list,
i was trying the lasted vi and found the old bug i found in this summer still
alive.
how to reproduce
*compile vi with ENABLE_FEATURE_VI_SETOPTS
*start vi
*choose insert mode
*type
use clip&paste to repeat that often
vi will intend the line to the right.
after some time vi crashes in th
Hello Alex,
Alexander Surma wrote:
>> I don't think that you need such a thing in the first place.
>> Short of booting with init=/bin/sh, just ln -s /bin/busybox /linuxrc
>>
> Problem is, that a initramfs (in contrast to initrd) ignores the init
> parameter (at least so it says in the kernel d
>
> Hm, I didn't mind the Job Control warning, I don't need background
> processes while debugging.
It is namely while debugging when any additional controlling feature is of
greater value :) IMHO.
Regards,
--
Vladimir
___
busybox mailing list
busybox@
> I don't think that you need such a thing in the first place.
> Short of booting with init=/bin/sh, just ln -s /bin/busybox /linuxrc
Problem is, that a initramfs (in contrast to initrd) ignores the init
parameter (at least so it says in the kernel documentation) and when I
tried using it, it didn'
>> is nothing else as a mapping of the
>> init-call to the default shell, so that instead of running init you are
>> being dropped to a shell.
>
> This leads to well-known "Job control" issues. cttyhack wrapper should be
> used.
Hm, I didn't mind the Job Control warning, I don't need background
pr
>
> So we should implicitly add IN_IGNORED to the watching mask regardless the
> user specified it on not. Then, after we have wait()ed for the agent, we
> should check whether IN_IGNORED is in received event mask, and exit if it
> is. Right?
>
Denys, please, take a look. May be so: http://drvv.ru
>
> is nothing else as a mapping of the
> init-call to the default shell, so that instead of running init you are
> being dropped to a shell.
This leads to well-known "Job control" issues. cttyhack wrapper should be
used.
> < USE_ASH(APPLET_ODDNAME(init, ash, _BB_DIR_SBIN, _BB_SUID_ALWAYS, ash)
On Tue, Nov 18, 2008 at 06:08:21PM +0100, Alexander Surma wrote:
>Hi list,
>
>I'm debugging my own little distribution (if you can call it that already)
>- the initramfs to be specific.
>My script for the creation of a initramfs uses busybox, and I want a add a
>certain FakeInit (as I call it), whi
Hi list,
I'm debugging my own little distribution (if you can call it that already)
- the initramfs to be specific.
My script for the creation of a initramfs uses busybox, and I want a add a
certain FakeInit (as I call it), which is nothing else as a mapping of the
init-call to the default shell,
this is a cleanup patch that does not change code only rearrange it.
the whole idea is to have better readable code.
all size changes are due to the compiler.
NTL it would be nice if someone who used IPV6 could confirm that is still works.
size interface.o.new interface.o
textdata bss
El Tue, Aug 19, 2008 at 04:26:26PM +0200 Bernhard Reutner-Fischer ha dit:
> On Tue, Aug 19, 2008 at 03:58:12PM +0200, Matthias Kaehlcke wrote:
> >Hi Bernhard,
> >
> >El Tue, Aug 19, 2008 at 01:57:13PM +0200 Bernhard Reutner-Fischer ha dit:
> >
> >> ...
> >>
> >> Care to resend?
> >
> >thanks for y
>
> it's a better way to catch all other weird ways inode can disappear by
> watching specifically
> for IN_IGNORED
>
> Since watching after IN_IGNORED is pointless, exiting after this
> might be useful for largish group of users.
So we should implicitly add IN_IGNORED to the watching mask regard
19 matches
Mail list logo
