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 13:33:40 -0700
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	"backports@...r.kernel.org" <backports@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Yann E. MORIN" <yann.morin.1998@...e.fr>,
	Michal Marek <mmarek@...e.cz>,
	Stefan Assmann <sassmann@...nic.de>
Subject: Re: [RFC v2 1/4] backports: replace CPTCFG prefix for CONFIG_BACKPORT

On Fri, Oct 31, 2014 at 1:22 PM, Johannes Berg
<johannes@...solutions.net> wrote:
> On Fri, 2014-10-31 at 20:34 +0100, Luis R. Rodriguez wrote:
>
>> > 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_ ?

Hm, OK well let me give it a shot, at compilation time which approach
are we going to use? I don't like the idea of having two different
sets of naming approaching for packaging and integration, however I
can see how that might be useful for determining where some code might
come from or how backports was used, but other than that we would need
to pick if we're going to support the integration naming scheme also
for packaging as an option or just use CPTCFG for it. If the same
naming scheme is an option then that means we either have to test both
or leave one untested. This is why I ultimately would prefer we just
stick to one approach for both.

The fact that CPTCFG has same length as CONFIG really has no empirical
value, its just cosmetic, meanwhile I am however more concerned with
the above and I think its worth some serious consideration.

> 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.

That's a good point, I take it that it does not matter which one we
pick for each, so long as its different? If so I think CONFIG_BACKPORT
is pretty clear for things we carry over like device drivers, but this
is just subjective and so long as we pick something I think it'll be
fine.

I do believe the harder thing to decide is the above possible
divergence thing and if we can agree on that I think the rest of the
series is not as controversial.

  Luis
--
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/