From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] change dom0 headers path Date: Thu, 20 Apr 2006 08:55:14 -0500 Message-ID: <444792C2.7050703@us.ibm.com> References: <20060420123936.GA840@totally.trollied.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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, John Levon List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > > On 20 Apr 2006, at 13:39, John Levon wrote: > >> Fairly obviously, we need to clean up the hard-coded "linux" names used >> in includes. This is the first step in a number of changes around >> letting dom0 build on something other than Linux. >> >> What are the plans for these headers when the Linux kernel lives in some >> place other than the xen tree itself? We'd like to be able to share the >> structure definitions, but our ioctl values will differ from Linux's... > > I'd prefer an interfacing library (or libraries) that can target Linux > interfaces, Sun interfaces, etc. This would avoid inclusion of kernel > interface headers outside that shim library. > > Maybe this only needs to be done for evtchn interfaces. I would have > hoped that libxenctrl and libxenguest would hide privcmd interfaces. I > wonder why so many things include ? Because libxc "leaks" a few of the dom0_op structures like dom0_getvcpuinfo_t, dom0_shadow_control_stats_t, etc in its public interface. This could be fixed by making sure all of those structures had wrapper (like xc_dominfo_t). Regards, Anthony Liguori > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel