linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2017-11-16  9:04 UTC|newest]

Thread overview: 13+ 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 ` [PATCH 8/9] change time types to new y2038 safe __kernel_* types Deepa Dinamani
     [not found] ` <20171110224259.15930-1-deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-10 22:42   ` [PATCH 9/9] nanosleep: change time types to " Deepa Dinamani
2017-11-14 14:24 ` [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion Arnd Bergmann
2017-11-15 23:11   ` Deepa Dinamani
2017-11-16  9:04     ` Thomas Gleixner [this message]
2017-11-16 23:42       ` Arnd Bergmann
2017-11-17  8:58         ` Thomas Gleixner
2017-11-17  9:31           ` Arnd Bergmann
2017-11-17  9:54             ` Thomas Gleixner
2017-11-17 10:30               ` Arnd Bergmann
2017-11-17 10:40                 ` Thomas Gleixner
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;
as well as URLs for NNTP newsgroup(s).