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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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
later.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel