From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: [PATCH 00 of 32 RFC] libxl: drop device_model_info, better defaults support, stubdoms by default Date: Mon, 16 Jan 2012 12:14:58 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: ian.jackson@citrix.com List-Id: xen-devel@lists.xenproject.org My original intention with this series was to introduce the ability for users of libxl to explicitly say "pick the default". Mainly by introducing the libxl_defbool type but also by arranging more generally that leaving a value set to zero means "default". However it turned into something of a yakk shaving excercise and so contains the following: * Removes support for comments in the IDL language itself. Generating comments in the generated files is not all that useful so lets just use source level comments in the .idl instead. * Switches to using keyword arguments for Fields in Aggregate types instead of a variadic tuple. * Removes libxl_device_model_info from the library API. The use of a device model to supply specific features is really an implementation detail within the library and not something users of the library should need to be concerned with. Many of the fields of the struct we really guest configuration details, e.g. VNC setup and therefore belong in libxl_domain_build_info. This struct also contained a number of things which were duplicated from the build_info and which could never sensibly differ in this context (e.g. guest total RAM, ACPI on off etc). I have tried to make a determination whether something belongs in the global part of libxl_domain_build_info or whether it is HVM specific. This forms a big part of the series. * Introduce libxl_defbool and switch to using it. * Some other changes to arrange that the 0 value means "default". At least one instance of this (the timer_mode enum) introduces a wierd disconnect between the underlying values and the libxl exposed values. I'm not sure that I like this. * Use device model stubdoms by default when possible. One question which arised from this change is how we deal with per-arch options in the future. Do we need to define libxl_domain_build_info_x86? We could also tag fields with a list of architectures. This series has been lightly tested with PV domains (with and without PVFB) and HVM domains (with and without stubdom).