[PATCH v2 28/46] statfs: Use statfs64 if arch does not have the statfs syscall

Markos Chandras markos.chandras at gmail.com
Wed Nov 28 09:27:15 UTC 2012


On 27 November 2012 23:36, Rich Felker <dalias at aerifal.cx> 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?

>
>
> 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.


-- 
Regards,
Markos


More information about the uClibc mailing list