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

[Vineet Gupta]

On Wednesday 28 November 2012 03:18 PM, Markos Chandras wrote:
> 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. 

Precisely - now we are all on same page. So collecting all the ideas so
far for conclusion:

(1) we keep stat/stat64 as completely different/independent and have
itemized copies in the syscall wrappers as needed - this is not good for
performance - typically a few fields in stat are ever looked at but
because of conversion we end up touching each one of them - and that too
twice. The slight advantage however for native 32 bit arches is that
64bit emulation (assigning a 64 bit field to 32 bit field) is restricted
to xconv layer only (but only for !_FILE_OFFSET_BITS and/or
LARGEFILE64_SOURCE)

(2) We unconditionally define _FILE_OFFSET_BITS=64 for no-legacy-syscall
kernel based uClibc ports and do away with 32bit (legacy) stat
completely. libc preprocessor tricks will compile time convert any stat
refs (struct/function) to stat64 variants. For native 32 bit archs this
means the 64 bit emulation code will be all over the place which can
cause some performance hit (e.g. Busybox ls will have 64 bit field -
although that is true even today because by default it is built with
FOB=64). Also can this cause potential issues with open source projects
which for some obscure reasons don't support FOB=64.

(3) Have stat/stat64 with same overall layout but stat will internally
have 32 bit items (with appropriate padding) - allowing both structs to
be used in the 64bit syscall interface. This needs no interworking crap
except for some overflow checks (by testing high word).

So in theory both #2 and #3 are acceptable solutions. I'd vote for #3.

Comments !

That should work. I will send a new
> patch when I have something working.
> 
> 

To make this plug-n-play for uClibc ports for future no-legacy-syscalls
kernels, you probably would need to define a
libc/sysdeps/linux/common-no-legacy/bits/{stat.h,xxx} and have that be
selected based on !ARCH_HAS_DEPRECATED_SYSCALLS.

Markos, I'm extremely sorry if I/we are making your life miserable - but
things touching the ABI are only done once so we better flush out any
issues (including performance) before casting it in stone.

-Vineet