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

Zack Weinberg zackw@panix.com
Tue Feb 11 01:11:00 GMT 2020


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.

zw



More information about the Libc-alpha mailing list