From: Thomas Gleixner <tglx@linutronix.de>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
"open list:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
Peter Zijlstra <peterz@infradead.org>,
Stefan Haberland <sth@linux.vnet.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux <sparclinux@vger.kernel.org>,
devel@driverdev.osuosl.org,
linux-s390 <linux-s390@vger.kernel.org>,
y2038 Mailman List <y2038@lists.linaro.org>,
Helge Deller <deller@gmx.de>,
the arch/x86 maintainers <x86@kernel.org>,
sebott@linux.vnet.ibm.com,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Will Deacon <will.deacon@arm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
oprofile-list@lists.sf.net,
Catalin Marinas <catalin.marinas@arm.com>,
linux-arch <linux-arch@vger.kernel.org>,
Robert Richter <rric@kernel.org>, Chris Metcalf <cmetc>
Subject: Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Date: Thu, 16 Nov 2017 10:04:00 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1711160958430.2191@nanos> (raw)
In-Reply-To: <CABeXuvpy1jbqjeUFHHX-MrJXQLA2QNYbAa6OX7qOpPp4q-mQYQ@mail.gmail.com>
On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> > I had on concern about x32, maybe we should check
> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec
> > bits.
>
> Thanks, I think you are right. I had the check conditional on
> CONFIG_64BIT_TIME and then removed as I forgot why I added it. :)
>
> > Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would
> > it help to just leave out that part for now and unconditionally
> > define '__kernel_timespec' as 'timespec' until we are ready to
> > convert the architectures?
>
> Another approach would be to use separate configs:
>
> 1. To indicate 64 bit time_t syscall support. This will be dependent
> on architectures as CONFIG_64BIT_TIME.
> We can delete this once all architectures have provided support for this.
>
> 2. Another config (maybe COMPAT_32BIT_TIME?) to be introduced later,
> which will compile out all syscalls/ features that use 32 bit time_t.
> This can help build a y2038 safe kernel later.
>
> Would this work for everyone?
Having extra config switches which are selectable by architectures and
removed when everything is converted is definitely the right way to go.
That allows you to gradually convert stuff w/o inflicting wreckage all over
the place.
Thanks,
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
John Stultz <john.stultz@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
y2038 Mailman List <y2038@lists.linaro.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Chris Metcalf <cmetcalf@mellanox.com>,
cohuck@redhat.com, David Miller <davem@davemloft.net>,
Helge Deller <deller@gmx.de>,
devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com,
gregkh <gregkh@linuxfoundation.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Jan Hoeppner <hoeppner@linux.vnet.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Julian Wiedmann <jwi@linux.vnet.ibm.com>,
Linux API <linux-api@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
"open list:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
Parisc List <linux-parisc@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Ingo Molnar <mingo@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
oberpar@linux.vnet.ibm.com, oprofile-list@lists.sf.net,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <peterz@infradead.org>,
Ralf Baechle <ralf@linux-mips.org>,
Steven Rostedt <rostedt@goodmis.org>,
Robert Richter <rric@kernel.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
sebott@linux.vnet.ibm.com,
sparclinux <sparclinux@vger.kernel.org>,
Stefan Haberland <sth@linux.vnet.ibm.com>,
Ursula Braun <ubraun@linux.vnet.ibm.com>,
Will Deacon <will.deacon@arm.com>,
the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Date: Thu, 16 Nov 2017 10:04:00 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1711160958430.2191@nanos> (raw)
Message-ID: <20171116090400.kT1QO2egMSI8yN9TBQxwmGSjV4XqjgkeccV9h_5Qpx8@z> (raw)
In-Reply-To: <CABeXuvpy1jbqjeUFHHX-MrJXQLA2QNYbAa6OX7qOpPp4q-mQYQ@mail.gmail.com>
On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> > I had on concern about x32, maybe we should check
> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec
> > bits.
>
> Thanks, I think you are right. I had the check conditional on
> CONFIG_64BIT_TIME and then removed as I forgot why I added it. :)
>
> > Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would
> > it help to just leave out that part for now and unconditionally
> > define '__kernel_timespec' as 'timespec' until we are ready to
> > convert the architectures?
>
> Another approach would be to use separate configs:
>
> 1. To indicate 64 bit time_t syscall support. This will be dependent
> on architectures as CONFIG_64BIT_TIME.
> We can delete this once all architectures have provided support for this.
>
> 2. Another config (maybe COMPAT_32BIT_TIME?) to be introduced later,
> which will compile out all syscalls/ features that use 32 bit time_t.
> This can help build a y2038 safe kernel later.
>
> Would this work for everyone?
Having extra config switches which are selectable by architectures and
removed when everything is converted is definitely the right way to go.
That allows you to gradually convert stuff w/o inflicting wreckage all over
the place.
Thanks,
tglx
next prev parent reply other threads:[~2017-11-16 9:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 22:42 [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion Deepa Dinamani
2017-11-10 22:42 ` Deepa Dinamani
2017-11-10 22:42 ` [PATCH 6/9] include: Add new y2038 safe __kernel_timespec Deepa Dinamani
2017-11-14 14:24 ` [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion Arnd Bergmann
2017-11-14 14:24 ` Arnd Bergmann
2017-11-15 23:11 ` Deepa Dinamani
2017-11-15 23:11 ` Deepa Dinamani
2017-11-16 9:04 ` Thomas Gleixner [this message]
2017-11-16 9:04 ` Thomas Gleixner
2017-11-16 23:42 ` Arnd Bergmann
2017-11-16 23:42 ` Arnd Bergmann
2017-11-17 8:58 ` Thomas Gleixner
2017-11-17 8:58 ` Thomas Gleixner
2017-11-17 9:31 ` Arnd Bergmann
2017-11-17 9:31 ` Arnd Bergmann
2017-11-17 9:54 ` Thomas Gleixner
2017-11-17 9:54 ` Thomas Gleixner
2017-11-17 10:30 ` Arnd Bergmann
2017-11-17 10:30 ` Arnd Bergmann
2017-11-17 10:40 ` Thomas Gleixner
2017-11-17 10:40 ` Thomas Gleixner
2017-11-17 10:46 ` Arnd Bergmann
2017-11-17 10:46 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1711160958430.2191@nanos \
--to=tglx@linutronix.de \
--cc=borntraeger@de.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=deepa.kernel@gmail.com \
--cc=deller@gmx.de \
--cc=devel@driverdev.osuosl.org \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=jejb@parisc-linux.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-s390@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=oprofile-list@lists.sf.net \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rric@kernel.org \
--cc=sebott@linux.vnet.ibm.com \
--cc=sparclinux@vger.kernel.org \
--cc=sth@linux.vnet.ibm.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox