public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Mike Frysinger <vapier@gentoo.org>
Cc: James Hogan <james.hogan@imgtec.com>,
	linux-arch@vger.kernel.org,
	"linux-kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] [PATCH] asm-generic/unistd.h: handle symbol prefixes in cond_syscall
Date: Fri, 24 Feb 2012 16:37:30 +0000	[thread overview]
Message-ID: <201202241637.30284.arnd@arndb.de> (raw)
In-Reply-To: <201202241119.44480.vapier@gentoo.org>

On Friday 24 February 2012, Mike Frysinger wrote:
> > Our trend is to move away from arch specific Kconfig symbols and
> > __ARCH_HAS_* macros towards just defining whatever you need in the
> > architecture as an override for the generic definition.
> 
> i don't see how __ARCH_HAS_xxx would help here.  the symbol prefix is a string, 
> not a bool value.  it's also already used by linux/export.h, asm-
> generic/vmlinux.lds.h, and module code in scripts/.

I gave __ARCH_HAS_xxx as an example because a lot of other places use that
to abstract architecture specific features, even if that wouldn't apply
here.

> > Just provide your own unistd.h that does
> 
> the point of asm-generic is so that arches don't have to keep copying & 
> pasting things that they really don't care about.  James' proposed patch looks 
> good to me.  it might be nice to go even further and add logic to a core 
> header so that CONFIG_SYMBOL_PREFIX is always defined ...

You are right. I did not realize that CONFIG_SYMBOL_PREFIX is an existing
symbol rather one that James defined for this purpose.

We actually have MODULE_SYMBOL_PREFIX providing the correct string
under a name that is not appropriate here. We can probably stick with
Jason's patch for now and add a more sophisticated logic if another
user of CONFIG_SYMBOL_PREFIX comes up.

So for Jason's patch:

Acked-by: Arnd Bergmann <arnd@arndb.de>

We could put that into the kernel now, but it's probably sufficient if
Jason keeps the patch with his others and submits it at the same time
when we get there.

	Arnd

  reply	other threads:[~2012-02-24 16:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-24 14:01 [RFC] [PATCH] asm-generic/unistd.h: handle symbol prefixes in cond_syscall James Hogan
2012-02-24 14:23 ` Arnd Bergmann
2012-02-24 14:24 ` Arnd Bergmann
2012-02-24 14:51   ` James Hogan
2012-02-24 15:09     ` Arnd Bergmann
2012-02-24 15:40       ` James Hogan
2012-02-24 16:19   ` Mike Frysinger
2012-02-24 16:37     ` Arnd Bergmann [this message]
2012-02-24 16:38       ` Arnd Bergmann
2012-02-24 16:56         ` James Hogan
2012-02-24 16:41 ` Mike Frysinger

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=201202241637.30284.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=james.hogan@imgtec.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vapier@gentoo.org \
    /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