All of lore.kernel.org
 help / color / mirror / Atom feed
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 0/5] Add generic macros for declaring various CPU structs
Date: Thu, 16 Jun 2011 11:34:10 +0100	[thread overview]
Message-ID: <20110616103409.GB2460@arm.com> (raw)
In-Reply-To: <20110616101536.GA32629@n2100.arm.linux.org.uk>

On Thu, Jun 16, 2011 at 11:15:36AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 16, 2011 at 11:12:41AM +0100, Will Deacon wrote:
> > >  * For consistency, I've renamed the arch/CPU name string labels.
> > >    If that is seen as unnecessary churn, it can be undone.
> > 
> > I don't see the win here, so let's leave the names like they are to avoid
> > unnecessary conflicts with other patches dealing with proc_info structs.
> 
> One of the issues is that there are proc-* files which use the same
> strings for several entries, for example, proc-xscale.S.
> 
> In general, the ELF name and arch name should be the same across all,
> just the CPU name should differ.

Hmmm, that explains why those strings were declared a bit differently.

A few of possible solutions to this:

1) Keep my macros as they are, but use a couple of #defines to make sure
	that arch_name and cpu_name are the same everywhere in a given
	proc-*.S file. Each cpu will get its own symbol for each of these
	strings, but the strings will be merged by the linker and so won't
	be duplicated in the kernel image.

2) Split define_proc_names into two macros, say, define_arch_names and
	define_cpu_name.  define_arch_names would be used once in the
	file.

3) Define a generic macro to define a string.  That would help automate
	string declarations, but really it would no longer be arch-
	specific and could live outside arch/arm.

4) Get rid of the define_proc_names macro altogether, and declare those
	things in the existing way.

Any view on these approaches?

Cheers
---Dave

  reply	other threads:[~2011-06-16 10:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14 10:58 [RFC PATCH v2 0/5] Add generic macros for declaring various CPU structs Dave Martin
2011-06-14 10:58 ` [RFC PATCH v2 1/5] ARM: mm: Add generic proc/arch struct definition macros Dave Martin
2011-06-15 23:57   ` Nicolas Pitre
2011-06-16 10:03     ` Dave Martin
2011-06-20  3:13       ` Nicolas Pitre
2011-06-20 10:56         ` Dave Martin
2011-06-14 10:58 ` [RFC PATCH v2 2/5] ARM: proc-v7: Use new generic " Dave Martin
2011-06-16 10:15   ` Will Deacon
2011-06-14 10:58 ` [RFC PATCH v2 3/5] ARM: cache-v7: " Dave Martin
2011-06-14 10:58 ` [RFC PATCH v2 4/5] ARM: proc-v6: " Dave Martin
2011-06-14 10:58 ` [RFC PATCH v2 5/5] ARM: cache-v6: " Dave Martin
2011-06-16 10:12 ` [RFC PATCH v2 0/5] Add generic macros for declaring various CPU structs Will Deacon
2011-06-16 10:15   ` Russell King - ARM Linux
2011-06-16 10:34     ` Dave Martin [this message]
2011-06-16 10:43   ` Dave Martin

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=20110616103409.GB2460@arm.com \
    --to=dave.martin@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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 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.