lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Nov 2020 17:25:44 +0000
From:   Luis Chamberlain <>
To:     Masahiro Yamada <>
Cc:     Linux Kbuild mailing list <>,
        Masahiro Yamada <>,
        Boris Kolpackov <>,
        Johannes Berg <>,
        Felix Fietkau <>,
        Patrick Franz <>,
        Ingo Molnar <>,
        Arnaldo Carvalho de Melo <>,
        Junio C Hamano <>,,
Subject: kconfig as a git subtree on Linux

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.
	git remote add update_ssh_config

	git subtree add --prefix=playbooks/roles/update_ssh_config_vagrant/update_ssh_config update_ssh_config master

	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

   * make add-remotes
   * make add-commits

Today's process for updating kconfig on external projects requires
substrantial manual oversight.



Powered by blists - more mailing lists