lists.openwall.net   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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 26 Nov 2020 15:38:38 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Boris Kolpackov <boris@...esynthesis.com>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Johannes Berg <johannes@...solutions.net>,
        Felix Fietkau <nbd@...nwrt.org>,
        Patrick Franz <patfra71@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Junio C Hamano <gitster@...ox.com>,
        linux-kernel@...r.kernel.org
Subject: Re: kconfig as a git subtree on Linux

On Thu, Nov 26, 2020 at 12:38:41PM +0200, Boris Kolpackov wrote:
> Luis Chamberlain <mcgrof@...nel.org> writes:
> 
> > 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.
> 
> I am maintaining one such copy/fork[1] and for me the effort to pull
> in the new version of upstream (which I currently do by just copying
> scripts/kconfig/*) is nothing compared to the effort of maintaining
> a set of patches[2] on top of that which are necessary to make kconfig
> buildable on other platforms and usable with other build systems.
> 
> So unless there is also an agreement that such portability patches
> are now welcome, this is not going to be a major improvement for me.

Unless you have tried git subtrees, I doubt you really mean this. How
is a 'make refresh' command as comparable as manually pulling in
changes from a project to your project?

> And right now such patches are clearly not welcome[3] (but no hard
> feelings; I wouldn't touch Windows with a ten-foot pole if I could
> help it).

Portability of kconfig to other platorm is a topic of its own. If that
sort of conversation can exist, I think it would have to be *secondary*
to deciding whether or not kconfig lives on its own to allow other
Linux projects to benefit from it.

  Luis

Powered by blists - more mailing lists