| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 2 of 9] libxl: return libxl_dominfo from libxl_ev
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
|
|
|
| |
|
Home