Date: 22-Feb-90 14:38:07 PST
Subject: SUMMARY: "Moving to SunOS4.1" discussion
Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "22-Feb-90 14:38:07 PST"
To: PCedarUsers:PARC:Xerox
Cc: Foote:OSBU North:Xerox
Reply-To: Foote:OSBU North:Xerox
From: Foote:OSBU North:Xerox


SUMMARY "Moving to SunOS4.1" discussion.


Last week I sent a proposal to CedarPorters:PARC on how we might approach the upgrade to SunOS4.1. Here is a modified version of this proposal, followed by a summary of the discussion to date. Further discussion on this topic will be held on PCedarImplementors:PARC, I'll continue to send summaries to PCedarUsers:PARC.


-- A Proposal for getting on 4.1 Pre-FCS

Executive summary:

I'd like to convince PFudge that it's in our best interests to migrate onto SunOS 4.1Pre-FCS. I'd like them to buy into a plan to get there (I propose such a plan), then commission me to do the grunt work.

FCS means First Customer Ship. Pre-FCS is the same as FCS unless Sun finds show stopper bugs while cutting release tapes.

Why upgrade to SunOS 4.1Pre-FCS:
performance advantages
bug fixes
no-swap patch not required
fix to C optimizer bugs
etc.
new features:
modload(8) - a way to dynamically load device drivers to running systems
a cleaner way for Tim to pin memory for his printer driver
new assembler to enable bundling
network boot server (to allow installation from a server rather than tapes)
etc.
to find incompatibilities while we're thinking about them
to learn how to upgrade (we'll be doing this again :-)
to learn how to manage forward and backward compatibility
common software base with SSU
(=> better testing coverage on the software exported to SSU)

Why not to upgrade:
we may have to do it again (SunOS4.1 FCS? SunOS4.1.x?)
risk that things will break
risk that the bug fixes for 4.1Pre-FCS introduced worse bugs
potential forward compatibility issues for exported C code (see details below)


Pre-requisites to upgrading machines to 4.1Pre-FCS:
0. There ought to be consensus that about the approach before we launch into it. We can hose each other up if we do it willy-nilly.
1. The world needs to be rebuilt with the 4.1Pre-FCS tools and demonstrated to run on both 4.0.3 and 4.1Pre-FCS machines (Done - through PCedarTools, Viewers and Tioga).
2. There needs to be an installation script analogous to TailorMachine.csh which will configure a freshly installed 4.1 machine to the "CSL/EDL approved" configuration, whatever that is.
3. Someone should sign up to be the upgrade co-ordinator. That person should be ready to take the heat when things go wrong (they will).
4. Verification that 4.1 Pre-FCS fixes the NFS bug that David Goldberg reported. Details from David:
> I've been running 4.1beta for several weeks, and it has a fairly
> serious problem, namely there is an nfs bug, where if you write to a
> filesystem mounted with 4k writes (which is what the automounter uses),
> the writes may be screwed up. I work around this by only compiling to
> my disk, rather than over nfs. We might be able to work around
> this by changing the automounter default to 2k or 8k.
5. PCR 2� is bounced to INSTALLED.
6. Server space is found for 4.1 shared files (Done).
7. Plumber is rebuilt -Bstatic (to give it forward and backward compatibility) and tested on 4.1 and 4.0.3 machines.
8. BridgeSessionD is modified for the 4.1 tty changes and is tested on 4.1 and 4.0.3 machines.

Plan
1. Implement and test TailorMachine4Dot1.csh - using the new 4.1 boot server (OS installation from a file server rather than from tape).
2. Continue to build upward to RawViewersWorld and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility.
3. Smodel the 4.1-built PCedarTools package and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility.
4. Smodel the 4.1-built RawViewersWorld package and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility.
5. Install 4.1Pre-FCS on pioneer machines (So far Demers, Weiser, Atkinson, CHauser and Plass have voluntered).
6. After sufficient grace period make 4.1 FCS the default new machine OS (the one you install after you take your machine out of the packing crate) and install it on pool machines.
7. After sufficient grace period install 4.1Pre-FCS on non-pioneer workstations.


More than you ever wanted to know about SunOS forward and backward compatibility:

Cedar/Mesa code
4.0.3 and 4.1Pre-FCS appear to be forward and backward compatible for Cedar/Mesa code running on INSTALLED (and later) PCR's. To validate this claim I've rebuilt the PCedarTools world from CedarPreBasics up to the language tools and used these tools on 4.1 and 4.0.3 to run the language tools regression tests. I found one module that had to change to be 4.0.3/4.1 compatible (LoaderUtilsImpl.c from CedarPreBasicsExtras which had to deal with a difference in /usr/include/ctype.h). We'll continue to build upward using the 4.1 tools until we have the rest of the world built, but we currently can't see anything that looks incompatible to Cedar/Mesa code. This, of course, is largely due to the abstraction layer that PCR represents.

C code
C code that does not depend on Sun provided shared libraries (ie linked with the -Bstatic flag) appears to be forward and backward compatible. To validate this claim I've rebuilt the language tools drivers used by SSU to drive the Mimosa tools and they validate, forward and backward, on both 4.0.3 and 4.1.

C code that depends on Sun provided shared libraries is claimed by Sun to have backward compatibility, but Sun makes no claim to support forward compatibility. This means that code compiled on 4.0.3 with shared libraries is claimed by Sun to run on 4.1 machines. But code compiled on 4.1 with shared libraries will give a load time warning when run on 4.0.3 machines.

The general forward compatibility problem with SunOS shared libraries isn't going to go away. At least for this update we can work around it by linking -Bstatic, but I don't know a general solution for this update or for any other. There are cases in which you can install new libraries on old kernels and make your application run - but it's problematic if the system call interface ever changes. Anybody have any ideas about how to deal with this issue? It seems too bad to be stuck on 4.0.3 forever.


I know of no C programs that are being built or developed by CSL or EDL which would be expected to use shared libraries and to also run on pre-4.1 machines. So I don't think there is any forward or backward compatibility problems for CSL or EDL - but that doesn't mean that such problems don't exist! If anybody knows about cases like this please let me know.


So my proposal is that PFudge discuss these issues, modify the plan where it needs changing, then commission me to go implement the upgrade plan. The resources I'm asking for are mainly consulting and review of this plan, but realistically PFudger's will have some disruption if we choose to upgrade. It's my hope that we can limit that disruption to the time it takes to upgrade your workstation's software, but you know how these things go.


My ulterior motive: 4.1Pre-FCS includes a new assembler which includes relocation records for each procedure body. If all of PCedar were built with these tools then I could use my Bundler on PCedar code to try to improve paging behavior and improve it's performance, particularly on smaller memory machines. Obviously SSU is also very interested in tools to improve performance on smaller memory machines.


-- end of Proposal for getting on 4.1 Pre-FCS

Summary of discussion to date:

Alan: Nothing is obviously broken, and I think it's a fine idea.

Mark: 4.1 fixes none of our (CSL/EDL) performance problems. 4.1 is tuned for 8MB performance, supposedly, but the increase is supposedly modest, and supposedly zero for > 8 MB. 4.1 Beta is also reported to have lots of bugs - let's wait for 4.1 FCS.

Jim: 4.1 enables bundling which MAY have performance advantages to machines > 8MB. It was also my impression that 4.1 did not require the no-swap patch, which might indicate that they've fixed up the swapper algorithm which MAY have some performance impact.

Alan: I've got a C program that uses shared libraries - I guess I'll go rebuild it -Bstatic.

Jim: Can anybody think of any other prerequisites to getting the pioneers started?

Jim: What about tools like "BecomeConsole" - are there others like this (C programs that we depend on that are built against SunOS shared libraries)?

Date: Fri, 23 Feb 90 08:28:04 PST
Sender: Tim Diebert:PARC:xerox
Subject: Moving to SunOS4.1
To: Foote:OSBU North:Xerox
Cc: Tim Diebert:PARC:Xerox, Shibata:HARC:Fuji Xerox, PCedarImplementors^:PARC:Xerox
Reply-To: Tim Diebert:PARC:xerox

Jim,

I think that we need to be careful with making a PCedar world that will
only run on SunOS4.1. As you might know, we are involved with at least
two groups at Fuji Xerox and at least one in Rank Xerox that are using
PCedar. One Fuji Xerox group is considering using PCedar imaging
software in a printer product. (More news on this as more details
become available.) The concern that I have is related to the
availablity of SunOS4.1 Export. If these folks can't get the OS, they
can't run a 4.1 only PCedar. This is clearly not to say that we should
support 4.0.3 forever, just until 4.1 export is available.

This concern aside, let's do it!

Tim

Date: 23-Feb-90 8:40:25 PST
Subject: Re: Moving to SunOS4.1
In-Reply-To: Originator: "::", UniqueString: "Your message of 23 Feb 90 08:29:41 PST (Friday)"
Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "23-Feb-90 8:40:25 PST"
To: Tim Diebert:PARC:Xerox
Cc: Foote:OSBU North:Xerox, Shibata:HARC:Fuji Xerox, PCedarImplementors:PARC:Xerox
Reply-To: Foote:OSBU North:Xerox
From: Foote:OSBU North:Xerox

> I think that we need to be careful with making a PCedar world that will only run on SunOS4.1.

I wholeheartedly agree.

Does anybody see anything in the proposal that would require this?


 -- Jim

Date: 23-Feb-90 8:48:49 PST
Subject: Re: Moving to SunOS4.1
Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "23-Feb-90 8:48:49 PST"
To: Tim Diebert:PARC:Xerox
Cc: Foote:OSBU North:Xerox, Shibata:HARC:Fuji Xerox, PCedarImplementors:PARC:Xerox
Reply-To: Foote:OSBU North:Xerox
From: Foote:OSBU North:Xerox

Boy was that ever a bad sentence. Let me try again.

Does anybody see anything in the proposal that would result in a PCedar that would only run on SunOS4.1? Does anyone know of a reason why PCedar's built on SunOS4.1 wouldn't run on SunOS4.0.3?


 -- Jim

----------------------------------------------------------------
Sender: James K. Foote:OSBU North:Xerox
Date: 23 Feb 90 08:40:25 PST (Friday)
Subject: Re: Moving to SunOS4.1
From: Foote
To: Tim Diebert:PARC
cc: Foote, Shibata:HARC:Fuji Xerox, PCedarImplementors:PARC
In-Reply-to: Your message of 23 Feb 90 08:29:41 PST (Friday)
Reply-to: Foote


> I think that we need to be careful with making a PCedar world that will only run on SunOS4.1.

I wholeheartedly agree.

Does anybody see anything in the proposal that would require this?


 -- Jim

----------------------------------------------------------------