Re: [PATCH v2 1/6] sysv/linux: Rename alpha functions to be alpha specific

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 10/02/2020 22:10, Zack Weinberg wrote:
> On Mon, Feb 10, 2020 at 4:53 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 10/02/2020 18:35, Zack Weinberg wrote:
>>> On Mon, Feb 10, 2020 at 4:25 PM Alistair Francis <alistair23@gmail.com> wrote:
>>>>  On Mon, Feb 10, 2020 at 1:11 PM Zack Weinberg <zackw@panix.com> wrote:
>>>>>
>>>>> On Mon, Feb 10, 2020 at 12:50 PM Alistair Francis
>>>>> <alistair.francis@wdc.com> wrote:
>>>>>>
>>>>>> These functions are alpha specifc, rename them to be clear.
>>>>>
>>>>> These functions were meant to be generic.  I put the file in
>>>>> s/u/s/l/alpha because it was only *used* on Alpha, at the time.
>>>>>
>>>>> What's stopping you from using these functions on all architectures?
>>>>
>>>> The Alpha functions use 32-bit versions of the timeval struct for a
>>>> 64-bit architecture. For all other architectures we want to use the
>>>> word size version (regardless of time_t size) for the timeval struct.
>>>> That's the main difference.
>>>
>>> I'm sorry, I haven't been following the discussion all that closely.
>>> Why is it necessary to use a 32-bit timeval struct (with 32-bit
>>> time_t, I presume) *only* on Alpha?  Is there no way we can smooth
>>> over this difference so that, as you say,
>>
>> Alpha is an outlier here, it is the only 64-bit architecture that did
>> the 32 bit to 64 bit transition some time ago.  All the generic code
>> assumes that 64-bit architectures always have 64-bit time_t
>> (__ASSUME_TIME64_SYSCALLS).
>>
>> And the old interface is not exported and *only* meant to be used in
>> compat symbols, different than the current way of handling y2038
>> prof code (where the user might still define the ABI with _TIME_SIZE).
>>
>> That's why I think alpha compat code should be compartmentalized on
>> alpha sysdep folder.
> 
> This doesn't address any of my concerns.  It should not be necessary
> to duplicate an *internal header* full of functions whose operation
> is, or ought to be, completely generic, just because the exposed API
> is different on Alpha.

The 32-bit timeval struct are alpha specific in a sense that no other
64-bit architectures have 32 time_t. 

We could certainly make it generic and add even more internally 
pre-processor magic to fit alpha code in generic definitions, but I
think it is really a worthless complication.  It is a legacy API, 
and it is highly unlikely that any other port will use such code.

I tend to see that generic code, such as the syscall consolidation
I have done over the years, should be defined when either you have
multiples ABIs that use it or if is the default for newer ports
(such as generic kABI).  Outliers implementations, such osf alpha
syscalls, should be secluded in alpha-only code.