From: Paul Bolle <pebolle@tiscali.nl>
To: Arnd Bergmann <arnd@arndb.de>
Cc: y2038@lists.linaro.org, baolin.wang@linaro.org,
tglx@linutronix.de, albert.aribaud@3adev.fr,
john.stultz@linaro.org, bamvor.zhangjian@linaro.org,
ruchandani.tina@gmail.com, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: [PATCH 00/19] converting system calls to 64-bit time_t, part 1
Date: Thu, 07 May 2015 11:24:53 +0200 [thread overview]
Message-ID: <1430990693.8171.70.camel@x220> (raw)
In-Reply-To: <2330671.lQAl76KQcx@wuerfel>
On Thu, 2015-05-07 at 10:52 +0200, Arnd Bergmann wrote:
> On Thursday 07 May 2015 09:39:18 Paul Bolle wrote:
> I realize the downsides of not posting the entire series at once
> here, but it seemed better to avoid spamming everyone too much,
> while I try to find out if we have agreement on the overall
> strategy.
That downside is worse when people only quickly skim your message for
clues while thinking about the problem they _think_ they've spotted
(like I did).
> For reference, see below for the ARM patch.
> > And then it occurred to me to check the y2038-syscalls git branch you
> > referenced. After which the above made much more sense. (Though my
> > remark that ARCH_HAS_COMPAT_TIME simply functions as an alias for COMPAT
> > also seems to hold for that branch.)
>
> Right, in fact both of these happen at the end of the git tree.
Still, you might consider making ARCH_HAS_COMPAT_TIME a plain bool and
adding "select ARCH_HAS_COMPAT_TIME" to the eight or so COMPAT entries.
But, clearly, I'm now wasting even more of your time by trying to save
face here.
Thanks,
Paul Bolle
prev parent reply other threads:[~2015-05-07 9:25 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 16:30 [PATCH 00/19] converting system calls to 64-bit time_t, part 1 Arnd Bergmann
2015-05-06 16:30 ` [PATCH 01/19] compat: remove compat_printk Arnd Bergmann
2015-05-06 16:30 ` [PATCH 02/19] initramfs: use vfs_stat/lstat directly Arnd Bergmann
2015-05-06 16:30 ` [PATCH 03/19] y2038: introduce linux/compat_time.h header Arnd Bergmann
2015-05-06 16:30 ` [PATCH 04/19] y2038: introduce CONFIG_COMPAT_TIME Arnd Bergmann
2015-05-06 16:30 ` [PATCH 05/19] y2038: make linux/compat_time.h usable on 32-bit Arnd Bergmann
2015-05-06 16:30 ` [PATCH 06/19] y2038: compile compat time code even when CONFIG_COMPAT is not set Arnd Bergmann
2015-05-06 16:30 ` [PATCH 07/19] y2038: add compat_sys_rt_sigtimedwait variants Arnd Bergmann
2015-05-06 16:30 ` [PATCH 08/19] y2038: introduce struct __kernel_timespec Arnd Bergmann
2015-05-06 16:30 ` [PATCH 09/19] y2038: introduce struct __kernel_stat Arnd Bergmann
2015-05-06 16:30 ` [PATCH 10/19] y2038: use __kernel_stat for sys_newstat syscalls Arnd Bergmann
2015-05-06 16:30 ` [PATCH 11/19] y2038: introduce and use struct __kernel_rusage Arnd Bergmann
2015-05-06 16:30 ` [PATCH 12/19] y2038: add compat_{get,put}_timespec64 Arnd Bergmann
2015-05-06 16:30 ` [PATCH 13/19] y2038: add compat handling for sys_semtimedop Arnd Bergmann
2015-05-15 22:46 ` Thomas Gleixner
2015-05-16 7:28 ` Arnd Bergmann
2015-05-16 19:54 ` Arnd Bergmann
2015-05-19 9:19 ` Thomas Gleixner
2015-05-06 16:30 ` [PATCH 14/19] y2038: use __kernel_timespec for sys_mq_timed{send,receive} Arnd Bergmann
2015-05-06 16:30 ` [PATCH 15/19] y2038: introduce timespec64_to_jiffies Arnd Bergmann
2015-05-19 9:28 ` Thomas Gleixner
2015-05-06 16:30 ` [PATCH 16/19] y2038: use __kernel_timespec in sys_rt_sigtimedwait Arnd Bergmann
2015-05-19 9:28 ` Thomas Gleixner
2015-05-06 16:30 ` [PATCH 17/19] y2038: use __kernel_timespec in sys_futex Arnd Bergmann
2015-05-15 22:53 ` Thomas Gleixner
2015-05-16 7:21 ` Thomas Gleixner
2015-05-19 9:24 ` Thomas Gleixner
2015-05-06 16:30 ` [PATCH 18/19] y2038: introduce jiffies_to_timespec64 Arnd Bergmann
2015-05-19 9:25 ` Thomas Gleixner
2015-05-06 16:30 ` [PATCH 19/19] y2038: use __kernel_timespec in sys_sched_rr_get_interval Arnd Bergmann
2015-05-19 9:27 ` Thomas Gleixner
2015-05-07 7:27 ` [PATCH 00/19] converting system calls to 64-bit time_t, part 1 Paul Bolle
2015-05-07 7:39 ` Paul Bolle
2015-05-07 8:52 ` Arnd Bergmann
2015-05-07 9:24 ` Paul Bolle [this message]
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=1430990693.8171.70.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=albert.aribaud@3adev.fr \
--cc=arnd@arndb.de \
--cc=bamvor.zhangjian@linaro.org \
--cc=baolin.wang@linaro.org \
--cc=john.stultz@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ruchandani.tina@gmail.com \
--cc=tglx@linutronix.de \
--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