On Thu, Nov 26, 2020 at 2:25 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> 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 https://github.com/mcgrof/update_ssh_config.git > > 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] https://github.com/mcgrof/update_ssh_config > [1] https://github.com/mcgrof/kdevops/ > [2] https://github.com/mcgrof/terraform-kdevops-add-host-ssh-config > [3] https://registry.terraform.io/modules/mcgrof/add-host-ssh-config/kdevops/latest > > 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, 058507195b534e6a1b3e8bf716b816ecf090c9c3 8b41fc4454e36fbfdbb23f940d023d4dece2de29 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
