[RFC] remove C schedulers from this repository

[etsal]

C schedulers have historically been used as a demonstration of how to start writing scheduler code, but as the ecosystem has matured are no longer representative of how we develop schedulers. Keeping the C schedulers solely in the kernel removes the need to support a C-based build system and toolchain in this repo, and avoids confusing newcomers who may try to deploy or hack on our example C schedulers we've had.

Any C schedulers missing from the kernel will be added to tools/sched_ext along with the rest.

EDIT: Please see comment in this thread for more details.

[oxyzenQ]

😵‍💫

[arighi]

Honestly I'd prefer to keep the C schedulers in the repo, some devs are not familiar with Rust and may want to create a scheduler in C. Having the C schedulers as template / examples is useful. Also for quick experimentation, it is so much easier to create a C scheduler than a Rust one.

[likewhatevs]

Keeping the C schedulers solely in the kernel removes the need to support a C-based build system and toolchain in this repo, and avoids confusing newcomers who may try to deploy or hack on our example C schedulers we've had.

If the motivation is to get rid of meson/complexity, maybe replace meson with a (few?) Makefile(s?)?

[oxyzenQ]

keep C scheduler or for alternative.

[etsal]

Updating with the discussion we had during scx office hours:

1. The ability to write and load C schedulers is not going away. This is just a change to separate the C schedulers from the Rust schedulers because they share almost no code, and effectively function as separate repos.
2. Existing schedulers will all go in tools/sched_ext. We will "lose" no schedulers in the process.
3. C schedulers are still nice for prototyping, so there is a case for keeping a C scheduler repository. We can keep a (read-only) separate scx-c-examples repository in this org.

[etsal]

Honestly I'd prefer to keep the C schedulers in the repo, some devs are not familiar with Rust and may want to create a scheduler in C. Having the C schedulers as template / examples is useful. Also for quick experimentation, it is so much easier to create a C scheduler than a Rust one.

Another followup from the office hours discussion today: https://github.com/etsal/scx-c-examples should be a self-contained repo for C schedulers that can be used for experimentation. We can add it to the org as a repo, and if we find out there is interest from people to contribute complex C schedulers that would be difficult to add into the tools/sched_ext directory we can place them there.