This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [patch] [3/3] dom0_ops explicitly sized types

To: Hollis Blanchard <hollisb@xxxxxxxxxx>
Subject: Re: [Xen-devel] [patch] [3/3] dom0_ops explicitly sized types
From: Chris Wright <chrisw@xxxxxxxxxxxx>
Date: Fri, 26 May 2006 11:57:46 -0700
Cc: Muli Ben-Yehuda <muli@xxxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>, xen-ppc-devel@xxxxxxxxxxxxxxxxxxx, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Delivery-date: Fri, 26 May 2006 11:55:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1148665048.26643.12.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1148511175.26460.35.camel@xxxxxxxxxxxxxxxxxxxxx> <1148511400.26460.39.camel@xxxxxxxxxxxxxxxxxxxxx> <1148511874.26460.47.camel@xxxxxxxxxxxxxxxxxxxxx> <20060525153957.GO6710@xxxxxxxxxxxx> <1148583731.15517.16.camel@xxxxxxxxxxxxxxxxxxxxx> <20060526133221.GA5569@xxxxxxxxxxxxxxxxx> <1148653733.24768.49.camel@xxxxxxxxxxxxxxxxxxxxx> <1148657437.26643.5.camel@xxxxxxxxxxxxxxxxxxxxx> <1148660853.24768.97.camel@xxxxxxxxxxxxxxxxxxxxx> <1148665048.26643.12.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/
* Hollis Blanchard (hollisb@xxxxxxxxxx) wrote:
> On Fri, 2006-05-26 at 17:27 +0100, Ian Campbell wrote:
> > 
> > Anyway, regardless of any opinion expressed here the Linux gatekeepers
> > will no doubt insist on __uN. We might as well do it now as change it
> > later.
> And where will userspace, e.g. tools/libxc/xc_linux.c, find the
> definition of __u64?

Same place they do for the rest of shared headers (glib-kernheaders,
for example).  Please use the proper form (u64 internal to kernel, and
__u64 for header visisble to userspace).  I'm going to have to clean it
up anyway.


Xen-devel mailing list