Messages in this thread | | | From | Bernd Schubert <> | Subject | Re: x86_64: 32bit emulation problems | Date | Wed, 2 Mar 2005 12:33:56 +0100 |
| |
On Wednesday 02 March 2005 10:13, Trond Myklebust wrote: > on den 02.03.2005 Klokka 09:18 (+0100) skreiv Andi Kleen: > > On Wed, Mar 02, 2005 at 12:46:23AM +0100, Andreas Schwab wrote: > > > Bernd Schubert <bernd-schubert@web.de> writes: > > > > Hmm, after compiling with -D_FILE_OFFSET_BITS=64 it works fine. But > > > > why does it work without this option on a 32bit kernel, but not on a > > > > 64bit kernel? > > > > > > See nfs_fileid_to_ino_t for why the inode number is different between > > > 32bit and 64bit kernels. > > > > Ok that explains it. Thanks.
Many thanks also from me!
> > > > Best would be probably to just do the shift unconditionally on 64bit > > kernels too. > > > > Trond, what do you think? > > Why would this be more appropriate than defining __kernel_ino_t on the > x86_64 platform to be of the size that you actually want the kernel to > support? > > I can see no good reason for truncating inode number values on platforms > that actually do support 64-bit inode numbers, but I can see several
Well, at least we would have a reason ;)
> reasons why you might want not to (utilities that need to detect hard > linked files for instance).
Anyway, glibc already seems to have a condition for that, so IMHO glibc also could truncate the inode numbers if needed. And finally glibc probably knows best if its compiled as 32bit or 64bit. Will take a look into the glibc sources.
Many, many thanks to all for their help!
Best wishes, Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |