[ECOS] JFFS2 Or Compiler Issue.

["Ramgopal Kota" <rkota at broadcom dot com>]

Hi,

I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue.
In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below 

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

struct jffs2_unknown_node
{
  /* All start like this */
  jint16_t magic;
  jint16_t nodetype;
  jint32_t totlen; /* So we can skip over nodes we don't grok */
  jint32_t hdr_crc;
} __attribute__((packed));

I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER.

If I change the code to the following it is working fine...

struct jffs2_unknown_node marker = {
      .magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK),
      .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), 
      .totlen = cpu_to_je32(c->cleanmarker_size)
    };

marker.magic =  cpu_to_je16(JFFS2_MAGIC_BITMASK);

I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag.
I am attaching the specs for the compiler I am using.
Compiler I am using is gcc version 3.2.1 (eCosCentric)

Thanks & Regards,
Ramgopal Kota

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Alex Schuilenburg
Sent: Tuesday, September 22, 2009 4:12 AM
To: Sergei Organov
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Re: Switching to using git on eCosForge

Sergei Organov wrote:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
> [...]
>   
>> My main argument against git is it has a very steep initial learning
>> curve,
>>     
> Really? Not in my experience. 
Yes, really, and not only my experience either. I guess I must be below
the curve on learning new technology, but then it could also be my age ;-)


> IMHO, those 3 we discuss are roughly the
> same, just having raw corners in different places. E.g., there is even a
> table of commands equivalence between hg and git somewhere.
>   
Several places actually.  And yes, functionality on each is roughly the
same.

>   
>> and from experience you can hang yourself if you do not know what
>> you are doing.  (Yes, there are rollbacks, etc, but sometimes it is a
>> while down the line before you realise you did something wrong).
>>     
>
> It's a very nice thing with git that it's virtually impossible to loose
> your work as soon as you committed it to git, really, even if you keep
> doing something wrong. Even though nowadays git does automatically run
> garbage collection, the reflog feature still keeps all unreferenced data
> intact for rather long time.
>
>   
And yes, functionality on each is roughly the same.  I think we should
stop going round in circles.  We appear to agree all three have similar
functionality. If you want a contest on which is the most powerful, I
will save you the trouble. git is currently the most powerful.  If you
want an example of a powerful feature git has that is harder to do in
the others, let me save you the trouble again: git commit --amend (in hg
if the commit is buried you will need to have been using queues and will
have to export changesets, fix and re-import - more painful, but
achievable). 

However, I would point out again that all three borrow from the others,
so evaluating is always going to be a moving target.
>> You really don't want to force new users on an additional learning
>> curve. There are 100's of commands to remember, whereas both bzr and
>> hg have one.
>>     
>
> Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only
> one as well: 'git' ;-)
>
> One does need additional learning curve switching from CVS to any of
> DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again,
> with git you can have gitcvsserver running to keep "CVS forever"
> users happy with their favorite clients.
>   
% ls -l /usr/bin/git-* | wc -l
136
%

and I only have git-core installed on that machine...

FWIW I already had come upto speed with DRCS with bzr and hg before I
played with git. Figuring out which command to use to do a specific task
without resorting to a manual was my initial stumbling block - I just
initially felt somewhat overwhelmed.  bzr and hg seemed easier to pick
up and start using where with git I was never quite sure if I was using
the correct options.  Too many bells and whistles I guess which was
compounded by not easily being able to find pointers to assure me I was
doing the right thing. Hence I never quite felt comfortable using git in
the beginning.  But of course this is a subjective opinion - YMMV.


>> Also, while documentation is improving (http://book.git-scm.com/), it is
>> not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
>> in terms of non-power users.  Both have books in print available from
>> places like Amazon.
>>     
>
> For me git's documentation was more than enough to have a quick-start.
>
>   
>> For example, I started my evaluation with bzr, then hg then git. bzr and
>> hg were a lot easiest to pick up and start using than git.
>>     
>
> I wonder, do you remember what the problem(s) with git was (were)? Care
> to give an example where git is harder than any of the other two?
>   
I never said I had problems doing things in git - I said I had problems
finding out how to do them. Tell me with a straight face that the number
of options in some of the git commands did not overwhelm you the first
time you saw them?

When you want to encourage community development, you really need to
keep it simple for developers to keep abreast of advances and contribute
back. Not have so many bells and whistles that they feel like they
should not touch anything in case it breaks, or worse, have someone who
thinks they know what they are doing but does not.

>   
>> I also have done most of my eval on Linux, dropping back to Windows to
>> see how easy it was to use and integrate graphical diff tools, etc.
>>
>> For other comparisons see:
>> http://code.google.com/p/support/wiki/DVCSAnalysis
>> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
>> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
>> http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands
>> http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
>> http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29
>> ...
>>
>> but bear in mind that arguments against either git or hg may have
>> disappeared with more recent versions.  You really need to try both...
>>     
>
> Yes, all 3 are improving and do borrow from each other. However, in my
> opinion, git is preferred in the long run as it has very clear, simple
> yet powerful model in its core, when hg already outlived its initial
> simple design model based on "every branch is a separate repository"
> idea (now it has 3(!) different kinds of branches), and bzr is being
> built from use-cases down (see how many times they have already changed
> format of repository). Yes, sure, me could be entirely wrong ;-)
>   
Not entirely wrong ;-)   When working with branches ever run "git
submodule update" when you've made and committed changes within a
submodule without checking out the branch first, only to discover later
that the changes were silently overwritten?

However, I strongly disagree with your comment "hg already outlived its
initial simple design..." though.  hg's design is just as simple as git
and there is nothing in hg's design IMHO that limits what it can do. It
is still evolving, just like git and eCos. The forests extension has
been around just as long as sub-modules AFAIKT, but I admit it is taking
a while for hg to make it part of their core functionality.

I am sure we can equally find flaws in the others preferred DRCS just as
we can find features...   

And defintely yes, all three borrow from each other, even documentation
in the case of git ;-)  http://cworth.org/hgbook-git/tour/).  But IMHO
hg still has stronger documentation and is easier for newcomers to start
with.

Anyway, it is good to have an alternative view on what the best choice
of DRCS for eCos is.  I guess you and I can agree to disagree on what
that choice should be though, and let others tell us what they think ;-)

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Attachment: 1.txt;size=8342;creation-date="Mon,
Description: 1.txt

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss