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

Markos Chandras markos.chandras at gmail.com
Mon Dec 3 16:30:28 UTC 2012


On 28 November 2012 10:58, Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
> 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

I think we don't need to provide a separate struct stat for new
architectures as functions such as fstatat(), will pass a
kernel_stat64
to the fstatat64 syscall which will then be converted back to 'stat'
using the __xstat32_conv helper (see the relevant patches I posted in
this patch series). However, a struct statfs is indeed needed for
fstatfs and statfs wrappers.

-- 
Regards,
Markos


More information about the uClibc mailing list