* Vineet Gupta:
> On 2/24/20 11:13 AM, Florian Weimer wrote:
>> * Vineet Gupta:
>>
>>> On 2/24/20 10:39 AM, Florian Weimer wrote:
> +# undef STAT64_IS_NOT_KERNEL_STAT64
Sorry, I think that going forward, we prefer that such macros are always
defined, with values 0 or 1 as appropriat
On 2/24/20 11:13 AM, Florian Weimer wrote:
> * Vineet Gupta:
>
>> On 2/24/20 10:39 AM, Florian Weimer wrote:
+# undef STAT64_IS_NOT_KERNEL_STAT64
>>> Sorry, I think that going forward, we prefer that such macros are always
>>> defined, with values 0 or 1 as appropriate.
>>
>> And that means w
* Vineet Gupta:
> On 2/24/20 10:39 AM, Florian Weimer wrote:
>>> +# undef STAT64_IS_NOT_KERNEL_STAT64
>>
>> Sorry, I think that going forward, we prefer that such macros are always
>> defined, with values 0 or 1 as appropriate.
>
> And that means we also need to additionally define this to 0 in al
On 2/24/20 10:39 AM, Florian Weimer wrote:
>> +# undef STAT64_IS_NOT_KERNEL_STAT64
>
> Sorry, I think that going forward, we prefer that such macros are always
> defined, with values 0 or 1 as appropriate.
And that means we also need to additionally define this to 0 in all ports which
don't end up
* Vineet Gupta:
> +/* Ports define to 1 when glibc struct stat64 is not compatible with
> + kernel stat64. This forces use of statx syscall (and explicit
> interworking)
> + even when fstat64 syscall is available. For asm-generic ABI this happened
> + with switch to 64-bit time_t. */
> +
>
An old version of asm-generic syscall ABI (e.g. ARC 2013) provided
fstat[at]64 syscalls for implementing the stat family.
These sycalls are passthru (no interworking/itemized-copy needed
between kernel and user structs since they are binary comaptible).
However with switch to 64-bit time_t the com
