[PATCH v2 1/6] sysv/linux: Rename alpha functions to be alpha specific
Zack Weinberg
zackw@panix.com
Tue Feb 11 17:21:00 GMT 2020
On Tue, Feb 11, 2020 at 12:14 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> 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.
Huh? Isn't it the exact same definition that would be used on the
32-bit architectures? All the variation should be hiding in the
definition of __time32_t?
zw
More information about the Libc-alpha
mailing list