From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marco Subject: Re: [PATCH 06/14] Pramfs: Include files Date: Sun, 21 Jun 2009 19:07:25 +0200 Message-ID: <4A3E68CD.6080803@gmail.com> References: <4A33A7EC.6070008@gmail.com> <20090613140459.GC30053@uranus.ravnborg.org> <200906140059.57362.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Ravnborg , Linux FS Devel , Linux Embedded , Linux Kernel To: Arnd Bergmann Return-path: In-Reply-To: <200906140059.57362.arnd@arndb.de> Sender: linux-embedded-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Arnd Bergmann wrote: > On Saturday 13 June 2009, Sam Ravnborg wrote: >>> + union { >>> + struct { >>> + /* >>> + * ptr to row block of 2D block pointer array, >>> + * file block #'s 0 to (blocksize/4)^2 - 1. >>> + */ >>> + off_t row_block; >> It is my understanding that we shall use: __kernel_off_t >> in exported headers. > > That is a correct understanding in general, however this case is > different, because it describes an on-disk data structure, > not a kernel to user space interface. Here, __kernel_off_t is just > as wrong as off_t, because it will differ between 32 and 64 bit > architectures, making the fs layout incompatible. I'd suggest > simply defining this as __u64. > > Moreover, file system layout should be described in terms of > big-endian or little-endian types (e.g. __be64 or __le64), > together with the right accessor functions. > > Arnd <>< > I was thinking about your comment and I think I'll use __kernel_off_t for the exported headers. I know that it will differ between 32 and 64 bit architectures, but for this kind of fs there isn't any compatibility problem at layout level. You cannot remove a chip of RAM from a board 32bit little endian and attach it to a board with a cpu 64bit big endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply "unsigned long" in the exported header file without any problems to little or big endian. Regards, Marco