* [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define @ 2019-06-27 10:42 Lukasz Majewski 2019-07-04 8:09 ` Lukasz Majewski 2019-07-08 11:23 ` Joseph Myers 0 siblings, 2 replies; 8+ messages in thread From: Lukasz Majewski @ 2019-06-27 10:42 UTC (permalink / raw) To: Joseph Myers; +Cc: Stepan Golosunov, libc-alpha, Arnd Bergmann [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define 2019-06-27 10:42 [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define Lukasz Majewski @ 2019-07-04 8:09 ` Lukasz Majewski 2019-07-08 11:23 ` Joseph Myers 1 sibling, 0 replies; 8+ messages in thread From: Lukasz Majewski @ 2019-07-04 8:09 UTC (permalink / raw) To: Joseph Myers Cc: Stepan Golosunov, libc-alpha, Arnd Bergmann, Carlos O'Donell, Alistair Francis [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define 2019-06-27 10:42 [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define Lukasz Majewski 2019-07-04 8:09 ` Lukasz Majewski @ 2019-07-08 11:23 ` Joseph Myers 2019-08-14 18:51 ` Alistair Francis 1 sibling, 1 reply; 8+ messages in thread From: Joseph Myers @ 2019-07-08 11:23 UTC (permalink / raw) To: Lukasz Majewski; +Cc: Stepan Golosunov, libc-alpha, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define 2019-07-08 11:23 ` Joseph Myers @ 2019-08-14 18:51 ` Alistair Francis 2019-08-16 0:10 ` Alistair Francis 0 siblings, 1 reply; 8+ messages in thread From: Alistair Francis @ 2019-08-14 18:51 UTC (permalink / raw) To: Joseph Myers Cc: Lukasz Majewski, Stepan Golosunov, GNU C Library, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define 2019-08-14 18:51 ` Alistair Francis @ 2019-08-16 0:10 ` Alistair Francis 2019-08-16 6:56 ` Lukasz Majewski 2019-08-16 15:49 ` Joseph Myers 0 siblings, 2 replies; 8+ messages in thread From: Alistair Francis @ 2019-08-16 0:10 UTC (permalink / raw) To: Joseph Myers Cc: Lukasz Majewski, Stepan Golosunov, GNU C Library, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define 2019-08-16 0:10 ` Alistair Francis @ 2019-08-16 6:56 ` Lukasz Majewski 2019-08-16 15:49 ` Joseph Myers 1 sibling, 0 replies; 8+ messages in thread From: Lukasz Majewski @ 2019-08-16 6:56 UTC (permalink / raw) To: Alistair Francis Cc: Joseph Myers, Stepan Golosunov, GNU C Library, Arnd Bergmann [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define 2019-08-16 0:10 ` Alistair Francis 2019-08-16 6:56 ` Lukasz Majewski @ 2019-08-16 15:49 ` Joseph Myers 2019-08-27 17:33 ` Alistair Francis 1 sibling, 1 reply; 8+ messages in thread From: Joseph Myers @ 2019-08-16 15:49 UTC (permalink / raw) To: Alistair Francis Cc: Lukasz Majewski, Stepan Golosunov, GNU C Library, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define 2019-08-16 15:49 ` Joseph Myers @ 2019-08-27 17:33 ` Alistair Francis 0 siblings, 0 replies; 8+ messages in thread From: Alistair Francis @ 2019-08-27 17:33 UTC (permalink / raw) To: Joseph Myers Cc: Lukasz Majewski, Stepan Golosunov, GNU C Library, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-27 17:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-27 10:42 [PATCH v8] y2038: Introduce __ASSUME_TIME64_SYSCALLS define Lukasz Majewski 2019-07-04 8:09 ` Lukasz Majewski 2019-07-08 11:23 ` Joseph Myers 2019-08-14 18:51 ` Alistair Francis 2019-08-16 0:10 ` Alistair Francis 2019-08-16 6:56 ` Lukasz Majewski 2019-08-16 15:49 ` Joseph Myers 2019-08-27 17:33 ` Alistair Francis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).