Re: [PATCH 4/5] sched_ext: Drop "ops" from scx_ops_exit(), scx_ops_error() and friends

[Andrea Righi <arighi@nvidia.com>]

On Thu, Apr 03, 2025 at 12:49:46PM -1000, Tejun Heo wrote:
> The tag "ops" is used for two different purposes. First, to indicate that
> the entity is directly related to the operations such as flags carried in
> sched_ext_ops. Second, to indicate that the entity applies to something
> global such as enable or bypass states. The second usage is historical and
> causes confusion rather than clarifying anything. For example,
> scx_ops_enable_state enums are named SCX_OPS_* and thus conflict with
> scx_ops_flags. Let's drop the second usages.
> 
> Drop "ops" from scx_ops_exit(), scx_ops_error() and friends.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
...
> @@ -1043,18 +1043,17 @@ static struct kobject *scx_root_kobj;
>  
>  static void process_ddsp_deferred_locals(struct rq *rq);
>  static void scx_bpf_kick_cpu(s32 cpu, u64 flags);
> -static __printf(3, 4) void scx_ops_exit_kind(enum scx_exit_kind kind,
> -					     s64 exit_code,
> -					     const char *fmt, ...);
> +static __printf(3, 4) void __scx_exit(enum scx_exit_kind kind, s64 exit_code,
> +				      const char *fmt, ...);
>  
> -#define scx_ops_error_kind(err, fmt, args...)					\
> -	scx_ops_exit_kind((err), 0, fmt, ##args)
> +#define __scx_error(err, fmt, args...)						\
> +	__scx_exit((err), 0, fmt, ##args)
>  

Can we move scx_error() here, right after __scx_error(), for better
readability?

> -#define scx_ops_exit(code, fmt, args...)					\
> -	scx_ops_exit_kind(SCX_EXIT_UNREG_KERN, (code), fmt, ##args)
> +#define scx_exit(code, fmt, args...)						\
> +	__scx_exit(SCX_EXIT_UNREG_KERN, (code), fmt, ##args)
>  
> -#define scx_ops_error(fmt, args...)						\
> -	scx_ops_error_kind(SCX_EXIT_ERROR, fmt, ##args)
> +#define scx_error(fmt, args...)							\
> +	__scx_error(SCX_EXIT_ERROR, fmt, ##args)

I've always found scx_exit_kind / exit_code a bit confusing, scx_exit_kind
represents the reason of the exit, while exit_code is an additional code to
describe the error.

Not necessarily for this patch set, but what do you think about renaming
scx_exit_kind to scx_exit_reason and scx_exit_reason() to
scx_exit_reason_str()?

Thanks,
-Andrea