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.
