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. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
