[PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Dear Joseph,

Do you have any more comments regarding the __ASSUME_TIME64_SYSCALL
flag patch [1] ?

Note:

[1] - https://patchwork.ozlabs.org/patch/1117100/


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

Dear all,

> Dear Joseph,
> 
> Do you have any more comments regarding the __ASSUME_TIME64_SYSCALL
> flag patch [1] ?

Gentle ping on this patch.

(But I'm also aware that we are in the middle of holidays season.)

> 
> Note:
> 
> [1] - https://patchwork.ozlabs.org/patch/1117100/
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma@denx.de




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Joseph Myers]

On Thu, 27 Jun 2019, Lukasz Majewski wrote:

> Dear Joseph,
> 
> Do you have any more comments regarding the __ASSUME_TIME64_SYSCALL
> flag patch [1] ?

I think it still needs major editing for clarity as well as idiomatic 
English usage.  Rather than sending a long list of detailed issues with 
particular words and phrases it probably makes more sense for me (or 
another native speaker with good familiarity with all the issues involved) 
to do that editing; I hope to look at that around August / September / 
October if no-one else does it first.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Alistair Francis]

On Mon, Jul 8, 2019 at 4:23 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 27 Jun 2019, Lukasz Majewski wrote:
>
> > Dear Joseph,
> >
> > Do you have any more comments regarding the __ASSUME_TIME64_SYSCALL
> > flag patch [1] ?
>
> I think it still needs major editing for clarity as well as idiomatic
> English usage.  Rather than sending a long list of detailed issues with
> particular words and phrases it probably makes more sense for me (or
> another native speaker with good familiarity with all the issues involved)
> to do that editing; I hope to look at that around August / September /
> October if no-one else does it first.

I'm a native English speaker and I think I now have a good sense of
what is going on, would it help if I read through it and send an
updated version?

Alistair

>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Alistair Francis]

On Wed, Aug 14, 2019 at 11:47 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Mon, Jul 8, 2019 at 4:23 AM Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Thu, 27 Jun 2019, Lukasz Majewski wrote:
> >
> > > Dear Joseph,
> > >
> > > Do you have any more comments regarding the __ASSUME_TIME64_SYSCALL
> > > flag patch [1] ?
> >
> > I think it still needs major editing for clarity as well as idiomatic
> > English usage.  Rather than sending a long list of detailed issues with
> > particular words and phrases it probably makes more sense for me (or
> > another native speaker with good familiarity with all the issues involved)
> > to do that editing; I hope to look at that around August / September /
> > October if no-one else does it first.
>
> I'm a native English speaker and I think I now have a good sense of
> what is going on, would it help if I read through it and send an
> updated version?

I had a go at it anyway, this is the updated comment I came up with:

/* Support for the 64-bit time Linux kernel syscalls.

   This flag indicates support for Linux kernel syscalls, which are able
   to handle the 64 bit time ABI. It is defined for all 64-bit architectures as
   they have always supported 64 bit time support. It is also defined for all
   32-bit architectures when using Linux kernel version 5.1 or newer.

   When __ASSUME_TIME64_SYSCALLS is defined glibc should call the *64/time64
   suffixed syscalls. These should be #defined to the the unsuffixed versions
   when required (such as when running on 64-bit systems).

   __ASSUME_TIME64_SYSCALLS being defined does not mean that __TIMESIZE is
   64-bit. In cases where the __TIMESIZE is 64-bit the 64-bit syscalls can be
   used directly. In cases where __TIMESIZE is 32-bit conversions between the
   original 32-bit values and the kernel's 64-bit values will need to occur.

   As an example - the syscall to set clock (clock_settime) - if the
   __ASSUME_TIME64_SYSCALLS is defined, it indicates that 64 bit time can
   be set in the system.

   On systems with __WORDSIZE == 64 the __NR_clock_settime syscall is used
   to achieve this goal. Contrary, systems with __WORDSIZE == 32 do use
   new __NR_clock_settime64 syscall available from Linux version 5.1.

   The __ASSUME_TIME64_SYSCALLS is defined for:

   1. Systems with intrinsic 64 bit time support (__WORDSIZE == 64).

   2. For x32 architecture, which is a special case in respect to 64 bit
      time support (it has __WORDSIZE==32 but __TIMESIZE==64)

   3. Systems with __WORDSIZE==32, which gain 64 bit time support
      with new set of syscalls added to Linux kernel 5.1.

   4. All new 32-bit architectures that only support 64-bit time, such as RV32.
   */

Alistair


>
> Alistair
>
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com

Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 3402 bytes --]

Hi Alistair,

> On Wed, Aug 14, 2019 at 11:47 AM Alistair Francis
> <alistair23@gmail.com> wrote:
> >
> > On Mon, Jul 8, 2019 at 4:23 AM Joseph Myers
> > <joseph@codesourcery.com> wrote:  
> > >
> > > On Thu, 27 Jun 2019, Lukasz Majewski wrote:
> > >  
> > > > Dear Joseph,
> > > >
> > > > Do you have any more comments regarding the
> > > > __ASSUME_TIME64_SYSCALL flag patch [1] ?  
> > >
> > > I think it still needs major editing for clarity as well as
> > > idiomatic English usage.  Rather than sending a long list of
> > > detailed issues with particular words and phrases it probably
> > > makes more sense for me (or another native speaker with good
> > > familiarity with all the issues involved) to do that editing; I
> > > hope to look at that around August / September / October if
> > > no-one else does it first.  
> >
> > I'm a native English speaker and I think I now have a good sense of
> > what is going on, would it help if I read through it and send an
> > updated version?  
> 
> I had a go at it anyway, this is the updated comment I came up with:
> 
> /* Support for the 64-bit time Linux kernel syscalls.
> 
>    This flag indicates support for Linux kernel syscalls, which are
> able to handle the 64 bit time ABI. It is defined for all 64-bit
> architectures as they have always supported 64 bit time support. It
> is also defined for all 32-bit architectures when using Linux kernel
> version 5.1 or newer.
> 
>    When __ASSUME_TIME64_SYSCALLS is defined glibc should call the
> *64/time64 suffixed syscalls. These should be #defined to the the
> unsuffixed versions when required (such as when running on 64-bit
> systems).
> 
>    __ASSUME_TIME64_SYSCALLS being defined does not mean that
> __TIMESIZE is 64-bit. In cases where the __TIMESIZE is 64-bit the
> 64-bit syscalls can be used directly. In cases where __TIMESIZE is
> 32-bit conversions between the original 32-bit values and the
> kernel's 64-bit values will need to occur.
> 
>    As an example - the syscall to set clock (clock_settime) - if the
>    __ASSUME_TIME64_SYSCALLS is defined, it indicates that 64 bit time
> can be set in the system.
> 
>    On systems with __WORDSIZE == 64 the __NR_clock_settime syscall is
> used to achieve this goal. Contrary, systems with __WORDSIZE == 32 do
> use new __NR_clock_settime64 syscall available from Linux version 5.1.
> 
>    The __ASSUME_TIME64_SYSCALLS is defined for:
> 
>    1. Systems with intrinsic 64 bit time support (__WORDSIZE == 64).
> 
>    2. For x32 architecture, which is a special case in respect to 64
> bit time support (it has __WORDSIZE==32 but __TIMESIZE==64)
> 
>    3. Systems with __WORDSIZE==32, which gain 64 bit time support
>       with new set of syscalls added to Linux kernel 5.1.
> 
>    4. All new 32-bit architectures that only support 64-bit time,
> such as RV32. */
> 

Thanks for providing the new description. Let's wait for comments from
glibc community members.

> Alistair
> 
> 
> >
> > Alistair
> >  
> > >
> > > --
> > > Joseph S. Myers
> > > joseph@codesourcery.com  



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Joseph Myers]

On Thu, 15 Aug 2019, Alistair Francis wrote:

> /* Support for the 64-bit time Linux kernel syscalls.
> 
>    This flag indicates support for Linux kernel syscalls, which are able
>    to handle the 64 bit time ABI. It is defined for all 64-bit architectures as

I think "syscalls, which are able to handle the 64 bit time ABI" is 
awkward.  "syscalls using 64-bit time" or similar would seem better.  
(Throughout, use "64-bit" with a hyphen as an adjective.)

>    they have always supported 64 bit time support. It is also defined for all
>    32-bit architectures when using Linux kernel version 5.1 or newer.

"always supported 64 bit time support" should lose the last "support" (and 
add the hyphen in 64-bit).

>    When __ASSUME_TIME64_SYSCALLS is defined glibc should call the *64/time64
>    suffixed syscalls. These should be #defined to the the unsuffixed versions
>    when required (such as when running on 64-bit systems).

I don't think the interface definition involves "should call".  It's more 
like "can call, without needing to check at runtime for ENOSYS errors".

>    On systems with __WORDSIZE == 64 the __NR_clock_settime syscall is used
>    to achieve this goal. Contrary, systems with __WORDSIZE == 32 do use
>    new __NR_clock_settime64 syscall available from Linux version 5.1.

Describing syscalls as "new" is a bad idea.  (You can also remove 
"Contrary" and "do".)

>    The __ASSUME_TIME64_SYSCALLS is defined for:

The __ASSUME_TIME64_SYSCALLS *macro*.

>    1. Systems with intrinsic 64 bit time support (__WORDSIZE == 64).

As I said in <https://sourceware.org/ml/libc-alpha/2019-05/msg00688.html>, 
don't use this "intrinsic" description.

>    3. Systems with __WORDSIZE==32, which gain 64 bit time support
>       with new set of syscalls added to Linux kernel 5.1.

And avoid "new".

>    4. All new 32-bit architectures that only support 64-bit time, such as RV32.

Again, avoid "new"; describe the actual properties involved so the comment 
doesn't depend on people reading it from a 2019 perspective in which 
certain things count as "new".  I think you mean 32-bit architectures for 
which support was added in Linux 5.1 or later, or for which the 
kernel/userspace ABI changed incompatibly in Linux 5.1 or later so that 
there are no syscalls using 32-bit time.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Alistair Francis]

On Fri, Aug 16, 2019 at 8:49 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 15 Aug 2019, Alistair Francis wrote:
>
> > /* Support for the 64-bit time Linux kernel syscalls.
> >
> >    This flag indicates support for Linux kernel syscalls, which are able
> >    to handle the 64 bit time ABI. It is defined for all 64-bit architectures as
>
> I think "syscalls, which are able to handle the 64 bit time ABI" is
> awkward.  "syscalls using 64-bit time" or similar would seem better.
> (Throughout, use "64-bit" with a hyphen as an adjective.)
>
> >    they have always supported 64 bit time support. It is also defined for all
> >    32-bit architectures when using Linux kernel version 5.1 or newer.
>
> "always supported 64 bit time support" should lose the last "support" (and
> add the hyphen in 64-bit).
>
> >    When __ASSUME_TIME64_SYSCALLS is defined glibc should call the *64/time64
> >    suffixed syscalls. These should be #defined to the the unsuffixed versions
> >    when required (such as when running on 64-bit systems).
>
> I don't think the interface definition involves "should call".  It's more
> like "can call, without needing to check at runtime for ENOSYS errors".
>
> >    On systems with __WORDSIZE == 64 the __NR_clock_settime syscall is used
> >    to achieve this goal. Contrary, systems with __WORDSIZE == 32 do use
> >    new __NR_clock_settime64 syscall available from Linux version 5.1.
>
> Describing syscalls as "new" is a bad idea.  (You can also remove
> "Contrary" and "do".)
>
> >    The __ASSUME_TIME64_SYSCALLS is defined for:
>
> The __ASSUME_TIME64_SYSCALLS *macro*.
>
> >    1. Systems with intrinsic 64 bit time support (__WORDSIZE == 64).
>
> As I said in <https://sourceware.org/ml/libc-alpha/2019-05/msg00688.html>,
> don't use this "intrinsic" description.
>
> >    3. Systems with __WORDSIZE==32, which gain 64 bit time support
> >       with new set of syscalls added to Linux kernel 5.1.
>
> And avoid "new".
>
> >    4. All new 32-bit architectures that only support 64-bit time, such as RV32.
>
> Again, avoid "new"; describe the actual properties involved so the comment
> doesn't depend on people reading it from a 2019 perspective in which
> certain things count as "new".  I think you mean 32-bit architectures for
> which support was added in Linux 5.1 or later, or for which the
> kernel/userspace ABI changed incompatibly in Linux 5.1 or later so that
> there are no syscalls using 32-bit time.

Thanks for the review.

I just talked to Lukasz and he is happy with me sending out the next
version of this patch so I'll send that now.

Alistair

>
> --
> Joseph S. Myers
> joseph@codesourcery.com