2010/10/22 Michal Simek <monstr@xxxxxxxxx>:
Akinobu Mita wrote:
minix bit operations are only used by minix filesystem and useless
by other modules. Because byte order of inode and block bitmaps is
defferent on each architecture like below:
m68k:
big-endian 16bit indexed bitmaps
h8300, microblaze, s390, sparc, m68knommu:
big-endian 32 or 64bit indexed bitmaps
Just one small fix microblaze little endian support is ready for merging
to mainline which means that microblaze is
big-endian 32bit and little-endian 32bit
m32r, mips, sh, xtensa:
big-endian 32 or 64bit indexed bitmaps for big-endian mode
little-endian bitmaps for little-endian mode
Others:
little-endian bitmaps
In order to move minix bit operations from asm/bitops.h to
architecture independent code in minix file system, this provides two
config options.
CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k.
CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which
use native byte order bitmaps (h8300, microblaze, s390, sparc,
m68knommu, m32r, mips, sh, xtensa).
The architectures which always use little-endian bitmaps do not select
these options.
I haven't created any Kconfig option for little/big endian microblaze
but there should be a little bit different handling for MINIX_FS_NATIVE_ENDIAN
as you are describing above.
Anyway I think you don't need to reflect this in your patch because
we are not using that filesystem and I will write it to my to-do list and
will fix it later.
If upcomming microblade little-endian mode will use little-endian
bitmaps for minixfs, microblade can continue to select
CONFIG_MINIX_FS_NATIVE_ENDIAN and you don't need to change it.
But if it will use big-endian bitmaps, it may need some extra work
to support it. Becuase there is no little-endian architecture
which uses bit-endian bitmaps for minixfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
