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]

Message-ID: <13581.1193831186@redhat.com>
Date:	Wed, 31 Oct 2007 11:46:26 +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:

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