From: Johannes Berg <johannes@sipsolutions.net>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
backports@vger.kernel.org, linux-kernel@vger.kernel.org,
yann.morin.1998@free.fr, mmarek@suse.cz, sassmann@kpanic.de
Subject: Re: [PATCH v2 09/13] backports: define C code backport version info using CPTCFG_
Date: Wed, 05 Nov 2014 22:20:58 +0100 [thread overview]
Message-ID: <1415222458.7485.14.camel@sipsolutions.net> (raw)
In-Reply-To: <20141105202923.GR12953@wotan.suse.de>
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.
johannes
next prev parent reply other threads:[~2014-11-05 21:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 3:18 [PATCH v2 00/13] backports: add kernel integration support Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 01/13] backports: move legacy and SmPL patch application into helper Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 02/13] backports: ifdef around module_init() module_exit() for modules Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 03/13] backports: allow for different backport prefix Luis R. Rodriguez
2014-11-05 7:46 ` Johannes Berg
2014-11-05 9:16 ` Luis R. Rodriguez
2014-11-05 9:22 ` Johannes Berg
2014-11-05 19:42 ` Luis R. Rodriguez
2014-11-05 21:17 ` Johannes Berg
2014-11-05 22:21 ` Luis R. Rodriguez
2014-11-05 23:09 ` Andi Kleen
2014-11-05 23:15 ` Luis R. Rodriguez
2014-11-05 23:31 ` Andi Kleen
2014-11-05 3:18 ` [PATCH v2 04/13] backports: replace BACKPORT_PWD with BACKPORT_DIR Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 05/13] backports: use BACKPORT_DIR prefix on kconfig sources Luis R. Rodriguez
2014-11-05 7:51 ` Johannes Berg
2014-11-05 20:11 ` Luis R. Rodriguez
2014-11-05 21:19 ` Johannes Berg
2014-11-05 22:22 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 06/13] backports: update dependencies map file Luis R. Rodriguez
2014-11-05 7:54 ` Johannes Berg
2014-11-05 20:13 ` Luis R. Rodriguez
2014-11-05 21:20 ` Johannes Berg
2014-11-05 22:23 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 07/13] backports: split Kconfig into Kconfig.package and Kconfig.sources Luis R. Rodriguez
2014-11-05 7:55 ` Johannes Berg
2014-11-05 20:14 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 08/13] backports: move version file generation to run earlier Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 09/13] backports: define C code backport version info using CPTCFG_ Luis R. Rodriguez
2014-11-05 7:57 ` Johannes Berg
2014-11-05 20:29 ` Luis R. Rodriguez
2014-11-05 21:20 ` Johannes Berg [this message]
2014-11-05 22:27 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 10/13] backports: add backport version parsing for kernel integration Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 11/13] backports: prefix c-file / h-file auto backport with BPAUTO Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 12/13] backports: remove extra BACKPORT_ prefix from kernel versioning Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 13/13] backports: add full kernel integration support Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1415222458.7485.14.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=backports@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=mmarek@suse.cz \
--cc=sassmann@kpanic.de \
--cc=yann.morin.1998@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.