On 27 November 2012 14:31, Vineet Gupta <[email protected]> wrote:
> On Tuesday 27 November 2012 03:47 PM, Markos Chandras wrote:
>> On 26 November 2012 20:32, Rich Felker <[email protected]> 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.
Hmm that's true. I haven't noticed it before
>
>> Same thing happens in the the kernel. A statfs structure is always
>> exported whether you can support the
>> 32-bit syscall or not.
>
>
> 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.
>
>
> 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 ;-)
I guess it's possible to observe a minor performance degradation
because of the time
we spend converting the 64-bit struct back to the 32-bit one.
--
Regards,
Markos
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
