Another compiler error: sumtool.c

[Ferenc Havasi]

Hi Andrew,

Thanks for warning. You are right, making target_endian to non-static is
a correct fix. I've commited it. We are using GCC 3.3.5, and it did not
warned us. I suppose you use newer GCC.

Artem B. Bityutskiy wrote:

> Andrew Lunn wrote:
>
>> Could you define small.
>
> No, I cannot. This must be found out experimentally. I just warned you
> about possible EBS effect.
>
>> I will be checking this anyway. I need to improve the mount time
>> performance of eCos's version of JFFS2. For the system i'm working on
>> now the eCos redboot loader has JFFS2 from CVS from a year or so
>> ago. It takes four or five times longer to mount the filesystem than
>> the JFFS2 code in the Linux 2.4.x version of the kernel redboot is
>> booting. For the particular application this device is being used in i
>> need very fast boot times and currently the RedBoot JFFS2 mount is the
>> bottleneck. So i was hopeing that bringing JFFS2 up to date in eCos's
>> Redboot and adding EBS might match the performance of the old 2.4.x
>> code. Testing will soon tell.
>
>
> EBS makes mount really faster. But then the JFFS2 checker is working,
> and in case of NOR+EBS it will work longer and eat more CPU. JFFS2
> writers are blocked while the checker is working, so it may slow down
> the boot process. That's the theory, experiments are needed.
>
Artem, I think you have a little bit negative attitude against
summary/EBS. :) You are right, we should write docs for summary, and we
will do it soon.

Just for information: EBS was mainly designed for NAND, because JFFS2
was designed for NOR, and produces very very slow mounting on big NAND
chips. The idea is simple, and it seems to cause mount speed up at NOR,
too. We've got many positive feedbacks. The price of the using EBS at
NOR is to disable the obsolating method of NOR and apply the one used on
NAND. I don't think it cause too much CPU penalty in normal usage, at
least nobody complained of it.

Bye,
Ferenc