For a while now, the kernel's configuration and build systems have been an area of concern for me. Almost nobody truly understands those complex subsystems, which were handled by a single maintainer.

That maintainer, Masahiro Yamada, has just stepped down after eight years on the job:

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6841d5cb20

Happily, Nathan Chancellor and Nicolas Schier have agreed to pick up the build system. The configuration system, instead, is now unmaintained. That ... seems less than optimal.

Thanks to Masahiro for doing this work all these years, and to Nathan and Nicolas for stepping up!

@corbet

I feel the kernel project's general aversion to external dependencies and preference to use local tools (typically written in C) plays a part here.

I think by far the biggest success in switching the kernel documentation to Sphinx is not the tool nor the produced documentation, but making contributing to documentation accessible to more people. Everything else follows.

@corbet

Who is going to invest a lot of time in, say, kconfig, when it's only applicable to configuring the kernel? I've looked at it several times, and quickly steered clear. There's no reward.

Perhaps kconfig could attract more interest if it was a separate project, a generally useful tool?

I know there are no easy answers, and especially the kernel build dependencies are a contentious topic.

@jani @corbet Kconfig is used in other projects.

@geert @jani @corbet I was surprised to find kconfig copied+pasted into one of the bootloaders. uboot perhaps?

@jani @corbet just wanted to advertise the Python reimplementation (it's a shame to me that something like this isn't in the Linux tree):
https://github.com/ulfalizer/Kconfiglib/tree/master
Perhaps it could be ported from curses to a more modern console ui like textual.

@irogers @jani Interesting. It claims to be used by projects like Zephyr, but has no activity in five years...are those projects maintaining their own forks?

@corbet @jani @irogers kconfiglib has always been "vendored" in Zephyr https://github.com/zephyrproject-rtos/zephyr/commits/main/scripts/kconfig

@corbet it could have been worse, at least the maintainer did not suddenly go "off-grid" while not leaving any key behind... https://github.com/pypi/support/issues/2526

@llvm @geert @corbet

I was aware of at least buildroot using it, but copy-pasting something from kernel doesn't make it a real project of its own. There's no community, there's no contributions back.

@jani @geert @corbet ah, right it was buildroot! (We use that for kernel CI)

@irogers @corbet Very interesting, TIL.

@corbet I've recently been writing my own replacement for kconfig over at https://github.com/landley/toybox/blob/master/scripts/kconfig.c but the kernel community got toxic enough I stepped way the heck back from it in something like 2017. (And that was before kconfig became turing complete in 2018, so "make allnoconfig" could rm -rf your home directory. And developed lexx/yacc dependencies.)

@llvm @geert @jani @corbet
We do have a kconfig fork integrated in kdevops with yaml output support. This was not desirable upstream but it was the initial goal. FYI, here the RFC from @mcgrof:

https://lore.kernel.org/all/20240823034455.3593819-1-mcgrof@kernel.org/

@jani @llvm @geert @corbet kconfig is used by buildroot, uboot, busybox, uclibc and zephyr. Zephyr has a python reimplementation, all others are (probably) copy and pastes of various stages of the kernel kconfig system. So there's potential for a shared project here but this is also interacting with many projects that generally move very slow and especially so considering their configuration system.

Maybe the zephyr implementation has potential? I haven't looked at that in detail yet.

@Bubu @jani @geert @corbet a python reimplementation of kconfig sounds nice!

@nathanchance

And thanks for confirming that I was right about uboot!

@corbet Every build system I have worked with seems to be overcomplicated and yet also kind of hard to do simple-ish things in. I have therefore (reluctantly) decided this is actually a hard problem.