Another compiler error: sumtool.c

Another compiler error: sumtool.c

[Andrew Lunn]

Hi Folks

Thanks to Artem's fix i can now compile jffs2 without write buffer
support. However the sumtool does not compile.....

lunn@londo:~/pkgs/mtd/mtd/util$ make
gcc -I../include -O2 -Wall -g -c -o sumtool.o sumtool.c -g -Wp,-MD,.sumtool.c.dep
sumtool.c:66: error: static declaration of 'target_endian' follows non-static declaration../include/mtd/jffs2-user.h:22: error: previous declaration of 'target_endian' was here
make: *** [sumtool.o] Error 1

The easy fix is to make target_endian not static in sumtool.c, but is
that the correct fix?

        Thanks
                Andrew

Re: Another compiler error: sumtool.c

[Artem B. Bityutskiy]

Andrew Lunn wrote:
> Hi Folks
> 
> Thanks to Artem's fix i can now compile jffs2 without write buffer
> support. However the sumtool does not compile.....
> 
> lunn@londo:~/pkgs/mtd/mtd/util$ make
> gcc -I../include -O2 -Wall -g -c -o sumtool.o sumtool.c -g -Wp,-MD,.sumtool.c.dep
> sumtool.c:66: error: static declaration of 'target_endian' follows non-static declaration../include/mtd/jffs2-user.h:22: error: previous declaration of 'target_endian' was here
> make: *** [sumtool.o] Error 1

Hmm, I did not enable EBS and did not test how it works. If you have 
small NOR flash, don't use EBS. EBS may make things worse on small NORs 
- both because of wasting space and because NOR+EBS looks like NAND for 
JFFS2 (jffs2_can_mark_obsolete() is 0 at os-linux.h), which leads to 
greater CPU load on mount (much more nodes to check). I believe Ferenc 
should write about this in a Readme file or in the EBS config help.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: Another compiler error: sumtool.c

[Andrew Lunn]

On Thu, Sep 22, 2005 at 10:20:50AM +0400, Artem B. Bityutskiy wrote:
> Andrew Lunn wrote:
> >Hi Folks
> >
> >Thanks to Artem's fix i can now compile jffs2 without write buffer
> >support. However the sumtool does not compile.....
> >
> >lunn@londo:~/pkgs/mtd/mtd/util$ make
> >gcc -I../include -O2 -Wall -g -c -o sumtool.o sumtool.c -g 
> >-Wp,-MD,.sumtool.c.dep
> >sumtool.c:66: error: static declaration of 'target_endian' follows 
> >non-static declaration../include/mtd/jffs2-user.h:22: error: previous 
> >declaration of 'target_endian' was here
> >make: *** [sumtool.o] Error 1
> 
> Hmm, I did not enable EBS and did not test how it works. If you have 
> small NOR flash, don't use EBS. EBS may make things worse on small NORs 
> - both because of wasting space and because NOR+EBS looks like NAND for 
> JFFS2 (jffs2_can_mark_obsolete() is 0 at os-linux.h), which leads to 
> greater CPU load on mount (much more nodes to check). I believe Ferenc 
> should write about this in a Readme file or in the EBS config help.

Could you define small.

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.

        Thanks
                Andrew

Re: Another compiler error: sumtool.c

[Artem B. Bityutskiy]

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.


-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: 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

Re: Another compiler error: sumtool.c

[Artem B. Bityutskiy]

Dear Ferenc,

Ferenc Havasi wrote:
>>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.
No, beleave me! :-) I am actually fond of it as it improves JFFS2 
scalability. I'm just being strict.

> 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.
May be you did not notice, I said EBS *may* be slow for *small* NOR 
flashes. This means it should be OK for large ones. How small - no idea. 
Just off the top of my head - may be 8-16 MB. I explained why I think so 
- if you don't agree - complain please :-). Don't take any offense 
please :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.