All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matteo Croce <technoboy85@gmail.com>
To: "Jörn Engel" <joern@logfs.org>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-mips@linux-mips.org, Felix Fietkau <nbd@openwrt.org>,
	Eugene Konev <ejka@imfi.kspu.ru>,
	linux-mtd@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	dwmw2@infradead.org
Subject: Re: [PATCH][MIPS][2/7] AR7: mtd partition map
Date: Fri, 21 Sep 2007 04:09:22 +0200	[thread overview]
Message-ID: <200709210409.23521.technoboy85@gmail.com> (raw)
In-Reply-To: <20070920200058.GB1692@lazybastard.org>

Il Thursday 20 September 2007 22:00:59 Jörn Engel ha scritto:
> 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:
> > > +#ifdef CONFIG_CPU_LITTLE_ENDIAN
> > > +#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
> soon.
> </offtopic>
> 
> 
> 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
> otherwise.
> 
> 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.

I use little endian since 99% of AR7s are little endian. Dunno if
le/be32_to_cpu does some runtime calculations. Do they?

WARNING: multiple messages have this Message-ID (diff)
From: Matteo Croce <technoboy85@gmail.com>
To: "Jörn Engel" <joern@logfs.org>
Cc: linux-mips@linux-mips.org, Felix Fietkau <nbd@openwrt.org>,
	Eugene Konev <ejka@imfi.kspu.ru>,
	linux-mtd@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	dwmw2@infradead.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH][MIPS][2/7] AR7: mtd partition map
Date: Fri, 21 Sep 2007 04:09:22 +0200	[thread overview]
Message-ID: <200709210409.23521.technoboy85@gmail.com> (raw)
In-Reply-To: <20070920200058.GB1692@lazybastard.org>

Il Thursday 20 September 2007 22:00:59 Jörn Engel ha scritto:
> 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:
> > > +#ifdef CONFIG_CPU_LITTLE_ENDIAN
> > > +#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
> soon.
> </offtopic>
> 
> 
> 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
> otherwise.
> 
> 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.

I use little endian since 99% of AR7s are little endian. Dunno if
le/be32_to_cpu does some runtime calculations. Do they?

  reply	other threads:[~2007-09-21  2:09 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-20 15:28 [PATCH][MIPS][0/7] AR7: 4th effort Matteo Croce
2007-09-20 15:43 ` [PATCH][MIPS][1/7] AR7: core support Matteo Croce
2007-09-21  1:57   ` Matteo Croce
2007-09-22 16:18   ` Atsushi Nemoto
2007-09-20 15:55 ` [PATCH][MIPS][2/7] AR7: mtd partition map Matteo Croce
2007-09-20 15:55   ` Matteo Croce
2007-09-20 16:53   ` Ralf Baechle
2007-09-20 16:53     ` Ralf Baechle
2007-09-20 17:52   ` Christoph Hellwig
2007-09-20 17:52     ` Christoph Hellwig
2007-09-20 18:34     ` Matteo Croce
2007-09-20 18:34       ` Matteo Croce
2007-09-20 19:29       ` Matteo Croce
2007-09-20 19:29         ` Matteo Croce
2007-09-20 19:35         ` Christoph Hellwig
2007-09-20 19:35           ` Christoph Hellwig
2007-09-20 20:00           ` Jörn Engel
2007-09-20 20:00             ` Jörn Engel
2007-09-21  2:09             ` Matteo Croce [this message]
2007-09-21  2:09               ` Matteo Croce
2007-09-21  2:20               ` Jörn Engel
2007-09-21  2:20                 ` Jörn Engel
2007-09-21  8:03               ` Christoph Hellwig
2007-09-21  8:03                 ` Christoph Hellwig
2007-09-21  8:18         ` Geert Uytterhoeven
2007-09-21  8:18           ` Geert Uytterhoeven
2007-09-20 16:00 ` [PATCH][MIPS][3/7] AR7: gpio char device Matteo Croce
2007-09-22 16:42   ` Atsushi Nemoto
2007-09-22 18:59     ` David Brownell
2007-09-23 15:47       ` Atsushi Nemoto
2007-09-20 16:03 ` [PATCH][MIPS][4/7] AR7: leds driver Matteo Croce
2007-09-20 22:54   ` Richard Purdie
2007-09-20 16:06 ` [PATCH][MIPS][5/7] AR7: watchdog timer Matteo Croce
2007-10-03 19:24   ` Wim Van Sebroeck
2007-10-03 20:17     ` Matteo Croce
2007-10-07 20:31       ` Wim Van Sebroeck
2007-09-20 16:11 ` [PATCH][MIPS][6/7] AR7: serial hack Matteo Croce
2007-09-20 16:13 ` [PATCH][MIPS][7/7] AR7: ethernet Matteo Croce
2007-09-29  5:39   ` Jeff Garzik
     [not found] <200709080143.12345.technoboy85@gmail.com>
2007-09-08  0:19 ` [PATCH][MIPS][2/7] AR7: mtd partition map Matteo Croce
2007-09-08  0:19   ` Matteo Croce

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=200709210409.23521.technoboy85@gmail.com \
    --to=technoboy85@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dwmw2@infradead.org \
    --cc=ejka@imfi.kspu.ru \
    --cc=hch@lst.de \
    --cc=joern@logfs.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nbd@openwrt.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.