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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 31 Oct 2007 09:03:18 +0900
From:	"Suzuki Takashi" <suzuki.takashi@...il.com>
To:	"David Howells" <dhowells@...hat.com>
Cc:	torvalds@...l.org, akpm@...ux-foundation.org,
	linux-am33-list@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]

On 10/31/07, David Howells <dhowells@...hat.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/