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

[Markos Chandras]

On 28 November 2012 09:27, Markos Chandras <markos.chandras at gmail.com> wrote:
> 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?

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