[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.