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

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

On 11/02/2020 13:23, Zack Weinberg wrote:
> On Tue, Feb 11, 2020 at 11:06 AM Alistair Francis <alistair23@gmail.com> wrote:
>>
>> On Tue, Feb 11, 2020 at 6:39 AM Zack Weinberg <zackw@panix.com> wrote:
>>>
>>> On Tue, Feb 11, 2020 at 8:25 AM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>> On 10/02/2020 22:10, Zack Weinberg wrote:
>>>>>
>>>>> 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 think we're talking past each other.  This patch is about
>>> tv32-compat.h.  tv32-compat.h contains conversion functions between
>>> e.g. struct timeval with 32-bit time_t and struct timeval with 64-bit
>>> time_t.  I still don't see any reason why these conversion functions
>>
>> The generic patches added by this series convert between a 64-bit
>> time_t and a wordsize time_t. Alpha is different in that it converts
>> between a 64-bit time_t and a 32-bit time_t on a 64-bit arch.
> 
> Yes, I understand that, but the definition of the 32-bit-time_t struct
> timeval is
> 
>   struct __timeval32 {
>      __time32_t tv_sec;
>      __suseconds_t tv_usec;
>   };
> 
> either way, isn't it?  So the conversion functions shouldn't care?
> 
> (If that's not what the definition of the 32-bit-time_t struct timeval
> is, then I would like to know why, in *excruciating* detail.)

Yes, but why expose this specific types on architectures that do not
really require it?  Sure we could make this code generic, but again
this will be used solely by alpha.