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

[Vineet Gupta]

On Tuesday 27 November 2012 03:47 PM, Markos Chandras wrote:
> On 26 November 2012 20:32, Rich Felker <dalias at aerifal.cx> wrote:
>>
>> As far as I know, there's nothing to maintain "backwards
>> compatibility" with. The stat structures vary per-arch, and an arch
>> that doesn't have a non-64-bit statfs syscall doesn't have an existing
>> "struct statfs" to maintain backwards compatibility with. You can just
>> define "struct statfs" to match the layout of the 64-bit struct.
> 
> I see what you mean but looking at the uClibc code
> (include/bits/statfs.h) struct statfs is always
> defined so your proposal of introducing yet another statfs for arches
> that don't have the non-64bit
> syscalls will conflict with this definition. It's always possible to
> #if/#endif the existing statfs structure with a new one
> for architectures that don't have the 32-bit version, but I don't
> think this is prettier to what I've done here.

Markos, pardon me if I'm wrong but isn't include/bits/statfs.h derived
out of either <arch>/bits/statfs.h or common/bits/statfs.h
So you could very cleanly override it for your per arch w/o any #ifdef mess.

> Same thing happens in the the kernel. A statfs structure is always
> exported whether you can support the
> 32-bit syscall or not. 

Well for the ABI we are targeting there's just the 64bit interface left
(if we focus on just stat/statfs for now) .. unless I'm missing something.

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 will save all the inter-working crap - and that's not to avoid code
changes but to avoid this shim layer which pollutes D-caches to begin
with. Since arch is using 64 bit interface - compiler would already be
equipped to generate 64 bit code - even if the arch is natively 32 bit.
The only downside I see with my suggestion is that 64bit generated code
on 32 bit arch might not be as efficient - so confining that to just the
internetwork layer might be better as opposed to littering 64 bit
generated code all over. Am I making sense or has the long day taken
toll on me !

Given my experience with benchmarking - I'm sure if we run LMBench on
the converted vs. existing libc - we will definitely see worse numbers
for things like lat_syscall {stat,fstat,open}. This makes me wonder if
this whole 64bit-only stat/statfs/xyz interface enforcement by upstream
kernel guys is to make sure that the newer guys fare worse to begin with ;-)


Also existing applications expect this
> well-known struct statfs. Changing it to a new one will
> result in an ABI break.

Well the existing users of code are not getting affected, and the new
users (ARC/Meta) have no choice than to break the ABI - as that is what
we are really doing here with this whole patch-series.