![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to README CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv9|
Return to README CVS log | Up to [Research Unix] / researchv9 |
1.1 ! root 1: Ninth Edition Unix System for Sun3 ! 2: Copyright (C) AT&T 1989. All Rights Reserved ! 3: ! 4: This directory contains the source for the Ninth Edition(v9) system ! 5: that was ported to the Sun. The source was derived from a snapshot of the ! 6: VAX v9 system, sometime around the beginning of 1987. It has ! 7: not been updated to incorporate changes that have been made ! 8: to the v9 system since then. ! 9: ! 10: In addition to the source, the binaries for a a Sun 3/75 or ! 11: 3/50 with a SCSI disk drive are included. A system may be built ! 12: very quickly by booting the Sun diskless from a Sun server, building ! 13: the v9 file system on the raw device, and then rebooting from the ! 14: v9 system on the disk drive. ! 15: ! 16: An overview of the directories is given below: ! 17: ! 18: X11 - contains the X11 release 1 code that runs under v9 ! 19: on the Sun. It does some things unconventionally. For example ! 20: the keyboard and mouse line disciplines are part of the X11 ! 21: server, instead of the operating system. The server just ! 22: reads the serial ports directly, with no operating system ! 23: intervention. ! 24: ! 25: cmd - source for all the commands. ! 26: ! 27: include - v9 include files for the Sun ! 28: ! 29: ipc - interprocess communications source, including dialers ! 30: and source for ipc libraries. ! 31: ! 32: jerq - 5620 software, only a small subset is included and ! 33: was ever tested. Once X windows was working, this directory ! 34: was essentially discarded. ! 35: ! 36: jtools - copy of 5620 tools that were ported to run under X11. ! 37: This includes things like Rob Pike's editor sam, Tom Cargill's pi, ! 38: mux style terminal windows and a bunch of other goodies. The ! 39: 5620 emulator library and associated tools can also be compiled ! 40: to run on a Sun under SunOS (under either X11 or Sunview). ! 41: ! 42: libc - C library source ! 43: libtermlib - terminal cursor control library ! 44: ! 45: netb - network file system code for mounting filesystems ! 46: of remote machines. Unlike NFS, it mounts the whole machine ! 47: and maps users between systems. Netb contains the server code ! 48: while the netb driver in the kernel provides the client code. ! 49: The server code will run on either a v9 or BSD machine. ! 50: ! 51: sys - the v9 kernel code. Directories that end in .old ! 52: contain the original VAX v9 code the files were derived from. ! 53: These were kept around to make it possible to diff them from ! 54: and upgrades made to the VAX v9 system. The directory ! 55: sys/construct contains the working binaries that can be ! 56: used to construct without all the normal bootstrapping problems. ! 57: ! 58: Notes: 1)all the source and makefiles(mkfiles), except for a few ! 59: in the sys/construct directory, assume they are being ! 60: compiled on a running v9 system. If you are going to X-compile ! 61: them under SunOS, some tweaking of the makefiles and compiler front ! 62: end may be necessary. ! 63: ! 64: 2)the compiler used by the v9 system generates symbol table ! 65: entries in the format of the v9 VAX compiler (rather than the ! 66: SUN format). When the v9 system was ported, it was simpler to ! 67: change the compiler than to backwards engineer a parser for ! 68: Suns yuckky symbol table (i.e. for use with pi). Since then, ! 69: I have written a Sun format symbol table parser so pi can be ! 70: used under SunOS. If I were going to do it over, I would not ! 71: modify the compiler. ! 72: ! 73: 3)the v9 tar is slightly different than the BSD tar. It handles ! 74: and stores symbolic links differently. Many of the binaries in ! 75: sys/construct/test are in v9 format tar files. If you want to ! 76: unpack them on a Sun under SunOS, there is a copy of the v9 tar ! 77: that runs under SunOS release 4.0 in sys/construct/host/v9tar.c. ! 78: By default, the v9 tar follows symbolic links when making tar files. ! 79: Use the L option to put the symbolic link in the tar file instead of ! 80: what the link points to. ! 81: ! 82: BOOTSTRAPPING: ! 83: Assuming your goal is to get a system running as soon as possible, ! 84: the following is a short cookbook that should generate a standalone ! 85: v9 system with minimal effort (provided you have a 3/50 or 3/75 with ! 86: a SCSI disk drive): ! 87: ! 88: 1) Install this source on a Sun server running SunOS ! 89: If you are reading this, you already did that. ! 90: 2) Format and label the SCSI disk you will install the system on using ! 91: the tools provided by Sun (diag, format). On SunOS release 4.0 you ! 92: can do it with format while the system is running Unix. Previous ! 93: releases required running diag in a stand-alone mode. Write down ! 94: the number of 512-byte blocks in the partitions you wish to make file ! 95: systems on. I usually put the root file system on partition a and the ! 96: usr file system on parition g. If the drive has already been ! 97: paritioned you can discover the number of block with the SunOS ! 98: dkinfo command. ! 99: 3) Boot up the system you want to install the v9 system on, under SunOS ! 100: from the server. Make sure the disk driver is in the SunOS kernel. ! 101: 4) Build SunOS versions of the v9 tools to construct file systems on ! 102: disks (fsck, mkfs) with the following commands: ! 103: cd sys/construct/host ! 104: make fsck mkfs ! 105: mv fsck mkfs .. ! 106: cd .. ! 107: The goal is to use these commands to install a complete v9 system ! 108: on the clean disk, using SunOS to do the installation. ! 109: 5) Edit the disk building proto files in sys/construct. These proto ! 110: files, used by mkfs, construct a new file system and initialize it ! 111: with a list of files, directories, etc. Four proto files are ! 112: already in the directory. Files of the form proto0a.* are for ! 113: building the root file system and files of the form proto0g.* are ! 114: for the user file system. The two that are there have the right ! 115: numbers for a CDC 155M Wren III drive and a CDC 300M Wren IV ! 116: (suffixes .cdc and .w4 respectively). In the proto0a file, ! 117: only two lines need to be edited: the second line and the next ! 118: to last line. The second line contains the number of 8K blocks ! 119: in the file system, followed by the number of inodes in the file ! 120: system. These numbers have to be adjusted to match the size of ! 121: the file system. The first number can be calculated by dividing ! 122: the number of 512byte blocks recorded in step 2 by 16. The second ! 123: number can be retrieved from mkfs by invoking it without a proto ! 124: file. For example, if the file system /dev/rsd0a has 2000 8K blocks, ! 125: running the command (must be su): ! 126: mkfs /dev/rsd0a 2000 ! 127: will print something like: ! 128: isize = 12416 ! 129: m/n = 3 1000 ! 130: and then build a file system. You can kill it after the lines are ! 131: printed as you don't actually need to build the file system yet. ! 132: The value of isize should be moved to the second value on the second ! 133: line of the proto file. ! 134: The last to next line of proto0a.* determines where the unix kernel ! 135: binary is taken from. If the system is a Sun 3/50 the line should ! 136: read: ! 137: unix ---755 0 4 test/unix.50 ! 138: while for a Sun 3/75 it should be: ! 139: unix ---755 0 4 test/unix.75. ! 140: In the /usr proto file, proto0g.*, only the second line, containing ! 141: the number of blocks + inodes needs to be modified. ! 142: 6) The binaries to construct a system are in sys/construct/test. ! 143: Some of these files need to be edited to match your site and ! 144: configuration. The only one that needs modification is etc/rc. ! 145: Look for the line with "ipconfig" in it. If the system is a ! 146: 3-75, the line should be (Intel Ethernet chips): ! 147: /usr/ipc/mgrs/ipconfig /dev/ie00 `cat /etc/whoami` mh-capek-net /dev/ie01 & ! 148: while for a 3-50 it should be: (AMD Lance Ethernet chips): ! 149: /usr/ipc/mgrs/ipconfig /dev/le00 `cat /etc/whoami` mh-capek-net /dev/le01 & ! 150: ! 151: Other files that you probably want to modify are: ! 152: etc/passwd ! 153: etc/whoami - should contain name of the system ! 154: 7) You are now ready to build the file systems: ! 155: cd sys/construct ! 156: mkfs /dev/rsd0a proto0a.new ! 157: mkfs /dev/rsd0g proto0g.new ! 158: 8) I would check them after you make them with fsck. ! 159: fsck /dev/rsd0a /dev/rsd0g ! 160: Expect fsck to complain: ! 161: file is not a block or character device; OK? ! 162: when it starts up, as it is compiled with v9's idea of ! 163: a file system, not SunOS'. Just type "y". If there are ! 164: any other problems, something went wrong making the file systems. ! 165: 9) Install the boot block on /dev/rsd0a (since the file systems have ! 166: a different format, a new boot block must also be installed): ! 167: cd test/stand ! 168: installboot bootpr /dev/rsd0a ! 169: cd ../.. ! 170: 10) You are now ready to boot the v9 system. Halt SunOS and boot ! 171: the v9 system in single user mode (it is IMPORTANT that you ! 172: bring it up single user when first booting): ! 173: b sd(0,0,0) -s ! 174: 11) It should print out the configuration info and then give you ! 175: the # prompt. Congratulations, you are now running under ! 176: Ninth Edition. ! 177: 12) Finish the installation procedure by executing the shell file ! 178: "startup" in the root directory: ! 179: cd / ! 180: startup ! 181: This file takes care of unpacking all the tar files used to ! 182: construct the system. It will run for several minutes as many of ! 183: the tar files have been compressed to save space. ! 184: You can see what it does by looking at it before you build ! 185: the system (sys/construct/test/startup). ! 186: 13) Give root a passwd ! 187: 14) Edit the Ethernet host and authentication tables in /usr/ipc/lib. ! 188: The files of interest are ! 189: inaddr.local ! 190: auth.local ! 191: to correspond to your site. The format of the files should be ! 192: obvious from looking at them. ! 193: 15) Type control-D to bring the system up multiuser. ! 194: 16) Log in as root and give yourself a login ! 195: 17) Log in as yourself. To use the X window system, copy the ! 196: following files from the /usr/dak directory: ! 197: .profile /* For correct PATH */ ! 198: .Xstart /* X startup file */ ! 199: .uwmrc ! 200: To start the X window system: ! 201: . .profile ! 202: Xstart ! 203: To get out of the X window system, type Xexit in any of the windows. ! 204: The window manager is configure so holding down the Sun keyboard ! 205: "LEFT" or "RIGHT" key and hitting the right mouse button generates ! 206: the window manager menu. ! 207: 19) After the system has been installed, future boots should be ! 208: automatic. Just power up or type >b sd() to the console monitor. ! 209: 20) Good luck ! 210: ! 211: If your are going to build your own system, you will need to build the ! 212: v9 config (sys/conf/src/config) first. There is a man page in that ! 213: directory describing it. The configuration files themselves, look ! 214: very similar to the configuration files used by Sun to build their kernels. ! 215: See sys/{3-50|3-75}/conf for examples. ! 216: ! 217: Some known bugs (I'm sure there are more): ! 218: The keyboard line discipline that the kernel pops on the console ! 219: (sys/sundev/kbdld.c) to map up-down keystrokes of the Sun keyboard ! 220: to ASCII characters is buggy. This discipline is only used when using the PROM to drive the screen (i.e. when not using a window system). ! 221: The problem is the discipline believes it will get ! 222: an up/down sequence for each key hit. Unfortunately, Sun ! 223: keyboads don't generate up/down codes like they are supposed to. ! 224: Sometimes the up or down sequence never gets transmitted. ! 225: The fix that Sun uses in their driver keeps a table containing ! 226: the state of each key, so if for example an up code for a key ! 227: is received but the driver thinks the key is already up, the ! 228: driver fakes the down code when it receives the up code. ! 229: If you have noticed that when you type quickly to a Sun ! 230: characters get transposed with a higher frequency than normal, ! 231: this is the reason. The driver in the X11 server keeps a ! 232: a state map of the keys and generates the fake codes. ! 233: The symptom you will see when not using X windows, is typed ! 234: characters on the console will be lost. ! 235: ! 236: The SCSI tape driver is not compatible with the drives shipped ! 237: by Sun. It works with the ARCHIVE Corporation Viper (2060S) ! 238: Half-Height Intelligent SCSI driver (the controller is built ! 239: in the drive). ! 240: ! 241: The SCSI disconned/reconnect doesn't work. It didn't work in ! 242: the SunOS release 3.1 drivers, from which the SCSI driver is ! 243: derived, either. ! 244: ! 245: ! 246: David Kapilow 5/11/89 ! 247: alice!dak or [email protected] ! 248: (201)-582-3596 ! 249: AT&T Bell Laboratories ! 250: RM 2B-424 ! 251: 600 Mountain Ave ! 252: Murray Hill, N.J. 07974
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.