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] change dom0 headers path

On Thu, Apr 20, 2006 at 03:31:09PM +0100, Keir Fraser wrote:

> >That's exactly what the patch as-is allows for: libxc/xen/dom0/ is only
> >created on Linux. If you'd prefer me to always create libxc/xen/linux/,
> >then make a dom0/ symlink point at it, that's fine, but it's kind of
> >pointless since it wouldn't get used on non-Linux anyway. It was also
> >one reason I was asking about plans for when linux sparse tree doesn't
> >exist.
> >
> >Or maybe I've got the wrong end of the stick; what are you proposing?
> 
> Well, it depends how much commonality we think there will be between 
> different OS's header files in future. 

I suppose it also depends on the future of the ioctl() interface in
Linux, as Anthony pointed out to me. To a large degree how much sharing
can really happen depends strongly on how these interfaces end up. We
already have some differences in the xenbus driver to replace
/proc/xen/xsd_{kva,port}.

> If the details are hidden inside libxc then it wouldn't hurt to
> guarantee very little at the kernel and have libxc include from linux/
> or solaris/ directly depending on how it is targetted at compile time.
> I'm not keen on the name dom0/ anyway -- those headers (particularly
> evtchn.h) are applicable to other domains too.

So, something more like:

libxc/xc_linux.c
libxc/xc_solaris.c
libxc/xen/linux/
libxc/xen/solaris/

with:

1) all the stuff hidden back into libxc
2) Makefile gubbins to -I the right path and pick the right C file

This seems workable for us.

regards,
john

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