[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m2wrpinn7p.fsf@igel.home>
Date: Sat, 16 Oct 2010 17:58:50 +0200
From: Andreas Schwab <schwab@...ux-m68k.org>
To: Akinobu Mita <akinobu.mita@...il.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Linux\/m68k" <linux-m68k@...r.kernel.org>
Subject: Re: [PATCH 22/22] bitops: remove minix bitops from asm/bitops.h
Akinobu Mita <akinobu.mita@...il.com> writes:
> 2010/10/16 Andreas Schwab <schwab@...ux-m68k.org>:
>> Akinobu Mita <akinobu.mita@...il.com> writes:
>>
>>> m68knommu is big-endian minixfs but m68k (mmu) is little-endian minixfs
>>> if I read arch/m68k/include/asm/bitops_{mm,no}.h correctly.
>>
>> Don't be confused by ^16, this is for the 16bit/32bit indexing
>> correction. The nommu version uses big-endian 32bit indexing which yet
>> another format.
>
> Oh, I see. I misunderstood.
>
> So we need a special handling for it to keep compatibility.
IMHO we only need two versions: big-endian filesystem with big-endian
16bit indexed bitmaps and little-endian filesystem with little-endian
bitmaps. The rest is just the result of careless copying. Note that
the minix filesystem does no byte swapping, so native byte order is the
only sensible mode.
Andreas.
--
Andreas Schwab, schwab@...ux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists