[lkml]   [2020]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kconfig as a git subtree on Linux
On Thu, Nov 26, 2020 at 2:25 AM Luis Chamberlain <> wrote:
> I'd like to propose we discuss the possibility of taking kconfig and
> making it a git subtree under the Linux kernel. This would allow
> other projects outside of the Linux kernel to be able to update their
> own copy / fork of kconfig in a jiffie *very* easily.
> Why? kconfig has far outlived its own purpose as a modeling variablity
> language hack on the Linux kernel, and *is* forked and *used* by *many*
> projects, to the point I think ignoring its use outside of the Linux
> kernel is doing a disservice to its own growth. Counting just personal
> projects I have 3 projects which use kconfig alone. Last time I counted
> about 30 or so external projects. I'm confident this is a shy number
> of today's reality.
> Yes this does beg the question, that if this is done, can / should
> this be considered elsewhere. And yes, I'd like to hear the rants
> about why this would be a completely unacceptable practice *at all*.
> I've been using git subtrees now for another project and I'm *very*
> happy with it so far. It lets me keep a project with some code on
> its own git tree, and then multiple third party trees can embrace
> it, and decide to update later whenever they want. An example is the
> update_ssh_config [0] python script which I use on kdevops [1] for
> vagrant, but since it is also used for terraform and terraform uses
> modules I ended up sharing the code for terraform for its own
> terrarorm module [2] [3]. I do most development and unit testing
> on the main update_ssh_config git tree, and when I want to integrate
> its changes into kdevops I just run:
> make refresh
> This is because on kdevops I have:
> $ cat Makefile.subtrees
> # If you need to use a git subtree, please add it here.
> add-remotes:
> git remote add update_ssh_config
> add-commits:
> git subtree add --prefix=playbooks/roles/update_ssh_config_vagrant/update_ssh_config update_ssh_config master
> refresh:
> git fetch update_ssh_config git subtree pull --prefix=playbooks/roles/update_ssh_config_vagrant/update_ssh_config update_ssh_config master
> Likewise for my terraform module, however there I just have these
> targets on my make Makefile. A person who first git cloned either the
> kdevops tree of the terraform module tree would first have to run the
> targets:
> * make add-remotes
> * make add-commits
> Today's process for updating kconfig on external projects requires
> substrantial manual oversight.
> [0]
> [1]
> [2]
> [3]
> Luis

I want to keep Kconfig in the kernel tree.

Other projects can throw in scripts/kconfig/,
but in some cases, they might need some adjustments
for their use.

Kconfig is almost standalone, but in reality,
there are some interactions between the build system
and kconfig.

I want to reserve the freedom for optimizations
that span across both kbuild and kconfig.

For example,


If we split Kconfig out as a standalone project,
such optimizations would become difficult.

A long time has passed since the Kconfig introduction, but
the Kconfig implementation is still in an immature state, in my opinion.

I want to fix them, and some of them are done
in a way that breaks backward compatibility.

In such cases, I fix in-kernel Kconfig files first,
and then, I fix the kconfig implementation.

For example,

Fix users: 8636a1f9677db4f883f29a072f401303acfc2edd
Fix Kconfig: f5451582c4e22ce8912aae4950810f3598c9b516

Fix users: df8df5e4bc37e39010cfdf5d50cf726fe08aae5b
Fix Kconfig: 09d5873e4d1f70202314b5fe40160f9b14b9d2d0

I can proceed confidently because we have Kconfig files
and scripts/kconfig in the same tree, and I can
do build tests easily.

Again, if we split Kconfig as a standalone project,
I would need to care about which projects would be
affected by such changes, say, not only Linux but also
dozens of projects, which I do not know much about.

Best Regards
Masahiro Yamada

 \ /
  Last update: 2020-11-28 23:39    [W:0.083 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site