[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 2 of 9] libxl: return libxl_dominfo from libxl_event_get_domain_death_info
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