All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Panin <pazke@orbita1.ru>
To: Dave Jones <davej@suse.de>,
	James Bottomley <James.Bottomley@steeleye.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	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 17:41:52 +0400	[thread overview]
Message-ID: <20020614134152.GA1293@pazke.ipt> (raw)
In-Reply-To: <davej@suse.de> <200206140013.g5E0DQR25561@localhost.localdomain> <20020614024547.H16772@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

On Птн, Июн 14, 2002 at 02:45:47 +0200, Dave Jones wrote:
> On Thu, Jun 13, 2002 at 08:13:26PM -0400, James Bottomley wrote:
>  > > 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 ? 
>  > That is really the way I've implemented it.
> 
> Ah, good.
> 
>  >  The only PC specific file in the 
>  > generic directory is mpparse.c (since neither visws nor voyager has an MP 
>  > compliant bios).  All the shareable files are kept in `kernel' and activated 
>  > by config options.
> 
> Another piece of low hanging fruit is probably dmi_scan.c
> There are no workarounds there for either (are they even DMI compliant?)
> so compiling it in doesn't make much sense.

We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.

>  > I can certainly move mpparse.c back to kernel and add an extra (non user 
>  > visible) config option.
> 
> if neither visws or voyager need it, I'd say it doesn't belong in the
> respective subarch directories period.

"Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
function MP_processor_info() from generic mpparse.c. May be it makes sence
to move to some generic file ?

>  > > Sounds quite logical. What does the current patches you have do ? I've
>  > > not had chance to look at them yet. 
>  > It creates directories `generic' for the standard pc and `visws'.  The voyager 
>  > patch creates a `voyager' directory.  Alternatively, these could be `mach-pc', 
>  > `mach-visws' and `mach-voyager'.
> 
> Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
> cast my vote for that one. If nothing else, it makes it obvious that
> the subdir isn't important if you don't care about $subarch
> 
>         Dave.

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

  parent reply	other threads:[~2002-06-14 13:43 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
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           ` Andrey Panin [this message]
2002-06-14 13:49             ` [PATCH: NEW SUBARCHITECTURE FOR 2.5.21] support for NCR voyager (3/4/5xxx series) 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=20020614134152.GA1293@pazke.ipt \
    --to=pazke@orbita1.ru \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=davej@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.