lkml.org 
[lkml]   [2002]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)
On Thu, Jun 13, 2002 at 11:48:57AM -0400, James Bottomley wrote:
> > [Q1] Will it be better to create separate directory for PC
> > architecture and split some PC'isms from arch/i386/generic ? Right now
> > it contains acpi.c, bootflag.c and dmi_scan.c which are not generic in
> > any way :)
> The thinking currently is that arch/i386 is really PC plus a few exceptions
> rather than a truly generic x86 plus additonal machine architectures, so it
> makes sense under this view that `generic' and PC be the same thing.

Would it make sense for the subarchs to use the generic code where possible,
and only reimplement it's own (for eg) apic.c as and when it actually
*needs* to be different ?

For the most part, I'd expect the existing subarchs we know about
(sgi visws, voyager, numaq), the amount of "own version" copies of
files would be quite low.

The big advantage of doing it this way, is that it reduces the overhead
of having to update every subarch when someone changes function
parameters. The downside is possibly slightly ickier Makefile's.

> > [Q2] May be directory naming like mach-visws, mach-voyager and
> > possible mach-pc will be more convinent ?
> To be more consistent with the way arch/arm does it? Certainly the renames
> can be done easily enough, what does the rest of the list think?

Sounds quite logical. What does the current patches you have do ?
I've not had chance to look at them yet.

Dave

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.058 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site