Re: [Xen-devel] [PATCH 2 of 9] libxl: return libxl_dominfo from libxl_event_get_domain_death_info

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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