public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: "Suzuki Takashi" <suzuki.takashi@gmail.com>
Cc: dhowells@redhat.com, torvalds@osdl.org,
	akpm@linux-foundation.org, linux-am33-list@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Date: Wed, 31 Oct 2007 11:46:26 +0000	[thread overview]
Message-ID: <13581.1193831186@redhat.com> (raw)
In-Reply-To: <b1c6420f0710301703n5c330ae2idb75c9a5703d5e7c@mail.gmail.com>

Suzuki Takashi <suzuki.takashi@gmail.com> wrote:

> But people aren't, are they?

On the other hand, these particular header files are of interest to arch
maintainers.

If there are variances between CPUs that mandate different sets of registers
or different usage protocols for equivalent modules, then you will end up with
something you'll object to.

Anyway, I've discussed this with MEI, and they're willing for some flattening
to take place.  The problem is how much?  I could just move all the
cpu-am33v2/ files into the dir above, but what happens if an incompatible CPU
core is introduced?

> If cpu-am33v3/cpu-regs.h #includes cpu-am33v2/cpu-regs.h,
> people have to
> 1) open cpu-am33v3/cpu-regs.h,
> saying #include <asm/cpu-am33v2/cpu-regs.h> (and sigh).
> 2) open cpu-am33v2/cpu-regs.h.

It's an awkward situation, yes, but not one most people will be concerned
with.  There needs to be some way to multiplex alternate register sets.  The
main ways of doing that are:

 (1) #include hell

 (2) #ifdef hell

 (3) Both

Which do you prefer?

Besides, you should use emacs tags:-)

However, I'll concede that the various versions of AM33 processor should
perhaps be represented by the same CPU subdirectory (cpu-am33), using #ifdef
to add extra features.  However, should, say, an AM34 be produced that's
effectively a variant of the AM33, then that scheme falls down too.

> This decreases development efficiency.

Like I said, it'll make very little difference to most people because few
people go poking around in the arch code.

> It is not too late to split into directories

It is already split up into directories.

> And at that time asm/cpu-regs.h should #include cpu/cpu-regs.h and
> people would #include asm/cpu-regs.h for the general purpose so that
> they aren't confused which is cpu-specific and which is proc-specific.

I'm confused as to what you're talking about.  asm/cpu-regs.h would not for
general purpose at all.  It would be an arch specific header file and should
not be used by code outside of the arch.

And if all asm/cpu-regs.h does is #include asm/cpu/cpu-regs.h, then what's the
point in having it?

> > > Stranger names here.
> >
> > How so?
> 
> The file is under cpu/, but the names are mn103e010_* which is proc-specific.

Good point.  That bears moving then.

David

  reply	other threads:[~2007-10-31 11:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 12:27 [PATCH 0/2] MN10300: Add the MN10300 architecture to Linux kernel [try #2] David Howells
2007-10-29 12:28 ` [PATCH 1/2] MN10300: Suppress AOUT library support in ELF binfmt if !CONFIG_BINFMT_AOUT " David Howells
2007-10-30 12:57 ` [Linux-am33-list] [PATCH 0/2] MN10300: Add the MN10300 architecture to Linux kernel " Suzuki Takashi
2007-10-30 14:14   ` David Howells
2007-10-30 15:10     ` Suzuki Takashi
2007-10-30 16:53       ` David Howells
2007-10-30 17:47         ` DJ Delorie
2007-10-30 21:59         ` Suzuki Takashi
2007-10-30 23:06           ` David Howells
2007-10-31 10:50             ` Alan Cox
2007-11-02 15:19             ` Suzuki Takashi
     [not found] ` <20071029122809.2846.58795.stgit@warthog.procyon.org.uk>
2007-10-30 14:40   ` [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the " Suzuki Takashi
2007-10-30 20:04     ` David Howells
2007-10-31  0:03       ` Suzuki Takashi
2007-10-31 11:46         ` David Howells [this message]
2007-11-03 16:07           ` Suzuki Takashi
2007-11-05 15:38             ` David Howells

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=13581.1193831186@redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-am33-list@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suzuki.takashi@gmail.com \
    --cc=torvalds@osdl.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