From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [PATCH 01/24] types: create Date: Fri, 25 Apr 2008 13:28:58 -0600 Message-ID: <20080425192858.GM14990@parisc-linux.org> References: <1209078352-7593-1-git-send-email-hpa@zytor.com> <1209078352-7593-2-git-send-email-hpa@zytor.com> <1209078352-7593-3-git-send-email-hpa@zytor.com> <20080425185251.GL14990@parisc-linux.org> <48122CB0.7020003@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <48122CB0.7020003-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> Sender: linux-arch-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: To: "H. Peter Anvin" Cc: Linus Torvalds , Jan Engelhardt , Andrew Morton , Linux Kernel Mailing List , Linux Arch Mailing List On Fri, Apr 25, 2008 at 12:10:40PM -0700, H. Peter Anvin wrote: > Well, compatibility with userspace is probably one aspect of that. > x86-64 is the odd man out there, it defines __s64 as "long long" even > for userspace, even though int64_t from is "long". This, > IMO, is the Wrong Thing, but it's a separate set of changes. > > The right thing to do is probably to always use "long long" in the > kernel, while defining __s64 et al as "long" on 64-bit platforms when > not under __KERNEL__. > > Again, this is a separate set of changes from this patchset, which is > just a code transformation. Understood, and agreed. It just seemed like an opportune time to mention the problem of printing a u64. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from palinux.external.hp.com ([192.25.206.14]:34488 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753319AbYDYT27 (ORCPT ); Fri, 25 Apr 2008 15:28:59 -0400 Date: Fri, 25 Apr 2008 13:28:58 -0600 From: Matthew Wilcox Subject: Re: [PATCH 01/24] types: create Message-ID: <20080425192858.GM14990@parisc-linux.org> References: <1209078352-7593-1-git-send-email-hpa@zytor.com> <1209078352-7593-2-git-send-email-hpa@zytor.com> <1209078352-7593-3-git-send-email-hpa@zytor.com> <20080425185251.GL14990@parisc-linux.org> <48122CB0.7020003@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48122CB0.7020003@zytor.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: "H. Peter Anvin" Cc: Linus Torvalds , Jan Engelhardt , Andrew Morton , Linux Kernel Mailing List , Linux Arch Mailing List Message-ID: <20080425192858.T8BgWMvzAT6xkW5eWaOPW0_NHgHccBqWpym69K75G5w@z> On Fri, Apr 25, 2008 at 12:10:40PM -0700, H. Peter Anvin wrote: > Well, compatibility with userspace is probably one aspect of that. > x86-64 is the odd man out there, it defines __s64 as "long long" even > for userspace, even though int64_t from is "long". This, > IMO, is the Wrong Thing, but it's a separate set of changes. > > The right thing to do is probably to always use "long long" in the > kernel, while defining __s64 et al as "long" on 64-bit platforms when > not under __KERNEL__. > > Again, this is a separate set of changes from this patchset, which is > just a code transformation. Understood, and agreed. It just seemed like an opportune time to mention the problem of printing a u64. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."