From: Arnd Bergmann <arnd@arndb.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
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 16:45:12 +0200 [thread overview]
Message-ID: <201010181645.13349.arnd@arndb.de> (raw)
In-Reply-To: <20101018135616.GB12449@n2100.arm.linux.org.uk>
On Monday 18 October 2010, Russell King - ARM Linux wrote:
> 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?
One optimization I can think of for the ARM headers would be to only
define find_first_zero_le_bit, find_next_zero_le_bit and find_next_le_bit
in arch/arm/include/asm/bitops.h and take the other definitions from
asm-generic/bitops/le.h, which encloses then duplicate ones in #ifdef.
> 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))
Note that patches 20 and 22 of the series completely eliminate the
the minix and ext2 definitions, putting them into architecture independent
code in those two file systems where they belong.
Adding the new definitions in patch 4 is just a logical step before removing
the old definitions in the later patches while maintaining bisectability.
> What I'm trying to say is please don't make the existing mess of bitops
> any worse than it currently is.
The series currently adds 20 lines to the arm code (could be reduced to
6 lines), but removes 26 lines which are essentially architecture
independent and shouldn't be there to start with. I'd call that the
opposite of making the mess worse.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/22] arm: introduce little endian bitops
Date: Mon, 18 Oct 2010 16:45:12 +0200 [thread overview]
Message-ID: <201010181645.13349.arnd@arndb.de> (raw)
In-Reply-To: <20101018135616.GB12449@n2100.arm.linux.org.uk>
On Monday 18 October 2010, Russell King - ARM Linux wrote:
> 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?
One optimization I can think of for the ARM headers would be to only
define find_first_zero_le_bit, find_next_zero_le_bit and find_next_le_bit
in arch/arm/include/asm/bitops.h and take the other definitions from
asm-generic/bitops/le.h, which encloses then duplicate ones in #ifdef.
> 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))
Note that patches 20 and 22 of the series completely eliminate the
the minix and ext2 definitions, putting them into architecture independent
code in those two file systems where they belong.
Adding the new definitions in patch 4 is just a logical step before removing
the old definitions in the later patches while maintaining bisectability.
> What I'm trying to say is please don't make the existing mess of bitops
> any worse than it currently is.
The series currently adds 20 lines to the arm code (could be reduced to
6 lines), but removes 26 lines which are essentially architecture
independent and shouldn't be there to start with. I'd call that the
opposite of making the mess worse.
Arnd
next prev parent reply other threads:[~2010-10-18 14:45 UTC|newest]
Thread overview: 65+ 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:44 ` [Ocfs2-devel] [PATCH 13/22] ocfs2: use " Akinobu Mita
2010-10-15 9:46 ` Akinobu Mita
2010-10-18 20:19 ` Joel Becker
2010-10-18 20:19 ` [Ocfs2-devel] " Joel Becker
2010-10-18 20:19 ` Joel Becker
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 ` [PATCH 03/22] s390: introduce little endian bitops 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-15 9:46 ` 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
2010-10-18 13:56 ` Russell King - ARM Linux
2010-10-18 14:45 ` Arnd Bergmann [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 ` [PATCH 06/22] m68knommu: introduce little endian bitops 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 ` [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-15 9:46 ` Akinobu Mita
2010-10-18 10:31 ` Jan Kara
2010-10-15 9:46 ` [PATCH 12/22] ext4: " Akinobu Mita
2010-10-15 9:46 ` [PATCH 14/22] nilfs2: " Akinobu Mita
2010-10-15 9:46 ` [PATCH 15/22] reiserfs: " Akinobu Mita
2010-10-15 9:46 ` [PATCH 16/22] udf: " 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 ` [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 ` [PATCH 21/22] m68k: convert minix bitops to use little endian bitops Akinobu Mita
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-16 7:59 ` Geert Uytterhoeven
2010-10-16 8:50 ` Andreas Schwab
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 15:58 ` Andreas Schwab
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=201010181645.13349.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/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.