From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: pointers in public headers Date: Fri, 25 Aug 2006 16:13:06 +0100 Message-ID: <44EF2FA2.76E4.0078.0@novell.com> References: <44EF142F.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >Io/xs_wire.h does not define a hypervisor interface so no need for guest >handles there. Good. >The rest are all x86-specific, and represent pointers that >don't really cleanly fit into the guest handle model and its accessor >macros. Since on x86 the guest handle stuff is really only an enforcement >method for ensuring we use the correct accessors I just left the tricky few >as they were. Are you trying to macro/typedef the world for compat >compilation, and these are annoying for you? :-) If so we could hide them >behind a different macro -- we'd need to do that anyway to avoid breaking >API compatibility. Yes, they present a lurking problem once the converted structures get accessed - clearly any kind of pointer is invalid when considering compatibility mode guests. I could certainly try to make the script catch them and convert them (to a integer type), but then the automation of copying the respective fields will trigger compiler warnings about converting integrals to/from pointers of different size. So, yes, some kind of macro would help, but I can't see how you would want to get away with not breaking API compatibility (which requires to leave a pointer in there somehow) but eliminating the pointer. Jan