briel@sctc.com (Marc Briel ) (12/28/90)
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
ag@cbmvax.commodore.com (Keith Gabryelski) (12/29/90)
In article <1990Dec28.150334.24778@sctc.com> briel@sctc.com (Marc Briel ) writes: >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? The 68k and 386 base ports are separate source trees. There are some things that were added for the 386 kernel only (for instance some cruft dealing with stream head processing). You have some work ahead of you. Pax, Keith
ronald@robobar.co.uk (Ronald S H Khoo) (12/29/90)
ag@cbmvax.commodore.com (Keith Gabryelski) writes: > The 68k and 386 base ports are separate source trees. ARRRRRRRRGGGGGGGGGGHHHHHHHHHHHH!!!!!!!!!! Does this mean we're going to see *different* kernel bugs across platforms? *cry* Is this going to continue to be the case, or does AT&T plan to merge the trees? Or can't you say ? Sigh. Roll on BSD 4.4 -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
ag@cbmvax.commodore.com (Keith Gabryelski) (12/30/90)
In article <1990Dec29.010014.6787@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >ag@cbmvax.commodore.com (Keith Gabryelski) writes: >> The 68k and 386 base ports are separate source trees. > >Does this mean we're going to see *different* kernel bugs across platforms? >*cry* There is still a lot of code that is shared. I don't know of any differences between the two trees in the networking tree. I do know that there are changes in the stream code. There will be diffreent kernel bugs just because there is different code specific to each processor. Pax, Keith
pinkas@st860.intel.com (Israel Pinkas) (01/02/91)
In article <1990Dec28.150334.24778@sctc.com> briel@sctc.com (Marc Briel ) writes: > 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? Not much. Most of the code is pretty generic. There are a few routines written in assembler, primarily for either speed, or to do something that cannot be done in C. > 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? From what I know, the source trees are separate. I don't know why. I am involved with a group that is porting SVR4 to the Intel i860. Our base was the i386 version. The i386 version is set up do deal with a large number of variations. When building, you specify the bus type (AT, Multibus, etc.) and the machine type (for hardware dependencies). We are treating all i860 machines (which don't have a bus) as a new bus type, to make life easier. We have discovered and fixed a few problems. These include things like unaligned accesses (not allowed by the i860) and code speedups. Everything is being fed back to AT&T. > 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). The 486 version is the same as the i386 version. It is available from AT&T, just like any other version. I can't comment on how much the two versions have in common. You might want to ask AT&T, through official cannels. > 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. I suspect that most of your changes to the generic 68030 version will be in the low level device drivers. We've done something similar here. We did the initial i860 port for an i860 card that plugged into an i386 bus. We modified the drivers so that instead of accesing H/W, a message was sent to a daemon on the i386 that accessed the H/W. This included everything from disk to mouse. A virtual machine could probably be done the same way. -Israel Pinkas Intel Corp. -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!st860!pinkas ARPA: pinkas%st860.intel.com@relay.cs.net CSNET: pinkas@st860.intel.com
guy@auspex.auspex.com (Guy Harris) (01/05/91)
>There is still a lot of code that is shared.
But there probably should be more code that's shared; what stuff got
added to the stream head on the 386 port, and what is the justification
for adding it only on the 386?
And there are other cases of bogusly unshared code:
Did they fix "setregs()" so that the ONLY thing it does is the
machine-DEPENDENT portion of post-"exec" initialization - i.e., did they
move stuff such as fiddling signal state and close close-on-exec files,
which sure as hell ain't machine-dependent (POSIX, the SVID, etc.
*require* that stuff) out into its caller?
Did they get rid of the notion of starting process 1 by copying a small
lump of machine-language code into the data space and jumping to it, and
instead do it SunOS-style, by faking an "execve()" call (which means
that you can print an error, instead of having the lump of code loop
infinitely, if it can't get "/sbin/init", and also means that you can
pass arguments, such as the "-s" argument which, in SunOS, means you
booted the system single-user; the S5 "init" could be tweaked to do a
more BSDish form of booting)?
(Yes, BSD currently does it in the same bogus fashion; I expect this
will be fixed for 4.4BSD.)
At least the new VM subtantially reduced the extent to which machine
dependencies permeate essentially machine-independent code....ag@cbmvax.commodore.com (Keith Gabryelski) (01/05/91)
In article <5032@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>There is still a lot of code that is shared. > >But there probably should be more code that's shared; what stuff got >added to the stream head on the 386 port, and what is the justification >for adding it only on the 386? The code added to the 386 stream head was placed there to handle the way they delt with the graphics hardware in release 3 (binary compatibilty). >And there are other cases of bogusly unshared code: > >Did they fix "setregs()" so that the ONLY thing it does is the >machine-DEPENDENT portion of post-"exec" initialization - >[...] setregs() doesn't seem to do anything unreasonable in the current release. >Did they get rid of the notion of starting process 1 by copying a small >lump of machine-language code into the data space and jumping to it, and >instead do it SunOS-style, by faking an "execve()" call (which means >that you can print an error, instead of having the lump of code loop >infinitely, if it can't get "/sbin/init", and also means that you can >pass arguments, such as the "-s" argument which, in SunOS, means you >booted the system single-user; the S5 "init" could be tweaked to do a >more BSDish form of booting)? This hasn't been delt with, although I agree that error messages would be a win. >At least the new VM subtantially reduced the extent to which machine >dependencies permeate essentially machine-independent code.... But breaks in a lot of cases (see previous discussion on fork() returning EAGAIN when physical memory runs low.). Pax, Keith