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