On Monday 11 July 2011 17:45, Bob Dunlop wrote:
> Hi,
>
> I've been chasing an intermittent problem with busybox's fdisk
> implementation. About one command in ten was failing on me when used
> with slow external USB disks on a 320MHz ARM system. The BLKRRPART
> ioctl was returning device busy.
On Wed, Jul 13, 2011 at 07:28:37AM +0200, Denys Vlasenko wrote:
> Yes, I think the approach this patch takes is not sustainable.
>
> History is a small file. If your flash fs and hardware can't cope
> even with periodic updates of a small file, then how it copes with
> other real-world cases?
>
>
On Sunday 10 July 2011 22:33, Kevin Cernekee wrote:
> On Fri, Jul 8, 2011 at 12:33 AM, Denys Vlasenko
> wrote:
> > There is probably no deep wisdom behind it. I think second #ifdef
> > should be changed to #ifdef VT_GETSTATE, it will make more sense that way.
>
> Here are a few patches to impleme
Denys,
>On Tuesday 31 May 2011 17:37, Nigel Hathaway wrote:
>> Package: busybox
>> Version: v1.18.4
>> Severity: low
>>
>> This patch applies on top of my previous VLAN and numeric DHCP option
>> >recognition patch.
>>
>> Whist this previous patch allows you to have DHCP options that are >unkno
On Wed, Jul 13 at 09:04, Denys Vlasenko wrote:
> On Monday 11 July 2011 17:45, Bob Dunlop wrote:
> > I traced it to a commented out sleep(2) in fdisk.c. With the sleep
> > reinstated fdisk is reliable.
>
> What is the minimum usleep(MICROSEC) it works for you?
>From previous post with the loop t
On 07/13/2011 07:28 AM, Denys Vlasenko wrote:
On Tuesday 12 July 2011 20:14, Laurent Bercot wrote:
BusyBox writes to .ash_history after each and every command, which we don't
want on e.g. mobile devices with a flash-based storage device.
Using a buffer helps reducing the amount of erase/write cy
On 07/13/2011 09:09 AM, Dan Fandrich wrote:
Or, what about just setting a large buffer on the history file stream
with setbuffer()?
Thanks for the suggestion, I'll look into this. I hadn't thought of
using anything like this yet.
I have a feeling that the resulting patch would be more complex (o
> I agree with both of you that patching every application is a no-go.
> However, a lot of flash based storage mediums are exposed as block
> devices nowadays, thus UBI can't always be used.
Specialized filesystems such as jffs2 or yaffs2 still can, however.
> isn't exactly ideal. Tweaking th
On 07/13/2011 03:13 PM, Laurent Bercot wrote:
Specialized filesystems such as jffs2 or yaffs2 still can, however.
Good point, but a lot of, for example closed, embedded/mobile devices
require a lot of hacking around to get something custom (like a
different fs) running.
Why shouldn't it be
On Wed, Jul 13, 2011 at 12:31 AM, Denys Vlasenko
wrote:
> + ssize_t s =
> open_read_close("/sys/class/tty/console/active",
> + &console[5], sizeof(console) - 5);
> + if (s > 0) {
> + /* found a
On Wed, Jul 13, 2011 at 8:10 AM, Kevin Cernekee wrote:
> On Wed, Jul 13, 2011 at 12:31 AM, Denys Vlasenko
> wrote:
>> + ssize_t s =
>> open_read_close("/sys/class/tty/console/active",
>> + &console[5], sizeof(console) - 5);
>> +
On 13/07/2011, at 10:52 PM, Dennis Groenen wrote:
> On 07/13/2011 07:28 AM, Denys Vlasenko wrote:
>> On Tuesday 12 July 2011 20:14, Laurent Bercot wrote:
BusyBox writes to .ash_history after each and every command, which we don't
want on e.g. mobile devices with a flash-based storage dev
On 13/07/2011, at 4:38 PM, Natanael Copa wrote:
> On Tue, Jul 12, 2011 at 9:07 AM, Denys Vlasenko
> wrote:
>> On Monday 11 July 2011 17:46, kyak wrote:
>>>
>>> If someone is interested, he can take it from here.
>>> Though i don't see that someone is too much interested in this patch.
>>> Especi
13 matches
Mail list logo
