|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 18/24] XSM: make XSM hooks well-formed ones
On 7/28/26 9:22 AM, Jan Beulich wrote: For whatever reason they didn't have an xsm_default_t first argument (to cope with XSM=n mode), making it impossible to (easily) cover them in xsm/hooks.h. flask_do_xsm_op() is also changed to return int, as all the function ever returns is an int. This way no new machinery needs adding to xsm/hooks.h. Instead one piece of compat machinery can then be dropped from xsm/flask/flask_op.c. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> --- Instead of XSM_HOOK, using XSM_OTHER may also be a sensible option here. I would say XSM_HOOK is sufficient since at this point it doesn't matter what op is passed the dummy policy is just going to return the same value. If the dummy policy is extended to support an op, then at that point the implementer can switch it to XSM_OTHER. Question is whether some/all of the other hooks still declared explicitly in struct xsm_ops should follow suit. I would say either comment these are exceptions or make them consistent, though I haven't studied if there would be any consequences (doubtful) changing the others. --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -439,7 +439,7 @@ static XSM_INLINE int xsm_hypfs_op(XSM_D#ifdef CONFIG_XSM -static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)+static XSM_INLINE int xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op) With this change, should there be a comment that the int is going to get cast to long before return?
Acked-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |