jay@metran.UUCP (Jay Ts) (04/21/91)
This question is prompted by the recent news of the "ACE" alliance that is forming to create an open standard based on the MIPS chip: Does the 88open standard allow for a company to develop a port of UNIX to a generic 88k system? In other words, is it possible for there to be a shrink-wrap UNIX port that will run on *all* 88open compliant machines? Jay Ts, Director Metran Technology Tampa FL uunet!pdn!tscs!metran!jay
scottl@convergent.com (Scott Lurndal) (04/23/91)
In article <12@metran.UUCP>, jay@metran.UUCP (Jay Ts) writes: |> Does the 88open standard allow for a company to develop a port of |> UNIX to a generic 88k system? In other words, is it possible for |> there to be a shrink-wrap UNIX port that will run on *all* 88open |> compliant machines? No. The standards developed by 88open are software standards. They define a software environment that must be presented by a conforming hardware platform. For a shrink-wrap unix to be feasible, the hardware would also need to be specified (i.e. how to address the various timers/clocks/ peripheral devices &c). This would be too restrictive for any hardware vendor to contemplate.
dfields@radium.urbana.mcd.mot.com (David Fields) (04/25/91)
In article <4155@risky.Convergent.COM>, scottl@convergent.com (Scott Lurndal) writes: |>In article <12@metran.UUCP>, jay@metran.UUCP (Jay Ts) writes: |> |>|> Does the 88open standard allow for a company to develop a port of |>|> UNIX to a generic 88k system? In other words, is it possible for |>|> there to be a shrink-wrap UNIX port that will run on *all* 88open |>|> compliant machines? |> |>No. The standards developed by 88open are software standards. They |>define a software environment that must be presented by a conforming |>hardware platform. |> |>For a shrink-wrap unix to be feasible, the hardware would also need |>to be specified (i.e. how to address the various timers/clocks/ |>peripheral devices &c). This would be too restrictive for any |>hardware vendor to contemplate. In it's pure form I agree. However, I think that it would be well within the relm of possibility to issolate the machine dependent parts of the kernel in to a well defined module which would then be vendor specific. Obviously this wouldn't satisfy every vendor but even a good issolation of platform and architecture [read chip family] dependent code at the source level would be very benificial. Given that machine dependent code in the Sys V reference ports aren't even ifdef'd for byte ordering in many cases I won't predict the amount of work... :-( The micro-kernel approach that some vendors are taking has the possibilty of allowing the servers, which contain the bulk of the "Unix TM" code, to be shrink-wrapped. It would probably be easier because of the clean interfaces required to partition the servers. Dave Fields // Motorola Computer Group // dfields@urbana.mcd.mot.com
andrew@frip.WV.TEK.COM (Andrew Klossner) (04/26/91)
[]
"I think that it would be well within the relm of possibility
to issolate the machine dependent parts of the kernel in to a
well defined module which would then be vendor specific."
We tried to do this. Spent great gobs of money, ended up with failure
-- the task turned out to be much bigger than initially estimated. We
fell back to a normal port of Motorola's system to our hardware.
A major problem is that releases of standard Unix come out so fast that
you couldn't keep up with them with this scheme, unless you had a lot
of resources to spend on the problem. And the payback isn't enough to
spend those resources.
-=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]guy@auspex.auspex.com (Guy Harris) (04/28/91)
> "I think that it would be well within the relm of possibility > to issolate the machine dependent parts of the kernel in to a > well defined module which would then be vendor specific." > >We tried to do this. Spent great gobs of money, ended up with failure >-- the task turned out to be much bigger than initially estimated. You may find that S5R4 does a better job of that than S5R3 did; I'm assuming the UNIX system for which you tried doing that was S5R3-based. For example, S5R4 has a Sun-style VM architecture, with the MMU support much better centralized (the difference between the last S5R4 load with the old VM stuff, and the first load with the new VM stuff, with regard to how much MMU dependencies permeated the system was huge). S5R4 may still not do it as well as it could, but it probably does it better; pressure should be applied to USL to improve S5 if there are areas where it doesn't isolate machine-independent and machine-dependent parts of the system (not just the kernel) as well as could be done. (For one thing, it'd probably be wise for all the ports that are "owned" by USL to come from *one* source tree; I very much doubt that "cat" needs to differ on different platforms, for example.) OSF/1 will probably be similar, at least in the MMU area; Mach has a similar notion of a "pmap module" for handling the MMU. >A major problem is that releases of standard Unix come out so fast that >you couldn't keep up with them with this scheme, unless you had a lot >of resources to spend on the problem. And the payback isn't enough to >spend those resources. The organizations that spend those resources should be the vendors of "porting base" systems, e.g. USL, OSF, etc., so that the releases of standard UNIX already fit that scheme and the purchasers of those systems don't have to run around trying to fit them into that scheme.
jat@xavax.com (John Tamplin) (05/01/91)
In article <4155@risky.Convergent.COM>, scottl@convergent.com (Scott Lurndal) writes: >In article <12@metran.UUCP>, jay@metran.UUCP (Jay Ts) writes: >|> Does the 88open standard allow for a company to develop a port of >|> UNIX to a generic 88k system? In other words, is it possible for >|> there to be a shrink-wrap UNIX port that will run on *all* 88open >|> compliant machines? > >No. The standards developed by 88open are software standards. They >define a software environment that must be presented by a conforming >hardware platform. > >For a shrink-wrap unix to be feasible, the hardware would also need >to be specified (i.e. how to address the various timers/clocks/ >peripheral devices &c). This would be too restrictive for any >hardware vendor to contemplate. 88open has spent at least some effort on this sort of thing -- EPIS (Executive Processor Interface Specification). I don't know the current status of it -- the date on the document I have is April 90 -- but it is intended to specify the interface between a kernel and the hardware in a machine independant manner. Porting a kernel onto new hardware would involve the following steps: 1) Obtain a portable kernel which interfaces with EPIS 2) Obtain the EPIS library for the hardware in question 3) Obtain device drivers for all peripherals 4) Link them together This would allow you to get a portable kernel running on new hardware, without requiring a porting job. -- John Tamplin Xavax jat@xavax.COM 2104 West Ferry Way ...!uunet!xavax!jat Huntsville, AL 35801