All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@turbolabs.com>
To: Brad Bozarth <prettygood@cs.stanford.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Big-endian reading/writing cramfs (vs 2.4.10)
Date: Fri, 28 Sep 2001 17:17:41 -0600	[thread overview]
Message-ID: <20010928171741.E930@turbolinux.com> (raw)
In-Reply-To: <20010928163313.C930@turbolinux.com> <Pine.LNX.4.33.0109281539220.11173-100000@earth.ayrnetworks.com>
In-Reply-To: <Pine.LNX.4.33.0109281539220.11173-100000@earth.ayrnetworks.com>

On Sep 28, 2001  15:54 -0700, Brad Bozarth wrote:
> > On Sep 28, 2001  14:58 -0700, Brad wrote:
> > > +#define CRAM_SWAB_16(x)	( ( (0x0000FF00 & (x)) >> 8   ) | \
> > > +			  ( (0x000000FF & (x)) << 8 ) )
> >
> > Why not just use the well-defined le16_to_cpu() and le32_to_cpu() macros?
> 
> I did, originally... And it worked in inode.c, but I couldn't get mkcramfs
> to compile using those macros.  It's outside of __KERNEL__ so I tried
> using __cpu_to_le32.  The following error occurred:

I didn't realize that the header was also used in user-space.  I would
still use the le32_to_cpu() style macros in the code, but only define
macros of your own if the kernel ones were not defined, using either
#ifndef __KERNEL__ or #ifndef le32_to_cpu, or both.

This way, you get the benefit of the fast asm-based instructions in
the kernel, and you only use the slow ones in user-space (mkcramfs)
where you don't really care.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert


      reply	other threads:[~2001-09-28 23:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-28 21:58 [PATCH] Big-endian reading/writing cramfs (vs 2.4.10) Brad
2001-09-28 22:33 ` Andreas Dilger
2001-09-28 22:54   ` Brad Bozarth
2001-09-28 23:17     ` Andreas Dilger [this message]

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=20010928171741.E930@turbolinux.com \
    --to=adilger@turbolabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prettygood@cs.stanford.edu \
    /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.