DRAFT -- March 14, 1988 9:21:10 am PST -- DRAFT Internal Memo XEROX To From Distribution Bob Hagmann PARC/CSL Subject Date Yggdrasil Development and Execution Environments March 14, 1988 Introduction This memo addresses the issues the development and execution environments for Yggdrasil. Although the decisions are intertwined, this memo mostly presents them as orthogonal. There are three additional sections to this memo. First, in what language should we write the service? This is for the bulk of the code. There may be some operating system or hardware dependent code that is written in a different language (e.g., C). Some small parts of the system may be hand coded for performance. Second, on what platform should we run? This section specifies some requirements. We expect to adopt the result from the ``OCM Committee on Computational Base'' committee (Common HOWL) if it makes an (accepted) recommendation to the OCM. Finally, this memo addresses the issue of operating system and programming environment. Language There are a few natural choices for language. Cedar and C were prime candidates. Other languages were considered too. C was rejected due to the lack of a good programming environment (although it may not be that bad anymore), lack of safety in the language/runtime, and lack of garbage collection. Although some of these problems can be mitigated, we chose Cedar. We think that Cedar is the best choice since we are knowledgeable in the language, it provides many of the features we want, it is efficient, we have lots of code (notably Alpine)and it has a good programming environment. (Recall that this is the language, not operating system, section.) Our code should be written in the (evolving?) machine independent Cedar style. We cannot depend on anything in the Cedar system we cannot port (e. g., we cannot depend on the semantics of processes). We plan to use the Mimosa ``Cedar to C'' translator as our eventual compiler. In the sort term, we will use the standard Cedar compiler (and run on Dorados). To run from translated code, we will need runtime support and an appropriate OS. Server hardware platform Requirements We need a 1 MIP CPU (or much more). Database systems are typically CPU bound, and we do not plan to be different. 10 MIP CPU's are likely to be a requirement at the end of the project. A minimum of 2 megabytes of main memory is required. No system will have a chance of reasonable performance with less memory. If the OS is UNIX, make this 4 megabytes. Any machine should be able to configure at least 8 megabytes of main memory. We expect to exceed this minimum-maximum. We expect servers to have at least 16 megabytes, with 32-128 megabytes common. We need pretty good I/O. Part of this is to be able to connect to large numbers of current devices. A SCSI bus seems to be a requirement, both for SCSI magnetic disks and for SCSI optical disks (RS 232 is usually needed for the jukebox controller). SCSI buses come in several flavors, and we have to be careful to choose the right flavor or talk all flavors (the Misc board should be able to talk all flavors). Our need for SCSI optical disks is eliminated if these disks and the jukebox are connected to a ``optical disk server'' (our proposal). We have to select the vendor for the optical disks and jukebox. Part of this decision is whether to directly attach the controllers for the optical disks and jukebox to the server, or whether to use an ``optical disk server.'' Currently we favor the ``optical disk server.'' approach since: much of the easy, boring code will be bought not cost effective to rewrite this code for a different environment trades schedule time and head count for money However, there are the following drawbacks: since the code is easy, we are not solving much of the problem performance will suffer (but usually not all that much) coordinating backups will be quite difficult The server will implement a multiple level, large scale storage hierarchy. It will need lots of magnetic hard disks. Typical servers should have 2-10 gigabytes in magnetic hard disks. This might sound like a lot, but it is necessary for this much magnetic hard disk space to hold all naming and attribute data, plus a large buffer for the working set of objects. A fast interface, say SMD-E, would be nice, but SCSI might be acceptable. We also should plan to have hardware that can later support read/write optical disks and stable main memory. Machine choice: Dorado, SUN, ... Dorado This is the interim choice. With the Misc Board, the Dorado can talk 10 mHz Ethernet, RS 232 and SCSI. The Dorado is not a growth path, so we should plan to get off of it ASAP. We have to worry about hardware support. SUN, Dragons with multiple SPARC processors, UNIX System V (e.g., HP's new machine), or whatever We must move to the server architecture that will result from the ``OCM Committee on Computational Base'' committee (Common HOWL). Any machine with a fast CPU, good I/O and large memories where Cedar can be ported is a candidate. The system must be built to be flexible to accept new storage and communications technology. Operating system and programming environment Key to the structure of the server will the language's and operating system's ability to support sharing and concurrency. There appear to be three solutions: 1) multiple concurrent threads sharing the same address space UNIX System V.3, V, Mach, SUN UNIX, and Cedar are examples 2) extremely fast IPC do I/O in "helper" processes (e.g. V) 3) asynchronous I/O (e.g. UNIX 4.3 BSD) use a single process that never blocks, except for when it want to build/use a lightweight process package Reference: papers on X implementation Second, we need good existing communications, with the hope for more in the future. Ideally, many protocols would be supported with high efficiency. Finally, we need reasonable programming environment support. Our proposal is to start with the Cedar operating system and programming environment, and port to the PARC server architecture. We expect that this will be some flavor of UNIX. We also expect that the Cedar programming environment will be ported, in some form, to the new architecture. We plan to ``ride the wave'' of this port. Communications and protocols Communications and protocols is a major issue. The service should be very widely available. After all, we are proposing to take over and radically expand all filing at PARC. We expect to speak XNS, Courier, XNS Filing, Courier, TCP/IP, SUN RPC, SUN NFS, and UDP. It is likely that we will have to speak some of ANSI/CCITT/OSI/... Filing and Retrieval, Cedar RPC, Pup FTP, Chat, and Pup Leaf. In addition, we will have our ``Native'' protocol with (eventual) full support for data model layered over some of the RPC protocols. Performance will be critical. To get it we may have to buy overly expensive CPU's. We have to be able to accept back-to-back packets, connect to multiple physical networks, and have sufficient bandwidth (10 megabits/second or much more) on the networks. We have to remain flexible to put new protocols as they become commercially available or needed in our environment. We have to be able to track new technology.  WordlistsYggdrasil.wordlistStyleDef BeginStyle (Cedar) AttachStyle (DefaultNest) "for print" {DoNest} PrintRule (look.w) "annotation looks" { "Cream" family bold face } ScreenRule (look.w) "annotation looks" { AlternateFontFamily bold+italic face } PrintRule (firstHeadersAfterPage) {0} .cvx .def (root) "format for root nodes" { cedarRoot docStandard 36 pt topMargin 36 pt headerMargin 1.75 in leftMargin 1.5 in rightMargin 9.00 in lineLength 24 pt topIndent 24 pt topLeading 0 leftIndent 10 pt rightIndent } ScreenRule (root) "format for root nodes" { cedarRoot docStandard 36 pt topMargin 36 pt headerMargin 1.75 in leftMargin 1.5 in rightMargin 5.25 in lineLength 24 pt topIndent 24 pt topLeading 0 leftIndent 10 pt rightIndent } PrintRule (positionInternalMemoLogo) "Xerox logo: screen" { docStandard 1 pt leading 1 pt topLeading 1 pt bottomLeading } ScreenRule (positionInternalMemoLogo) "for Xerox logo" { docStandard 1 pt leading 1 pt topLeading -28 pt bottomLeading -1.5 in leftIndent } PrintRule (internalMemoLogo) "Xerox logo: screen" { "Logo" family 18 bp size 20 pt topLeading 20 pt bottomLeading } ScreenRule (internalMemoLogo) "for Xerox logo" { "Logo" family 18 pt size 12 pt leading -28 pt topLeading 36 pt bottomLeading -1.5 in leftIndent } PrintRule (memoHead) "for the To, From, Subject nodes at front of memos" { docStandard AlternateFontFamily 240 pt tabStops } StyleRule (raggedIndent) "ragged-right block" { block flushLeft lineFormatting flushLeft lastLineFormatting 1.5 em restIndent } StyleRule EndStyleIunleadedMark centerFooteros//Iblock insideHeaderbox IpositioninternalmemologoIinternalmemologomemoheadsO t O OOOOO O??OOhead LLLLWLLL LLLIitem-QCQ-+Q>Q7Qi ,LLll Ly`LL, ==Q:  Q% 'QBQ'Q%%LL<