Re: [PATCH v2 sched_ext/for-6.19] sched_ext: Use ___v2 suffix for new kfuncs and fix scx build errors

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, Oct 22, 2025 at 09:38:14PM +0200, Andrea Righi wrote:
...
> Ahh ok, so user-space schedulers will always continue to pass all the
> arguments "normally" and we just assemble the args struct via an inline
> helper.
> 
> So, IIUC, using an _argpack suffix or something similar (instead of ___v2)
> should be a reasonable solution, right?

Yeah, something with less than three underscores as that has a different
meaning (ignore when matching).

> > Here, there is no noticeable feature difference before and after for
> > existing schedulers, so I don't think it's necessary to introduce __COMPAT
> > prefix.
> 
> The problem is that some schedulers (i.e., scx_bpfland, scx_cosmos) are
> explicitly checking bpf_ksym_exists(scx_bpf_select_cpu_and). If
> scx_bpf_select_cpu_and() becomes a static inline, we break the build and we
> also break binary compatibility. Hence the __COMPAT for the inline
> helpers...

Hmm... binary compatibility shouldn't break as the original
scx_bpf_select_cpu_and() is still there, right? Build breaks because now the
symbol is an inline one, but the solution there, I think, is either
providing a __COMPAT macro which helps testing the availability of
scx_bpf_select_cpu_and() or just making them test the ___compat symbol,
right? ie. kernel API changes aren't required to guarantee source level
backward compatibility (like how we did the dsq_insert renames) as long as
it provides a way to maintain both forward and backward binary
compatibility.

Thanks.

-- 
tejun