Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]

["Suzuki Takashi" <suzuki.takashi@gmail.com>]

On 10/31/07, David Howells <dhowells@redhat.com> wrote:
> > Does this mean cpu-am33v3, cpu-am33v4, etc. will be created
> > when a new core comes up?
>
> Yes.  Note that the headers in a later one can 'inherit' from those of an
> earlier one simply by #including that earlier one, much like archs do with
> asm-generic headers.

GCC is willing to include the earlier one.
But people aren't, are they?

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.

This decreases development efficiency.
If there is no difference and they are all #including only headers,
there is nothing but development efficiency decrease.
It is not too late to split into directories
only after some large difference to the earlier one comes on.

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.

> > Isn't it possible to split codes by features, instead of target cores?
>
> Perhaps, but I personally am not in a position to judge what features are
> common to what CPUs.  I'll have to let someone from MEI answer that one.  I'll
> discuss it with them.

Ok. I'll wait.

> > Stranger names here.
>
> How so?

The file is under cpu/, but the names are mn103e010_* which is proc-specific.


-- 
Suzuki Takashi
Japan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/