[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201202241637.30284.arnd@arndb.de>
Date: Fri, 24 Feb 2012 16:37:30 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Mike Frysinger <vapier@...too.org>
Cc: James Hogan <james.hogan@...tec.com>, linux-arch@...r.kernel.org,
"linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH] asm-generic/unistd.h: handle symbol prefixes in cond_syscall
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@...db.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
--
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/
Powered by blists - more mailing lists