Browse Source

Plan 9 from Bell Labs 2006-01-26

David du Colombier 16 years ago
parent
commit
84ec658f21

+ 9 - 41
dist/replica/_plan9.db

@@ -231,9 +231,9 @@
 386/bin/fortune - 775 sys sys 1135570810 67113
 386/bin/fossil - 20000000775 sys sys 1042005470 0
 386/bin/fossil/conf - 775 sys sys 1085077052 1506
-386/bin/fossil/flchk - 775 sys sys 1135570810 237600
-386/bin/fossil/flfmt - 775 sys sys 1135570811 245747
-386/bin/fossil/fossil - 775 sys sys 1135570812 360522
+386/bin/fossil/flchk - 775 sys sys 1138211975 237734
+386/bin/fossil/flfmt - 775 sys sys 1138211976 245881
+386/bin/fossil/fossil - 775 sys sys 1138211977 360656
 386/bin/fossil/last - 775 sys sys 1135570812 63280
 386/bin/freq - 775 sys sys 1136397208 61797
 386/bin/fs - 20000000775 sys sys 954380769 0
@@ -567,7 +567,7 @@
 386/lib/libstdio.a - 664 sys sys 1115950159 126206
 386/lib/libsunrpc.a - 664 sys sys 1115950160 355994
 386/lib/libthread.a - 664 sys sys 1135531448 71308
-386/lib/libventi.a - 664 sys sys 1124766772 97708
+386/lib/libventi.a - 664 sys sys 1138211977 98048
 386/mbr - 775 sys sys 1131317338 407
 386/mkfile - 664 sys sys 948141303 46
 386/pbs - 775 sys sys 1131317339 494
@@ -5391,7 +5391,7 @@ power/mkfile - 664 sys sys 948141304 46
 rc - 20000000775 sys sys 944959447 0
 rc/bin - 20000000775 sys sys 1018637942 0
 rc/bin/9fat: - 775 sys sys 1133179689 367
-rc/bin/9fs - 775 sys sys 1079969823 948
+rc/bin/9fs - 775 sys sys 1138240042 1027
 rc/bin/B - 775 sys sys 945617206 645
 rc/bin/C - 775 sys sys 1127395076 855
 rc/bin/Kill - 775 sys sys 1018637942 115
@@ -5591,46 +5591,35 @@ sparc64/lib - 20000000775 sys sys 1114458535 0
 sparc64/mkfile - 664 sys sys 1114458667 46
 sys - 20000000775 sys sys 952648870 0
 sys/doc - 20000000775 sys sys 1018471272 0
-sys/doc/-.2669382.gif - 664 sys sys 1019969850 2078
 sys/doc/8½ - 20000000775 sys sys 945616779 0
-sys/doc/8½/8½.html - 664 sys sys 1020895860 33484
 sys/doc/8½/8½.ms - 664 sys sys 1020895859 31593
 sys/doc/8½/8½.ps - 664 sys sys 1020895860 797150
 sys/doc/8½/fig1.ps - 664 sys sys 1020895859 473747
 sys/doc/8½/mkfile - 664 sys sys 1020895860 215
-sys/doc/9.html - 664 sys sys 1136302690 87619
 sys/doc/9.ms - 664 sys sys 953237044 84632
 sys/doc/9.ps - 664 sys sys 960837924 508340
-sys/doc/acid.html - 664 sys sys 1091459045 71723
 sys/doc/acid.ms - 664 sys sys 1127411211 65062
 sys/doc/acid.ps - 664 sys sys 1015012454 426359
-sys/doc/acidpaper.html - 664 sys sys 1091459045 46880
 sys/doc/acidpaper.ms - 664 sys sys 952880777 44805
 sys/doc/acidpaper.ps - 664 sys sys 960837913 359639
 sys/doc/acme - 20000000775 sys sys 945616779 0
 sys/doc/acme/acme.fig1 - 664 sys sys 944959632 164559
 sys/doc/acme/acme.fig2 - 664 sys sys 944959632 56026
-sys/doc/acme/acme.html - 664 sys sys 1020013936 51769
 sys/doc/acme/acme.ms - 664 sys sys 952880782 49851
 sys/doc/acme/acme.pdf - 664 sys sys 1020384351 117006
 sys/doc/acme/acme.ps - 664 sys sys 960837907 611301
 sys/doc/acme/bs - 664 sys sys 944959634 556
 sys/doc/acme/mkfile - 664 sys sys 961259926 304
-sys/doc/ape.html - 664 sys sys 1091459042 14415
 sys/doc/ape.ms - 664 sys sys 953344517 12595
 sys/doc/ape.ps - 664 sys sys 960837914 258779
-sys/doc/asm.html - 664 sys sys 1091459045 31098
 sys/doc/asm.ms - 664 sys sys 958247686 28542
 sys/doc/asm.ps - 664 sys sys 960837915 322051
-sys/doc/auth.html - 664 sys sys 1091459079 77445
 sys/doc/auth.ms - 664 sys sys 1021579975 66803
 sys/doc/auth.ps - 664 sys sys 1021579976 451672
 sys/doc/cleanps - 775 sys sys 961259933 184
 sys/doc/colophon.ps - 664 sys sys 960837922 214122
-sys/doc/comp.html - 664 sys sys 1091459046 42144
 sys/doc/comp.ms - 664 sys sys 954266992 37792
 sys/doc/comp.ps - 664 sys sys 960837915 345786
-sys/doc/compiler.html - 664 sys sys 1091459044 32960
 sys/doc/compiler.ms - 664 sys sys 1067721142 30279
 sys/doc/compiler.ps - 664 sys sys 1091459054 309735
 sys/doc/contents.ms - 664 sys sys 1019916701 4920
@@ -5641,7 +5630,6 @@ sys/doc/fossil.ms - 664 sys sys 1063856349 31400
 sys/doc/fossil.pdf - 664 sys sys 1042123169 63200
 sys/doc/fossil.ps - 664 sys sys 1135487951 313552
 sys/doc/fs - 20000000775 sys sys 945616779 0
-sys/doc/fs/fs.html - 664 sys sys 1020013937 21345
 sys/doc/fs/fs.pdf - 664 sys sys 1020384351 47177
 sys/doc/fs/fs.ps - 664 sys sys 960837905 276918
 sys/doc/fs/mkfile - 664 sys sys 961259926 282
@@ -5656,7 +5644,6 @@ sys/doc/fs/p7 - 664 sys sys 953844581 958
 sys/doc/fs/p8 - 664 sys sys 953844574 881
 sys/doc/fs/xx - 664 sys sys 944959592 65957
 sys/doc/il - 20000000775 sys sys 945616779 0
-sys/doc/il/il.html - 664 sys sys 1020013937 12278
 sys/doc/il/il.ms - 664 sys sys 952880783 11367
 sys/doc/il/il.pdf - 664 sys sys 1020384351 44630
 sys/doc/il/il.ps - 664 sys sys 960837905 258028
@@ -5666,29 +5653,21 @@ sys/doc/il/transition.fig - 664 sys sys 944959591 15431
 sys/doc/il/transition.pic - 664 sys sys 944959591 11912
 sys/doc/il/xx - 664 sys sys 944959591 48924
 sys/doc/index.htm - 664 sys sys 1019916696 6906
-sys/doc/index.html - 664 sys sys 1020082751 6906
-sys/doc/lexnames.html - 664 sys sys 1091459043 37261
 sys/doc/lexnames.ms - 664 sys sys 954383595 34046
 sys/doc/lexnames.ps - 664 sys sys 960837909 335546
-sys/doc/libmach.html - 664 sys sys 1091459044 26650
 sys/doc/libmach.ms - 664 sys sys 1021579974 24145
 sys/doc/libmach.ps - 664 sys sys 960837916 291283
-sys/doc/lp.html - 664 sys sys 1091459043 21721
 sys/doc/lp.ms - 664 sys sys 954614673 22366
 sys/doc/lp.ps - 664 sys sys 960837917 294399
-sys/doc/mk.html - 664 sys sys 1091459046 40021
 sys/doc/mk.ms - 664 sys sys 952880779 34413
 sys/doc/mk.ps - 664 sys sys 960837917 329779
 sys/doc/mkfile - 664 sys sys 1091459055 4411
-sys/doc/mkfiles.html - 664 sys sys 1091459045 17750
 sys/doc/mkfiles.ms - 664 sys sys 952880779 17888
 sys/doc/mkfiles.ps - 664 sys sys 960837918 269496
-sys/doc/names.html - 664 sys sys 1091459046 23529
 sys/doc/names.ms - 664 sys sys 954269607 22103
 sys/doc/names.ps - 664 sys sys 960837918 288716
 sys/doc/net - 20000000775 sys sys 954033300 0
 sys/doc/net/mkfile - 664 sys sys 961259927 345
-sys/doc/net/net.html - 664 sys sys 1020013937 43449
 sys/doc/net/net.ms - 664 sys sys 952880783 41191
 sys/doc/net/net.pdf - 664 sys sys 1020384351 82603
 sys/doc/net/net.ps - 664 sys sys 960837908 350053
@@ -5696,25 +5675,19 @@ sys/doc/net/tree - 664 sys sys 944959636 866
 sys/doc/net/tree.pout - 664 sys sys 944959636 1755
 sys/doc/network.art - 664 sys sys 944959651 2260
 sys/doc/network.pic - 664 sys sys 944959651 4124
-sys/doc/plumb.html - 664 sys sys 1091459044 55783
 sys/doc/plumb.ms - 664 sys sys 954383596 53250
 sys/doc/plumb.ps - 664 sys sys 960837910 391830
-sys/doc/port.html - 664 sys sys 1091459042 18123
 sys/doc/port.ms - 664 sys sys 1020111393 16694
 sys/doc/port.ps - 664 sys sys 1020111394 268901
 sys/doc/preamble - 664 sys sys 961259497 203475
 sys/doc/prfile - 775 sys sys 944959668 3782
-sys/doc/prog4.html - 664 sys sys 1091459046 18653
 sys/doc/prog4.ms - 664 sys sys 1019932830 16485
 sys/doc/prog4.ps - 664 sys sys 1019932831 271581
 sys/doc/ps - 664 sys sys 944959649 1739
-sys/doc/rc.html - 664 sys sys 1091459044 41702
 sys/doc/rc.ms - 664 sys sys 1063856321 34373
 sys/doc/rc.ps - 664 sys sys 960837920 337955
-sys/doc/release3.html - 664 sys sys 1019922810 6329
 sys/doc/release3.ms - 664 sys sys 961261276 5492
 sys/doc/release3.ps - 664 sys sys 961261277 230682
-sys/doc/release4.html - 664 sys sys 1091459042 6473
 sys/doc/release4.ms - 664 sys sys 1063856338 5160
 sys/doc/release4.ps - 664 sys sys 1091459052 230868
 sys/doc/sam - 20000000775 sys sys 945617037 0
@@ -5731,24 +5704,19 @@ sys/doc/sam/fig6.pic - 464 sys sys 944959644 1105
 sys/doc/sam/fig7.pic - 464 sys sys 944959644 258
 sys/doc/sam/mkfile - 664 sys sys 961259927 574
 sys/doc/sam/refs - 464 sys sys 944959644 2652
-sys/doc/sam/sam.html - 664 sys sys 1020013938 100660
 sys/doc/sam/sam.ms - 464 sys sys 954266468 94536
 sys/doc/sam/sam.pdf - 664 sys sys 1020384352 156123
 sys/doc/sam/sam.ps - 664 sys sys 960837910 707546
 sys/doc/sam/sam.tut - 464 sys sys 944959644 40481
-sys/doc/sleep.html - 664 sys sys 1091459043 16602
 sys/doc/sleep.ms - 664 sys sys 953237030 15206
 sys/doc/sleep.ps - 664 sys sys 960837920 263882
-sys/doc/spin.html - 664 sys sys 1091459042 75873
 sys/doc/spin.ms - 664 sys sys 953344522 67475
 sys/doc/spin.ps - 664 sys sys 960837923 443064
 sys/doc/title - 664 sys sys 1018974170 740
 sys/doc/title.ps - 664 sys sys 1018974170 214289
 sys/doc/trademarks.ps - 664 sys sys 960837912 217896
-sys/doc/troff.html - 664 sys sys 1019922811 110932
 sys/doc/troff.ms - 664 sys sys 953237047 120683
 sys/doc/troff.ps - 664 sys sys 1091459051 782310
-sys/doc/utf.html - 664 sys sys 1091459044 43965
 sys/doc/utf.ms - 664 sys sys 952880781 41659
 sys/doc/utf.ps - 664 sys sys 960837922 363085
 sys/doc/venti - 20000000775 sys sys 1019852318 0
@@ -5763,7 +5731,7 @@ sys/doc/venti/emelie.gif - 664 sys sys 1019852316 5004
 sys/doc/venti/emelie2.gif - 664 sys sys 1019852317 4357
 sys/doc/venti/mkfile - 664 sys sys 1019965454 79
 sys/doc/venti/probablity.gif - 664 sys sys 1019852317 1244
-sys/doc/venti/venti.html - 664 sys sys 1019852317 55272
+sys/doc/venti/venti.html - 664 sys sys 1138233389 55272
 sys/doc/venti/venti.pdf - 664 sys sys 1020384352 139090
 sys/doc/venti/venti.ps - 664 sys sys 1019852320 2012620
 sys/games - 20000000775 sys sys 952648872 0
@@ -7596,7 +7564,7 @@ sys/man/3/segment - 664 sys sys 1017423721 2378
 sys/man/3/srv - 664 sys sys 958419690 1470
 sys/man/3/ssl - 664 sys sys 1018386776 3413
 sys/man/3/tls - 664 sys sys 1045501496 7018
-sys/man/3/uart - 664 sys sys 1102093395 1710
+sys/man/3/uart - 664 sys sys 1138191356 2003
 sys/man/3/usb - 664 sys sys 1126971427 6960
 sys/man/3/vga - 664 sys sys 1131301005 4957
 sys/man/4 - 20000000775 sys sys 1018581459 0
@@ -7682,7 +7650,7 @@ sys/man/6/plot - 664 sys sys 944959679 6739
 sys/man/6/plumb - 664 sys sys 969499892 10918
 sys/man/6/regexp - 664 sys sys 954089523 2050
 sys/man/6/rewrite - 664 sys sys 969499892 3235
-sys/man/6/smtpd - 664 sys sys 971095216 8192
+sys/man/6/smtpd - 664 sys sys 1138191586 8178
 sys/man/6/snap - 664 sys sys 1132452694 2402
 sys/man/6/thumbprint - 664 sys sys 1019866709 1124
 sys/man/6/users - 664 sys sys 1130912014 1392
@@ -15530,7 +15498,7 @@ sys/src/libthread/xincmips.s - 664 sys sys 1014928160 674
 sys/src/libthread/xincport.h - 664 sys sys 1127405405 211
 sys/src/libthread/xincpower.s - 664 sys sys 1048645448 342
 sys/src/libventi - 20000000775 sys sys 947360466 0
-sys/src/libventi/client.c - 664 sys sys 1121977166 5362
+sys/src/libventi/client.c - 664 sys sys 1138191441 5493
 sys/src/libventi/debug.c - 664 sys sys 1045502093 1258
 sys/src/libventi/errfmt.c - 664 sys sys 1019678691 133
 sys/src/libventi/fatal.c - 664 sys sys 1084468118 225

+ 9 - 41
dist/replica/plan9.db

@@ -231,9 +231,9 @@
 386/bin/fortune - 775 sys sys 1135570810 67113
 386/bin/fossil - 20000000775 sys sys 1042005470 0
 386/bin/fossil/conf - 775 sys sys 1085077052 1506
-386/bin/fossil/flchk - 775 sys sys 1135570810 237600
-386/bin/fossil/flfmt - 775 sys sys 1135570811 245747
-386/bin/fossil/fossil - 775 sys sys 1135570812 360522
+386/bin/fossil/flchk - 775 sys sys 1138211975 237734
+386/bin/fossil/flfmt - 775 sys sys 1138211976 245881
+386/bin/fossil/fossil - 775 sys sys 1138211977 360656
 386/bin/fossil/last - 775 sys sys 1135570812 63280
 386/bin/freq - 775 sys sys 1136397208 61797
 386/bin/fs - 20000000775 sys sys 954380769 0
@@ -567,7 +567,7 @@
 386/lib/libstdio.a - 664 sys sys 1115950159 126206
 386/lib/libsunrpc.a - 664 sys sys 1115950160 355994
 386/lib/libthread.a - 664 sys sys 1135531448 71308
-386/lib/libventi.a - 664 sys sys 1124766772 97708
+386/lib/libventi.a - 664 sys sys 1138211977 98048
 386/mbr - 775 sys sys 1131317338 407
 386/mkfile - 664 sys sys 948141303 46
 386/pbs - 775 sys sys 1131317339 494
@@ -5391,7 +5391,7 @@ power/mkfile - 664 sys sys 948141304 46
 rc - 20000000775 sys sys 944959447 0
 rc/bin - 20000000775 sys sys 1018637942 0
 rc/bin/9fat: - 775 sys sys 1133179689 367
-rc/bin/9fs - 775 sys sys 1079969823 948
+rc/bin/9fs - 775 sys sys 1138240042 1027
 rc/bin/B - 775 sys sys 945617206 645
 rc/bin/C - 775 sys sys 1127395076 855
 rc/bin/Kill - 775 sys sys 1018637942 115
@@ -5591,46 +5591,35 @@ sparc64/lib - 20000000775 sys sys 1114458535 0
 sparc64/mkfile - 664 sys sys 1114458667 46
 sys - 20000000775 sys sys 952648870 0
 sys/doc - 20000000775 sys sys 1018471272 0
-sys/doc/-.2669382.gif - 664 sys sys 1019969850 2078
 sys/doc/8½ - 20000000775 sys sys 945616779 0
-sys/doc/8½/8½.html - 664 sys sys 1020895860 33484
 sys/doc/8½/8½.ms - 664 sys sys 1020895859 31593
 sys/doc/8½/8½.ps - 664 sys sys 1020895860 797150
 sys/doc/8½/fig1.ps - 664 sys sys 1020895859 473747
 sys/doc/8½/mkfile - 664 sys sys 1020895860 215
-sys/doc/9.html - 664 sys sys 1136302690 87619
 sys/doc/9.ms - 664 sys sys 953237044 84632
 sys/doc/9.ps - 664 sys sys 960837924 508340
-sys/doc/acid.html - 664 sys sys 1091459045 71723
 sys/doc/acid.ms - 664 sys sys 1127411211 65062
 sys/doc/acid.ps - 664 sys sys 1015012454 426359
-sys/doc/acidpaper.html - 664 sys sys 1091459045 46880
 sys/doc/acidpaper.ms - 664 sys sys 952880777 44805
 sys/doc/acidpaper.ps - 664 sys sys 960837913 359639
 sys/doc/acme - 20000000775 sys sys 945616779 0
 sys/doc/acme/acme.fig1 - 664 sys sys 944959632 164559
 sys/doc/acme/acme.fig2 - 664 sys sys 944959632 56026
-sys/doc/acme/acme.html - 664 sys sys 1020013936 51769
 sys/doc/acme/acme.ms - 664 sys sys 952880782 49851
 sys/doc/acme/acme.pdf - 664 sys sys 1020384351 117006
 sys/doc/acme/acme.ps - 664 sys sys 960837907 611301
 sys/doc/acme/bs - 664 sys sys 944959634 556
 sys/doc/acme/mkfile - 664 sys sys 961259926 304
-sys/doc/ape.html - 664 sys sys 1091459042 14415
 sys/doc/ape.ms - 664 sys sys 953344517 12595
 sys/doc/ape.ps - 664 sys sys 960837914 258779
-sys/doc/asm.html - 664 sys sys 1091459045 31098
 sys/doc/asm.ms - 664 sys sys 958247686 28542
 sys/doc/asm.ps - 664 sys sys 960837915 322051
-sys/doc/auth.html - 664 sys sys 1091459079 77445
 sys/doc/auth.ms - 664 sys sys 1021579975 66803
 sys/doc/auth.ps - 664 sys sys 1021579976 451672
 sys/doc/cleanps - 775 sys sys 961259933 184
 sys/doc/colophon.ps - 664 sys sys 960837922 214122
-sys/doc/comp.html - 664 sys sys 1091459046 42144
 sys/doc/comp.ms - 664 sys sys 954266992 37792
 sys/doc/comp.ps - 664 sys sys 960837915 345786
-sys/doc/compiler.html - 664 sys sys 1091459044 32960
 sys/doc/compiler.ms - 664 sys sys 1067721142 30279
 sys/doc/compiler.ps - 664 sys sys 1091459054 309735
 sys/doc/contents.ms - 664 sys sys 1019916701 4920
@@ -5641,7 +5630,6 @@ sys/doc/fossil.ms - 664 sys sys 1063856349 31400
 sys/doc/fossil.pdf - 664 sys sys 1042123169 63200
 sys/doc/fossil.ps - 664 sys sys 1135487951 313552
 sys/doc/fs - 20000000775 sys sys 945616779 0
-sys/doc/fs/fs.html - 664 sys sys 1020013937 21345
 sys/doc/fs/fs.pdf - 664 sys sys 1020384351 47177
 sys/doc/fs/fs.ps - 664 sys sys 960837905 276918
 sys/doc/fs/mkfile - 664 sys sys 961259926 282
@@ -5656,7 +5644,6 @@ sys/doc/fs/p7 - 664 sys sys 953844581 958
 sys/doc/fs/p8 - 664 sys sys 953844574 881
 sys/doc/fs/xx - 664 sys sys 944959592 65957
 sys/doc/il - 20000000775 sys sys 945616779 0
-sys/doc/il/il.html - 664 sys sys 1020013937 12278
 sys/doc/il/il.ms - 664 sys sys 952880783 11367
 sys/doc/il/il.pdf - 664 sys sys 1020384351 44630
 sys/doc/il/il.ps - 664 sys sys 960837905 258028
@@ -5666,29 +5653,21 @@ sys/doc/il/transition.fig - 664 sys sys 944959591 15431
 sys/doc/il/transition.pic - 664 sys sys 944959591 11912
 sys/doc/il/xx - 664 sys sys 944959591 48924
 sys/doc/index.htm - 664 sys sys 1019916696 6906
-sys/doc/index.html - 664 sys sys 1020082751 6906
-sys/doc/lexnames.html - 664 sys sys 1091459043 37261
 sys/doc/lexnames.ms - 664 sys sys 954383595 34046
 sys/doc/lexnames.ps - 664 sys sys 960837909 335546
-sys/doc/libmach.html - 664 sys sys 1091459044 26650
 sys/doc/libmach.ms - 664 sys sys 1021579974 24145
 sys/doc/libmach.ps - 664 sys sys 960837916 291283
-sys/doc/lp.html - 664 sys sys 1091459043 21721
 sys/doc/lp.ms - 664 sys sys 954614673 22366
 sys/doc/lp.ps - 664 sys sys 960837917 294399
-sys/doc/mk.html - 664 sys sys 1091459046 40021
 sys/doc/mk.ms - 664 sys sys 952880779 34413
 sys/doc/mk.ps - 664 sys sys 960837917 329779
 sys/doc/mkfile - 664 sys sys 1091459055 4411
-sys/doc/mkfiles.html - 664 sys sys 1091459045 17750
 sys/doc/mkfiles.ms - 664 sys sys 952880779 17888
 sys/doc/mkfiles.ps - 664 sys sys 960837918 269496
-sys/doc/names.html - 664 sys sys 1091459046 23529
 sys/doc/names.ms - 664 sys sys 954269607 22103
 sys/doc/names.ps - 664 sys sys 960837918 288716
 sys/doc/net - 20000000775 sys sys 954033300 0
 sys/doc/net/mkfile - 664 sys sys 961259927 345
-sys/doc/net/net.html - 664 sys sys 1020013937 43449
 sys/doc/net/net.ms - 664 sys sys 952880783 41191
 sys/doc/net/net.pdf - 664 sys sys 1020384351 82603
 sys/doc/net/net.ps - 664 sys sys 960837908 350053
@@ -5696,25 +5675,19 @@ sys/doc/net/tree - 664 sys sys 944959636 866
 sys/doc/net/tree.pout - 664 sys sys 944959636 1755
 sys/doc/network.art - 664 sys sys 944959651 2260
 sys/doc/network.pic - 664 sys sys 944959651 4124
-sys/doc/plumb.html - 664 sys sys 1091459044 55783
 sys/doc/plumb.ms - 664 sys sys 954383596 53250
 sys/doc/plumb.ps - 664 sys sys 960837910 391830
-sys/doc/port.html - 664 sys sys 1091459042 18123
 sys/doc/port.ms - 664 sys sys 1020111393 16694
 sys/doc/port.ps - 664 sys sys 1020111394 268901
 sys/doc/preamble - 664 sys sys 961259497 203475
 sys/doc/prfile - 775 sys sys 944959668 3782
-sys/doc/prog4.html - 664 sys sys 1091459046 18653
 sys/doc/prog4.ms - 664 sys sys 1019932830 16485
 sys/doc/prog4.ps - 664 sys sys 1019932831 271581
 sys/doc/ps - 664 sys sys 944959649 1739
-sys/doc/rc.html - 664 sys sys 1091459044 41702
 sys/doc/rc.ms - 664 sys sys 1063856321 34373
 sys/doc/rc.ps - 664 sys sys 960837920 337955
-sys/doc/release3.html - 664 sys sys 1019922810 6329
 sys/doc/release3.ms - 664 sys sys 961261276 5492
 sys/doc/release3.ps - 664 sys sys 961261277 230682
-sys/doc/release4.html - 664 sys sys 1091459042 6473
 sys/doc/release4.ms - 664 sys sys 1063856338 5160
 sys/doc/release4.ps - 664 sys sys 1091459052 230868
 sys/doc/sam - 20000000775 sys sys 945617037 0
@@ -5731,24 +5704,19 @@ sys/doc/sam/fig6.pic - 464 sys sys 944959644 1105
 sys/doc/sam/fig7.pic - 464 sys sys 944959644 258
 sys/doc/sam/mkfile - 664 sys sys 961259927 574
 sys/doc/sam/refs - 464 sys sys 944959644 2652
-sys/doc/sam/sam.html - 664 sys sys 1020013938 100660
 sys/doc/sam/sam.ms - 464 sys sys 954266468 94536
 sys/doc/sam/sam.pdf - 664 sys sys 1020384352 156123
 sys/doc/sam/sam.ps - 664 sys sys 960837910 707546
 sys/doc/sam/sam.tut - 464 sys sys 944959644 40481
-sys/doc/sleep.html - 664 sys sys 1091459043 16602
 sys/doc/sleep.ms - 664 sys sys 953237030 15206
 sys/doc/sleep.ps - 664 sys sys 960837920 263882
-sys/doc/spin.html - 664 sys sys 1091459042 75873
 sys/doc/spin.ms - 664 sys sys 953344522 67475
 sys/doc/spin.ps - 664 sys sys 960837923 443064
 sys/doc/title - 664 sys sys 1018974170 740
 sys/doc/title.ps - 664 sys sys 1018974170 214289
 sys/doc/trademarks.ps - 664 sys sys 960837912 217896
-sys/doc/troff.html - 664 sys sys 1019922811 110932
 sys/doc/troff.ms - 664 sys sys 953237047 120683
 sys/doc/troff.ps - 664 sys sys 1091459051 782310
-sys/doc/utf.html - 664 sys sys 1091459044 43965
 sys/doc/utf.ms - 664 sys sys 952880781 41659
 sys/doc/utf.ps - 664 sys sys 960837922 363085
 sys/doc/venti - 20000000775 sys sys 1019852318 0
@@ -5763,7 +5731,7 @@ sys/doc/venti/emelie.gif - 664 sys sys 1019852316 5004
 sys/doc/venti/emelie2.gif - 664 sys sys 1019852317 4357
 sys/doc/venti/mkfile - 664 sys sys 1019965454 79
 sys/doc/venti/probablity.gif - 664 sys sys 1019852317 1244
-sys/doc/venti/venti.html - 664 sys sys 1019852317 55272
+sys/doc/venti/venti.html - 664 sys sys 1138233389 55272
 sys/doc/venti/venti.pdf - 664 sys sys 1020384352 139090
 sys/doc/venti/venti.ps - 664 sys sys 1019852320 2012620
 sys/games - 20000000775 sys sys 952648872 0
@@ -7596,7 +7564,7 @@ sys/man/3/segment - 664 sys sys 1017423721 2378
 sys/man/3/srv - 664 sys sys 958419690 1470
 sys/man/3/ssl - 664 sys sys 1018386776 3413
 sys/man/3/tls - 664 sys sys 1045501496 7018
-sys/man/3/uart - 664 sys sys 1102093395 1710
+sys/man/3/uart - 664 sys sys 1138191356 2003
 sys/man/3/usb - 664 sys sys 1126971427 6960
 sys/man/3/vga - 664 sys sys 1131301005 4957
 sys/man/4 - 20000000775 sys sys 1018581459 0
@@ -7682,7 +7650,7 @@ sys/man/6/plot - 664 sys sys 944959679 6739
 sys/man/6/plumb - 664 sys sys 969499892 10918
 sys/man/6/regexp - 664 sys sys 954089523 2050
 sys/man/6/rewrite - 664 sys sys 969499892 3235
-sys/man/6/smtpd - 664 sys sys 971095216 8192
+sys/man/6/smtpd - 664 sys sys 1138191586 8178
 sys/man/6/snap - 664 sys sys 1132452694 2402
 sys/man/6/thumbprint - 664 sys sys 1019866709 1124
 sys/man/6/users - 664 sys sys 1130912014 1392
@@ -15530,7 +15498,7 @@ sys/src/libthread/xincmips.s - 664 sys sys 1014928160 674
 sys/src/libthread/xincport.h - 664 sys sys 1127405405 211
 sys/src/libthread/xincpower.s - 664 sys sys 1048645448 342
 sys/src/libventi - 20000000775 sys sys 947360466 0
-sys/src/libventi/client.c - 664 sys sys 1121977166 5362
+sys/src/libventi/client.c - 664 sys sys 1138191441 5493
 sys/src/libventi/debug.c - 664 sys sys 1045502093 1258
 sys/src/libventi/errfmt.c - 664 sys sys 1019678691 133
 sys/src/libventi/fatal.c - 664 sys sys 1084468118 225

+ 46 - 0
dist/replica/plan9.log

@@ -27199,3 +27199,49 @@
 1138120255 0 c sys/src/9/port/devuart.c - 664 sys sys 1138118881 12141
 1138127457 0 c sys/src/9/port/portdat.h - 664 sys sys 1138127259 22540
 1138131057 0 c sys/games/lib/fortunes - 664 sys sys 1138129633 257147
+1138192278 0 c sys/man/3/uart - 664 sys sys 1138191356 2003
+1138192278 1 c sys/man/6/smtpd - 664 sys sys 1138191586 8178
+1138192278 2 c sys/src/libventi/client.c - 664 sys sys 1138191441 5493
+1138212084 0 c 386/bin/fossil/flchk - 775 sys sys 1138211975 237734
+1138212084 1 c 386/bin/fossil/flfmt - 775 sys sys 1138211976 245881
+1138212084 2 c 386/bin/fossil/fossil - 775 sys sys 1138211977 360656
+1138212084 3 c 386/lib/libventi.a - 664 sys sys 1138211977 98048
+1138230089 0 c sys/doc/9.html - 664 sys sys 1138229042 163762
+1138230089 1 c sys/doc/auth.html - 664 sys sys 1138229043 256779
+1138230089 2 a sys/doc/contents.html - 664 sys sys 1138229042 27104
+1138230089 3 c sys/doc/names.html - 664 sys sys 1138229043 49369
+1138233689 0 c sys/doc/venti/venti.html - 664 sys sys 1138233389 55272
+1138233689 1 d sys/doc/utf.html - 664 sys sys 1091459044 0
+1138233689 2 d sys/doc/troff.html - 664 sys sys 1019922811 0
+1138233689 3 d sys/doc/spin.html - 664 sys sys 1091459042 0
+1138233689 4 d sys/doc/sleep.html - 664 sys sys 1091459043 0
+1138233689 5 d sys/doc/sam/sam.html - 664 sys sys 1020013938 0
+1138233689 6 d sys/doc/release4.html - 664 sys sys 1091459042 0
+1138233689 7 d sys/doc/release3.html - 664 sys sys 1019922810 0
+1138233689 8 d sys/doc/rc.html - 664 sys sys 1091459044 0
+1138233689 9 d sys/doc/prog4.html - 664 sys sys 1091459046 0
+1138233689 10 d sys/doc/port.html - 664 sys sys 1091459042 0
+1138233689 11 d sys/doc/plumb.html - 664 sys sys 1091459044 0
+1138233689 12 d sys/doc/net/net.html - 664 sys sys 1020013937 0
+1138233689 13 d sys/doc/names.html - 664 sys sys 1138229043 0
+1138233689 14 d sys/doc/mkfiles.html - 664 sys sys 1091459045 0
+1138233689 15 d sys/doc/mk.html - 664 sys sys 1091459046 0
+1138233689 16 d sys/doc/lp.html - 664 sys sys 1091459043 0
+1138233689 17 d sys/doc/libmach.html - 664 sys sys 1091459044 0
+1138233689 18 d sys/doc/lexnames.html - 664 sys sys 1091459043 0
+1138233689 19 d sys/doc/index.html - 664 sys sys 1020082751 0
+1138233689 20 d sys/doc/il/il.html - 664 sys sys 1020013937 0
+1138233689 21 d sys/doc/fs/fs.html - 664 sys sys 1020013937 0
+1138233689 22 d sys/doc/contents.html - 664 sys sys 1138229042 0
+1138233689 23 d sys/doc/compiler.html - 664 sys sys 1091459044 0
+1138233689 24 d sys/doc/comp.html - 664 sys sys 1091459046 0
+1138233689 25 d sys/doc/auth.html - 664 sys sys 1138229043 0
+1138233689 26 d sys/doc/asm.html - 664 sys sys 1091459045 0
+1138233689 27 d sys/doc/ape.html - 664 sys sys 1091459042 0
+1138233689 28 d sys/doc/acme/acme.html - 664 sys sys 1020013936 0
+1138233689 29 d sys/doc/acidpaper.html - 664 sys sys 1091459045 0
+1138233689 30 d sys/doc/acid.html - 664 sys sys 1091459045 0
+1138233689 31 d sys/doc/9.html - 664 sys sys 1138229042 0
+1138233689 32 d sys/doc/8½/8½.html - 664 sys sys 1020895860 0
+1138233689 33 d sys/doc/-.2669382.gif - 664 sys sys 1019969850 0
+1138240891 0 c rc/bin/9fs - 775 sys sys 1138240042 1027

+ 3 - 1
rc/bin/9fs

@@ -20,7 +20,9 @@ case other
 case juke
 	srv -q il!jukefs && mount /srv/il!jukefs /n/njuke && bind -c /n/njuke/juke /n/juke
 case sources
-	srv -m tcp!sources.cs.bell-labs.com sources /n/sources
+	srv -q tcp!sources.cs.bell-labs.com sources /n/sources &&
+		{ mount /srv/sources /n/sources ||
+		  mount -n /srv/sources /n/sources }
 case sourcesdump
 	9fs sources
 	mount /srv/sources /n/sourcesdump main/archive

BIN
sys/doc/-.2669382.gif


+ 0 - 868
sys/doc/8½/8½.html

@@ -1,868 +0,0 @@
-<html>
-<title>
-data
-</title>
-<body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
-<H1>8&#189;, the Plan 9 Window System
-</H1>
-<DL><DD><I>Rob Pike<br>
-rob@plan9.bell-labs.com<br>
-</I></DL>
-<DL><DD><H4>ABSTRACT</H4>
-<DL>
-<DT><DT>&#32;<DD>
-NOTE:<I> Originally appeared, in a slightly different form, in
-Proc. of the Summer 1991 USENIX Conf.,
-pp. 257-265,
-Nashville.
-Note that
-<TT>8&#189;</TT>
-has been replaced by
-<TT>rio</TT>
-(see
-<A href="/magic/man2html/1/rio"><I>rio</I>(1)).
-</A></I><DT>&#32;<DD></dl>
-<br>
-The Plan 9 window system, 8&#189;, is a modest-sized program of novel design.
-It provides textual I/O and bitmap graphic services to both
-local and remote client programs by offering a multiplexed file service to those clients.
-It serves traditional UNIX files like
-<TT>/dev/tty</TT>
-as well as more unusual ones that provide access to the mouse
-and the raw screen.
-Bitmap graphics operations are provided by serving a file called
-<TT>/dev/bitblt</TT>
-that interprets client messages to perform raster operations.
-The file service that 8&#189; offers its clients is identical to that it uses for
-its own implementation, so it is fundamentally no more than
-a multiplexer.
-This architecture has some rewarding symmetries and can be implemented
-compactly.
-</DL>
-<H4>Introduction
-</H4>
-<P>
-In 1989 I constructed a toy window system from only a few hundred
-lines of source code using a custom language and an unusual architecture
-involving concurrent processes [Pike89].
-Although that system was rudimentary at best, it demonstrated that
-window systems are not inherently complicated.
-The following year, for the new Plan 9 distributed system [Pike92], I applied some of
-the lessons from that toy project to write, in C,
-a production-quality window system
-called 8&#189;.
-8&#189; provides, on black-and-white, grey-scale, or color displays,
-the services required of a modern window system, including
-programmability and support for remote graphics.
-The entire system, including the default program that runs in the 
-window &#173; the equivalent of
-<TT>xterm</TT>
-[Far89] with `cutting and pasting' between windows &#173;
-is well under 90 kilobytes of text on a Motorola 68020 processor, about
-half the size of the
-operating system
-kernel that supports it and a tenth the size of the X server
-[Sche86]
-<I>without</I>
-<TT>xterm</TT>.
-</P>
-<P>
-What makes 8&#189; so compact?  Much of the saving comes from overall simplicity:
-8&#189; has little graphical fanciness, a concise programming interface, and
-a simple, fixed user interface.
-8&#189; also makes some decisions by fiat
-&#173; three-button mouse, overlapping windows, built-in terminal program and
-window manager, etc. &#173;
-rather than trying to appeal to all tastes.
-Although compact, 8&#189; is not ascetic.
-It provides the fundamentals and
-enough extras to make them comfortable to use.
-The most important contributor to its small size, though, is its
-overall design as a file server.
-This structure may be applicable to window systems
-on traditional UNIX-like operating systems.
-</P>
-<P>
-The small size of 8&#189; does not reflect reduced functionality:
-8&#189; provides service roughly equivalent to the X window system.
-8&#189;'s clients may of course be as complex as they choose,
-although the tendency to mimic 8&#189;'s design
-and the clean programming interface means they
-are not nearly as bloated as X applications.
-</P>
-<H4>User's Model
-</H4>
-<P>
-8&#189; turns the single screen, mouse, and keyboard of the terminal
-(in Plan 9 terminology) or workstation (in commercial terminology) into an array
-of independent virtual terminals that may be textual terminals supporting a shell and
-the usual suite of tools
-or graphical applications using the full power of the bitmap screen and mouse.
-Text is represented in UTF, an encoding of the Unicode Standard [Pike93].
-The entire programming interface is provided through
-reading and writing files in
-<TT>/dev</TT>.
-</P>
-<P>
-Primarily for reasons of history and familiarity,
-the general model and appearance of 8&#189; are similar to those of
-<TT>mux</TT>
-[Pike88].
-The right button has a short menu for controlling window creation, destruction,
-and placement.
-When a window is created, it runs the default shell,
-<TT>rc</TT>
-[Duff90], with standard input
-and output directed to the window and accessible through the file
-<TT>/dev/cons</TT>
-(`console'),
-analogous to the
-<TT>/dev/tty</TT>
-of UNIX.
-The name change represents a break with the past: Plan 9 does not provide a
-Teletype-style model of terminals.  8&#189; provides the only way
-most users ever access Plan 9.
-</P>
-<P>
-Graphical applications,
-like ordinary programs,
-may be run by typing their names
-to the shell running in a window.
-This runs the application in the same window;
-to run the application in a new window one may use an external program,
-<TT>window</TT>,
-described below.
-For graphical applications, the virtual terminal model
-is extended somewhat to allow programs to perform graphical operations,
-access the
-mouse, and perform related functions by reading and writing files with
-suggestive names such as
-<TT>/dev/mouse</TT>
-and
-<TT>/dev/window</TT>
-multiplexed per-window
-much like
-<TT>/dev/cons</TT>.
-The implementation and semantics of these files,
-described below, is central to the structure of 8&#189;.
-</P>
-<P>
-The default program that runs in a window is familiar to users of Blit terminals [Pike83].
-It is very similar to that of
-<TT>mux</TT>
-[Pike88], providing mouse-based editing of input and output text,
-the ability to scroll back to see earlier output, and so on.
-It also has a new feature, toggled by typing ESC,
-that enables the user to control when
-typed characters may be read by the shell or application,
-instead of (for example) after each newline.
-This feature makes the window program directly useful for many text-editing
-tasks such as composing mail messages before sending them.
-</P>
-<H4>Plan 9 and 8&#189;
-</H4>
-<P>
-Plan 9 is a distributed system that provides support for UNIX-like applications
-in an environment built from distinct CPU servers, file servers, and terminals
-connected by a variety of networks [Pike90].
-The terminals are comparable to modest workstations that, once connected to a file
-server over a medium-bandwidth network such as Ethernet, are self-sufficient computers
-running a full operating system.
-Unlike workstations, however, their role is just to
-provide an affordable multiplexed user interface to the rest of the system:
-they run the window system and support simple interactive
-tasks such as text editing.
-Thus they lie somewhere between workstations and X terminals in design,
-cost, performance, and function.
-(The terminals can be used
-for general computing, but in practice Plan 9 users do their
-computing on the CPU servers.)
-The Plan 9 terminal software, including 8&#189;,
-was developed on a 68020-based
-machine called a Gnot
-and has been ported to
-the NeXTstation,
-the MIPS Magnum 3000,
-SGI Indigos,
-and Sun SPARCstations&#173;all small workstations that we use as terminals&#173;as
-well as PCs.
-</P>
-<P>
-Heavy computations such as compilation, text processing,
-or scientific calculation are done on the CPU servers, which are connected
-to the file servers by high-bandwidth networks.
-For interactive work,
-these computations can access the terminal that instantiated them.
-The terminal and CPU server being used by a particular user are connected to the
-same file server, although over different networks; Plan 9 provides a view of the
-file server that is independent of location in the network.
-</P>
-<P>
-The components of Plan 9 are connected by a common protocol based on the sharing of files.
-All resources in the network are implemented as file servers; programs that wish to
-access them connect to them over the network and communicate using ordinary file
-operations.
-An unusual aspect of Plan 9 is that the
-name space
-of a process, the set of files that can be accessed by name
-(for example by an
-<TT>open</TT>
-system call) is not global to all processes on a machine; distinct processes
-may have distinct name spaces.  The system provides methods by which processes
-may change their name spaces, such as the ability to
-<I>mount</I>
-a service upon an existing directory, making the files of the service
-visible in the directory.
-(This is a different operation from its
-UNIX
-namesake.)
-Multiple services may be mounted upon the same directory,
-allowing the files from multiple services to be accessed in the same directory.
-Options to the
-<TT>mount</TT>
-system call control the order of searching for files in such a
-union directory.
-</P>
-<P>
-The most obvious example of a network resource is a file server, where permanent
-files reside.  There are a number of unusual services, however, whose design in
-a different environment would likely not be file-based.  Many are described
-elsewhere [Pike92]; some examples are the representation
-of processes for debugging,
-much like Killian's process files for the 8th edition [Kill84],
-and the implementation of the name/value pairs of the
-UNIX
-<TT>exec</TT>
-environment as files.
-User processes may also implement a file service and make it available to clients
-in the network, much like the `mounted streams' in the 9th Edition
-[Pres90].
-A typical example is a program that interprets an externally-defined file system
-such as that on a CD-ROM or a standard
-UNIX
-system and makes the contents available to Plan 9 programs.
-This design is used by all distributed applications in Plan 9, including 8&#189;.
-</P>
-<P>
-8&#189; serves a set of files in the conventional directory
-<TT>/dev</TT>
-with names like
-<TT>cons</TT>,
-<TT>mouse</TT>,
-and
-<TT>screen</TT>.
-Clients of 8&#189; communicate with the window system by reading and writing
-these files.
-For example, a client program, such as a shell,
-can print text by writing its standard output, which is automatically
-connected to
-<TT>/dev/cons</TT>,
-or it may open and write that file explicitly.
-Unlike files served by a traditional file server, however, the instance of
-<TT>/dev/cons</TT>
-served in each window by 8&#189; is a distinct file;
-the per-process name spaces of Plan 9 allow 8&#189; to provide a unique
-<TT>/dev/cons</TT>
-to each client.
-This mechanism is best illustrated by the creation of a new 8&#189; client.
-</P>
-<P>
-When 8&#189; starts, it creates a full-duplex pipe to be the communication
-medium for the messages that implement the file service it will provide.
-One end will be shared by all the clients; the other end is held by
-8&#189; to accept requests for I/O.
-When a user makes a new window using the mouse,
-8&#189; allocates the window data structures and forks a child process.
-The child's name space,
-initially shared with the parent,
-is then duplicated
-so that changes the child makes to its name space will not affect the parent.
-The child then attaches its end of the communication pipe,
-<TT>cfd</TT>,
-to the directory
-<TT>/dev</TT>
-by doing a
-<TT>mount</TT>
-system call:
-<DL><DT><DD><TT><PRE>
-mount(cfd, "/dev", MBEFORE, buf)
-</PRE></TT></DL>
-This call attaches the service associated with the file descriptor
-<TT>cfd</TT>
-&#173; the client end of the pipe &#173; to the beginning of
-<TT>/dev</TT>
-so that the files in the new service take priority over existing files
-in the directory.
-This makes the new files
-<TT>cons</TT>,
-<TT>mouse</TT>,
-and so on,
-available in
-<TT>/dev</TT>
-in a way that hides any files with the same names already in place.
-The argument
-<TT>buf</TT>
-is a character string (null in this case),
-described below.
-</P>
-<P>
-The client process then closes file descriptors 0, 1, and 2 and opens
-<TT>/dev/cons</TT>
-repeatedly to connect the standard
-input, output, and error files to the window's
-<TT>/dev/cons</TT>.
-It then does an
-<TT>exec</TT>
-system call to begin executing the shell in the window.
-This entire sequence, complete with error handling, is 33 lines of C.
-</P>
-<P>
-The view of these events from 8&#189;'s end of the pipe is a sequence
-of file protocol messages from the new client generated by the
-intervening operating
-system in response to the
-<TT>mount</TT>
-and
-<TT>open</TT>
-system calls executed by the client.
-The message generated by the
-<TT>mount</TT>
-informs 8&#189; that a new client has attached to the file service it provides;
-8&#189;'s response is a unique identifier kept by the operating system and
-passed in all messages generated by I/O on the files derived from that
-<TT>mount</TT>.
-This identifier is used by 8&#189; to distinguish the various clients so
-each sees a unique
-<TT>/dev/cons</TT>;
-most servers do not need to make this distinction.
-</P>
-<P>
-A process unrelated to 8&#189; may create windows by a variant of this mechanism.
-When 8&#189; begins, it uses a Plan 9 service to `post' the client end of the
-communication pipe in a public place.
-A process may open that pipe and
-<TT>mount</TT>
-it to attach to the window system,
-much in the way an X client may connect to a
-UNIX
-domain socket to the server bound to the file system.
-The final argument to
-<TT>mount</TT>
-is passed through uninterpreted by the operating
-system.
-It provides a way for the client and server to
-exchange information at the time of the
-<TT>mount</TT>.
-8&#189; interprets it as the dimensions of the window to be
-created for the new client.  (In the case above, the window has been
-created by the time the mount occurs, and
-<TT>buf</TT>
-carries no information.)
-When the
-<TT>mount</TT>
-returns, the process can open the files of the new window and begin I/O to
-use it.
-</P>
-<P>
-Because 8&#189;'s interface is based on files,
-standard system utilities can be used to control its services.
-For example,
-its method of creating windows externally is packaged in a
-16-line shell script, called
-<TT>window</TT>,
-the core of which is just a
-<TT>mount</TT>
-operation that prefixes 8&#189;'s directory to
-<TT>/dev</TT>
-and runs a command passed on the argument line:
-<DL><DT><DD><TT><PRE>
-mount -b $'8&#189;serv' /dev
-$* &#60; /dev/cons &#62; /dev/cons &#62;[2] /dev/cons &amp;
-</PRE></TT></DL>
-The
-<TT>window</TT>
-program is typically employed by users to create their
-initial working environment when they boot the system, although
-it has more general possibilities.
-</P>
-<P>
-Other basic features of the system fall out naturally from the
-file-based model.
-When the user deletes a window, 8&#189; sends the equivalent of a
-UNIX
-signal to the process group &#173; the clients &#173; in the window,
-removes the window from the screen, and poisons the incoming connections
-to the files that drive it.  If a client ignores the signal and
-continues to write to the window, it will get I/O errors.
-If, on the other hand, all the processes in a window exit spontaneously,
-they will automatically close all connections to the window.
-8&#189; counts references to the window's files; when none are left,
-it shuts down the window and removes it from the screen.
-As a different example, when the user hits the DEL key to generate an
-interrupt,
-8&#189; writes a message to a special file, provided by Plan 9's
-process control interface, that interrupts all the processes
-in the window.
-In all these examples, the implementation works seamlessly
-across a network.
-</P>
-<P>
-There are two valuable side effects of implementing
-a window system by multiplexing
-<TT>/dev/cons</TT>
-and other such files.
-First, the problem of giving a meaningful
-interpretation to the file
-<TT>/dev/cons</TT>
-(<TT>/dev/tty</TT>)
-in each window is solved automatically.
-To provide
-<TT>/dev/cons</TT>
-is the fundamental job of the window system, rather than just an awkward burden;
-other systems must often make special and otherwise irrelevant arrangements for
-<TT>/dev/tty</TT>
-to behave as expected in a window.
-Second, any program that can access the server, including a
-process on a remote machine, can access the files using standard
-read and write system calls to communicate with the window system,
-and standard open and close calls to connect to it.
-Again, no special arrangements need to be made for remote processes to
-use all the graphics facilities of 8&#189;.
-</P>
-<H4>Graphical input
-</H4>
-<P>
-Of course 8&#189; offers more than ASCII I/O to its clients.
-The state of the mouse may be discovered by reading the file
-<TT>/dev/mouse</TT>,
-which returns a ten-byte message encoding the state
-of the buttons and the position of the cursor.
-If the mouse has not moved since the last read of
-<TT>/dev/mouse</TT>,
-or if the window associated with the instance of
-<TT>/dev/mouse</TT>
-is not the `input focus', the read blocks.
-</P>
-<P>
-The format of the message is:
-<DL><DT><DD><TT><PRE>
-<TT>'m'</TT>
-1 byte of button state
-4 bytes of x, low byte first
-4 bytes of y, low byte first
-</PRE></TT></DL>
-As in all shared data structures in Plan 9,
-the order of every byte in the message is defined 
-so all clients can execute the same code to unpack the message
-into a local data structure.
-</P>
-<P>
-For keyboard input, clients can read
-<TT>/dev/cons</TT>
-or, if they need character-at-a-time input,
-<TT>/dev/rcons</TT>
-(`raw console').
-There is no explicit event mechanism to help clients that need to read
-from multiple sources.
-Instead, a small (365 line) external
-support library can be used.
-It attaches a process
-to the various blocking input sources &#173; mouse, keyboard, and perhaps
-a third user-provided file descriptor &#173;
-and funnels their input into a single pipe from which may be read
-the various types of
-events in the traditional style.
-This package is a compromise.  As discussed in a previous paper
-[Pike89] I prefer
-to free applications from event-based programming.  Unfortunately, though, I see
-no easy way to achieve this in single-threaded C programs, and am unwilling
-to require all programmers to master concurrent programming.
-It should be noted, though, that even this compromise results in a small
-and easily understood interface.  An example program that uses it is
-given near the end of the paper.
-</P>
-<H4>Graphical output
-</H4>
-<P>
-The file
-<TT>/dev/screen</TT>
-may be read by any client to recover the contents of the entire screen,
-such as for printing (see Figure 1).
-Similarly,
-<TT>/dev/window</TT>
-holds the contents of the current window.
-These are read-only files.
-</P>
-<P>
-To perform graphics operations in their windows, client programs access
-<TT>/dev/bitblt</TT>.
-It implements a protocol that encodes bitmap graphics operations.
-Most of the messages in the protocol (there are 23 messages in all, about
-half to manage the multi-level fonts necessary for efficient handling
-of Unicode characters)
-are transmissions (via a write)
-from the client to the window system to perform a graphical
-operation such as a
-<TT>bitblt</TT>
-[PLR85] or character-drawing operation; a few include return information
-(recovered via a read) to the client.
-As with
-<TT>/dev/mouse</TT>,
-the
-<TT>/dev/bitblt</TT>
-protocol is in a defined byte order.
-Here, for example, is the layout of the
-<TT>bitblt</TT>
-message:
-<DL><DT><DD><TT><PRE>
-<TT>'b'</TT>
-2 bytes of destination id
-2x4 bytes of destination point
-2 bytes of source id
-4x4 bytes of source rectangle
-2 bytes of boolean function code
-</PRE></TT></DL>
-</P>
-<DL>
-<DT><DT>&#32;<DD>
-Figure 1.
-A representative 8&#189; screen, running on a NeXTstation under Plan 9
-(with no NeXT software).  In the upper right, a program announces the
-arrival of mail.  In the top and left are a broswer for astronomical
-databases and an image of a galaxy produced by the browser.
-In the lower left there is a screen editor,
-<TT>sam</TT>
-[Pike87],
-editing Japanese text encoded in UTF,
-and in the lower right an 8&#189; running recursively and, inside that instantiation,
-a previewer for
-<TT>troff</TT>
-output.
-Underneath the faces is a small window running the command that
-prints the screen by passing
-<TT>/dev/screen</TT>
-to the bitmap printing utility.
-<br>&#32;<br>
-</dl>
-<P>
-The message is trivially constructed from the
-<TT>bitblt</TT>
-subroutine in the library, defined as
-<DL><DT><DD><TT><PRE>
-void bitblt(Bitmap *dst, Point dp,
-            Bitmap *src, Rectangle sr, Fcode c).
-</PRE></TT></DL>
-</P>
-<P>
-The `id'
-fields in the message indicate another property of 8&#189;:
-the clients do not store the actual data for any of their bitmaps locally.
-Instead, the protocol provides a message to allocate a bitmap, to be
-stored in the server, and returns to the client an integer identifier,
-much like a
-UNIX
-file descriptor, to be used in operations on that bitmap.
-Bitmap number 0 is conventionally the client's window,
-analogous to standard input for file I/O.
-In fact, no bitmap graphics operations are executed in the client at all;
-they are all performed on its behalf by the server.
-Again, using the standard remote file operations in Plan 9,
-this permits remote machines having no graphics capability, such
-as the CPU server,
-to run graphics applications.
-Analogous features of the original Andrew window system [Gos86]
-and of X [Sche86] require more complex mechanisms.
-</P>
-<P>
-Nor does 8&#189; itself operate directly on bitmaps.
-Instead, it calls another server to do its graphics operations for it,
-using an identical protocol.
-The operating system for the Plan 9 terminals contains an internal
-server that implements that protocol, exactly as does 8&#189;, but for a single
-client.  That server stores the actual bytes for the bitmaps
-and implements the fundamental bitmap graphics operations.
-Thus the environment in which 8&#189; runs
-has exactly the structure it provides for its clients;
-8&#189; reproduces the environment for its clients,
-multiplexing the interface to keep the clients separate.
-</P>
-<P>
-This idea of multiplexing by simulation is applicable to more
-than window systems, of course, and has some side effects.
-Since 8&#189; simulates its own environment for its clients, it may run
-in one of its own windows (see Figure 1).
-A useful and common application of this
-technique is to connect a window to a remote machine, such as a CPU
-server, and run the window system there so that each subwindow is automatically
-on the remote machine.
-It is also a handy way to debug a new version of the window system
-or to create an environment with, for example, a different default font.
-</P>
-<H4>Implementation
-</H4>
-<P>
-To provide graphics to its clients, 8&#189; mostly just multiplexes and passes
-through to its own server the clients' requests, occasionally rearranging
-the messages to maintain the fiction that the clients have unique screens
-(windows).
-To manage the overlapping windows it uses the layers model,
-which is handled by a separate library [Pike83a].
-Thus it has little work to do and is a fairly simple program;
-it is dominated by a couple of switch statements to interpret
-the bitmap and file server protocols.
-The built-in window program and its associated menus and text-management
-support are responsible for most of the code.
-</P>
-<P>
-The operating system's server is also compact:
-the version for the 68020 processor, excluding the implementation
-of a half dozen bitmap graphics operations, is 2295 lines of C
-(again, about half dealing with fonts);
-the graphics operations are another 2214 lines.
-</P>
-<P>
-8&#189; is structured as a set of communicating coroutines,
-much as discussed in a 1989 paper [Pike89].
-One coroutine manages the mouse, another the keyboard, and another
-is instantiated to manage the state of each window and associated client.
-When no coroutine wishes to run, 8&#189; reads the next file I/O request from
-its clients, which arrive serially on the full-duplex communication pipe.
-Thus 8&#189; is entirely synchronous.
-</P>
-<P>
-The program source is small and compiles in about 10 seconds
-in our Plan 9 environment.  There are ten source files and
-one
-<TT>makefile</TT>
-totaling 5100 lines.
-This includes the source for the window management process,
-the cut-and-paste terminal program,
-the window/file server itself,
-and a small coroutine library
-(<TT>proc.c</TT>).
-It does not include the layer library
-(another 1031 lines)
-or the library to handle the cutting and pasting of text
-displayed in a window (960 lines),
-or the general graphics support library that manages all the
-non-drawing aspects of graphics &#173; arithmetic on points and rectangles,
-memory management, error handling, clipping, &#173; plus fonts,
-events, and non-primitive drawing operations such as circles and ellipses
-(a final 3051 lines).
-Not all the pieces of these libraries are used by 8&#189; itself;
-a large part of the graphics library in particular is used only by clients.
-Thus it is somewhat unfair to 8&#189; just to sum these numbers, including
-the 4509 lines of support in the kernel, and arrive
-at a total implementation size of 14651 lines of source to implement
-all of 8&#189; from the lowest levels to the highest.
-But that number gives a fair measure of the complexity of the overall system.
-</P>
-<P>
-The implementation is also efficient.
-8&#189;'s performance is competitive to X windows'.
-Compared using Dunwoody's and Linton's
-<TT>gbench</TT>
-benchmarks on the 68020,
-distributed with the ``X Test Suite'',
-circles and arcs are drawn about half as fast in 8&#189; as in
-X11 release 4 compiled with
-<TT>gcc</TT>
-for equivalent hardware,
-probably because they are currently implemented in a user library
-by calls to the
-<TT>point</TT>
-primitive.
-Line drawing speed is about equal between the two systems.
-Unicode text is drawn about the same speed by 8&#189; as ASCII text by
-X, and
-the
-<TT>bitblt</TT>
-test is runs four times faster for 8&#189;.
-These numbers vary enough to caution against drawing sweeping
-conclusions, but they
-suggest that 8&#189;'s architecture does not penalize its performance.
-Finally, 8&#189; boots in under a second and creates a new window
-apparently instantaneously.
-</P>
-<H4>An example
-</H4>
-<P>
-Here is a complete program that runs under 8&#189;.
-It prints the string
-<TT>"hello world"</TT>
-wherever the left mouse button is depressed, and exits when the
-right mouse button is depressed.
-It also prints the string in the center of its window, and maintains
-that string when the window is resized.
-<DL><DT><DD><TT><PRE>
-#include &#60;u.h&#62;
-#include &#60;libc.h&#62;
-#include &#60;libg.h&#62;
-
-void
-ereshaped(Rectangle r)
-{
-    Point p;
-
-    screen.r = r;
-    bitblt(&amp;screen, screen.r.min, &amp;screen, r, Zero); /* clear */
-    p.x = screen.r.min.x + Dx(screen.r)/2;
-    p.y = screen.r.min.y + Dy(screen.r)/2;
-    p = sub(p, div(strsize(font, "hello world"), 2));
-    string(&amp;screen, p, font, "hello world", S);
-}
-
-main(void)
-{
-    Mouse m;
-
-    binit(0, 0, 0);	/* initialize graphics library */
-    einit(Emouse);	/* initialize event library */
-    ereshaped(screen.r);
-    for(;;){
-        m = emouse();
-        if(m.buttons &amp; RIGHTB)
-            break;
-        if(m.buttons &amp; LEFTB){
-            string(&amp;screen, m.xy, font, "hello world", S);
-            /* wait for release of button */
-            do; while(emouse().buttons &amp; LEFTB);
-        }
-    }
-}
-</PRE></TT></DL>
-The complete loaded binary is a little over 26K bytes on a 68020.
-This program should be compared to the similar ones in the excellent paper
-by Rosenthal [Rose88].
-(The current program does more: it also employs the mouse.)
-The clumsiest part is
-<TT>ereshaped</TT>,
-a function with a known name that is called from the event library
-whenever the window is
-reshaped or moved, as is discovered inelegantly but adequately
-by a special case of a mouse message.
-(Simple so-called expose events are not events
-at all in 8&#189;; the layer library takes care of them transparently.)
-The lesson of this program, with deference to Rosenthal, is that if
-the window system is cleanly designed a toolkit should be unnecessary
-for simple tasks.
-</P>
-<H4>Status
-</H4>
-<P>
-As of 1992, 8&#189; is in regular daily use by almost all the 60 people in our
-research center.  Some of those people use it to access Plan 9 itself; others
-use it as a front end to remote
-UNIX
-systems, much as one would use an X terminal.
-</P>
-<P>
-Some things about 8&#189; may change.
-It would be nice if its capabilities were more easily accessible
-from the shell.
-A companion to this paper [Pike91] proposes one way to do this,
-but that does not include any graphics functionality.
-Perhaps a textual version of the
-<TT>/dev/bitblt</TT>
-file is a way to proceed; that would allow, for example,
-<TT>awk</TT>
-programs to draw graphs directly.
-</P>
-<P>
-Can this style of window system be built on other operating systems?
-A major part of the design of 8&#189; depends on its structure as a file server.
-In principle this could be done for any system that supports user processes
-that serve files, such as any system running NFS or AFS [Sun89, Kaza87].
-One requirement, however, is 8&#189;'s need
-to respond to its clients' requests out of order:
-if one client reads
-<TT>/dev/cons</TT>
-in a window with no characters to be read,
-other clients should be able to perform I/O in their windows, or even
-the same window.
-Another constraint is that the 8&#189; files are like devices,
-and must not be cached by the client.
-NFS cannot honor these requirements; AFS may be able to.
-Of course, other interprocess communication mechanisms such as sockets
-could be used as a basis for a window system.  One may even argue that
-X's model fits into this overall scheme.  It may prove easy and worthwhile
-to write a small 8&#189;-like system for commercial
-UNIX
-systems to demonstrate that its merits can be won in systems other than
-Plan 9.
-</P>
-<H4>Conclusion
-</H4>
-<P>
-In conclusion, 8&#189; uses an unusual architecture in
-concert with the file-oriented interprocess communication of Plan 9
-to provide network-based interactive graphics to client programs.
-It demonstrates that even production-quality window systems are not
-inherently large or complicated
-and may be simple to use and to program.
-</P>
-<H4>Acknowledgements
-</H4>
-<P>
-Helpful comments on early drafts of this paper were made by
-Doug Blewett,
-Stu Feldman,
-Chris Fraser,
-Brian Kernighan,
-Dennis Ritchie,
-and Phil Winterbottom.
-8&#189;'s support for color was added by Howard Trickey.
-Many of the ideas leading to 8&#189; were tried out in earlier, sometimes less
-successful, programs.  I would like to thank those users who suffered
-through some of my previous 7&#189; window systems.
-</P>
-<H4>References
-</H4>
-<br>&#32;<br>
-[Duff90] Tom Duff, ``Rc - A Shell for Plan 9 and UNIX systems'', Proc. of the Summer 1990 UKUUG Conf., London, July, 1990, pp. 21-33, reprinted, in a different form, in this volume.
-<br>&#32;<br>
-[Far89] Far too many people, XTERM(1), Massachusetts Institute of Technology, 1989.
-<br>&#32;<br>
-[Gos86] James Gosling and David Rosenthal,
-``A window manager for bitmapped displays and UNIX'', in Methodology of Window Management, edited by F.R.A. Hopgood et al., Springer, 1986.
-<br>&#32;<br>
-[Kaza87] Mike Kazar, ``Synchronization and Caching issues in the Andrew File System'', Tech. Rept. CMU-ITC-058, Information Technology Center, Carnegie Mellon University, June, 1987.
-<br>&#32;<br>
-[Kill84] Tom Killian, ``Processes as Files'', USENIX Summer Conf. Proc., Salt Lake City June, 1984.
-<br>&#32;<br>
-[Pike83] Rob Pike, ``The Blit: A Multiplexed Graphics Terminal'', Bell Labs Tech. J., V63, #8, part 2, pp. 1607-1631.
-<br>&#32;<br>
-[Pike83a] Rob Pike, ``Graphics in Overlapping Bitmap Layers'', Trans. on Graph., Vol 2, #2, 135-160, reprinted in Proc. SIGGRAPH '83, pp. 331-356.
-<br>&#32;<br>
-[Pike87] Rob Pike, ``The Text Editor <TT>sam</TT>'', Softw. - Prac. and Exp., Nov 1987, Vol 17 #11, pp. 813-845, reprinted in this volume.
-<br>&#32;<br>
-[Pike88] Rob Pike, ``Window Systems Should Be Transparent'', Comp. Sys., Summer 1988, Vol 1 #3, pp. 279-296.
-<br>&#32;<br>
-[Pike89] Rob Pike, ``A Concurrent Window System'', Comp. Sys., Spring 1989, Vol 2 #2, pp. 133-153.
-<br>&#32;<br>
-[Pike91] Rob Pike, ``A Minimalist Global User Interface'', USENIX Summer Conf. Proc., Nashville, June, 1991.
-<br>&#32;<br>
-[Pike92]  Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil Winterbottom,
-Operating Systems Review
-Vol 27, #2, Apr 1993, pp. 72-76
-(reprinted from Proceedings of the 5th ACM SIGOPS European Workshop, Mont Saint-Michel, 1992, Paper n&#186; 34, and reprinted in this volume).
-<br>&#32;<br>
-[Pike94] Rob Pike and Ken Thompson, ``Hello World or &#191;ALPHA&#191;&#191;MU&#191;&#191;ALPHA &#191;&#191;&#191;MUEPSILON or &#191;&#191;&#191;&#191;&#191; &#191;&#191;'', USENIX Winter Conf. Proc., San Diego, Jan, 1993, reprinted in this volume.
-<br>&#32;<br>
-[PLR85] Rob Pike, Bart Locanthi and John Reiser, ``Hardware/Software Tradeoffs for Bitmap Graphics on the Blit'', Softw. - Prac. and Exp., Feb 1985, Vol 15 #2, pp. 131-152.
-<br>&#32;<br>
-[Pres90] David L. Presotto and Dennis M. Ritchie, ``Interprocess Communication in the Ninth Edition Unix System'', Softw. - Prac. and Exp., June 1990, Vol 20 #S1, pp. S1/3-S1/17.
-<br>&#32;<br>
-[Rose88] David Rosenthal, ``A Simple X11 Client Program -or- How hard can it really be to write ``Hello, World''?'', USENIX Winter Conf. Proc., Dallas, Jan, 1988, pp. 229-242.
-<br>&#32;<br>
-[Sche86] Robert W. Scheifler and Jim Gettys,
-``The X Window System'',
-ACM Trans. on Graph., Vol 5 #2, pp. 79-109.
-<br>&#32;<br>
-[Sun89] Sun Microsystems, NFS: Network file system protocol specification,
-RFC 1094, Network Information Center, SRI International, March, 1989.
-<br>
-<br>&#32;<br>
-<A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
-</body></html>

+ 0 - 2373
sys/doc/9.html

@@ -1,2373 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<title>
--
-</title>
-<body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
-<center><H1>Plan 9 from Bell Labs
-</H1>
-<DL><DD><I>Rob Pike<br>
-Dave Presotto<br>
-Sean Dorward<br>
-Bob Flandrena<br>
-Ken Thompson<br>
-Howard Trickey<br>
-Phil Winterbottom<br>
-Bell Laboratories, Murray Hill, NJ, 07974
-USA<br>
-</center></I></DL>
-<H4>Motivation
-</H4>
-<P>
-</P>
-<DL>
-<DT><DT>&#32;<DD>
-NOTE:<I> Appeared in a slightly different form in
-Computing Systems,
-Vol 8 #3, Summer 1995, pp. 221-254.
-</I><DT>&#32;<DD></dl>
-<br>
-By the mid 1980's, the trend in computing was
-away from large centralized time-shared computers towards
-networks of smaller, personal machines,
-typically UNIX `workstations'.
-People had grown weary of overloaded, bureaucratic timesharing machines
-and were eager to move to small, self-maintained systems, even if that
-meant a net loss in computing power.
-As microcomputers became faster, even that loss was recovered, and
-this style of computing remains popular today.
-<P>
-In the rush to personal workstations, though, some of their weaknesses
-were overlooked.
-First, the operating system they run, UNIX, is itself an old timesharing system and
-has had trouble adapting to ideas
-born after it.  Graphics and networking were added to UNIX well into
-its lifetime and remain poorly integrated and difficult to administer.
-More important, the early focus on having private machines
-made it difficult for networks of machines to serve as seamlessly as the old
-monolithic timesharing systems.
-Timesharing centralized the management
-and amortization of costs and resources;
-personal computing fractured, democratized, and ultimately amplified
-administrative problems.
-The choice of
-an old timesharing operating system to run those personal machines
-made it difficult to bind things together smoothly.
-</P>
-<P>
-Plan 9 began in the late 1980's as an attempt to have it both
-ways: to build a system that was centrally administered and cost-effective
-using cheap modern microcomputers as its computing elements.
-The idea was to build a time-sharing system out of workstations, but in a novel way.
-Different computers would handle
-different tasks: small, cheap machines in people's offices would serve
-as terminals providing access to large, central, shared resources such as computing
-servers and file servers.  For the central machines, the coming wave of
-shared-memory multiprocessors seemed obvious candidates.
-The philosophy is much like that of the Cambridge
-Distributed System [NeHe82].
-The early catch phrase was to build a UNIX out of a lot of little systems,
-not a system out of a lot of little UNIXes.
-</P>
-<P>
-The problems with UNIX were too deep to fix, but some of its ideas could be
-brought along.  The best was its use of the file system to coordinate
-naming of and access to resources, even those, such as devices, not traditionally
-treated as files.
-For Plan 9, we adopted this idea by designing a network-level protocol, called 9P,
-to enable machines to access files on remote systems.
-Above this, we built a naming
-system that lets people and their computing agents build customized views
-of the resources in the network.
-This is where Plan 9 first began to look different:
-a Plan 9 user builds a private computing environment and recreates it wherever
-desired, rather than doing all computing on a private machine.
-It soon became clear that this model was richer
-than we had foreseen, and the ideas of per-process name spaces
-and file-system-like resources were extended throughout
-the system&#x2014;to processes, graphics, even the network itself.
-</P>
-<P>
-By 1989 the system had become solid enough
-that some of us began using it as our exclusive computing environment.
-This meant bringing along many of the services and applications we had
-used on UNIX.  We used this opportunity to revisit many issues, not just
-kernel-resident ones, that we felt UNIX addressed badly.
-Plan 9 has new compilers,
-languages,
-libraries,
-window systems,
-and many new applications.
-Many of the old tools were dropped, while those brought along have
-been polished or rewritten.
-</P>
-<P>
-Why be so all-encompassing?
-The distinction between operating system, library, and application
-is important to the operating system researcher but uninteresting to the
-user.  What matters is clean functionality.
-By building a complete new system,
-we were able to solve problems where we thought they should be solved.
-For example, there is no real `tty driver' in the kernel; that is the job of the window
-system.
-In the modern world, multi-vendor and multi-architecture computing
-are essential, yet the usual compilers and tools assume the program is being
-built to run locally; we needed to rethink these issues.
-Most important, though, the test of a system is the computing
-environment it provides.
-Producing a more efficient way to run the old UNIX warhorses
-is empty engineering;
-we were more interested in whether the new ideas suggested by
-the architecture of the underlying system encourage a more effective way of working.
-Thus, although Plan 9 provides an emulation environment for
-running POSIX commands, it is a backwater of the system.
-The vast majority
-of system software is developed in the `native' Plan 9 environment.
-</P>
-<P>
-There are benefits to having an all-new system.
-First, our laboratory has a history of building experimental peripheral boards.
-To make it easy to write device drivers,
-we want a system that is available in source form
-(no longer guaranteed with UNIX, even
-in the laboratory in which it was born).
-Also, we want to redistribute our work, which means the software
-must be locally produced.  For example, we could have used some vendors'
-C compilers for our system, but even had we overcome the problems with
-cross-compilation, we would have difficulty
-redistributing the result.
-</P>
-<P>
-This paper serves as an overview of the system.  It discusses the architecture
-from the lowest building blocks to the computing environment seen by users.
-It also serves as an introduction to the rest of the Plan 9 Programmer's Manual,
-which it accompanies.  More detail about topics in this paper
-can be found elsewhere in the manual.
-</center></P>
-<H4>Design
-</H4>
-<P>
-The view of the system is built upon three principles.
-First, resources are named and accessed like files in a hierarchical file system.
-Second, there is a standard protocol, called 9P, for accessing these
-resources.
-Third, the disjoint hierarchies provided by different services are
-joined together into a single private hierarchical file name space.
-The unusual properties of Plan 9 stem from the consistent, aggressive
-application of these principles.
-</P>
-<P>
-A large Plan 9 installation has a number of computers networked
-together, each providing a particular class of service.
-Shared multiprocessor servers provide computing cycles;
-other large machines offer file storage.
-These machines are located in an air-conditioned machine
-room and are connected by high-performance networks.
-Lower bandwidth networks such as Ethernet or ISDN connect these
-servers to office- and home-resident workstations or PCs, called terminals
-in Plan 9 terminology.
-Figure 1 shows the arrangement.
-<DL><DT><DD><TT><PRE>
-<br><img src="network.pic.0.gif"><br>
-</PRE></TT></DL>
-</P>
-<DL>
-<DT><DT>&#32;<DD>
-<I>Figure 1. Structure of a large Plan 9 installation.</I>
-CPU servers and file servers share fast local-area networks,
-while terminals use slower wider-area networks such as Ethernet,
-Datakit, or telephone lines to connect to them.
-Gateway machines, which are just CPU servers connected to multiple
-networks, allow machines on one network to see another.
-<br>&#32;<br>
-</dl>
-<P>
-The modern style of computing offers each user a dedicated workstation or PC.
-Plan 9's approach is different.
-The various machines with screens, keyboards, and mice all provide
-access to the resources of the network, so they are functionally equivalent,
-in the manner of the terminals attached to old timesharing systems.
-When someone uses the system, though,
-the terminal is temporarily personalized by that user.
-Instead of customizing the hardware, Plan 9 offers the ability to customize
-one's view of the system provided by the software.
-That customization is accomplished by giving local, personal names for the
-publicly visible resources in the network.
-Plan 9 provides the mechanism to assemble a personal view of the public
-space with local names for globally accessible resources.
-Since the most important resources of the network are files, the model
-of that view is file-oriented.
-</P>
-<P>
-The client's local name space provides a way to customize the user's
-view of the network.  The services available in the network all export file
-hierarchies.
-Those important to the user are gathered together into
-a custom name space; those of no immediate interest are ignored.
-This is a different style of use from the idea of a `uniform global name space'.
-In Plan 9, there are known names for services and uniform names for
-files exported by those services,
-but the view is entirely local.  As an analogy, consider the difference
-between the phrase `my house' and the precise address of the speaker's
-home.  The latter may be used by anyone but the former is easier to say and
-makes sense when spoken.
-It also changes meaning depending on who says it,
-yet that does not cause confusion.
-Similarly, in Plan 9 the name
-<TT>/dev/cons</TT>
-always refers to the user's terminal and
-<TT>/bin/date</TT>
-the correct version of the date
-command to run,
-but which files those names represent depends on circumstances such as the
-architecture of the machine executing
-<TT>date</TT>.
-Plan 9, then, has local name spaces that obey globally understood
-conventions;
-it is the conventions that guarantee sane behavior in the presence
-of local names.
-</P>
-<P>
-The 9P protocol is structured as a set of transactions that
-send a request from a client to a (local or remote) server and return the result.
-9P controls file systems, not just files:
-it includes procedures to resolve file names and traverse the name
-hierarchy of the file system provided by the server.
-On the other hand,
-the client's name space is held by the client system alone, not on or with the server,
-a distinction from systems such as Sprite [OCDNW88].
-Also, file access is at the level of bytes, not blocks, which distinguishes
-9P from protocols like NFS and RFS.
-A paper by Welch compares Sprite, NFS, and Plan 9's network file system structures [Welc94].
-</P>
-<P>
-This approach was designed with traditional files in mind,
-but can be extended
-to many other resources.
-Plan 9 services that export file hierarchies include I/O devices,
-backup services,
-the window system,
-network interfaces,
-and many others.
-One example is the process file system,
-<TT>/proc</TT>,
-which provides a clean way
-to examine and control running processes.
-Precursor systems had a similar idea [Kill84], but Plan 9 pushes the
-file metaphor much further [PPTTW93].
-The file system model is well-understood, both by system builders and general users,
-so services that present file-like interfaces are easy to build, easy to understand,
-and easy to use.
-Files come with agreed-upon rules for
-protection,
-naming,
-and access both local and remote,
-so services built this way are ready-made for a distributed system.
-(This is a distinction from `object-oriented' models, where these issues
-must be faced anew for every class of object.)
-Examples in the sections that follow illustrate these ideas in action.
-</center></P>
-<H4>The Command-level View
-</H4>
-<P>
-Plan 9 is meant to be used from a machine with a screen running
-the window system.
-It has no notion of `teletype' in the UNIX sense.  The keyboard handling of
-the bare system is rudimentary, but once the window system, 8&frac12; [Pike91],
-is running,
-text can be edited with `cut and paste' operations from a pop-up menu,
-copied between windows, and so on.
-8&frac12; permits editing text from the past, not just on the current input line.
-The text-editing capabilities of 8&frac12; are strong enough to displace
-special features such as history in the shell,
-paging and scrolling,
-and mail editors.
-8&frac12; windows do not support cursor addressing and,
-except for one terminal emulator to simplify connecting to traditional systems,
-there is no cursor-addressing software in Plan 9.
-</P>
-<P>
-Each window is created in a separate name space.
-Adjustments made to the name space in a window do not affect other windows
-or programs, making it safe to experiment with local modifications to the name
-space, for example
-to substitute files from the dump file system when debugging.
-Once the debugging is done, the window can be deleted and all trace of the
-experimental apparatus is gone.
-Similar arguments apply to the private space each window has for environment
-variables, notes (analogous to UNIX signals), etc.
-</P>
-<P>
-Each window is created running an application, such as the shell, with
-standard input and output connected to the editable text of the window.
-Each window also has a private bitmap and multiplexed access to the
-keyboard, mouse, and other graphical resources through files like
-<TT>/dev/mouse</TT>,
-<TT>/dev/bitblt</TT>,
-and
-<TT>/dev/cons</TT>
-(analogous to UNIX's
-<TT>/dev/tty</TT>).
-These files are provided by 8&frac12;, which is implemented as a file server.
-Unlike X windows, where a new application typically creates a new window
-to run in, an 8&frac12; graphics application usually runs in the window where it starts.
-It is possible and efficient for an application to create a new window, but
-that is not the style of the system.
-Again contrasting to X, in which a remote application makes a network
-call to the X server to start running,
-a remote 8&frac12; application sees the
-<TT>mouse</TT>,
-<TT>bitblt</TT>,
-and
-<TT>cons</TT>
-files for the window as usual in
-<TT>/dev</TT>;
-it does not know whether the files are local.
-It just reads and writes them to control the window;
-the network connection is already there and multiplexed.
-</P>
-<P>
-The intended style of use is to run interactive applications such as the window
-system and text editor on the terminal and to run computation- or file-intensive
-applications on remote servers.
-Different windows may be running programs on different machines over
-different networks, but by making the name space equivalent in all windows,
-this is transparent: the same commands and resources are available, with the same names,
-wherever the computation is performed.
-</P>
-<P>
-The command set of Plan 9 is similar to that of UNIX.
-The commands fall into several broad classes.  Some are new programs for
-old jobs: programs like
-<TT>ls</TT>,
-<TT>cat</TT>,
-and
-<TT>who</TT>
-have familiar names and functions but are new, simpler implementations.
-<TT>Who</TT>,
-for example, is a shell script, while
-<TT>ps</TT>
-is just 95 lines of C code.
-Some commands are essentially the same as their UNIX ancestors:
-<TT>awk</TT>,
-<TT>troff</TT>,
-and others have been converted to ANSI C and extended to handle
-Unicode, but are still the familiar tools.
-Some are entirely new programs for old niches: the shell
-<TT>rc</TT>,
-text editor
-<TT>sam</TT>,
-debugger
-<TT>acid</TT>,
-and others
-displace the better-known UNIX tools with similar jobs.
-Finally, about half the commands are new.
-</P>
-<P>
-Compatibility was not a requirement for the system.
-Where the old commands or notation seemed good enough, we
-kept them.  When they didn't, we replaced them.
-</center></P>
-<H4>The File Server
-</H4>
-<P>
-A central file server stores permanent files and presents them to the network
-as a file hierarchy exported using 9P.
-The server is a stand-alone system, accessible only over the network,
-designed to do its one job well.
-It runs no user processes, only a fixed set of routines compiled into the
-boot image.
-Rather than a set of disks or separate file systems,
-the main hierarchy exported by the server is a single
-tree, representing files on many disks.
-That hierarchy is
-shared by many users over a wide area on a variety of networks.
-Other file trees exported by
-the server include
-special-purpose systems such as temporary storage and, as explained
-below, a backup service.
-</P>
-<P>
-The file server has three levels of storage.
-The central server in our installation has
-about 100 megabytes of memory buffers,
-27 gigabytes of magnetic disks,
-and 350 gigabytes of
-bulk storage in a write-once-read-many (WORM) jukebox.
-The disk is a cache for the WORM and the memory is a cache for the disk;
-each is much faster, and sees about an order of magnitude more traffic,
-than the level it caches.
-The addressable data in the file system can be larger than the size of the
-magnetic disks, because they are only a cache;
-our main file server has about 40 gigabytes of active storage.
-</P>
-<P>
-The most unusual feature of the file server
-comes from its use of a WORM device for
-stable storage.
-Every morning at 5 o'clock, a
-<I>dump</I>
-of the file system occurs automatically.
-The file system is frozen and
-all blocks modified since the last dump
-are queued to be written to the WORM.
-Once the blocks are queued,
-service is restored and
-the read-only root of the dumped
-file system appears in a
-hierarchy of all dumps ever taken, named by its date.
-For example, the directory
-<TT>/n/dump/1995/0315</TT>
-is the root directory of an image of the file system
-as it appeared in the early morning of March 15, 1995.
-It takes a few minutes to queue the blocks,
-but the process to copy blocks to the WORM, which runs in the background, may take hours.
-</P>
-<P>
-There are two ways the dump file system is used.
-The first is by the users themselves, who can browse the
-dump file system directly or attach pieces of
-it to their name space.
-For example, to track down a bug,
-it is straightforward to try the compiler from three months ago
-or to link a program with yesterday's library.
-With daily snapshots of all files,
-it is easy to find when a particular change was
-made or what changes were made on a particular date.
-People feel free to make large speculative changes
-to files in the knowledge that they can be backed
-out with a single
-copy command.
-There is no backup system as such;
-instead, because the dump
-is in the file name space, 
-backup problems can be solved with
-standard tools
-such as
-<TT>cp</TT>,
-<TT>ls</TT>,
-<TT>grep</TT>,
-and
-<TT>diff</TT>.
-</P>
-<P>
-The other (very rare) use is complete system backup.
-In the event of disaster,
-the active file system can be initialized from any dump by clearing the
-disk cache and setting the root of
-the active file system to be a copy
-of the dumped root.
-Although easy to do, this is not to be taken lightly:
-besides losing any change made after the date of the dump, this recovery method
-results in a very slow system.
-The cache must be reloaded from WORM, which is much
-slower than magnetic disks.
-The file system takes a few days to reload the working
-set and regain its full performance.
-</P>
-<P>
-Access permissions of files in the dump are the same
-as they were when the dump was made.
-Normal utilities have normal
-permissions in the dump without any special arrangement.
-The dump file system is read-only, though,
-which means that files in the dump cannot be written regardless of their permission bits;
-in fact, since directories are part of the read-only structure,
-even the permissions cannot be changed.
-</P>
-<P>
-Once a file is written to WORM, it cannot be removed,
-so our users never see
-``please clean up your files''
-messages and there is no
-<TT>df</TT>
-command.
-We regard the WORM jukebox as an unlimited resource.
-The only issue is how long it will take to fill.
-Our WORM has served a community of about 50 users
-for five years and has absorbed daily dumps, consuming a total of
-65% of the storage in the jukebox.
-In that time, the manufacturer has improved the technology,
-doubling the capacity of the individual disks.
-If we were to upgrade to the new media,
-we would have more free space than in the original empty jukebox.
-Technology has created storage faster than we can use it.
-</center></P>
-<H4>Unusual file servers
-</H4>
-<P>
-Plan 9 is characterized by a variety of servers that offer
-a file-like interface to unusual services.
-Many of these are implemented by user-level processes, although the distinction
-is unimportant to their clients; whether a service is provided by the kernel,
-a user process, or a remote server is irrelevant to the way it is used.
-There are dozens of such servers; in this section we present three representative ones.
-</P>
-<P>
-Perhaps the most remarkable file server in Plan 9 is 8&frac12;, the window system.
-It is discussed at length elsewhere [Pike91], but deserves a brief explanation here.
-8&frac12; provides two interfaces: to the user seated at the terminal, it offers a traditional
-style of interaction with multiple windows, each running an application, all controlled
-by a mouse and keyboard.
-To the client programs, the view is also fairly traditional:
-programs running in a window see a set of files in
-<TT>/dev</TT>
-with names like
-<TT>mouse</TT>,
-<TT>screen</TT>,
-and
-<TT>cons</TT>.
-Programs that want to print text to their window write to
-<TT>/dev/cons</TT>;
-to read the mouse, they read
-<TT>/dev/mouse</TT>.
-In the Plan 9 style, bitmap graphics is implemented by providing a file
-<TT>/dev/bitblt</TT>
-on which clients write encoded messages to execute graphical operations such as
-<TT>bitblt</TT>
-(RasterOp).
-What is unusual is how this is done:
-8&frac12; is a file server, serving the files in
-<TT>/dev</TT>
-to the clients running in each window.
-Although every window looks the same to its client,
-each window has a distinct set of files in
-<TT>/dev</TT>.
-8&frac12; multiplexes its clients' access to the resources of the terminal
-by serving multiple sets of files.  Each client is given a private name space
-with a
-<I>different</I>
-set of files that behave the same as in all other windows.
-There are many advantages to this structure.
-One is that 8&frac12; serves the same files it needs for its own implementation&#x2014;it
-multiplexes its own interface&#x2014;so it may be run, recursively, as a client of itself.
-Also, consider the implementation of
-<TT>/dev/tty</TT>
-in UNIX, which requires special code in the kernel to redirect
-<TT>open</TT>
-calls to the appropriate device.
-Instead, in 8&frac12; the equivalent service falls out
-automatically: 8&frac12; serves
-<TT>/dev/cons</TT>
-as its basic function; there is nothing extra to do.
-When a program wants to
-read from the keyboard, it opens
-<TT>/dev/cons</TT>,
-but it is a private file, not a shared one with special properties.
-Again, local name spaces make this possible; conventions about the consistency of
-the files within them make it natural.
-</P>
-<P>
-8&frac12; has a unique feature made possible by its design.
-Because it is implemented as a file server,
-it has the power to postpone answering read requests for a particular window.
-This behavior is toggled by a reserved key on the keyboard.
-Toggling once suspends client reads from the window;
-toggling again resumes normal reads, which absorb whatever text has been prepared,
-one line at a time.
-This allows the user to edit multi-line input text on the screen before the application sees it,
-obviating the need to invoke a separate editor to prepare text such as mail
-messages.
-A related property is that reads are answered directly from the
-data structure defining the text on the display: text may be edited until
-its final newline makes the prepared line of text readable by the client.
-Even then, until the line is read, the text the client will read can be changed.
-For example, after typing
-<DL><DT><DD><TT><PRE>
-% make
-rm *
-</PRE></TT></DL>
-to the shell, the user can backspace over the final newline at any time until
-<TT>make</TT>
-finishes, holding off execution of the
-<TT>rm</TT>
-command, or even point with the mouse
-before the
-<TT>rm</TT>
-and type another command to be executed first.
-</P>
-<P>
-There is no
-<TT>ftp</TT>
-command in Plan 9.  Instead, a user-level file server called
-<TT>ftpfs</TT>
-dials the FTP site, logs in on behalf of the user, and uses the FTP protocol
-to examine files in the remote directory.
-To the local user, it offers a file hierarchy, attached to
-<TT>/n/ftp</TT>
-in the local name space, mirroring the contents of the FTP site.
-In other words, it translates the FTP protocol into 9P to offer Plan 9 access to FTP sites.
-The implementation is tricky;
-<TT>ftpfs</TT>
-must do some sophisticated caching for efficiency and
-use heuristics to decode remote directory information.
-But the result is worthwhile:
-all the local file management tools such as
-<TT>cp</TT>,
-<TT>grep</TT>,
-<TT>diff</TT>,
-and of course
-<TT>ls</TT>
-are available to FTP-served files exactly as if they were local files.
-Other systems such as Jade and Prospero
-have exploited the same opportunity [Rao81, Neu92],
-but because of local name spaces and the simplicity of implementing 9P,
-this approach
-fits more naturally into Plan 9 than into other environments.
-</P>
-<P>
-One server,
-<TT>exportfs</TT>,
-is a user process that takes a portion of its own name space and
-makes it available to other processes by
-translating 9P requests into system calls to the Plan 9 kernel.
-The file hierarchy it exports may contain files from multiple servers.
-<TT>Exportfs</TT>
-is usually run as a remote server
-started by a local program,
-either
-<TT>import</TT>
-or
-<TT>cpu</TT>.
-<TT>Import</TT>
-makes a network call to the remote machine, starts
-<TT>exportfs</TT>
-there, and attaches its 9P connection to the local name space.  For example,
-<DL><DT><DD><TT><PRE>
-import helix /net
-</PRE></TT></DL>
-makes Helix's network interfaces visible in the local
-<TT>/net</TT>
-directory.  Helix is a central server and
-has many network interfaces, so this permits a machine with one network to
-access to any of Helix's networks.  After such an import, the local
-machine may make calls on any of the networks connected to Helix.
-Another example is
-<DL><DT><DD><TT><PRE>
-import helix /proc
-</PRE></TT></DL>
-which makes Helix's processes visible in the local
-<TT>/proc</TT>,
-permitting local debuggers to examine remote processes.
-</P>
-<P>
-The
-<TT>cpu</TT>
-command connects the local terminal to a remote
-CPU server.
-It works in the opposite direction to
-<TT>import</TT>:
-after calling the server, it starts a
-<I>local</I>
-<TT>exportfs</TT>
-and mounts it in the name space of a process, typically a newly created shell, on the
-server.
-It then rearranges the name space
-to make local device files (such as those served by
-the terminal's window system) visible in the server's
-<TT>/dev</TT>
-directory.
-The effect of running a
-<TT>cpu</TT>
-command is therefore to start a shell on a fast machine, one more tightly
-coupled to the file server,
-with a name space analogous
-to the local one.
-All local device files are visible remotely, so remote applications have full
-access to local services such as bitmap graphics,
-<TT>/dev/cons</TT>,
-and so on.
-This is not the same as
-<TT>rlogin</TT>,
-which does nothing to reproduce the local name space on the remote system,
-nor is it the same as
-file sharing with, say, NFS, which can achieve some name space equivalence but
-not the combination of access to local hardware devices, remote files, and remote
-CPU resources.
-The
-<TT>cpu</TT>
-command is a uniquely transparent mechanism.
-For example, it is reasonable
-to start a window system in a window running a
-<TT>cpu</TT>
-command; all windows created there automatically start processes on the CPU server.
-</center></P>
-<H4>Configurability and administration
-</H4>
-<P>
-The uniform interconnection of components in Plan 9 makes it possible to configure
-a Plan 9 installation many different ways.
-A single laptop PC can function as a stand-alone Plan 9 system;
-at the other extreme, our setup has central multiprocessor CPU
-servers and file servers and scores of terminals ranging from small PCs to
-high-end graphics workstations.
-It is such large installations that best represent how Plan 9 operates.
-</P>
-<P>
-The system software is portable and the same
-operating system runs on all hardware.
-Except for performance, the appearance of the system on, say,
-an SGI workstation is the same
-as on a laptop.
-Since computing and file services are centralized, and terminals have
-no permanent file storage, all terminals are functionally identical.
-In this way, Plan 9 has one of the good properties of old timesharing systems, where
-a user could sit in front of any machine and see the same system.  In the modern
-workstation community, machines tend to be owned by people who customize them
-by storing private information on local disk.
-We reject this style of use,
-although the system itself can be used this way.
-In our group, we have a laboratory with many public-access machines&#x2014;a terminal
-room&#x2014;and a user may sit down at any one of them and work.
-</P>
-<P>
-Central file servers centralize not just the files, but also their administration
-and maintenance.
-In fact, one server is the main server, holding all system files; other servers provide
-extra storage or are available for debugging and other special uses, but the system
-software resides on one machine.
-This means that each program
-has a single copy of the binary for each architecture, so it is
-trivial to install updates and bug fixes.
-There is also a single user database; there is no need to synchronize distinct
-<TT>/etc/passwd</TT>
-files.
-On the other hand, depending on a single central server does limit the size of an installation.
-</P>
-<P>
-Another example of the power of centralized file service
-is the way Plan 9 administers network information.
-On the central server there is a directory,
-<TT>/lib/ndb</TT>,
-that contains all the information necessary to administer the local Ethernet and
-other networks.
-All the machines use the same database to talk to the network; there is no
-need to manage a distributed naming system or keep parallel files up to date.
-To install a new machine on the local Ethernet, choose a
-name and IP address and add these to a single file in
-<TT>/lib/ndb</TT>;
-all the machines in the installation will be able to talk to it immediately.
-To start running, plug the machine into the network, turn it on, and use BOOTP
-and TFTP to load the kernel.
-All else is automatic.
-</P>
-<P>
-Finally,
-the automated dump file system frees all users from the need to maintain
-their systems, while providing easy access to backup files without
-tapes, special commands, or the involvement of support staff.
-It is difficult to overstate the improvement in lifestyle afforded by this service.
-</P>
-<P>
-Plan 9 runs on a variety of hardware without
-constraining how to configure an installation.
-In our laboratory, we
-chose to use central servers because they amortize costs and administration.
-A sign that this is a good decision is that our cheap
-terminals remain comfortable places
-to work for about five years, much longer than workstations that must provide
-the complete computing environment.
-We do, however, upgrade the central machines, so
-the computation available from even old Plan 9 terminals improves with time.
-The money saved by avoiding regular upgrades of terminals
-is instead spent on the newest, fastest multiprocessor servers.
-We estimate this costs about half the money of networked workstations
-yet provides general access to more powerful machines.
-</center></P>
-<H4>C Programming
-</H4>
-<P>
-Plan 9 utilities are written in several languages.
-Some are scripts for the shell,
-<TT>rc</TT>
-[Duff90]; a handful
-are written in a new C-like concurrent language called Alef [Wint95], described below.
-The great majority, though, are written in a dialect of ANSI C [ANSIC].
-Of these, most are entirely new programs, but some
-originate in pre-ANSI C code
-from our research UNIX system [UNIX85].
-These have been updated to ANSI C
-and reworked for portability and cleanliness.
-</P>
-<P>
-The Plan 9 C dialect has some minor extensions,
-described elsewhere [Pike95], and a few major restrictions.
-The most important restriction is that the compiler demands that
-all function definitions have ANSI prototypes
-and all function calls appear in the scope of a prototyped declaration
-of the function.
-As a stylistic rule,
-the prototyped declaration is placed in a header file
-included by all files that call the function.
-Each system library has an associated header file, declaring all
-functions in that library.
-For example, the standard Plan 9 library is called
-<TT>libc</TT>,
-so all C source files include
-<TT>&lt;libc.h&gt;</TT>.
-These rules guarantee that all functions
-are called with arguments having the expected types &#x2014; something
-that was not true with pre-ANSI C programs.
-</P>
-<P>
-Another restriction is that the C compilers accept only a subset of the
-preprocessor directives required by ANSI.
-The main omission is
-<TT>#if</TT>,
-since we believe it
-is never necessary and often abused.
-Also, its effect is
-better achieved by other means.
-For instance, an
-<TT>#if</TT>
-used to toggle a feature at compile time can be written
-as a regular
-<TT>if</TT>
-statement, relying on compile-time constant folding and
-dead code elimination to discard object code.
-</P>
-<P>
-Conditional compilation, even with
-<TT>#ifdef</TT>,
-is used sparingly in Plan 9.
-The only architecture-dependent
-<TT>#ifdefs</TT>
-in the system are in low-level routines in the graphics library.
-Instead, we avoid such dependencies or, when necessary, isolate
-them in separate source files or libraries.
-Besides making code hard to read,
-<TT>#ifdefs</TT>
-make it impossible to know what source is compiled into the binary
-or whether source protected by them will compile or work properly.
-They make it harder to maintain software.
-</P>
-<P>
-The standard Plan 9 library overlaps much of
-ANSI C and POSIX [POSIX], but diverges
-when appropriate to Plan 9's goals or implementation.
-When the semantics of a function
-change, we also change the name.
-For instance, instead of UNIX's
-<TT>creat</TT>,
-Plan 9 has a
-<TT>create</TT>
-function that takes three arguments,
-the original two plus a third that, like the second
-argument of
-<TT>open</TT>,
-defines whether the returned file descriptor is to be opened for reading,
-writing, or both.
-This design was forced by the way 9P implements creation,
-but it also simplifies the common use of
-<TT>create</TT>
-to initialize a temporary file.
-</P>
-<P>
-Another departure from ANSI C is that Plan 9 uses a 16-bit character set
-called Unicode [ISO10646, Unicode].
-Although we stopped short of full internationalization,
-Plan 9 treats the representation
-of all major languages uniformly throughout all its
-software.
-To simplify the exchange of text between programs, the characters are packed into
-a byte stream by an encoding we designed, called UTF-8,
-which is now
-becoming accepted as a standard [FSSUTF].
-It has several attractive properties,
-including byte-order independence,
-backwards compatibility with ASCII,
-and ease of implementation.
-</P>
-<P>
-There are many problems in adapting existing software to a large
-character set with an encoding that represents characters with
-a variable number of bytes.
-ANSI C addresses some of the issues but
-falls short of
-solving them all.
-It does not pick a character set encoding and does not
-define all the necessary I/O library routines.
-Furthermore, the functions it
-<I>does</I>
-define have engineering problems.
-Since the standard left too many problems unsolved,
-we decided to build our own interface.
-A separate paper has the details [Pike93].
-</P>
-<P>
-A small class of Plan 9 programs do not follow the conventions
-discussed in this section.
-These are programs imported from and maintained by
-the UNIX community;
-<TT>tex</TT>
-is a representative example.
-To avoid reconverting such programs every time a new version
-is released,
-we built a porting environment, called the ANSI C/POSIX Environment, or APE [Tric95].
-APE comprises separate include files, libraries, and commands,
-conforming as much as possible to the strict ANSI C and base-level
-POSIX specifications.
-To port network-based software such as X Windows, it was necessary to add
-some extensions to those
-specifications, such as the BSD networking functions.
-</center></P>
-<H4>Portability and Compilation
-</H4>
-<P>
-Plan 9 is portable across a variety of processor architectures.
-Within a single computing session, it is common to use
-several architectures: perhaps the window system running on
-an Intel processor connected to a MIPS-based CPU server with files
-resident on a SPARC system.
-For this heterogeneity to be transparent, there must be conventions
-about data interchange between programs; for software maintenance
-to be straightforward, there must be conventions about cross-architecture
-compilation.
-</P>
-<P>
-To avoid byte order problems,
-data is communicated between programs as text whenever practical.
-Sometimes, though, the amount of data is high enough that a binary
-format is necessary;
-such data is communicated as a byte stream with a pre-defined encoding
-for multi-byte values.
-In the rare cases where a format
-is complex enough to be defined by a data structure,
-the structure is never
-communicated as a unit; instead, it is decomposed into
-individual fields, encoded as an ordered byte stream, and then
-reassembled by the recipient.
-These conventions affect data
-ranging from kernel or application program state information to object file
-intermediates generated by the compiler.
-</P>
-<P>
-Programs, including the kernel, often present their data
-through a file system interface,
-an access mechanism that is inherently portable.
-For example, the system clock is represented by a decimal number in the file
-<TT>/dev/time</TT>;
-the
-<TT>time</TT>
-library function (there is no
-<TT>time</TT>
-system call) reads the file and converts it to binary.
-Similarly, instead of encoding the state of an application
-process in a series of flags and bits in private memory,
-the kernel
-presents a text string in the file named
-<TT>status</TT>
-in the 
-<TT>/proc</TT>
-file system associated with each process.
-The Plan 9
-<TT>ps</TT>
-command is trivial: it prints the contents of
-the desired status files after some minor reformatting; moreover, after
-<DL><DT><DD><TT><PRE>
-import helix /proc
-</PRE></TT></DL>
-a local
-<TT>ps</TT>
-command reports on the status of Helix's processes.
-</P>
-<P>
-Each supported architecture has its own compilers and loader.
-The C and Alef compilers produce intermediate files that
-are portably encoded; the contents
-are unique to the target architecture but the format of the
-file is independent of compiling processor type.
-When a compiler for a given architecture is compiled on
-another type of processor and then used to compile a program
-there,
-the intermediate produced on
-the new architecture is identical to the intermediate
-produced on the native processor.  From the compiler's
-point of view, every compilation is a cross-compilation.
-</P>
-<P>
-Although each architecture's loader accepts only intermediate files produced
-by compilers for that architecture,
-such files could have been generated by a compiler executing
-on any type of processor.
-For instance, it is possible to run
-the MIPS compiler on a 486, then use the MIPS loader on a
-SPARC to produce a MIPS executable.
-</P>
-<P>
-Since Plan 9 runs on a variety of architectures, even in a single installation,
-distinguishing the compilers and intermediate names
-simplifies multi-architecture
-development from a single source tree.
-The compilers and the loader for each architecture are
-uniquely named; there is no
-<TT>cc</TT>
-command.
-The names are derived by concatenating a code letter
-associated with the target architecture with the name of the
-compiler or loader.  For example, the letter `8' is
-the code letter for Intel
-<I>x</I>86
-processors; the C compiler is named
-<TT>8c</TT>,
-the Alef compiler
-<TT>8al</TT>,
-and the loader is called
-<TT>8l</TT>.
-Similarly, the compiler intermediate files are suffixed
-<TT>.8</TT>,
-not
-<TT>.o</TT>.
-</P>
-<P>
-The Plan 9
-build program
-<TT>mk</TT>,
-a relative of
-<TT>make</TT>,
-reads the names of the current and target
-architectures from environment variables called
-<TT></TT><I>cputype</I>
-and
-</TT><TT></TT><TT>objtype</TT>.
-By default the current processor is the target, but setting
-<TT></TT><I>objtype</I>
-to the name of another architecture
-before invoking
-</TT><TT>mk</TT>
-results in a cross-build:
-<DL><DT><DD><TT><PRE>
-% objtype=sparc mk
-</PRE></TT></DL>
-builds a program for the SPARC architecture regardless of the executing machine.
-The value of
-</TT><TT></TT><TT>objtype</TT>
-selects a
-file of architecture-dependent variable definitions
-that configures the build to use the appropriate compilers and loader.
-Although simple-minded, this technique works well in practice:
-all applications in Plan 9 are built from a single source tree
-and it is possible to build the various architectures in parallel without conflict.
-</center></P>
-<H4>Parallel programming
-</H4>
-<P>
-Plan 9's support for parallel programming has two aspects.
-First, the kernel provides
-a simple process model and a few carefully designed system calls for
-synchronization and sharing.
-Second, a new parallel programming language called Alef
-supports concurrent programming.
-Although it is possible to write parallel
-programs in C, Alef is the parallel language of choice.
-</P>
-<P>
-There is a trend in new operating systems to implement two
-classes of processes: normal UNIX-style processes and light-weight
-kernel threads.
-Instead, Plan 9 provides a single class of process but allows fine control of the
-sharing of a process's resources such as memory and file descriptors.
-A single class of process is a
-feasible approach in Plan 9 because the kernel has an efficient system
-call interface and cheap process creation and scheduling.
-</P>
-<P>
-Parallel programs have three basic requirements:
-management of resources shared between processes,
-an interface to the scheduler,
-and fine-grain process synchronization using spin locks.
-On Plan 9,
-new processes are created using the
-<TT>rfork</TT>
-system call.
-<TT>Rfork</TT>
-takes a single argument,
-a bit vector that specifies
-which of the parent process's resources should be shared,
-copied, or created anew
-in the child.
-The resources controlled by
-<TT>rfork</TT>
-include the name space,
-the environment,
-the file descriptor table,
-memory segments,
-and notes (Plan 9's analog of UNIX signals).
-One of the bits controls whether the
-<TT>rfork</TT>
-call will create a new process; if the bit is off, the resulting
-modification to the resources occurs in the process making the call.
-For example, a process calls
-<TT>rfork(RFNAMEG)</TT>
-to disconnect its name space from its parent's.
-Alef uses a
-fine-grained fork in which all the resources, including
-memory, are shared between parent
-and child, analogous to creating a kernel thread in many systems.
-</P>
-<P>
-An indication that
-<TT>rfork</TT>
-is the right model is the variety of ways it is used.
-Other than the canonical use in the library routine
-<TT>fork</TT>,
-it is hard to find two calls to
-<TT>rfork</TT>
-with the same bits set; programs
-use it to create many different forms of sharing and resource allocation.
-A system with just two types of processes&#x2014;regular processes and threads&#x2014;could
-not handle this variety.
-</P>
-<P>
-There are two ways to share memory.
-First, a flag to
-<TT>rfork</TT>
-causes all the memory segments of the parent to be shared with the child
-(except the stack, which is
-forked copy-on-write regardless).
-Alternatively, a new segment of memory may be
-attached using the
-<TT>segattach</TT>
-system call; such a segment
-will always be shared between parent and child.
-</P>
-<P>
-The
-<TT>rendezvous</TT>
-system call provides a way for processes to synchronize.
-Alef uses it to implement communication channels,
-queuing locks,
-multiple reader/writer locks, and
-the sleep and wakeup mechanism.
-<TT>Rendezvous</TT>
-takes two arguments, a tag and a value.
-When a process calls
-<TT>rendezvous</TT>
-with a tag it sleeps until another process
-presents a matching tag.
-When a pair of tags match, the values are exchanged
-between the two processes and both
-<TT>rendezvous</TT>
-calls return.
-This primitive is sufficient to implement the full set of synchronization routines.
-</P>
-<P>
-Finally, spin locks are provided by
-an architecture-dependent library at user level.
-Most processors provide atomic test and set instructions that
-can be used to implement locks.
-A notable exception is the MIPS R3000, so the SGI
-Power series multiprocessors have special lock hardware on the bus.
-User processes gain access to the lock hardware
-by mapping pages of hardware locks
-into their address space using the
-<TT>segattach</TT>
-system call.
-</P>
-<P>
-A Plan 9 process in a system call will block regardless of its `weight'.
-This means that when a program wishes to read from a slow
-device without blocking the entire calculation, it must fork a process to do
-the read for it.  The solution is to start a satellite
-process that does the I/O and delivers the answer to the main program
-through shared memory or perhaps a pipe.
-This sounds onerous but works easily and efficiently in practice; in fact,
-most interactive Plan 9 applications, even relatively ordinary ones written
-in C, such as
-the text editor Sam [Pike87], run as multiprocess programs.
-</P>
-<P>
-The kernel support for parallel programming in Plan 9 is a few hundred lines
-of portable code; a handful of simple primitives enable the problems to be handled
-cleanly at user level.
-Although the primitives work fine from C,
-they are particularly expressive from within Alef.
-The creation
-and management of slave I/O processes can be written in a few lines of Alef,
-providing the foundation for a consistent means of multiplexing
-data flows between arbitrary processes.
-Moreover, implementing it in a language rather than in the kernel
-ensures consistent semantics between all devices
-and provides a more general multiplexing primitive.
-Compare this to the UNIX
-<TT>select</TT>
-system call:
-<TT>select</TT>
-applies only to a restricted set of devices,
-legislates a style of multiprogramming in the kernel,
-does not extend across networks,
-is difficult to implement, and is hard to use.
-</P>
-<P>
-Another reason
-parallel programming is important in Plan 9 is that
-multi-threaded user-level file servers are the preferred way
-to implement services.
-Examples of such servers include the programming environment
-Acme [Pike94],
-the name space exporting tool
-<TT>exportfs</TT>
-[PPTTW93],
-the HTTP daemon,
-and the network name servers
-<TT>cs</TT>
-and
-<TT>dns</TT>
-[PrWi93].
-Complex applications such as Acme prove that
-careful operating system support can reduce the difficulty of writing
-multi-threaded applications without moving threading and
-synchronization primitives into the kernel.
-</center></P>
-<H4>Implementation of Name Spaces
-</H4>
-<P>
-User processes construct name spaces using three system calls:
-<TT>mount</TT>,
-<TT>bind</TT>,
-and
-<TT>unmount</TT>.
-The
-<TT>mount</TT>
-system call attaches a tree served by a file server to
-the current name space.  Before calling
-<TT>mount</TT>,
-the client must (by outside means) acquire a connection to the server in
-the form of a file descriptor that may be written and read to transmit 9P messages.
-That file descriptor represents a pipe or network connection.
-</P>
-<P>
-The
-<TT>mount</TT>
-call attaches a new hierarchy to the existing name space.
-The
-<TT>bind</TT>
-system call, on the other hand, duplicates some piece of existing name space at
-another point in the name space.
-The
-<TT>unmount</TT>
-system call allows components to be removed.
-</P>
-<P>
-Using
-either
-<TT>bind</TT>
-or
-<TT>mount</TT>,
-multiple directories may be stacked at a single point in the name space.
-In Plan 9 terminology, this is a
-<I>union</I>
-directory and behaves like the concatenation of the constituent directories.
-A flag argument to
-<TT>bind</TT>
-and
-<TT>mount</TT>
-specifies the position of a new directory in the union,
-permitting new elements
-to be added either at the front or rear of the union or to replace it entirely.
-When a file lookup is performed in a union directory, each component
-of the union is searched in turn and the first match taken; likewise,
-when a union directory is read, the contents of each of the component directories
-is read in turn.
-Union directories are one of the most widely used organizational features
-of the Plan 9 name space.
-For instance, the directory
-<TT>/bin</TT>
-is built as a union of
-<TT>/</TT><I>cputype/bin</I>
-(program binaries),
-</TT><TT>/rc/bin</TT>
-(shell scripts),
-and perhaps more directories provided by the user.
-This construction makes the shell
-</TT><TT></TT><TT>PATH</TT>
-variable unnecessary.
-</P>
-<P>
-One question raised by union directories
-is which element of the union receives a newly created file.
-After several designs, we decided on the following.
-By default, directories in unions do not accept new files, although the
-<TT>create</TT>
-system call applied to an existing file succeeds normally.
-When a directory is added to the union, a flag to
-<TT>bind</TT>
-or
-<TT>mount</TT>
-enables create permission (a property of the name space) in that directory.
-When a file is being created with a new name in a union, it is created in the
-first directory of the union with create permission; if that creation fails,
-the entire
-<TT>create</TT>
-fails.
-This scheme enables the common use of placing a private directory anywhere
-in a union of public ones,
-while allowing creation only in the private directory.
-</P>
-<P>
-By convention, kernel device file systems
-are bound into the
-<TT>/dev</TT>
-directory, but to bootstrap the name space building process it is
-necessary to have a notation that permits
-direct access to the devices without an existing name space.
-The root directory
-of the tree served by a device driver can be accessed using the syntax
-<TT>#</TT><I>c</I>,
-where
-<I>c</I>
-is a unique character (typically a letter) identifying the
-<I>type</I>
-of the device.
-Simple device drivers serve a single level directory containing a few files.
-As an example,
-each serial port is represented by a data and a control file:
-<DL><DT><DD><TT><PRE>
-% bind -a '#t' /dev
-% cd /dev
-% ls -l eia*
---rw-rw-rw- t 0 bootes bootes 0 Feb 24 21:14 eia1
---rw-rw-rw- t 0 bootes bootes 0 Feb 24 21:14 eia1ctl
---rw-rw-rw- t 0 bootes bootes 0 Feb 24 21:14 eia2
---rw-rw-rw- t 0 bootes bootes 0 Feb 24 21:14 eia2ctl
-</PRE></TT></DL>
-The
-<TT>bind</TT>
-program is an encapsulation of the
-<TT>bind</TT>
-system call; its
-<TT>-a</TT>
-flag positions the new directory at the end of the union.
-The data files
-<TT>eia1</TT>
-and
-<TT>eia2</TT>
-may be read and written to communicate over the serial line.
-Instead of using special operations on these files to control the devices,
-commands written to the files
-<TT>eia1ctl</TT>
-and
-<TT>eia2ctl</TT>
-control the corresponding device;
-for example,
-writing the text string
-<TT>b1200</TT>
-to
-<TT>/dev/eia1ctl</TT>
-sets the speed of that line to 1200 baud.
-Compare this to the UNIX
-<TT>ioctl</TT>
-system call: in Plan 9, devices are controlled by textual messages,
-free of byte order problems, with clear semantics for reading and writing.
-It is common to configure or debug devices using shell scripts.
-</P>
-<P>
-It is the universal use of the 9P protocol that
-connects Plan 9's components together to form a
-distributed system.
-Rather than inventing a unique protocol for each
-service such as
-<TT>rlogin</TT>,
-FTP, TFTP, and X windows,
-Plan 9 implements services
-in terms of operations on file objects,
-and then uses a single, well-documented protocol to exchange information between
-computers.
-Unlike NFS, 9P treats files as a sequence of bytes rather than blocks.
-Also unlike NFS, 9P is stateful: clients perform
-remote procedure calls to establish pointers to objects in the remote
-file server.
-These pointers are called file identifiers or
-<I>fids</I>.
-All operations on files supply a fid to identify an object in the remote file system.
-</P>
-<P>
-The 9P protocol defines 17 messages, providing
-means to authenticate users, navigate fids around
-a file system hierarchy, copy fids, perform I/O, change file attributes, 
-and create and delete files.
-Its complete specification is in Section 5 of the Programmer's Manual [9man].
-Here is the procedure to gain access to the name hierarchy supplied by a server.
-A file server connection is established via a pipe or network connection.
-An initial
-<TT>session</TT>
-message performs a bilateral authentication between client and server.
-An
-<TT>attach</TT>
-message then connects a fid suggested by the client to the root of the server file
-tree.
-The
-<TT>attach</TT>
-message includes the identity of the user performing the attach; henceforth all
-fids derived from the root fid will have permissions associated with
-that user.
-Multiple users may share the connection, but each must perform an attach to
-establish his or her identity.
-</P>
-<P>
-The
-<TT>walk</TT>
-message moves a fid through a single level of the file system hierarchy.
-The
-<TT>clone</TT>
-message takes an established fid and produces a copy that points
-to the same file as the original.
-Its purpose is to enable walking to a file in a directory without losing the fid</