On 28 November 2012 09:27, Markos Chandras <[email protected]> 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. > And the 32-bit structure you will pass to the INLINE_SYSCALL() will > end up in kernel space so it has to > 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?
Right so I was partly wrong. We still need to have the 32-bit syscalls around but like you said we can define our own struct statfs which would look like the 64-bit one. So the function signatures will not have to change. Furthermore, within the 32-bit syscall we will pass this new struct statfs to the 64-bit syscall. That should work. I will send a new patch when I have something working. -- Regards, Markos _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
