From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akinobu Mita Subject: Re: [PATCH v2 22/22] bitops: remove minix bitops from asm/bitops.h Date: Fri, 22 Oct 2010 16:55:10 +0900 Message-ID: References: <1287672077-5797-1-git-send-email-akinobu.mita@gmail.com> <1287672077-5797-23-git-send-email-akinobu.mita@gmail.com> <4CC0CA8E.4050600@monstr.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <4CC0CA8E.4050600@monstr.eu> Sender: sparclinux-owner@vger.kernel.org To: monstr@monstr.eu Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Arnd Bergmann , Christoph Hellwig , Andrew Morton , Greg Ungerer , Geert Uytterhoeven , Roman Zippel , Andreas Schwab , linux-m68k@lists.linux-m68k.org, Martin Schwidefsky , Heiko Carstens , linux390@de.ibm.com, linux-s390@vger.kernel.org, Yoshinori Sato , microblaze-uclinux@itee.uq.edu.au, "David S. Miller" , sparclinux@vger.kernel.org, Hirokazu Takata , linux-m32r@ml.linux-m32r.org, Ralf Baechle , linux-mips@linux-mips.org, Paul Mundt , linux-sh@vger.kernel.org, Chris Zankel List-Id: linux-arch.vger.kernel.org 2010/10/22 Michal Simek : > 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: >> =A0 =A0 =A0 big-endian 16bit indexed bitmaps >> >> h8300, microblaze, s390, sparc, m68knommu: >> =A0 =A0 =A0 big-endian 32 or 64bit indexed bitmaps > > Just one small fix microblaze little endian support is ready for merg= ing > to mainline which means that microblaze is > big-endian 32bit =A0and =A0little-endian 32bit > >> >> m32r, mips, sh, xtensa: >> =A0 =A0 =A0 big-endian 32 or 64bit indexed bitmaps for big-endian mo= de >> =A0 =A0 =A0 little-endian bitmaps for little-endian mode >> >> Others: >> =A0 =A0 =A0 little-endian bitmaps >> >> In order to move minix bit operations from asm/bitops.h to >> architecture independent code in minix file system, this provides tw= o >> 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 sele= ct >> 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_NATI= VE_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 sparclinux" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:51087 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753684Ab0JVHzL convert rfc822-to-8bit (ORCPT ); Fri, 22 Oct 2010 03:55:11 -0400 MIME-Version: 1.0 In-Reply-To: <4CC0CA8E.4050600@monstr.eu> References: <1287672077-5797-1-git-send-email-akinobu.mita@gmail.com> <1287672077-5797-23-git-send-email-akinobu.mita@gmail.com> <4CC0CA8E.4050600@monstr.eu> Date: Fri, 22 Oct 2010 16:55:10 +0900 Message-ID: Subject: Re: [PATCH v2 22/22] bitops: remove minix bitops from asm/bitops.h From: Akinobu Mita Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-arch-owner@vger.kernel.org List-ID: To: monstr@monstr.eu Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Arnd Bergmann , Christoph Hellwig , Andrew Morton , Greg Ungerer , Geert Uytterhoeven , Roman Zippel , Andreas Schwab , linux-m68k@lists.linux-m68k.org, Martin Schwidefsky , Heiko Carstens , linux390@de.ibm.com, linux-s390@vger.kernel.org, Yoshinori Sato , microblaze-uclinux@itee.uq.edu.au, "David S. Miller" , sparclinux@vger.kernel.org, Hirokazu Takata , linux-m32r@ml.linux-m32r.org, Ralf Baechle , linux-mips@linux-mips.org, Paul Mundt , linux-sh@vger.kernel.org, Chris Zankel Message-ID: <20101022075510.ZG2koiRmCikvr9RZitrxC52dS8yqzwCGUm6N2dZHi10@z> 2010/10/22 Michal Simek : > 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.