[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tools/ocaml/libs/xc: add OCaml stubs to query CPU policy


  • To: Christian Lindig <christian.lindig@xxxxxxxxxx>
  • From: Edwin Torok <edvin.torok@xxxxxxxxxx>
  • Date: Fri, 18 Jun 2021 13:42:54 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=govfGUbBDrKO4hTp6bLafsGHvf3JHixr+3zDBDqBrBU=; b=mz122f3vQJeCGXMHAOTY3Eqnj9vjzEq679LhcNVl1Gnf9mcJdgJgtkbFSpnhlD+aHiIwnSc6l7iIxb85WK87VWtCkYkkCiszoIYwlNykqfr8WsrPpB6GEj+cY8N74tL4mRT4QyQDzJFyQedaHxjUY03BF81kKWro8vrWCRxA3gPYANfiIW5b9zwRjBQPF8Wdkkv68LmdwUaWA4tiU8hb4+AyoWJhp9frwr4nLzmRf2pVOvj4tIuR+B5YfI6YxoigL3RLkr8vZTku7UFm1Azn8T0Pl8AFPdjjAYbdYGZVhvnL5Wbu/rSemkLDchwIsSjuEsLGMs9zE9uAkJLrFbjpaQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aFo4MsSPIc1U1onEpdxIv4LKjnROBEtXeYOCkACrA9fQQ4U74OzVooXIP0aG6JM7vlojPWTVOOtvgRAWHb1/DyvNHGDS1Reu+olvISwoG3ra2HvqMA4Wg5itEuccVxvZmKvxzTe0A3lIqEnJfO5cPmvIBrMGIRARdat+aE63mcfFGaIsKHHm34rqPa7IWc9347HtaQg/Sjk8OImI2cAcf0sFfjOiVgFGRtAa24xYDHaSpaSS221fT/MdK+uRK57tiebJeebZSw8uqCQJv+xz1Hq2XT9XTp3ToCk2XYazCpEOH/SXVCy4vnenoeAnQbMKCA5yDPPGZSR3dgS2YWvXgg==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "David Scott" <dave@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Delivery-date: Fri, 18 Jun 2021 13:43:01 +0000
  • Ironport-hdrordr: A9a23:ufgPI6i3nf09o/bp44b6Yl0M1HBQXrkji2hC6mlwRA09TyX4ra CTdZEgviMc5wx9ZJhNo7q90cq7IE80i6Qb3WB5B97LYOCMggeVxe9Zg7ff/w==
  • Ironport-sdr: rrWpM8aFJu+vYM+CJMbUuEq6gLcdEzeTajbB7gXQ048oG368LK4Wli37xzyyYW9Ur1DxJLg7xD pF0+zLMIBfE/y8WjjKK34jOyTOIrjxtgw0KPpaYU0sY79xr7joD2eTty4bQU5D/nRVXTS02dkt dquEzdPNOPRmiHrW3euG05toSy6723yG8dV2s+UlHzNQdBub0IoyaFWO2GC/mdqf/w76ECdFUO z6eNvPAbmpZuy5PRlwY7fj7+d3EJG7xAaEI+4Gf0AFeizT6T472/K305jziYxkACuEYx23nV8R DUE=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXZC8pdx4Fbe3SD0u2mLoPzHVclasZvgMAgAAJS4A=
  • Thread-topic: [PATCH] tools/ocaml/libs/xc: add OCaml stubs to query CPU policy


> On 18 Jun 2021, at 14:09, Christian Lindig <christian.lindig@xxxxxxxxxx> 
> wrote:
> 
> 
> 
>> On 18 Jun 2021, at 11:45, Edwin Török <edvin.torok@xxxxxxxxxx> wrote:
>> 
>> Introduces following functions in Xenctrl and associated types:
>> get_system_cpu_policy
>> cpu_policy_to_featureset,
>> string_of_xen_cpu_policy_index
>> 
>> These are wrappers around the existing C functions in xenctrl.h,
>> that will be used by xenopsd initially.
>> 
>> -Wno-declaration-after-statement is disabled to allow mixing
>> declarations and code to simplify writing the stubs
>> by using variable length arrays on the stack instead of
>> allocating/freeing memory
>> (which would require additional error-handling logic).
>> 
>> Signed-off-by: Edwin Török <edvin.torok@xxxxxxxxxx>
>> ---
>> tools/ocaml/libs/xc/Makefile        |   2 +-
>> tools/ocaml/libs/xc/xenctrl.ml      |  37 ++++++
>> tools/ocaml/libs/xc/xenctrl.mli     |  71 ++++++++++
>> tools/ocaml/libs/xc/xenctrl_stubs.c | 195 ++++++++++++++++++++++++++++
>> 4 files changed, 304 insertions(+), 1 deletion(-)
> 
> Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
> 
>> 
>> +static CAMLprim value Val_leaves(const xen_cpuid_leaf_t *leaves, uint32_t 
>> nr_leaves)
>> +{
>> +    CAMLparam0();
>> +    CAMLlocal1(result);
>> +    uint32_t i;
>> +
>> +    result = caml_alloc(nr_leaves, 0);
>> +    for (i=0;i<nr_leaves;i++)
>> +        Store_field(result, i, Val_cpuid_leaf(&leaves[i]));
>> +
>> +    CAMLreturn(result);
>> +}
> 
> Is  caml_alloc(nr_leaves, 0) the right allocation? The 0 is the tag. There is 
> another instance of this below. What is the type of the returned value from 
> an OCaml perspective?


It is an array, so I think tag 0 is. Right (that is what the implementation of 
call_alloc_array does too). I could perhaps try to use caml_alloc_array instead 
to make this more obvious.


Best regards,
—Edwin

> 
> — C


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.