On Wed, Nov 28, 2012 at 09:27:15AM +0000, Markos Chandras wrote: > On 27 November 2012 23:36, Rich Felker <[email protected]> wrote: > > > > The claim of "ABI break" is nonsense. There is presently NO WAY to use > > this legacy stat structure on no-legacy-syscall kernels. So there is > > no way anything could be using it. Really, on no-legacy-syscall > > kernels, _FILE_OFFSET_BITS should always be 64 and the legacy structs > > should not even exist. But if you insist on providing them anyway, you > > should use the same layout as the 64-bit struct that the syscall > > supports, rather than writing nasty bloat to convert to a completely > > non-native legacy structure that has nothing to do with the kernel. > > You seem to ignore part of my replies. I explained that 32-bit > syscalls need to be present > so existing applications can link and work as expected. For example, > many applications still use > stastfs() instead of statfs64(). As a result of which, we still need > the 32-bit structures around.
On 64-bit machines, statfs and statfs64 are the same function. Moreover, whenever _FILE_OFFSET_BITS is defined to 64 (which should always be done; mixing programs compiled with different settings can lead to subtle and dangerous bugs with file descriptor inheritance) statfs is statfs64. Nobody should ever be calling statfs64 by name. > And the 32-bit structure you will pass to the INLINE_SYSCALL() will > end up in kernel space so it has to It never ends up in kernelspace on no-legacy-syscall archs because THERE IS NO SUCH SYSCALL. You have to make the statfs64 syscall instead, and the 32-bit structure only exists by virtue of whatever translations you do in userspace. > have a similar layout with the kernel statfs structure which ( I > already said that ) is always defined in new architectures > in $KERNEL/include/asm-generic/statfs.h. So even if we provide our own > in uClibc, we can't change the kernel one. > Do I miss something? Yes. You miss that THERE IS NO KERNEL ONE on these archs. > > There is no such thing as a "positive pointer". Pointers do not have > > sign. > > OK I meant an arbitrary positive integer that the user can pass in the > statfs(). Many LTP tests does that. The only different is that > these tests will crash libc in new architectures but will return -1 > on old ones. Your proposed "test that the pointer is positive" nonsense makes it impossible to use statfs. *Most* uses of statfs involve a pointer which, when cast to int, becomes a negative number (due to being on the stack). Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
