[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
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. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |