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

[Markos Chandras]

On 27 November 2012 15:19, Markos Chandras <markos.chandras at gmail.com> wrote:
> On 27 November 2012 15:08, Mark Salter <msalter at redhat.com> wrote:
>> On Tue, 2012-11-27 at 14:53 +0000, Markos Chandras wrote:
>>> > Now a crazy idea - for the arches under consideration (i.e no
>>> backward
>>> > compatibility baggage) can we simply typedef statfs/stat structures
>>> to
>>> > statfs64 and stat64 respectively. This is extending Rich's
>>> suggestion.
>>>
>>> That could work too. I can't think why this would break anything but I
>>> will know
>>> more once I try that locally.
>>>
>>
>> This should be for 32-bit systems only. There are no stat64/statfs64
>> structs in 64-bit kernels. (well, except for some 32-bit compatibility
>> syscalls).
>>
>> --Mark
>>
>>
>
> My understanding is that only the 32-bit structures need to be defined
> to match the 64-bit ones.
> The 32-bit syscalls need to be implemented to use the 64-bit syscall
> internally for existing applications
> to be able to link and run as expected.
>

I am still not convinced that this is the best approach to solve this problem.
This requires every new architecture to carry a copy of statfs64 and
stat64 structures (in libc/sysdeps/linux/$arch/{stat,statfs}.h)
which is then typedef'd to statfs and stat. And I am not sure if this
typedef'd thing would work. We would have something like this:

typedef struct statfs64 statfs

but then we need to replace all the referenced of "struct statfs" with
"statfs". This seems ugly. Unless of course I miss something.

Moreover

#define statfs64 statfs

will not work because this will also rename the function signatures
(and have other possible side-effects)

What is wrong with copying the 64-bit structure members back to the
32-bit one like my patch does?
I know it's not ideal but to me it seems prettier (and maybe simpler)
than the alternatives.

-- 
Regards,
Markos