![[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.