On 15.11.2023 13:54, Oleksii wrote:
> On Wed, 2023-11-15 at 11:00 +0100, Jan Beulich wrote:
>> On 10.11.2023 17:30, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/monitor.h
>>> @@ -0,0 +1,62 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * include/asm-GENERIC/monitor.h
>>> + *
>>> + * Arch-specific monitor_op domctl handler.
>>> + *
>>> + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
>>> + * Copyright (c) 2016, Bitdefender S.R.L.
>>> + *
>>> + */
>>> +
>>> +#ifndef __ASM_GENERIC_MONITOR_H__
>>> +#define __ASM_GENERIC_MONITOR_H__
>>> +
>>> +#include <xen/sched.h>
>>
>> What is this needed for? I expect ...
>>
>>> +struct xen_domctl_monitor_op;
>>> +
>>> +static inline
>>> +void arch_monitor_allow_userspace(struct domain *d, bool
>>> allow_userspace)
>>
>> ... struct domain, but since you never de-reference any such pointer,
>> forward-
>> declaring that (just like struct xen_domctl_monitor_op) would do
>> here. Which
>> would leave you with needing at most xen/types.h, but maybe as little
>> as
>> xen/stdbool.h and xen/stdint.h.
> Yes, the reason for " #include <xen/sched.h> " was ' struct domain '.
> Let's switch to forward-declaring.
> 
> Shouldn't it be included <xen/compiler.h> too for inline?

I'm actually not sure why we (still?) override "inline" there. It's a
normal keyword in C99. IOW I don't think xen/compiler.h would be
needed here (just for that).

Jan

Reply via email to