The NCR voyager architecture is essentially a precursor of the intel APIC one.
The Voyager systems support from one to eight "processor" slots which take
big cards with 1-4 486-686 processors. The difficulties for linux are mainly
that the Interrupts are delivered through the VIC architecture of 8 8259 PIC
dyads (so some processors accept interrupts and some don't); the 8259 dyads
are accessible only locally to the interrupt handling processor, so global
interrupt enable and disable becomes a difficult concept.
Since the architecture support depends fairly intimitely on the existing i386
code, I've slotted it into the i386 architecture directory rather than trying
to create a separate one.
The architecture was released publicly in March 2001 for both the 2.2 and 2.4
kernel series. It has a fairly small user base.
The diffs are ~151k, so I refer to them by URL rather than bunging up the
mailing list. The URL is
http://www.hansenpartnership.com/voyager/files/voyager-2.5.1.diff
All comments welcome.
James Bottomley
On Sun, 23 Dec 2001, James Bottomley wrote:
> Since the architecture support depends fairly intimitely on the existing i386
> code, I've slotted it into the i386 architecture directory rather than trying
> to create a separate one.
> http://www.hansenpartnership.com/voyager/files/voyager-2.5.1.diff
> All comments welcome.
Things like this...
+#ifdef CONFIG_VOYAGER
+ }
+#endif
*really* gross me out. One thing I intend to do at some point in
2.5 also is to split out the visws setup code to setup-visws.c or
the likes, as a, it's more or less unmaintained, and b, more
noisy ifdef's.
I'd be *so* much happier to see your patch with setup-voyager.c,
and a single ifdef in setup.c wrapping setup_voyager() or the likes.
On another related topic, the bootmem stuff in setup.c would be
so much nicer to be split into a bootmem.c imho.
This would also make sharing the x86 bootmem code with the x86-64
bootmem code a lot simpler.
comments ?
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Sun, 23 Dec 2001, James Bottomley wrote:
> The NCR voyager architecture is essentially a precursor ...
One thing which worries me is that the number of
these machines is very small, so the code could
temporarily go the way the SGI visws code went.
It would be nice if this code was split out in
such a way that it won't have any impact on the
maintainability of the mainstream code, so even
if the voyager folks go on holiday, normal Linux
development can continue and the resulting bitrot
will be limited to just the voyager code.
cheers,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
[email protected] said:
> One thing which worries me is that the number of these machines is
> very small, so the code could temporarily go the way the SGI visws
> code went.
> It would be nice if this code was split out in such a way that it
> won't have any impact on the maintainability of the mainstream code,
> so even if the voyager folks go on holiday, normal Linux development
> can continue and the resulting bitrot will be limited to just the
> voyager code.
I would like to do this. I didn't do it for the 2.4 series because such a
patch would have been very difficult to maintain. I'll see if I can separate
the VISW code as well.
James
[email protected] said:
> I'd be *so* much happier to see your patch with setup-voyager.c, and a
> single ifdef in setup.c wrapping setup_voyager() or the likes.
> On another related topic, the bootmem stuff in setup.c would be so
> much nicer to be split into a bootmem.c imho.
> This would also make sharing the x86 bootmem code with the x86-64
> bootmem code a lot simpler.
Separation is clearly a better way to go. I'll see what I can do (and whether
I can take the visw along too). Where is the x86-64 code? I haven't seen it
since 2.4.13-ac8.
James Bottomley
On Thu, 27 Dec 2001, James Bottomley wrote:
> Separation is clearly a better way to go. I'll see what I can do (and whether
> I can take the visw along too). Where is the x86-64 code? I haven't seen it
> since 2.4.13-ac8.
In cvs at x86-64.org. (info on website at same address).
Andi hasn't merged any releases newer than 2.4.14, so it's a little
behind, but I'd guess we'll be switching it over to track 2.5 at some
point. Andi?
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Thu, 27 Dec 2001, James Bottomley wrote:
> I would like to do this. I didn't do it for the 2.4 series because such a
> patch would have been very difficult to maintain. I'll see if I can separate
> the VISW code as well.
I did this a while ago (just put the patch at
http://www.codemonkey.org.uk/patches/2.5/small-bits/visws-split.diff)
There's a slightly better version in 2.5.1-dj6 which I'll put up later
today if all goes well.
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs