Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!news.cs.indiana.edu!msi.umn.edu!sctc.com!briel
From: briel@sctc.com (Marc Briel )
Newsgroups: comp.unix.misc
Subject: Porting AT&T System V Release 4 to multiple cpus
Summary: How localized are the cpu dependencies in Release 4?
Keywords: UNIX port 68030 486
Message-ID: <1990Dec28.150334.24778@sctc.com>
Date: 28 Dec 90 15:03:34 GMT
Organization: Secure Computing Technology Corporation
Lines: 35

We are currently planning to port AT&T System V Release 4 to a
proprietary 68030 based platform. We are also considering another port
to a 486 based platform. Theoretically, how much additional effort is
required to do the 486 port if the platforms are "identical" except
for the difference in MPU used?

Really, the question boils to the following:

How well isolated are the CPU dependencies in AT&T System V Release 4?
Do almost all of the modules change between a 68030 version and a 486
version or do only a few modules change?

We are licensing the 68030 version source from AT&T. Is there a 486
version source? How many source modules are identical between the two
versions. If many of the modules are identical, we can port those
modules to out 68030 platform first and then just recompile them for
the 486 (again theoretically).

I should also point out that System V will run as a "application"
virtual operating system on top of a proprietry "virtual-machine-like"
kernel with some unusual characteristics. As a result, we need to make
modifications to many System V modules that would normally not be
touched in a "standard UNIX port" even if we start with 68030 version
source and are porting to a 68030 hardware platform. Since so many
changes are required, it would be very nice if we didn't have to redo
all of those changes from scratch on 486 version source. If mostof
the source modules are identical between the 68030 and 486 versions,
we can use th same modified source for both versions.


Any knowkedge, experience, or insights on this topic are appreciated!


				Marc Briel
				briel@sctc.com