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

On Fri, 2006-05-26 at 10:30 -0500, Hollis Blanchard wrote:
> On Fri, 2006-05-26 at 15:28 +0100, Ian Campbell wrote:
> > On Fri, 2006-05-26 at 16:32 +0300, Muli Ben-Yehuda wrote:
> > > > I assume you're referring specifically to the privcmd structure change,
> > > > which is the only Linux-specific part of the patch. The privcmd
> > > > structure is shared between userspace and the kernel. Since "u64" is a
> > > > kernel type, we need to use "uint64_t", which has meaning in
> > > > userspace.
> > > 
> > > Oh well, I didn't realize it was shared with userspace... sorry for
> > > the false alarm.
> > 
> > I think Linus' opinion[0] is that kernel headers which are shared with
> > userspace cannot assume that stdint.h has been included so you need to
> > use __u64 and friends.
> > 
> > Ian.
> > 
> > [0] http://www.ussg.iu.edu/hypermail/linux/kernel/0412.1/1456.html.
> > There's been plenty of other traffic in lkml about it too.
> There certainly has been plenty of traffic, but I have seen no clear
> statements (other than "THIS IS BAD" with little explanation). In fact
> there was just a thread about it this month
> (http://www.ussg.iu.edu/hypermail/linux/kernel/0605.0/0146.html), and I
> still don't understand the objections.
> If you use __u64, you'd need to include some header defining what __u64
> is, so you're requiring another header anyways. You might as well use
> the standard stdint.h rather than inventing your own.

As I understand it the issue is that the C spec makes the __* namespace
available for the kernel to pollute and reserves the non-prefixed
namespace for application usage. (Single underscore is for compiler or
libc internals or something).

An application which has not included stdint.h itself can expect to use
uint64_t however it wishes, including making it a struct, a function or
even something as gross as a 32 bit signed int etc. Exporting some other
idea of what uint64_t should be via the kernel headers breaks this. I
guess this is more of a problem when a kernel header gets indirectly
included -- presumably an app which includes a kernel header directly
knows what it is doing.

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


Xen-devel mailing list