mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: Michal Marek <mmarek@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>, Rusty Russell <rusty@ozlabs.org>,
	"David Howells" <dhowells@redhat.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] MODSIGN: Avoid using .incbin in C source
Date: Wed, 5 Dec 2012 10:30:58 +0000	[thread overview]
Message-ID: <50BF2262.7080603@imgtec.com> (raw)
In-Reply-To: <20121205095057.GA26543@sepie.suse.cz>

On 05/12/12 09:50, Michal Marek wrote:
>> How about the revised patch below?
> [...]
>> diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S
>> new file mode 100644
>> index 0000000..695d4e3
>> --- /dev/null
>> +++ b/kernel/modsign_certificate.S
>> @@ -0,0 +1,18 @@
>> +#ifndef SYMBOL_PREFIX
>> +#define ASM_SYMBOL(sym) sym
>> +#else
>> +#define PASTE2(x,y) x##y
>> +#define PASTE(x,y) PASTE2(x,y)
>> +#define ASM_SYMBOL(sym) PASTE(SYMBOL_PREFIX, sym)
>> +#endif
> 
> 
> It looks good, but looking at your patch, I just noticed that we have two
> versions of the SYMBOL_PREFIX macro in the kernel now:
> 
> scripts/Makefile.lib has had since some time
> 
> ifdef CONFIG_SYMBOL_PREFIX
> _sym_flags = -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
> _cpp_flags += $(_sym_flags)
> _a_flags += $(_sym_flags)
> endif
> 
> while include/linux/kernel.h now has
> 
> /* This helps us to avoid #ifdef CONFIG_SYMBOL_PREFIX */
> #ifdef CONFIG_SYMBOL_PREFIX
> #define SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
> #else
> #define SYMBOL_PREFIX ""
> #endif
> 
> So depending on whether you include <linux/kernel.h> or not,
> SYMBOL_PREFIX expands to either a string or a token. James, Rusty, how
> about the patch below? If Takashi's patch is applied first, then
> obviously the modsign_pubkey.c part should be dropped and the ASM_SYMBOL
> definition in modsign_certificate.S can be simplified instead.
> 
> Michal
> 
> From df545c46fb89c085387f4d98c7a4fb06a7f678a9 Mon Sep 17 00:00:00 2001
> From: Michal Marek <mmarek@suse.cz>
> Date: Wed, 5 Dec 2012 10:03:15 +0100
> Subject: [PATCH] linux/kernel.h: Avoid conflicting SYMBOL_PREFIX definition
> 
> scripts/Makefile.lib already defines SYMBOL_PREFIX to the token _ if
> CONFIG_SYMBOL_PREFIX is defined. Drop the string definition in
> linux/kernel.h and change scripts/Makefile.lib to define SYMBOL_PREFIX
> on all architectures.

Hi Michal,

Yeh, that looks good to me, and I like it just being automatically
defined rather than having to include linux/kernel.h (potentially from
low level architecture headers too).

However I think it's unfortunate having to stringify from C as it's
pretty much always required to be in string form when used from a C
file, usually in an asm block. Any objection to defining SYMBOL_PREFIX
with the quotes around it for _c_flags only? E.g. see below

Cheers
James

> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index bdf42fd..1138e77 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -119,11 +119,10 @@ _c_flags += $(if $(patsubst n%,, \
>  		$(CFLAGS_GCOV))
>  endif
>  
> -ifdef CONFIG_SYMBOL_PREFIX
>  _sym_flags = -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
> -_cpp_flags += $(_sym_flags)
> +_c_flags += $(_sym_flags)
>  _a_flags += $(_sym_flags)
> -endif
> +_cpp_flags += $(_sym_flags)
>  
>  
>  # If building the kernel in a separate objtree expand all occurrences
> 

How about this instead (i.e. no changes to kernel/modsign_pubkey.c)?

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0be6f11..a76967e 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -119,11 +119,11 @@ _c_flags += $(if $(patsubst n%,, \
 		$(CFLAGS_GCOV))
 endif
 
-ifdef CONFIG_SYMBOL_PREFIX
 _sym_flags = -DSYMBOL_PREFIX=$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))
-_cpp_flags += $(_sym_flags)
+_c_sym_flags = -DSYMBOL_PREFIX=\"$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))\"
+_c_flags += $(_c_sym_flags)
 _a_flags += $(_sym_flags)
-endif
+_cpp_flags += $(_sym_flags)
 
 
 # If building the kernel in a separate objtree expand all occurrences


  parent reply	other threads:[~2012-12-05 10:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-04 10:18 [PATCH 1/3] MODSIGN: Fix comparison erros in scripts/sign-file Michal Marek
2012-12-04 10:18 ` [PATCH 2/3] MODSIGN: Avoid using .incbin in C source Michal Marek
2012-12-04 10:18 ` [PATCH 3/3] MODSIGN: Drop ccache hack Michal Marek
2012-12-04 18:15 ` [PATCH 1/3] MODSIGN: Fix comparison erros in scripts/sign-file David Howells
2012-12-04 18:17 ` [PATCH 2/3] MODSIGN: Avoid using .incbin in C source David Howells
2012-12-04 23:58   ` Rusty Russell
2012-12-05  7:39     ` Takashi Iwai
2012-12-05  9:50       ` Michal Marek
2012-12-05 10:06         ` Takashi Iwai
2012-12-05 10:30         ` James Hogan [this message]
2012-12-05 11:05           ` Michal Marek
2012-12-05 11:16             ` James Hogan
2012-12-07  4:40         ` Rusty Russell
2012-12-10 10:12           ` James Hogan
2012-12-05 10:30     ` David Howells
2012-12-05 10:54       ` Michal Marek
2012-12-05 12:35     ` David Howells
2012-12-05  7:46   ` Takashi Iwai
2012-12-04 18:29 ` [PATCH 3/3] MODSIGN: Drop ccache hack David Howells
2012-12-04 23:44 ` [PATCH 1/3] MODSIGN: Fix comparison erros in scripts/sign-file Rusty Russell

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=50BF2262.7080603@imgtec.com \
    --to=james.hogan@imgtec.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=rusty@ozlabs.org \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome