WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch] [3/3] dom0_ops explicitly sized types
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Fri, 26 May 2006 12:32:35 -0500
Cc: Muli Ben-Yehuda <muli@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ppc-devel@xxxxxxxxxxxxxxxxxxx, Hollis Blanchard <hollisb@xxxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 26 May 2006 10:33:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1148660853.24768.97.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: <1148509900.26460.22.camel@xxxxxxxxxxxxxxxxxxxxx> <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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.2 (X11/20060522)
Ian Campbell wrote:
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).

The relevant portions of the spec are:


     7.1.3 Reserved identifiers



      [#1] Each header declares or defines all identifiers  listed
      in  its  associated  subclause,  and  optionally declares or
      defines identifiers listed in its associated future  library
      directions   subclause  and  identifiers  which  are  always
      reserved either for  any  use  or  for  use  as  file  scope
      identifiers.

         - All identifiers  that  begin  with  an  underscore  and
           either  an  uppercase  letter or another underscore are
           always reserved for any use.

         - All identifiers  that  begin  with  an  underscore  are
           always  reserved  for  use as macros and as identifiers
           with file scope in  both  the  ordinary  and  tag  name
           spaces.

         - Each macro name in  any  of  the  following  subclauses
           (including  the  future library directions) is reserved
           for use as specified if any of its  associated  headers
           is  included;  unless  explicitly stated otherwise (see
           7.1.8 <http://www.vmunix.com/%7Egabor/c/draft.html#7.1.8>).

         - All identifiers with external linkage  in  any  of  the
           following  subclauses  (including  the  future  library
           directions) are always reserved for use as  identifiers
           with external linkage.133

         - Each identifier with file scope listed in  any  of  the
           following  subclauses  (including  the  future  library
           directions) is reserved for use  as  macro  and  as  an
           identifier  with  file  scope in the same name space if
           any of its associated headers is included.

      [#2] No other identifiers  are  reserved.   If  the  program
      declares  or  defines an identifier that is reserved in that
      context (other than as allowed by 7.1.8 
<http://www.vmunix.com/%7Egabor/c/draft.html#7.1.8>),  the  behavior  is
      undefined.134


It's pretty clear that __* names are reserved. The kernel is wrong here. The best explanation I've gotten is "egocentrism" :-)

Regards,

Anthony Liguori

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


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