From: Dave Jones <davej@suse.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Andrey Panin <pazke@orbita1.ru>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series)
Date: Fri, 14 Jun 2002 01:17:09 +0200 [thread overview]
Message-ID: <20020614011709.E16772@suse.de> (raw)
In-Reply-To: <pazke@orbita1.ru> <200206131548.g5DFmv407602@localhost.localdomain>
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
next prev parent reply other threads:[~2002-06-13 23:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-09 17:54 [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series) James Bottomley
2002-06-13 8:20 ` Andrey Panin
2002-06-13 15:48 ` James Bottomley
2002-06-13 23:17 ` Dave Jones [this message]
2002-06-14 0:13 ` James Bottomley
2002-06-14 0:45 ` Dave Jones
2002-06-14 2:19 ` Matthew D. Pitts
2002-06-14 2:52 ` SCSI host/channel/lun/part to /dev/sd* or maj/minor mapping Mark Atwood
2002-06-14 13:41 ` [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series) Andrey Panin
2002-06-14 13:49 ` Dave Jones
2002-06-14 13:52 ` Andrey Panin
2002-06-14 14:14 ` James Bottomley
2002-06-14 14:16 ` Dave Jones
2002-06-17 13:36 ` Andrey Panin
2002-06-17 14:03 ` Dave Jones
2002-06-16 0:00 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020614011709.E16772@suse.de \
--to=davej@suse.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pazke@orbita1.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox