public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Artem B. Bityutskiy" <dedekind@yandex.ru>
Cc: Linux MTD <linux-mtd@lists.infradead.org>
Subject: Re: Another compiler error: sumtool.c
Date: Thu, 22 Sep 2005 08:41:04 +0200	[thread overview]
Message-ID: <20050922064104.GM8421@lunn.ch> (raw)
In-Reply-To: <43324D42.5060407@yandex.ru>

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

  reply	other threads:[~2005-09-22  6:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21 21:13 Another compiler error: sumtool.c Andrew Lunn
2005-09-22  6:20 ` Artem B. Bityutskiy
2005-09-22  6:41   ` Andrew Lunn [this message]
2005-09-22  6:50     ` Artem B. Bityutskiy
2005-09-22  9:40       ` Ferenc Havasi
2005-09-22  9:50         ` Artem B. Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050922064104.GM8421@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=dedekind@yandex.ru \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox