search for: libxl_string_list

Following series cleans up a few niggles in the libxl destructor autogeneration. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...17 17:51:32 2012 +0100 @@ -21,8 +21,7 @@ def randomize_enum(e): return random.choice([v.name for v in e.values]) handcoded = ["libxl_cpumap", "libxl_key_value_list", - "libxl_cpuid_policy_list", "libxl_file_reference", - "libxl_string_list"] + "libxl_cpuid_policy_list", "libxl_string_list"] def gen_rand_init(ty, v, indent = " ", parent = None): s = "" @@ -179,13 +178,6 @@ static void libxl_cpuid_policy_list_rand *pp = p; } -static void libxl_file_reference_ra...

The series introduces auto-generation of the type definitions used in the libxl interface followed by auto-generation of a destructor function for each type. In the future it may be possible to use the related data structures for other purposes, for example auto-generation of the functions to marshal between C and language binding data types. tools/_libxl_types.h should be identical both before

...ck", namespace="libxl_") +libxl_console_constype = Number("console_constype", namespace="libxl_") +libxl_disk_phystype = Number("disk_phystype", namespace="libxl_") +libxl_nic_type = Number("nic_type", namespace="libxl_") libxl_string_list = Builtin("string_list", destructor_fn="libxl_string_list_destroy", passby=PASS_BY_REFERENCE) libxl_key_value_list = Builtin("key_value_list", destructor_fn="libxl_key_value_list_destroy", passby=PASS_BY_REFERENCE) @@ -85,7 +85,7 @@ libxl_file_reference = St...

The following series flushes my documentation queue and replaces previous postings of those patches. The main difference is that the xl cfg file is now formatted using POD instead of markdown and presented as a manpage. I have setup a cron job to build docs/html and publish it at http://xenbits.xen.org/docs/unstable/ (it''s a bit bare right now). The motivation for some of these patches

The following series of patches fill in most of the gaps in the OCaml bindings to libxl, to make them useful for clients such as xapi/xenopsd (from XCP). There are a number of bugfixes to the existing bindings as well. I have an experimental version of xenopsd that successfully uses the new bindings. An earlier version of the first half of the series was submitted to the last by Ian Campbell on

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

Hello, Third version of the NUMA placement series Xen 4.2. All the comments received during v2''s review have been addressed (more details in single changelogs). The most notable changes are the following: - the libxl_cpumap --> libxl_bitmap renaming has been rebased on top of the recent patches that allows us to allocate bitmaps of different sizes; - the heuristics for deciding

This patch set adds XSM security labels to useful debugging output locations, and fixes some assumptions that all interrupts behaved like GSI interrupts (which had useful non-dynamic IDs). It also cleans up the policy build process and adds an example of how to use the user field in the security context. Debug output: [PATCH 01/10] xsm: Add security labels to event-channel dump [PATCH 02/10] xsm: