linux-kernel - Re: [RFC v2 1/4] backports: replace CPTCFG prefix for CONFIG

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 linux-cve-announce 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:	Fri, 31 Oct 2014 21:22:23 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	backports@...r.kernel.org, linux-kernel@...r.kernel.org,
	yann.morin.1998@...e.fr, mmarek@...e.cz, sassmann@...nic.de
Subject: Re: [RFC v2 1/4] backports: replace CPTCFG prefix for
 CONFIG_BACKPORT

On Fri, 2014-10-31 at 20:34 +0100, Luis R. Rodriguez wrote:

> > I really think you need to make this optional for the in-tree
> > generation, otherwise it will complicate things a lot for anyone who's
> > already using backports in a way that doesn't have it regenerated all
> > the time.
> 
> Logistically I do agree this will implicate tons of merge conflicts
> if a git tree was used for development based on backports, however
> functionally I don't expect this this to create divergence.

Agree, but it's going to be a nightmare from the merge point of view,
and also the CPTCFG_ is nicer to replace back and forth between
backports-based development and the kernel, due to this:

> > Additionally, CPTCFG_ had the advantage of having the same length as
> > CONFIG_, so code style wise it was nicer to replace.



> > Please make this a post-process step that runs on everything, including
> > the backport stuff, rather than running only on the source and assuming
> > the backport stuff already uses this convention.
> 
> I want to but lets consider the amount of work to maintain the two
> separate approaches, is it worth it?

I don't see why it'd be maintaining two approaches? Right now we have
scripting to replace CONFIG_ with CPTCFG_, so couldn't we just add more
scripting to replace CPTCFG_ with CONFIG_BACKPORT_ ?

That also makes me think of something else - we currently use BACKPORT_
as a prefix for some of the other stuff under compat/Kconfig, and in
fact rename some things (like CONFIG_BACKPORT_AVERAGE) so maybe also
using CONFIG_BACKPORT_ here isn't a great idea? Might want to use
something else, say CONFIG_BPT_ or so.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/