On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote:
quoted
On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote:
quoted
On Fri, 1 Feb 2008 21:02:08 +0100
Bastian Blank [off-list ref] wrote:
quoted
Fix ext4 bitops.
This is incomplete. Please tell us what was "fixed".
If it was a build error then please quote the compile error output in the
changelog, as well as the usual description of what the problem is, and how
it was fixed.
| fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
| fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
The s390 specific bitops uses parts of the generic implementation.
Include the correct header.
That doesn't work:
fs/built-in.o: In function `ext4_mb_release_inode_pa':
mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
fs/built-in.o: In function `ext4_mb_init_cache':
mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
This still needs generic_find_next_le_bit which comes
from lib/find_next_bit.c. That one doesn't get built on s390 since we
don't set GENERIC_FIND_NEXT_BIT.
Currently we have the lengthly patch below queued.
Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
impression the ext4 people don't (compile) test on big endian machines?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote:
On Sun, 3 Feb 2008, Heiko Carstens wrote:
quoted
On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote:
quoted
On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote:
quoted
On Fri, 1 Feb 2008 21:02:08 +0100
Bastian Blank [off-list ref] wrote:
quoted
Fix ext4 bitops.
This is incomplete. Please tell us what was "fixed".
If it was a build error then please quote the compile error output in the
changelog, as well as the usual description of what the problem is, and how
it was fixed.
| fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
| fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
The s390 specific bitops uses parts of the generic implementation.
Include the correct header.
That doesn't work:
fs/built-in.o: In function `ext4_mb_release_inode_pa':
mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
fs/built-in.o: In function `ext4_mb_init_cache':
mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
This still needs generic_find_next_le_bit which comes
from lib/find_next_bit.c. That one doesn't get built on s390 since we
don't set GENERIC_FIND_NEXT_BIT.
Currently we have the lengthly patch below queued.
Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
impression the ext4 people don't (compile) test on big endian machines?
Gr{oetje,eeting}s,
I have sent this patches to linux-arch expecting a review from
different arch people. It is true that the patches are tested only on
powerpc, x86-64, x86. That's the primary reason of me sending the
patches to linux-arch.
http://marc.info/?l=linux-arch&m=119503501127737&w=2
-aneesh
| fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
| fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
The s390 specific bitops uses parts of the generic implementation.
Include the correct header.
That doesn't work:
fs/built-in.o: In function `ext4_mb_release_inode_pa':
mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
fs/built-in.o: In function `ext4_mb_init_cache':
mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
This still needs generic_find_next_le_bit which comes
from lib/find_next_bit.c. That one doesn't get built on s390 since we
don't set GENERIC_FIND_NEXT_BIT.
Currently we have the lengthly patch below queued.
Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
impression the ext4 people don't (compile) test on big endian machines?
Gr{oetje,eeting}s,
I have sent this patches to linux-arch expecting a review from
different arch people. It is true that the patches are tested only on
powerpc, x86-64, x86. That's the primary reason of me sending the
patches to linux-arch.
Is there anything special I need to do so the ext4 code actually uses
ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
test if the s390 implementation is ok.
On Mon, Feb 04, 2008 at 10:24:36AM +0100, Heiko Carstens wrote:
quoted
quoted
quoted
quoted
| fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
| fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
The s390 specific bitops uses parts of the generic implementation.
Include the correct header.
That doesn't work:
fs/built-in.o: In function `ext4_mb_release_inode_pa':
mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
fs/built-in.o: In function `ext4_mb_init_cache':
mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
This still needs generic_find_next_le_bit which comes
from lib/find_next_bit.c. That one doesn't get built on s390 since we
don't set GENERIC_FIND_NEXT_BIT.
Currently we have the lengthly patch below queued.
Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
impression the ext4 people don't (compile) test on big endian machines?
Gr{oetje,eeting}s,
I have sent this patches to linux-arch expecting a review from
different arch people. It is true that the patches are tested only on
powerpc, x86-64, x86. That's the primary reason of me sending the
patches to linux-arch.
Is there anything special I need to do so the ext4 code actually uses
ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
test if the s390 implementation is ok.
With the latest linus kernel in git you can test it by mounting ext4
mount -t ext4dev <device> <mntpoint>
-aneesh
On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote:
quoted
On Sun, 3 Feb 2008, Heiko Carstens wrote:
quoted
On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote:
quoted
On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote:
quoted
On Fri, 1 Feb 2008 21:02:08 +0100
Bastian Blank [off-list ref] wrote:
quoted
Fix ext4 bitops.
This is incomplete. Please tell us what was "fixed".
If it was a build error then please quote the compile error output in the
changelog, as well as the usual description of what the problem is, and how
it was fixed.
| fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
| fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
The s390 specific bitops uses parts of the generic implementation.
Include the correct header.
That doesn't work:
fs/built-in.o: In function `ext4_mb_release_inode_pa':
mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
fs/built-in.o: In function `ext4_mb_init_cache':
mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
This still needs generic_find_next_le_bit which comes
from lib/find_next_bit.c. That one doesn't get built on s390 since we
don't set GENERIC_FIND_NEXT_BIT.
Currently we have the lengthly patch below queued.
Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
impression the ext4 people don't (compile) test on big endian machines?
I have sent this patches to linux-arch expecting a review from
different arch people. It is true that the patches are tested only on
powerpc, x86-64, x86. That's the primary reason of me sending the
patches to linux-arch.
http://marc.info/?l=linux-arch&m=119503501127737&w=2
Sometimes it's difficult to see what can go wrong due to a single patch that
just adds a #define. Sorry, I missed the lack of prototype for
generic_find_next_le_bit() and that we don't set GENERIC_FIND_NEXT_BIT,
just like s390.
And yes, usually I rely on the -mm autocompiler to catch things like
this, but this time it didn't work out...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds