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:	Tue, 30 Oct 2007 20:04:05 +0000
From:	David Howells <dhowells@...hat.com>
To:	"Suzuki Takashi" <suzuki.takashi@...il.com>
Cc:	dhowells@...hat.com, 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]

Suzuki Takashi <suzuki.takashi@...il.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.

> 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.

> If similar codes were in multiple files and directories, it would be
> hard to maintain them.

#include is a wonderful thing.

> > +#ifdef CONFIG_MN10300_PROC_MN103E010
> > +       nop
> > +       nop
> > +       nop
> > +#endif
> 
> This should be conditioned by a feature.
> Isn't it a feature or a limitation that several non-FPU instructions are
> necessary just after the EPSW_FE is set?

Or it could just be a h/w bug in this particular processor.  I can always
patch it later to change the name.  Whatever it is, I suspect it will always
be controlled implicitly.

> Are these specific to MN103E010, or applicable to some other LSIs?

Yes.

> If they are not specific to MN103E010, the file names aren't good.

I realise that, but I haven't been able to get any better names for them.

> Stranger names here.

How so?

David
-
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/