All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: Joao Marcos Costa <joaomarcos.costa@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	u-boot@lists.denx.de
Subject: Re: [PATCH] squashfs: Fix compilation on big endian systems
Date: Thu, 7 Apr 2022 11:54:55 +0200	[thread overview]
Message-ID: <20220407115455.265f0cf3@xps13> (raw)
In-Reply-To: <20220407094159.ntw7vt5mcmdtmfp6@pali>

Hi Pali,

pali@kernel.org wrote on Thu, 7 Apr 2022 11:41:59 +0200:

> On Thursday 07 April 2022 09:54:21 Miquel Raynal wrote:
> > Hi Pali,
> > 
> > pali@kernel.org wrote on Wed,  6 Apr 2022 23:31:53 +0200:
> > 
> > Would you mind explaining a little bit how this change fixes it? It
> > does not look straightforward to me.  
> 
> Yes! I though that it is straightforward this change...
> byteorder/little_endian.h defines cpu_to_le* macros for Little Endian
> systems and byteorder/big_endian.h for Big Endian systems.
> 
> File asm/byteorder.h is then ARCH-specific and implements macros for the
> current architecture (by including the correct header file).
> 
> So currently if you try to compile squashfs for big endian systems you
> get compile error:
> 
>   In file included from ./arch/powerpc/include/asm/byteorder.h:82,
>                    from include/linux/unaligned/access_ok.h:4,
>                    from ./arch/powerpc/include/asm/unaligned.h:9,
>                    from fs/squashfs/sqfs_filesystem.h:11,
>                    from fs/squashfs/sqfs_dir.c:16:
>   include/linux/byteorder/big_endian.h:34: warning: "__cpu_to_le32" redefined
>    #define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
> 
>   In file included from fs/squashfs/sqfs_dir.c:10:
>   include/linux/byteorder/little_endian.h:34: note: this is the location of the previous definition
>    #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
> 
> Or:
> 
>   In file included from fs/squashfs/sqfs.c:14:
>   include/linux/byteorder/little_endian.h:89:21: error: redefinition of ‘__be16_to_cpup’
>    static inline __u16 __be16_to_cpup(const __be16 *p)
>                        ^~~~~~~~~~~~~~
>   In file included from ./arch/powerpc/include/asm/byteorder.h:82,
>                    from include/linux/unaligned/access_ok.h:4,
>                    from ./arch/powerpc/include/asm/unaligned.h:9,
>                    from fs/squashfs/sqfs.c:10:
>   include/linux/byteorder/big_endian.h:89:21: note: previous definition of ‘__be16_to_cpup’ was here
>    static inline __u16 __be16_to_cpup(const __be16 *p)
>                        ^~~~~~~~~~~~~~
> 
> As some header files include correct asm/byteorder.h file and this
> squashfs includes additional little_endian.h.

Great, thanks for the thorough explanation. Based on what you said,
wouldn't it be cleaner to just get rid of the little_endian.h include
rather than also use the ARCH specific byteorder.h header?

> 
> > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > ---
> > >  fs/squashfs/sqfs.c     | 3 +--
> > >  fs/squashfs/sqfs_dir.c | 3 +--
> > >  2 files changed, 2 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> > > index 5d9c52af80ba..41cb811c1b32 100644
> > > --- a/fs/squashfs/sqfs.c
> > > +++ b/fs/squashfs/sqfs.c
> > > @@ -11,8 +11,7 @@
> > >  #include <errno.h>
> > >  #include <fs.h>
> > >  #include <linux/types.h>
> > > -#include <linux/byteorder/little_endian.h>
> > > -#include <linux/byteorder/generic.h>
> > > +#include <asm/byteorder.h>
> > >  #include <memalign.h>
> > >  #include <stdlib.h>
> > >  #include <string.h>
> > > diff --git a/fs/squashfs/sqfs_dir.c b/fs/squashfs/sqfs_dir.c
> > > index a265b98fe685..ed83c90682ff 100644
> > > --- a/fs/squashfs/sqfs_dir.c
> > > +++ b/fs/squashfs/sqfs_dir.c
> > > @@ -7,8 +7,7 @@
> > >  
> > >  #include <errno.h>
> > >  #include <linux/types.h>
> > > -#include <linux/byteorder/little_endian.h>
> > > -#include <linux/byteorder/generic.h>
> > > +#include <asm/byteorder.h>
> > >  #include <stdint.h>
> > >  #include <stdio.h>
> > >  #include <stdlib.h>  
> > 
> > Cheers,
> > Miquèl  


Thanks,
Miquèl

  reply	other threads:[~2022-04-07  9:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 21:31 [PATCH] squashfs: Fix compilation on big endian systems Pali Rohár
2022-04-07  7:54 ` Miquel Raynal
2022-04-07  9:41   ` Pali Rohár
2022-04-07  9:54     ` Miquel Raynal [this message]
2022-04-07  9:58       ` Pali Rohár
2022-06-01 14:08         ` Tom Rini
2022-06-03 14:24           ` Miquel Raynal
2022-05-10 14:33 ` Pali Rohár
2022-05-23  9:32   ` Pali Rohár
2022-06-03 19:48 ` Tom Rini

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=20220407115455.265f0cf3@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=joaomarcos.costa@bootlin.com \
    --cc=pali@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=u-boot@lists.denx.de \
    /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.