[Top] [All Lists]

Re: [PATCH][MIPS][2/7] AR7: mtd partition map

To: Christoph Hellwig <>
Subject: Re: [PATCH][MIPS][2/7] AR7: mtd partition map
From: Jörn Engel <>
Date: Thu, 20 Sep 2007 22:00:59 +0200
Cc: Matteo Croce <>,, Felix Fietkau <>, Eugene Konev <>,, Andrew Morton <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <>
User-agent: Mutt/1.5.9i
On Thu, 20 September 2007 21:35:49 +0200, Christoph Hellwig wrote:
> On Thu, Sep 20, 2007 at 09:29:11PM +0200, Matteo Croce wrote:
> > +#define LOADER_MAGIC1      0xfeedfa42
> > +#define LOADER_MAGIC2      0xfeed1281
> > +#else
> > +#define LOADER_MAGIC1      0x42faedfe
> > +#define LOADER_MAGIC2      0x8112edfe
> > +#endif
> Please keep only one defintion and use le/be32_to_cpu on it.
> > +struct ar7_bin_rec {
> > +   unsigned int checksum;
> > +   unsigned int length;
> > +   unsigned int address;
> > +};
> Wich means you'd need an endianess annotation here.  What about the
> length and address fields, are they always native-endian unlike
> the checksum field or will the need to be byte-swapped aswell?

<slightly off-topic, feel free to skip>
If this is indeed the squashfs magic, le/be32_to_cpu won't help.
Squashfs can have either endianness, tries to detect the one actually
used by checking either magic and sets a flag in the superblock.
Afterwards every single access checks the flag and conditionally swaps
fields around or not.

If squashfs had a fixed endianness, quite a lot of this logic could get
removed and both source and object size would shrink.  Some two years
after requesting this for the first time, I'm thinking about just doing
it myself.  If I find a sponsor who pays me for it, I might even do it

I don't really understand why the squashfs magic number should be used
in this code at all.  It may have set a bad example, though.  In general
you should decide on a fixed endianness (1) and use the beXX_to_cpu
macros when accessing data unless you have a very good reason to do

1) Big endian is my preferred choice because it is easy to read in a
hexdump and the opposite of my notebook.  Being forced to do endian
conversions during development/testing helps to find problems early.


Joern's library part 13:

<Prev in Thread] Current Thread [Next in Thread>