[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
|
