From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure Date: Tue, 21 Apr 2015 16:57:18 +0200 Message-ID: <3231171.5TrYVVBLh4@wuerfel> References: <1429509459-17068-1-git-send-email-baolin.wang@linaro.org> <3755355.Xf0HbltZXg@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Thomas Gleixner Cc: pang.xunlei@linaro.org, peterz@infradead.org, heiko.carstens@de.ibm.com, paulus@samba.org, cl@linux.com, heenasirwani@gmail.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, y2038@lists.linaro.org, rafael.j.wysocki@intel.com, ahh@google.com, fweisbec@gmail.com, pjt@google.com, riel@redhat.com, richardcochran@gmail.com, tj@kernel.org, john.stultz@linaro.org, rth@twiddle.net, Baolin Wang , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, schwidefsky@de.ibm.com, linux390@de.ibm.com, linuxppc-dev@lists.ozlabs.org List-Id: linux-arch.vger.kernel.org T24gVHVlc2RheSAyMSBBcHJpbCAyMDE1IDE2OjE0OjI2IFRob21hcyBHbGVpeG5lciB3cm90ZToK PiA+IE5vdGUgdGhlIHVzZSBvZiBhIHNlcGFyYXRlIF9fa2VybmVsX2l0aW1lcnNwZWM2NCBmb3Ig dGhlIHVzZXIgaW50ZXJmYWNlCj4gPiBoZXJlLCB3aGljaCBJIHRoaW5rIHdpbGwgYmUgbmVlZGVk IHRvIGhpZGUgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlCj4gPiBub3JtYWwgaXRpbWVyc3Bl YyBvbiA2NC1iaXQgbWFjaGluZXMsIGFuZCB0aGUgbmV3IGl0aW1lcnNwZWMgb24gMzItYml0Cj4g PiBwbGF0Zm9ybXMgdGhhdCB3aWxsIGJlIGRlZmluZWQgZGlmZmVyZW50bHkgKHVzaW5nICdsb25n IGxvbmcnKS4KPiAKPiBDb25mdXNlZC4KPiAKPiB0aW1lc3BlYzY0IC8gaXRpbWVyc3BlYzY0IHNo b3VsZCBiZSB0aGUgc2FtZSBpbmRlcGVuZGVudCBvZiA2NGJpdCBhbmQKPiAzMmJpdC4gU28gd2h5 IGRvIHdlIG5lZWQgYW5vdGhlciB2YXJpYW50ID8KClRoZXJlIGFyZSBtdWx0aXBsZSByZWFzb25z OgoKKiBPbiA2NC1iaXQgc3lzdGVtcywgdGltZXNwZWM2NCB3b3VsZCBhbHdheXMgYmUgZGVmaW5l ZCBpbiB0aGUgc2FtZSB3YXkKICBhcyBzdHJ1Y3QgdGltZXNwZWMgeyBfX2tlcm5lbF90aW1lX3Qg dHZfc2VjOyBsb25nIHR2X25zZWM7IH0sIHdpdGgKICBfX2tlcm5lbF90aW1lX3QgYmVpbmcgJ2xv bmcnLiBPbiAzMi1iaXQsIHdlIHByb2JhYmx5IG5lZWQgdG8gbWFrZSBib3RoCiAgbWVtYmVycyAn bG9uZyBsb25nJyBmb3IgdGhlIHVzZXIgc3BhY2Ugc2lkZSwgaW4gb3JkZXIgdG8gc2hhcmUgdGhl CiAgc3lzY2FsbCBpbXBsZW1lbnRhdGlvbiB3aXRoIHRoZSBrZXJuZWwgc2lkZSwgYnV0IHdlIG1h eSBhbHNvIHdhbnQgdG8KICBrZWVwIHRoZSBpbnRlcm5hbCB0aW1lc3BlYzY0IHVzaW5nIGEgJ2xv bmcnIGZvciB0dl9uc2VjLCBhcyB3ZSBkbwogIHRvZGF5LiBUaGlzIG1lYW5zIHRoYXQgYm90aCB0 aGUgYmluYXJ5IGxheW91dCAocGFkZGluZyBvciBubyBwYWRkaW5nKQogIGFuZCB0aGUgYmFzaWMg dHlwZXMgKGxvbmcgb3IgbG9uZyBsb25nKSBhcmUgZGlmZmVyZW50IGJldHdlZW4gMzItYml0CiAg YW5kIDY0LWJpdCwgYW5kIGJldHdlZW4ga2VybmVsIGFuZCB1c2VyIHNwYWNlCiogV2Ugc2hvdWxk IG5vdCBwdXQgJ3N0cnVjdCB0aW1lc3BlYzY0JyBpbnRvIHRoZSB1c2VyIHNwYWNlIG5hbWVzcGFj ZSwKICBhcyBhcHBsaWNhdGlvbnMgbWlnaHQgYWxyZWFkeSB1c2UgdGhhdCBpZGVudGlmaWVyLiBU aGlzIGlzIHNpbWlsYXIKICB0byB0aGUgX191MzIvdTMyIG9yIF9fa2VybmVsX3RpbWVfdC90aW1l X3QgdHVwbGUgb2YgdHlwZXMgZm9yIGludGVyZmFjZQogIGFuZCBpbi1rZXJuZWwgdXNlcy4gVGhp cyBpcyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IHdoZW4gZW1iZWRkaW5nIGEKICB0aW1lc3BlYyBp biBhbm90aGVyIGRhdGEgc3RydWN0dXJlLgoqIE15IHBsYW4gaXMgdG8gdXNlIGEgdGVtcG9yYXJ5 IGhhY2sgd2hlcmUgSSBhY3R1YWxseSBkZWZpbmUKICBfX2tlcm5lbF90aW1lc3BlYzY0IHRvIGxv b2sgbGlrZSB0aGUgMzItYml0IHZlcnNpb24gb2YgdGltZXNwZWMsCiAgYXMgYW4gaW50ZXJtZWRp YXRlIHN0ZXAgd2hlbiBjb252ZXJ0aW5nIGFsbCAzMi1iaXQgYXJjaGl0ZWN0dXJlcyBvdmVyCiAg dG8gdXNlIHRoZSBjb21wYXRfKigpIHN5c2NhbGxzIGluIHBsYWNlIG9mIHRoZSBleGlzdGluZyBv bmVzLCBzbwogIEkgY2FuIGNoYW5nZSBvdmVyIHRoZSBub3JtYWwgc3lzY2FsbHMgdG8gdXNlIF9f a2VybmVsX3RpbWVzcGVjNjQKICB3aXRob3V0IGhhdmluZyB0byBjaGFuZ2UgYWxsIGFyY2hpdGVj dHVyZXMgYXQgb25jZSwgb3IgaGF2aW5nIHRvCiAgbW9kaWZ5IGVhY2ggc3lzY2FsbCBtdWx0aXBs ZSB0aW1lcy4KCj4gPiBJIHdvdWxkIGFsc28gcHJlZmVyIG5vdCB0b28gbWFueSBwZW9wbGUgdG8g d29yayBvbiB0aGUgc3lzY2FsbHMsIGFuZAo+ID4gd291bGQgcmF0aGVyIGhhdmUgQmFvbGluIG5v dCB0b3VjaCBhbnkgb2YgdGhlIHN5c2NhbGwgcHJvdG90eXBlcyBmb3IKPiA+IHRoZSBtb21lbnQu Cj4gCj4gSSBkaWQgbm90IGFzayBoaW0gdG8gY2hhbmdlIGFueSBvZiB0aGUgc3lzY2FsbCBwcm90 b3R5cGVzLiBJIGp1c3QKPiB3YW50ZWQgaGltIHRvIHNwbGl0IG91dCB0aGUgZ3V0cyBvZiB0aGUg c3lzY2FsbCBpbnRvIGEgc2VwZXJhdGUgc3RhdGljCj4gZnVuY3Rpb24gdG8gYXZvaWQgYWxsIHRo YXQgY29kZSBjaHVybi4KCk9rLCBJIHdhc24ndCBzdXJlIGFib3V0IHRoYXQgcGFydCwgdGhhbmtz IGZvciBjbGFyaWZ5aW5nLgoKCUFybmQKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KTGludXhwcGMtZGV2IG1haWxpbmcgbGlzdApMaW51eHBwYy1kZXZAbGlz dHMub3psYWJzLm9yZwpodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vbGludXhwcGMt ZGV2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de ([212.227.17.10]:55376 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750714AbbDUO7K (ORCPT ); Tue, 21 Apr 2015 10:59:10 -0400 From: Arnd Bergmann Subject: Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure Date: Tue, 21 Apr 2015 16:57:18 +0200 Message-ID: <3231171.5TrYVVBLh4@wuerfel> In-Reply-To: References: <1429509459-17068-1-git-send-email-baolin.wang@linaro.org> <3755355.Xf0HbltZXg@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Thomas Gleixner Cc: y2038@lists.linaro.org, Baolin Wang , pang.xunlei@linaro.org, peterz@infradead.org, benh@kernel.crashing.org, heiko.carstens@de.ibm.com, paulus@samba.org, cl@linux.com, heenasirwani@gmail.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, mpe@ellerman.id.au, rafael.j.wysocki@intel.com, ahh@google.com, fweisbec@gmail.com, pjt@google.com, riel@redhat.com, richardcochran@gmail.com, schwidefsky@de.ibm.com, john.stultz@linaro.org, rth@twiddle.net, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, tj@kernel.org, linux390@de.ibm.com, linuxppc-dev@lists.ozlabs.org Message-ID: <20150421145718.UmGPYBKOkWyKdATN_0Ka6zpPRJXvtOgp71sIREpT-Is@z> On Tuesday 21 April 2015 16:14:26 Thomas Gleixner wrote: > > Note the use of a separate __kernel_itimerspec64 for the user interface > > here, which I think will be needed to hide the differences between the > > normal itimerspec on 64-bit machines, and the new itimerspec on 32-bit > > platforms that will be defined differently (using 'long long'). > > Confused. > > timespec64 / itimerspec64 should be the same independent of 64bit and > 32bit. So why do we need another variant ? There are multiple reasons: * On 64-bit systems, timespec64 would always be defined in the same way as struct timespec { __kernel_time_t tv_sec; long tv_nsec; }, with __kernel_time_t being 'long'. On 32-bit, we probably need to make both members 'long long' for the user space side, in order to share the syscall implementation with the kernel side, but we may also want to keep the internal timespec64 using a 'long' for tv_nsec, as we do today. This means that both the binary layout (padding or no padding) and the basic types (long or long long) are different between 32-bit and 64-bit, and between kernel and user space * We should not put 'struct timespec64' into the user space namespace, as applications might already use that identifier. This is similar to the __u32/u32 or __kernel_time_t/time_t tuple of types for interface and in-kernel uses. This is particularly important when embedding a timespec in another data structure. * My plan is to use a temporary hack where I actually define __kernel_timespec64 to look like the 32-bit version of timespec, as an intermediate step when converting all 32-bit architectures over to use the compat_*() syscalls in place of the existing ones, so I can change over the normal syscalls to use __kernel_timespec64 without having to change all architectures at once, or having to modify each syscall multiple times. > > I would also prefer not too many people to work on the syscalls, and > > would rather have Baolin not touch any of the syscall prototypes for > > the moment. > > I did not ask him to change any of the syscall prototypes. I just > wanted him to split out the guts of the syscall into a seperate static > function to avoid all that code churn. Ok, I wasn't sure about that part, thanks for clarifying. Arnd