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

[Adhemerval Zanella]

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.

> 
>> If Alpha didn't have this requirement we could then just remove the
>> Alpha specific overrides after this series and use all of the new
>> generic y2038 infrastructure.
> 
> Also, even if we really are stuck with an Alpha-specific struct
> timeval32, I don't see why that affects the definitions of the
> conversion functions?
> 
> zw
>