On Tue, May 28, 2024 at 10:33:10AM GMT, Michal Suchánek wrote:
On Tue, May 28, 2024 at 03:34:35PM +0800, Shung-Hsi Yu wrote:
sched-ext is a BPF extensible scheduler class that aims to make experimentation and exploration easier (among other goals). It currently live as out-of-tree Linux Kernel patchset[1], but has been either already in-use or considered by Valve, Meta/Oculus, and ChromOS[1].
Fredrik (Lönnegren) is currently working on it in home:flonnegren:sched-ext. While that works, it would certainly be nice to have its own project to host both the kernel and associated userspace[2] components. Given it is kernel-related, I naturally gravitates towards having a "Kernel:sched-ext" subproject and from there have Kernel:sched-ext:HEAD (akin to Kernel:HEAD) and Kernel:sched-ext:stable (akin to Kernel:stable). @Kernel project maintainers do you think that can be considered?
I do not think making sched-ext work available in a project under Kernel makes it any easier for people to use it than installing from a home project.
The Kernel project makes use of the kbuild automation to upload the content of the kernel-source git tree. Since you do not maintain the sched-ext in kernel-source there is no reason to share that project.
Thanks for the explanation, fair points. Kernel project should be for content of kernel-source and sched-ext doesn't fit in there. Regarding development project vs home project, let me pivot a bit. Yes, there's no different when it comes to installion, but a development project offers a sense of credibility that home project cannot, and hint that it is a group effort that will be continuously maintained, rather than a one-shot attempt (only time will tell though (: ). Again, it's a nice to have; not having a development project certainly does not prevent us from working on sched-ext. Shung-Hsi