From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>,
Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 04/22] arm: introduce little endian bitops
Date: Mon, 18 Oct 2010 14:56:16 +0100 [thread overview]
Message-ID: <20101018135616.GB12449@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTi=1w9uV81CagrE53xEYkMaFh_3cM_+ybctT2ng4@mail.gmail.com>
On Mon, Oct 18, 2010 at 10:22:59PM +0900, Akinobu Mita wrote:
> 2010/10/18 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Fri, Oct 15, 2010 at 06:46:03PM +0900, Akinobu Mita wrote:
> >> Introduce little endian bit operations by renaming native ext2 bit
> >> operations. The ext2 bit operations are kept by using little endian
> >> bit operations until the conversions are finished.
> >
> > Can you explain why we need another level of indirection rather than
> > using asm-generic/bitops/le.h, asm-generic/bitops/minix.h and
> > asm-generic/bitops/ext2-non-atomic.h ?
>
> Sorry for not CCing the cover letter of this patch series.
>
> Currently there are no common little-endian bit operations for all
> architectures, although some architectures implicitly include
> asm-generic/bitops/le.h through asm-generic/bitops/minix-le.h or
> asm-generic/bitops/ext2-non-atomic.h.
>
> So some drivers (net/rds/cong.c and virt/kvm/kvm_main.c) need to
> include asm/bitops/le.h directly. When I tried to remove the
> direct inclusion of asm-generic/bitops/le.h by using ext2_*(),
> several people prefer another solution like this patch series does.
>
> This patch series introduces little-endian bit operations for
> all architectures and convert all ext2 non-atomic bit operations
> and minix bit operations to use little-endian bit operations.
> it enables to remove ext2 non-atomic and minix bit operations
> from asm/bitops.h. The reason they should be removed from
> asm/bitops.h is as follows:
>
> For ext2 non-atomic bit operations, they are used for little-endian
> byte order bitmap access by some filesystems and modules.
> But using ext2_*() functions on a module other than ext2 filesystem
> makes someone feel strange.
>
> For minix bit operations, they are only used by minix filesystem
> and useless by other modules. Because byte order of inode and block
> bitmap is defferent on each architectures.
>
> There are several issues including arm part. So I'm now fixing them.
le.h provides:
generic___set_le_bit
generic___test_and_set_le_bit
...
Your new patches provide:
__set_le_bit
__test_and_set_le_bit
Would it not be better to have le.h provide one set of these LE bitops
(called either generic___set_le_bit or __set_le_bit - which ever you
prefer), and then have everyone using those common names (including
minix-le.h and ext2-non-atomic.h) rather than adding a whole series of
new bitop macros to the current mess?
To put it another way, if we're providing a set of guaranteed-little-endian
bitops, I'd like to see ARM doing this:
#define __test_and_set_le_bit(nr,p) ...
#include <asm-generic/bitops/minix-le.h>
#include <asm-generic/bitops/ext2-non-atomic.h>
where ext2-non-atomic.h could just be:
#define ext2_set_bit(nr,addr) __test_and_set_le_bit((nr),(unsigned long *)(addr))
instead of defining its own minix and ext2 bitops as we do now:
#ifndef __ARMEB__
#define WORD_BITOFF_TO_LE(x) ((x))
#else
#define WORD_BITOFF_TO_LE(x) ((x) ^ 0x18)
#endif
#define ext2_set_bit(nr,p) \
__test_and_set_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
vs the current 'generic' stuff:
ARM byteorder.h (roughly):
#ifdef __ARMEB__
#define __BIG_ENDIAN 4321
#else
#define __LITTLE_ENDIAN 1234
#endif
le.h:
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
#if defined(__LITTLE_ENDIAN)
#define generic___test_and_set_le_bit(nr, addr) __test_and_set_bit(nr, addr)
#elif defined(__BIG_ENDIAN)
#define generic___test_and_set_le_bit(nr, addr) \
__test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
#endif
ext2-non-atomic.h:
#define ext2_set_bit(nr,addr) \
generic___test_and_set_le_bit((nr),(unsigned long *)(addr))
What I'm trying to say is please don't make the existing mess of bitops
any worse than it currently is.
next prev parent reply other threads:[~2010-10-18 13:56 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-15 9:45 [PATCH 00/22] Introduce little endian bitops Akinobu Mita
2010-10-15 9:45 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 01/22] bitops: merge little and big endian definisions in asm-generic/bitops/le.h Akinobu Mita
2010-10-15 9:46 ` [PATCH 02/22] bitops: rename generic le bitops functions Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 03/22] s390: introduce little endian bitops Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 11:12 ` Arnd Bergmann
2010-10-18 4:51 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 04/22] arm: " Akinobu Mita
2010-10-18 9:26 ` Russell King - ARM Linux
2010-10-18 9:26 ` Russell King - ARM Linux
2010-10-18 13:22 ` Akinobu Mita
2010-10-18 13:22 ` Akinobu Mita
2010-10-18 13:56 ` Russell King - ARM Linux [this message]
2010-10-18 14:45 ` Arnd Bergmann
2010-10-18 15:07 ` Russell King - ARM Linux
2010-10-18 15:07 ` Russell King - ARM Linux
2010-10-18 13:58 ` Russell King - ARM Linux
2010-10-18 13:58 ` Russell King - ARM Linux
2010-10-15 9:46 ` [PATCH 05/22] m68k: introduce le bitops Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 06/22] m68knommu: introduce little endian bitops Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 07/22] bitops: introduce little endian bitops for most architectures Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 08/22] rds: stop including asm-generic/bitops/le.h Akinobu Mita
2010-10-15 9:46 ` [PATCH 09/22] kvm: " Akinobu Mita
2010-10-15 9:46 ` [PATCH 10/22] asm-generic: use little endian bitops Akinobu Mita
2010-10-15 11:06 ` Arnd Bergmann
2010-10-15 9:46 ` [PATCH 11/22] ext3: " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-18 10:31 ` Jan Kara
2010-10-18 10:31 ` Jan Kara
2010-10-15 9:46 ` [PATCH 12/22] ext4: " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 13/22] ocfs2: " Akinobu Mita
2010-10-18 20:19 ` Joel Becker
2010-10-18 20:19 ` Joel Becker
2010-10-15 9:46 ` [PATCH 14/22] nilfs2: " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 15/22] reiserfs: " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 16/22] udf: " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-18 10:46 ` Jan Kara
2010-10-15 9:46 ` [PATCH 17/22] ufs: " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 18/22] md: use little endian bit operations Akinobu Mita
2010-10-18 2:41 ` Neil Brown
2010-10-15 9:46 ` [PATCH 19/22] dm: " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 20/22] bitops: remove ext2 non-atomic bitops from asm/bitops.h Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-15 9:46 ` [PATCH 21/22] m68k: convert minix bitops to use little endian bitops Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-18 8:58 ` Andreas Schwab
2010-10-18 8:58 ` Andreas Schwab
2010-10-15 9:46 ` [PATCH 22/22] bitops: remove minix bitops from asm/bitops.h Akinobu Mita
2010-10-15 10:53 ` Arnd Bergmann
2010-10-15 18:53 ` Mike Frysinger
2010-10-15 20:15 ` Arnd Bergmann
2010-10-15 20:15 ` Arnd Bergmann
2010-10-16 7:59 ` Geert Uytterhoeven
2010-10-16 7:59 ` Geert Uytterhoeven
2010-10-16 8:50 ` Andreas Schwab
2010-10-16 11:35 ` Geert Uytterhoeven
2010-10-16 12:40 ` Akinobu Mita
2010-10-16 12:57 ` Andreas Schwab
2010-10-16 12:57 ` Andreas Schwab
2010-10-16 13:47 ` Akinobu Mita
2010-10-16 13:47 ` Akinobu Mita
2010-10-16 15:58 ` Andreas Schwab
2010-10-19 15:05 ` Akinobu Mita
2010-10-15 11:14 ` [PATCH 00/22] Introduce little endian bitops Arnd Bergmann
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=20101018135616.GB12449@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=hch@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).