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

[Alistair Francis <alistair23 at gmail dot com>]

On Mon, Feb 10, 2020 at 1: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.

Agreed. That is the goal with this patch.

This patch moves and renames the Alpha functions to make sure there is
no conflict with any of the new work.

Alistair

>
> >
> >> 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
> >