On Mon, 26 Jul 2010, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2 of 9] libxl: return
> libxl_dominfo from libxl_event_get_domain_death_info"):
> > if libxl should hide libxc then allowing clients to include a Xen header
> > is an even worse layering violation.
>
> I don't think so. The purpose of the doctrine that libxl callers
> should not need to call libxc is so that libxl is complete. And
> anything which libxc exports is contingent.
>
> I certainly think that libxl callers should not make Xen hypercalls,
> need to know SCHEDOP numbers, etc. etc. But I think it is OK for
> libxl to expose it its callers anything that forms part of the
> abstract interface to Xen guests. So that includes:
> * shutdown reasons
> * the difference between various kinds of HV and PV block devices
> (hda, xvda, sda, ...), including the facility to specify the
> actual xenstore interface combined PV block device number
> * the fact that a guest may have multiple consoles (PV and
> emulated serial) - even if the current toolstack implementation
> does not support all possible combinations
>
> The concrete interface (event channels, rings, frame numbers, etc.)
> should remain opaque but there is no point abstracting away and
> translating the numerical values of a Xen public enum whose
> semantics we _do_ want to expose.
>
enum alone would OK, but most header files contains other stuff as well,
so including features.h would be fine but including platform.h would not.
In order to have a clear policy we should just say that including Xen
header files should be avoided.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home