[PATCH v7.1 07/13] ARC: Linux Syscall Interface

[Vineet Gupta]

On 7/7/20 2:32 PM, Joseph Myers wrote:
> On Tue, 7 Jul 2020, Vineet Gupta via Libc-alpha wrote:
> 
>>> Each implementation has it ows requirements so I can't really say if
>>> a helper function does make sense for all of them.  For pause
>>> specifically we can even simplify to since all architectures have
>>> either ppoll or ppoll_time64:
>>>
>>>   int
>>>   __libc_pause (void)
>>>   {
>>>   #ifdef __NR_ppoll_time64
>>>     return SYSCALL_CANCEL (ppoll_time64, NULL, 0, NULL, NULL);
>>>   #else
>>>     return SYSCALL_CANCEL (ppoll, NULL, 0, NULL, NULL);
>>>   #endif
>>>   }
>>
>> But how is this compatible with older kernels (and perhaps this is a general
>> question). I mean one/more ABIs minimum kernel would not have the ppoll or ppoll64
>> so how will new glibc work with such a kernel ? Is it not required to ?
> 
> See commit 089b772f98afd9eb6264c6489bc96a30bf6af4ac, where I removed 
> __ASSUME_PPOLL because all supported kernel versions now had that syscall 
> for all glibc architectures.

But that still doesn't explain how new glibc works with old kernels (for say when
a port support was first merged, with say asm-generic ABI).

Ah it seems any glibc is only required to work with "arch_minimum_kernel" (generic
or architecture override) which over time itself keeps moving forward due to
various reasons (e.g. 64-bit time support etc). So indeed a bleeding edge glibc of
today won't necessarily work with an arch kernel for say when its glibc port was
first merged, but will for the corresponding arch_minimum_kernel.

> In general this sort of thing needs a review of whether a given syscall is 
> available for all glibc architectures in their minimum kernel versions.  
> For the old kernels in question, that means checking the 
> architecture-specific syscall table as used to dispatch syscalls at 
> runtime, which used to have an architecture-specific format before 
> unification work was done; it used to mean checking asm/unistd.h as well, 
> but now we have syscall tables in glibc that's probably no longer 
> required.  It also involves checking compat syscall tables for 32-bit 
> binaries on 64-bit kernels, as sometimes a syscall didn't get added to the 
> native and compat syscall tables at the same time (see the comments in 
> sparc/kernel-features.h about various socket-related syscalls, for 
> example).
>