linux-kernel - Re: [PATCH v2 09/13] backports: define C code backport version info using CPTCFG

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]

Message-ID: <20141105222737.GV12953@wotan.suse.de>
Date:	Wed, 5 Nov 2014 23:27:37 +0100
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Johannes Berg <johannes@...solutions.net>
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: [PATCH v2 09/13] backports: define C code backport version
	info using CPTCFG_

On Wed, Nov 05, 2014 at 10:20:58PM +0100, Johannes Berg wrote:
> On Wed, 2014-11-05 at 21:29 +0100, Luis R. Rodriguez wrote:
> 
> > > What difference does this make? It'll break some scripting that we have
> > > for sure (assuming the BACKPORTED_ prefix), so naturally I'd like to see
> > > why it is necessary.
> > 
> > Sure, let me explain. So if we don't unify we will have to end up with defines
> > for some packaging version scheme to another. The approach I took here was to
> > minimize impact on on userspace side generation side of things and only
> > affect the target C code by modifying the Makefile to define variables
> > we can share. That's pretty much it. I ended up defining things with
> > CPTCFG_ as that will get morphed to the other bp_prefix later for us
> > when integrating. That lets us share it.
> > 
> > Addressing this on scripts that do rely on touching C / H files should
> > just be a matter of doing a direct translation to 3 variables.
> 
> In this particular case I'm not really sure I see why it needs to be
> morphed at all?
> 
> Anyway, I realized that the whole thing doesn't matter as much to me as
> I thought it does, we just have to adjust the one place that changes our
> versions file.

If you don't mind the collateral I hope you'd trust me that the alternative
is ugglier. I will note now, since we'll prbably forget later, that this
will also require quite a bit of thought when and if multiple integrations
will be supported. For now sharing the versioning info for packaging and
integration is at least making the code generic between the two.

 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/